Change routing build to t-route master branch

[mattw-nws]

Switch to building/installing t-route master instead of t-route ngen branch.

Additions

• Several small build system improvements, including using ${BUILD_PARALLEL_JOBS} instead of $(nproc), and a way to optionally pass a pre-downloaded boost tarball to the image creation process.

Removals

• Does not work out of the box to use legacy t-route (e.g. ngen branch), which might limit capability with some older hydrofabric datasets.

Changes

• Now compiles and builds master t-route by default (instead of ngen branch)
• Several Python elements are now installed in the global (root) site. This enables use-cases where a user other than mpi(1000) is used, e.g. using docker run --user=$(uid -u), so now the routing modules are available to that user (tested!).

Testing

1. Built and ran the gauge_01073000 dataset, including using --user to change the uid

Screenshots

Notes

Todos

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows project standards (link if applicable)
• Passes all existing automated tests
• Any change in functionality is tested
• 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 👇)
• Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• Reviewers requested with the Reviewers tool ➡️

Testing checklist

Target Environment support

• Linux

[robertbartel]

There are a few things I suggest changing and a couple others I had questions about.

[robertbartel]

We probably don't want to do this, at least not exactly this way. This would cause rebuilding of anything depending on Boost any time the entrypoint script changes.

[robertbartel]

This change to how pip is installed feels somewhat brittle. What was the reason behind it?

[robertbartel]

There are some flaws with both the old approach and this change. The problem with going this way is the lack of safeguards around BUILD_PARALLEL_JOBS having a sane value (e.g., unset, double the CPUs on the host, etc.). Using the nproc approach provides protections but offers less control.

Ideally, we'd control this a different way anyway, but I don't think it's quite that simple to do with our tools. They are based on the old style docker-compose (not the same as docker compose), and it isn't clear at glance how we would accomplish this at image build time.

For the moment, I recommend leaving this as it was. We need to revise things, but that should be handled separately in something like #325.

[robertbartel]

This may end up being irrelevant, depending on what's done about an earlier comment ...

I'm curious as to why this file name change was done. I don't see any issues with it beyond a few uncommon and essentially trivial side effects when debugging image stages. But the old way didn't exactly seem troublesome.

Also, are we certain the -j flag isn't needed?

[robertbartel]

@mattw-nws, pinging you again on this one, just to keep it on your radar. In addition to the stuff I commented on, it looks like the branch will need rebasing, probably due to #353.

[robertbartel]

This is now superseded by #429.