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

Boris Kolpackov boris at codesynthesis.com
Sun Aug 20 08:09:10 UTC 2017

Norbert Lange <nolange79 at gmail.com> writes:
> yes, i unpack build2 into WORKDIR, unpack libbutl into WORKDIR/libbutl,
> and the debian stuff goes into WORKDIR/debian.
> the BUILDDIR was WORKDIR/_bstr/p1.
> I should not leave WORKDIR during the build, only the final packages
> land outside.

A pretty easy solution would be to unpack build2 as WORKDIR/build2/,
libbutl as WORKDIR/build2/libbutl/ and then you can have all the
out directories directly in WORKDIR/, next to build2/. Will this
not work for some reason?

> This stay-in-WORKDIR Scheme is not unique to debian packages by the way,
> some IDEs (highly) prefer this aswell. Not having an option to build
> inside a sub-directory is a big obstruction for me personally, and I
> think for a rather large portion of developers (and their tools). Since
> you support plain in-tree compilation (objects right next to sources),
> I doubt this is a technical limitation.

We rely pretty heavily on out/src either being the same or having parallel
structure. That code is pretty hairy as it is so I doubt we will ever support
this "half-way" approach. I don't think it qualifies as out-of-tree since
in my view it must not (or may not be able to; think /usr/src) modifying
the source tree at all.

If the above approach does not work for some reason, then we can try
going back to the in-tree build. I will have to figure out what to do
with those version files cleanup (which, I admit, is not very symmetrical

> In nothing else, add some helpful error message =)

Yes, this we should do.

> A command line argument like `--source <THIS IS ALWAYS A DIRECTORY PATH>`
> would be alot more robust and easy to support in scripting (paths are known
> everywhere, mappings using @ are not).

The problem with using an option is that it won't support more complex
build specifications. In build2 you can perform several operations on
multiple projects at once. For example, you can configure several projects
at once:

b configure: build2/@build2-build/ bpkg/@bpkg-build/ config.cxx=clang++

Or, here is another, more elaborate example (which uses the real buildspec
syntax as opposed to the ':'-shortcut):

b 'configure(build2/@build2-build/)' \
'{update test install clean}(build2-build/)'

We could have added a "dumb" mode with an option for singe project
configuration but then you may never discover the true power of build2.
Why not give it a chance rather than expecting it to do things the way
you are used to? ;-)

BTW, the buildspec syntax is described in more detail in b(1):


I think it is worth a read.


More information about the users mailing list