[build2] possible to do something similar to DESTDIR= make install?

[Norbert Lange]

Hello,

Bootstrap works fine, but static build failed.
Exhibit A: Running just in a subdirectory as I planned:

tmp/build2-toolchain/_bstr/p1/build2/b-boot build2/@_bstr/p2/
config.cxx=g++ config.bin.lib=static
error: out_base suffix does not match src_root
  info: src_root: ./
  info: out_base: _bstr/p2/

Exhibit B: Adding a subdirectory:
/tmp/build2-toolchain/_bstr/p1/build2/b-boot build2/@_bstr/p2/build2/
config.cxx=g++ config.bin.lib=static
build2/buildfile:5:15: error: unable to determine src_root for imported libbutl
  info: consider configuring _bstr/p2/libbutl/

Exhibit C: Building libbutl first (note that this would accept
@_bstr/p2/ aswell)
/tmp/build2-toolchain/_bstr/p1/build2/b-boot
libbutl/@_bstr/p2/libbutl/ config.cxx=g++ config.bin.lib=static
mkdir fsdir{_bstr/p2/libbutl/}
...<snip>...
/tmp/build2-toolchain/_bstr/p1/build2/b-boot build2/@_bstr/p2/build2/
config.cxx=g++ config.bin.lib=static
build2/buildfile:5:15: error: unable to determine src_root for imported libbutl
  info: consider configuring _bstr/p2/libbutl/

Not sure how to proceed there. Git repo is updated with a README,
should you want to know the steps I am doing,
or want to try for yourself.

Now to something else, libbutl and build2. Are those expected to be
developed together, having always the same version,
or could eg. libbutl be stable and not receiving updates and
version-numbers like build2?
debian source packages have one version number, and atleast one of
them has to be "bootstrapped".
This leaves 3 options, 1. would be the least amount of work, 3. really nasty.

1.  Always build them together - independent fixes aren`t possible.
Both will get a new binary and a new version

2.  Bootstrap libbutl with an included build2.
    That means libbutl wont depend on a build2 package from debian for
building, but building build2 will require libbutl.

3.  Bootstrap build2 with included libbutl.
    Would likely require linking statically (not something debian is
particullarly fond of), or some advanced trickery
    to properly reroute and generate the depencies on the system
libbutl afterwards.
    By default a big machinery of scripts handles dependencies
automatically (remarkable well).

For a extreme example of 1. look at
https://packages.debian.org/source/sid/llvm-toolchain-snapshot and
scroll down.
There are multiple source-projects, all ending up with the same version-number.

Norbert

PS. those error messages, out_base suffix restrictions and pragmatic
reliance on adding a slash at the end of paths
is really confusing. sure you don`t want to add some explicit
arguments (like --source <path>) for that, its easy to mess up,
especially in scripts?

2017-08-15 18:12 GMT+02:00 Boris Kolpackov <boris at codesynthesis.com>:
> Ok, I've implemented the makefile and re-staged the toolchain (available
> from the same place).
>
> Here is a completely out-of-tree build, for all three stages (bootstrap,
> static, shared):
>
>
> tar xf build2-X.Y.Z.tar.gz
> tar xf libbutl-X.Y.Z.tar.gz
> mv libbutl-X.Y.Z build2-X.Y.Z/ # build2-X.Y.Z is now your .orig
>
> # Bootstrap (in build2-boot/).
> #
> mkdir build2-boot
> make -f ../build2-X.Y.Z/bootstrap.gmake CXX=g++ -j 8
> cd ..
> build2-boot/build2/b-boot --version
>
> # Static build (in build2-static/).
> #
> build2-boot/build2/b-boot build2-X.Y.Z/@build2-static/ \
>   config.cxx=g++ config.bin.lib=static
> build2-static/build2/b --version
>
> # Shared build (build2-shared/).
> #
> build2-static/build2/b configure: build2-X.Y.Z/@build2-shared/ \
>  config.cxx=g++                     \
>  config.cc.coptions=-O3             \
>  config.install.root=/usr           \
>  config.install.chroot=/tmp/install
>
> build2-static/build2/b build2-shared/
> build2-static/build2/b install: build2-shared/
>
>
> Let me know if there are any issues.
>
> Boris