make installcheck reaches wrong testing code after sourcing nest_vars.sh for a different version

[TomBugnon]

Hi all,

I notice that when installing a given version of NEST using the usual routine:

rm -r bld
mkdir bld
cd bld
cmake ${SOURCE_DIR} -DCMAKE_INSTALL_PREFIX:PATH=${INSTALL_DIR}
make
make install
make installcheck

... the testing suite that is used for the install checks is not that of the NEST version that was just built, but rather that of the NEST version referenced by the environment variables from nest_vars.sh.

This caused me quite some headaches as I was trying to install nest versions with different test suites although the same nest_vars.sh script had been sourced in my .zshrc the whole time..

Adding the line source "${INSTALL_DIR}/bin/nest_vars.sh" before make installcheck seems to solve the issue.

[terhorstd]

@jougs any updates on this?

[jougs]

Basically, the code is ready, but depends on the merge of #1039. I'll start a PR once that's done.

[clinssen]

Is this not already fixed by #1561?

[jougs]

In principle yes (and please feel free to add the magic fixed word to #1561).

The cleanest solution from my point of view is, however, to remove the problematic exports altogether in order to also prevent possible problems for people not running make installcheck or do_tests.sh, but

1. sourced nest_vars.sh previously for NEST installation A
2. manually re-set PATH and PYTHONPATH later on to make another NEST installation B available (unknowingly that there are other variables set by step 1.)
3. run into problems with B, as it still uses parts of A.

And above that, as I laid out #1578, none of the exports is really needed for the proper working of NEST, as all exported variables are set to their defaults anyway. Actually, I don't see a good reason why one would want to use NEST A with the documentation or SLI library of NEST B and am considering to remove the mechanism for reading NEST_DOC_DIR/NEST_DATA_DIR from the environment altogether.

[heplesser]

@jougs I agree that a complete clean-up is useful. Would you create a new issue for that, so this one can be safely closed when #1561 is merged?