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

Norbert Lange nolange79 at gmail.com
Wed Dec 20 14:14:40 UTC 2017


Hello,

just did an update to the debian packages, handling the dependency to
libpkgconf (the version in Debian is very outdated and only has the
pkgconf tool)

2017-09-07 11:52 GMT+02:00 Boris Kolpackov <boris at codesynthesis.com>:
> Norbert Lange <nolange79 at gmail.com> writes:
>
>> Debian packages are supposed to use "the archives as is from the
>> build2 distribution".
>>
>> BTW. it would be great if there is a way to list all build2 archives
>> (or at least the latest version).
>
> Hm, I am starting to wonder if it's better to go back to using the
> build2-toolchain archive. This way we get:
>
> 1. All the sources (build2, libbutl) as subdirectories so we should be able
>    to setup an out of tree bootstrap and build (but see below).
>
> 2. There is the toolchain.sha256 file in:
>
>    https://stage.build2.org/0/   (stage)
>    https://download.build2.org/  (release)
>
>    That points to the latest version (the first line is always for the
>    build2-toolchain archive; we use it for our build bots).

Even better solution would be to provide a archive containing just
build2 and libutil,
as those are closely tied and needed for bootstrap.
The remaining projects can be build independently, and if the are
updated independently then that's the correct way.
Think of buildservers whcih kick of builds after changed upstream, you
would want the builds restricted to the packages
that actually changed.

If that's not an option, using the individual packages is better.

>
> There is a small issue with using build2-toolchain and having output
> directories inside: it is itself a build2 project. We can, however,
> "cut it off" by creating configurations for output directories (they
> have amalgamation= in their bootstrap.build which cuts off the outer
> project). Here are the command lines (you can read more about create
> in b(1)):
>
> # Bootstrap.
> #
> mkdir build2-boot
> make -C build2-boot -f ../build2/bootstrap.gmake CXX=g++ -j 8
> build2-boot/build2/b-boot --version
>
> # Static build.
> #
> build2-boot/build2/b-boot create: build2-static/,cxx \
>   config.cxx=g++        \
>   config.bin.lib=static
> build2-boot/build2/b-boot configure: libbutl/@build2-static/libbutl/
> build2-boot/build2/b-boot configure: build2/@build2-static/build2/
> build2-boot/build2/b-boot build2-static/build2/build2/
> build2-static/build2/build2/b --version
>
> # Shared build.
> #
> build2-static/build2/build2/b create: build2-shared/,cxx \
>  config.cxx=g++                  \
>  config.cc.coptions=-O3          \
>  config.bin.rpath=/usr/local/lib \
>  config.install.root=/usr/local  \
>  config.install.sudo=sudo
> build2-static/build2/build2/b configure: libbutl/@build2-shared/libbutl/
> build2-static/build2/build2/b configure: build2/@build2-shared/build2/
> build2-static/build2/build2/b build2-shared/
> build2-static/build2/build2/b install: build2-shared/
>
> Then cleanup is a matter of deleting the output directories.

Hmm, I already used such schemes just to restrict builds.
Gonna make another attempt someday.

Norbert

>
>
>> The naming scheme is completely different, look at these:
>>
>> ./libboost_filesystem.so.1.62.0
>> ./libboost_filesystem.a
>> ./libboost_filesystem.so
>>
>> ./libbutl.so
>> ./libbutl.a
>> ./libbutl-0.7.0-a.0.z.so
>
> Ok, a couple of points:
>
> 1. Firstly, there was a bug (which is now fixes), the last name should have
>    been in this form:
>
>    libbutl-0.7.0-a.0.510bad1358bc443a.so
>
> 2. Once you switch to using released versions, it will become much tidier:
>
>    libbutl-0.7.so
>
> 3. We are currently using platform-independent library versioning scheme
>    by embedding the relevant version part into the library name. There is
>    nothing wrong with this approach and there are quite a few libraries
>    packaged for Debian that use it (for example, our own ODB runtimes).
>
>    There is provision (but not actual implementation) in build2 to support
>    platform-specific library versioning schemes (the semantics is very
>    different on each platform). So eventually we will get there.
>
> Boris



More information about the users mailing list