Test for multiple targets, linking shared library

[GPMueller]

The test was commented out on PR #23 with 57ff743, because we don't yet know how we want to solve rpath etc.
The executable cannot be run and the test is therefore useless.

[NOhs]

I think this should have high priority. Features discussed only require more tests like these, so we need to find an easy solution to this. I think for now it would suffice to get the tests running by playing with some path environment variables.

[GPMueller]

I currently tend towards the following solution (described as an example project):

• build the shared librarytargetA in it's own build directory build/targetA/bin
• the dependency targetB->targetA causes the contents of build/targetA/bin to be copied to build/targetB/bin (and on Linux and OSX we pass the flags -Wl,-rpath='.')
• build the executable targetB into build/targetB/bin

This would have the advantage that - analogous to a clean Python venv - we can be sure that dependencies can be resolved properly and that each target is relocatable on its own.
Further, this would immediately be a proper "installable" package on Windows and it would not be far from an OSX ".App" bundle.

Additionally, we could bundle system-installed libraries, but this would probably require parsing compiler output from -Wl,--trace (see https://stackoverflow.com/a/23131842/4069571 - I see no other way...), also meaning we would have to take care not to bundle EVERYTHING, including piles of system libs.

My research so far:

Linux and OSX

It seems that now, on both OSX and Linux, we could add something like -Wl,-rpath='.', so together with the other link options this could look like -Wl,-rpath,./path/to/foo -L/path/to/foo -lfoo.

If we want to keep package management (something homebrew-like maybe) in mind I see three options:

1. we can simply bundle things together into one build/bin folder and link with -rpath=.
2. builds are always "clean" (i.e. separate from each-other), so we should link relative paths such as -rpath=../../otherlib/bin. For relocation/packaging, the correct subdirectories of the build folder would have to be copied out (without depfiles etc.)
3. project or target builds may be placed next to each-other (e.g. by the packaging process) and they may link among each-other. This would require versions to be a part of the paths, so that things don't get mixed up when multiple versions are built/installed.

OSX

I found this reference.

See https://stackoverflow.com/a/31825252/4069571 :

• -install_name @rpath/myprint.dylib
• -rpath @executable_path

See this description for how to do .App packages

Windows

I think we really do not want to force rpath-like behaviour on Windows: http://blog.omega-prime.co.uk/2012/12/06/rpath-emulation-absolute-dll-references-on-windows/
See also dynamic-link-library-search-order and dynamic-link-library-redirection

[GPMueller]

One more thing to consider: it seems that flatpak is gaining traction and our packaging on Linux systems should probably go in that direction https://flatpak.org/

[GPMueller]

The work in progress on feature-tests can illustrate the same problem. When tests are automatically built for a shared library, they may not run because the library is not found at runtime.
I believe placing the library in the corresponding binary directory would quite nicely solve these issues.

Any bin folder would therefore be its own self-contained collection of applications (and/or libraries).

[NOhs]

For non-trivial tests, we could define targets as follows:

[mylib]
target_type = "shared library"

[mylib2]
target_type = "shared library"

[complex_test]
is_test = true
dependencies = ["mylib", "mylib2"]