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

[Boris Kolpackov]

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