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

[Norbert Lange]

> I tried to wrap my head around it and it hurts ;-). I still don't
> understand why the following approach can't work

I am just returning the favor ;)

> 1. Package build2/ and libbutl/ source directories as subdirectories of
>    the .orig archive.
>
>    My understanding is that you have to combine them anyway (i.e., you
>    cannot just take the archives as is from the build2 distribution) so
>    this shouldn't be adding much overhead.

Debian packages are supposed to use "the archives as is from the
build2 distribution".
I can`t do this as of yet, since I depend on the additions and fixes
in 0.7.0 and the archives aren`t available
from your site.
Once its released, you rename the archives and place the debian.tar.xz
next to it,
you don`t touch upstream archives, not even by repacking.
(Simplified, buts thats the idea behind it).

BTW. it would be great if there is a way to list all build2 archives
(or at least the latest version).
There are some tools who allow automated queries of new upstream versions, and
preparation of new packages (all  that archive-renaming and unpacking business).
See the file debian/watch.ex for the templates

>    BTW, calling this .orig build2-toolchain is probably a bad idea unless
>    you also plan to bundle bpkg into it. But it is probably better to build
>    bpkg as a separate package since there is no technical need to bundle it.

Agreed. Any recommendations about the name?
think it should be build2-<something>.

> I assume you are talking about this:
>
> libbutl-0.7.0-a.0.510bad1358bc443a.so
>
> If so, then this is due to you using a pre-release (i.e., not final)
> version from stage. It includes the git commit id thus the unusual
> look. But SONAME should still match:

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

TBH I am not much experienced with these library schemes,
but the one first one is totally dominant at least in debian.

Other schemes are only used if the libs aren`t backwards-compatible
and multiple versions need to be installed simultaneously.

My gut feeling is that it should be either
libbutl.so.0.7.0-a.0.z (backwards-compatible) or
libbutl-0.7.0.so.a.0.z

kind regards,
Norbert

2017-09-03 17:47 GMT+02:00 Boris Kolpackov <boris at codesynthesis.com>:
> Norbert Lange <nolange79 at gmail.com> writes:
>
>> I managed to get a usable package. I implemented a manual cleanup, so
>> I don`t depend on a built bootstrap binary and fail otherwise.
>> For ease of use, I added the build2/libutil sources:
>> https://github.com/nolange/deb-build2-toolchain/releases/tag/0.7.0-1
>
> I tried to wrap my head around it and it hurts ;-). I still don't
> understand why the following approach can't work:
>
> 1. Package build2/ and libbutl/ source directories as subdirectories of
>    the .orig archive.
>
>    My understanding is that you have to combine them anyway (i.e., you
>    cannot just take the archives as is from the build2 distribution) so
>    this shouldn't be adding much overhead.
>
>    So you have:
>
>    build2-X.Y.Z\
>    |
>    `--build2\
>       |
>       `-- libbutl\
>
>    BTW, calling this .orig build2-toolchain is probably a bad idea unless
>    you also plan to bundle bpkg into it. But it is probably better to build
>    bpkg as a separate package since there is no technical need to bundle it.
>
>
> 2. Bootstrap and build out of tree inside the unpacked .orig/.debian by
>    creating output directories next to sources, for example:
>
>    build2-X.Y.Z\
>    |
>    |--debian\           # From .debian.
>    |
>    |--build2\           # From .orig.
>    |
>    |--build2-bootstrap\
>    |
>    |--build2-static\
>    |
>    `--build2-shared\
>
>    Then cleaning any stage is a matter of removing the corresponding
>    directory.
>
>
>> I am bit concerned that accidentally typing in the wrong terminal b
>> could traverse huge directory trees and "update" files it should not?
>> (just for kicks: it will segfault when done in / for me)
>
> Yes, that was a bit crazy. In the early day we tried to accommodate too
> many ways a user may want to (not) specify src/out. I've cleaned that
> logic up and it is a lot saner now (and doesn't segfault).
>
>
>> some quirks are still with the library, do you intent to version by
>> some custom filename scheme?
>> (package names of shared libraries should be identical to their
>> soname/filename)
>
> I assume you are talking about this:
>
> libbutl-0.7.0-a.0.510bad1358bc443a.so
>
> If so, then this is due to you using a pre-release (i.e., not final)
> version from stage. It includes the git commit id thus the unusual
> look. But SONAME should still match:
>
> $ objdump -p libbutl-0.7.0-a.0.510bad1358bc443a.so | grep SONAME
>
> SONAME               libbutl-0.7.0-a.0.510bad1358bc443a.so
>
> Boris