[build2] Disabling rpath linking for all update operations

[Matthew Krupcale]

On Mon, Mar 25, 2019 at 10:33 AM Boris Kolpackov
<boris at codesynthesis.com> wrote:
> Firstly, instead of the `update` operation you can use `update-for-install`.

Ah okay, I did miss that. This will eliminate the second link during
%install since I presume `update-for-install` will not use rpath, like
`install`?

> Then, for testing, you would want to configure the tests/ subproject to run against
> what's been installed.
>
> In other words (using build2 as an example):
>
> b configure:          build2/
> b update-for-install: build2/build2/               # Don't build tests/.
> b install:            build2/
> b configure:          build2/tests/@build2-tests/
> b update:             build2-tests/
> b test:               build2-tests/

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?

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? Or would this
try to re-link exe{b} since that's what's being tested?

> If you also want to run unit tests (the tests/ subproject contains
> integration tests), then this will become:
>
> b configure:          build2/
> b update:             build2/build2/
> b test:               build2/build2/               # Run unit tests.
> b update-for-install: build2/build2/               # Relink without rpath.
> b install:            build2/
> b configure:          build2/tests/@build2-tests/
> b update:             build2-tests/
> b test:               build2-tests/                # Run integration tests.

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?

> I was initially thinking of overloading
> config.bin.rpath=false but I now realize that's not a good idea: one
> may want to disable this "automatic dependency rpath" but still have
> the custom ones.

Yeah, I thought about that as well. Seems like a good plan.

> Even if the above approach (update-for-install plus testing installed)
> works out for you, we may still want to add this since I am sure someone
> else will need it sooner or later.

Yeah, I think for my use-case that would be the simplest way to
achieve what I want: one build for all targets for which we install
and test. This is also easier because it means I don't have to know
the particular sub-projects or where unit / integration tests are, and
I can just use the root directory as the target. This is especially
true since I'm actually building the whole build2 toolchain, and I'd
have to handle these tests separately for each component.