Moving the shared library build files into submodule

[stcui007]

The goal here is to make the submodule more self contained and less affected by changes in ngen framework.

Additions

CMakeLists.txt petbmi.pc.in

Removals

-

Changes

INSTALL.md

Testing

1. Build the shared library locally.

Screenshots

Notes

-

Todos

-

Checklist

• [x ] PR has an informative and human-readable title
• [x ] Changes are limited to a single goal (no scope creep)
• [x ] Code can be automatically merged (no conflicts)
• [x ] Code follows project standards (link if applicable)
• [ ] Passes all existing automated tests
• [x ] Any change in functionality is tested
• [x ] New functions are documented (with a description, list of inputs, and expected output)
• [ ] Placeholder code is flagged / future todos are captured in comments
• [ ] Visually tested in supported browsers and devices (see checklist below :point_down:)
• [ ] Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• [x ] Reviewers requested with the Reviewers tool :arrow_right:

Testing checklist

Target Environment support

• [ ] Windows
• [x ] Linux
• [ ] Browser

Accessibility

• [x] Keyboard friendly
• [ ] Screen reader friendly

Other

• [x ] Is useable without CSS
• [ x] Is useable without JS
• [ ] Flexible from small to large screens
• [x ] No linting errors or warnings
• [ ] JavaScript tests are passing

[SnowHydrology]

@madMatchstick I don't have a strong opinion on this. We can still build PET in standalone mode. However, I agree about consistency and we should have a similar set of build options across our supported models.

[stcui007]

I have created a PR in the module for building shared libs for use in Ngen. It might need to be merged when appropriate. The plan is we are going to move the cmake build files into all the submodules eventually.

On Tue, Feb 15, 2022 at 6:47 AM K. Jennings @.***> wrote:

@madMatchstick https://github.com/madMatchstick I don't have a strong opinion on this. We can still build PET in standalone mode. However, I agree about consistency and we should have a similar set of build options across our supported models.

— Reply to this email directly, view it on GitHub https://github.com/NOAA-OWP/evapotranspiration/pull/7#issuecomment-1040231535, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACA4SRNH6YPTB33NOT6YXCLU3JDLZANCNFSM5OEUIMYQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[SnowHydrology]

@stcui007, that's good to know. Will this mean we can eventually remove the duplicate model names from the extern path in Nextgen?

[stcui007]

At this moment we are still keeping the same directory structure. We are keeping a README file there for some git operations.

On Tue, Feb 15, 2022 at 8:31 AM K. Jennings @.***> wrote:

@stcui007 https://github.com/stcui007, that's good to know. Will this mean we can eventually remove the duplicate model names from the extern path in Nextgen?

— Reply to this email directly, view it on GitHub https://github.com/NOAA-OWP/evapotranspiration/pull/7#issuecomment-1040342407, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACA4SRKYDG26E7X7XBT35MDU3JPURANCNFSM5OEUIMYQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>