regx/fwd: make the module static

[ggouaillardet]

and enable test/util/orte_nidmap

Signed-off-by: Gilles Gouaillardet gilles@rist.or.jp

[ggouaillardet]

@rhc54 @jjhursey this PR makes the regx/fwd module static, so test/util/orte_nidmap can be invoked by make check even it make install was not performed.

feel free to merge or close this PR, i do not have a strong opinion on that.

[rhc54]

I'm not wild about making it static. I'm not sure how "make check", which is a user-level test to be run when installing, really benefits from testing the nidmap generator. There isn't anything system-sensitive in that code. Seems to me that the test would be better placed in the ompi-tests repo under the orte code, yes?

[jjhursey]

I like making the fwd component static. The old code was effectively static, and folks can always build it out if they really don't want it. What's your hesitation?

[rhc54]

Mostly an issue of "oddity" - we don't have any other framework that behaves that way, and it concerns me that someone will almost certainly break it by accident as a result. I also just don't believe it is necessary, as per below.

My other concern, frankly, is that we keep throwing things into "make check" that don't belong there. The "make check" support is supposed to be solely for installers to verify that their installation was correct - i.e., to check that system-dependent configuration code came up with the correct conclusions. This test (and the associated framework) has no system dependencies in it with respect to the configure logic, and thus it doesn't actually test anything of use to the installer.

Therefore, it more properly belongs in ompi-tests, or if you really are paranoid, in the Jenkins smoke tests.

[jjhursey]

Per discussion on the teleconf, moving this test to MTT is probably better.

I'm fine leaving the components as dynamic. If someone wants a component to become static or excluded there is a configure option for it. I was just hoping to not contribute to the proliferation of .so's that we need to load in a shared build just for this case.