Tests don't set rpath about libs-base HOT 3 OPEN

Doing 'make check' for base already runs the base testsuite on the uninstalled library, which is usually what you want.
So what is the nature of the issue/problem?
Is it that you want testcases, once built, to be executable directly/externally and still use the uninstalled library without having to reproduce the LD_LIBRARY_PATH 'magic' that the test suite does for you when you run the tests normally?
Or is it that you want to have gnustep-tests, when run for the base testsuite, think it should build and run the tests using the library in ../../Source/obj and headers in ../../Headers if they exist?

I looked up -rpath online and found that the order of precedence for library search is:

1. LD_LIBRARY_PATH
2. -rpath
3. system default paths

I added a couple of lines to build the testcases with -rpath as it seems harmless, but I'm not at all sure it actually resolves either of those two issues most of the time since LD_LIBRARY_PATH takes precedence, though it clearly fixes them in the case you are building/testing a library for the first time (ie there is no installed version).

So if you run testcases using gnustep-tests or even directly in a gnustep environment, I expect the LD_LIBRARY_PATH will cause the installed version to be used (if it exists), but the uninstalled version (pointed to by -rpath) to be used otherwise.

On the other hand, if you run them using 'make check' the normal code to set LD_LIBRARY_PATH to point to the uninstalled library for the duration of the tests will still be used.

from libs-base.

Doing 'make check' for base already runs the base testsuite on the uninstalled library, which is usually what you want.

Does it? I encountered this problem running make check and having everything fail.

Is it that you want testcases, once built, to be executable directly/externally and still use the uninstalled library without having to reproduce the LD_LIBRARY_PATH 'magic' that the test suite does for you when you run the tests normally?

This is pretty much a minimum if I'm trying to debug a failing test, yes.

from libs-base.

Does it?
Yes ... try 'make messages=yes check' to see how it's setting up the environment.

eg.

$ cd Tests
[richard@centos-linux Tests]$ make check
This is gnustep-make 2.7.0. Type 'gmake print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
(
GNUSTEP_LOCAL_ADDITIONAL_MAKEFILES="/home/richard/git/libs-base/base.make";
ADDITIONAL_INCLUDE_DIRS="-I/home/richard/git/libs-base/Headers -I/home/richard/git/libs-base/Source/.";
ADDITIONAL_LIB_DIRS="-L/home/richard/git/libs-base/Source/./obj";
ADDITIONAL_LDFLAGS="-Wl,-rpath,/home/richard/git/libs-base/Source/./obj";
LD_LIBRARY_PATH="/home/richard/git/libs-base/Source/./obj:/home/richard/GNUstep/Library/Libraries:/home/richard/gnustep-ng/Local/Library/Libraries:/home/richard/gnustep-ng/System/Library/Libraries";
PATH="/home/richard/git/libs-base/Tools/./obj:/home/richard/GNUstep/Tools:/home/richard/gnustep-ng/Local/Tools:/home/richard/gnustep-ng/System/Tools:/usr/lib64/qt-3.3/bin:/home/richard/perl5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/richard/bin";
export GNUSTEP_LOCAL_ADDITIONAL_MAKEFILES;
export ADDITIONAL_INCLUDE_DIRS;
export ADDITIONAL_LDFLAGS;
export ADDITIONAL_LIB_DIRS;
export LD_LIBRARY_PATH;
export PATH;
if [ "" = "" ]; then
gnustep-tests base;
else
gnustep-tests --debug base;
fi;
)
--- Running tests in base ---
--- Running tests in base/coding ---
--- Running tests in base/Functions ---
...

I encountered this problem running make check and having everything fail.
Then it would be good to know what made it fail, so it could be dealt with.
I use this on an almost daily basis.

This is pretty much a minimum if I'm trying to debug a failing test, yes.
I'm used to having my LD_LIBRARY_PATH set up by scripts for each different environment I'm working in, but I can see how, if you don't automate that sort of thing, it could be a pain.

One option if you don't want to alter your normal shell is to put the LD_LIBRARY_PATH setup into TestInfo for the directory your testcases are in, then you can use gnustep-tests --debug to debug any failing testcases.
gnustep-make does something similar for libraries and frameworks using the foo_TEST_DIR option to integrate regression tests for the library/framework named 'foo'. In this case 'make check' generates a 'make-check.env' file which provides the environment for gnustep-tests to run testcases in.

from libs-base.