[build2] Disabling rpath linking for all update operations

[Boris Kolpackov]

Matthew Krupcale <mkrupcale at matthewkrupcale.com> writes:

> [...] I presume `update-for-install` will not use rpath, like `install`?

Correct.


> Since in my case the libraries are installed using
> `config.install.chroot` and are thus not actually on the usual library
> search paths after %install, I suppose I would need to add e.g.
> config.cxx.loptions+="-L/chroot/install/path" to the tests/ config,
> yes?

Yes, more generally, you will need to make the installed project
importable by the tests/ subproject. In case of libraries it means
adding -L.../lib and in case of executables -- adding .../bin to
PATH.


> Alternatively, if I'm configuring and building tests/ separately
> (either in-source or out-of-source) anyways, couldn't I just use the
> config.import.* of the e.g. libbutl out_root, as for the first `b
> configure:`, then only the tests will have the rpath added for `b
> test:`, and everything is only built/linked once still?

Yes, but the point is to test the final, installed result, not something
intermediate in out_root. A lot can break during installation (e.g.,
a library header is not installed or the executable is not runnable
from the new location).


> Currently, I'm just building/installing/testing the root directory
> target, so I suppose I'm also doing the unit tests. In this case, I
> think there will still be 2 links, once for the unit tests (with
> rpath) and then for the installation (without rpath), yes?

Yes. If you really wanted to, you could avoid the relink by only
building the unit test executables. But that would require listing
their targets explicitly (maybe we should add an alias target for
that).


> Yeah, I think for my use-case that would be the simplest way [...]

Yes, simplest but not necessarily the best (see above about testing
the end-result).

But I agree it may be the most practical in the circumstances. So I
will look into adding the ability to disable rapth.


> This is also easier because it means I don't have to know the
> particular sub-projects or where unit / integration tests are [...]

These are actually well-defined in a project that follows the canonical
structure (which all the build2 toolchain projects naturally do):

https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#proj-struct