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

[Norbert Lange]

>> 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 is a fixed debian automatism, working on the unmodified archives,
 so atleast here I can`t.
I will have to build "in-tree", and take some care to be able to clean
up everything.

> 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.

Yes, thats semantics. For me the important part is being able to easily clean
up everything, and potentially having multiple builds lying around.
BTW, you will often have "meta" folders and files, think about the
.git subdirectory
or project files for editiors/ideas.
I find code "being pretty hairy" is a good reason for second guesses =)

> 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
> currently).

Another option would be to add a subdirectory in the build2 archives,
but I dont find this very clean.

>> 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):
>
> https://build2.org/build2/doc/b.xhtml
>
> I think it is worth a read.
>
> Boris

I will absolutely read up some more, but my point stands that this
will be a hindrance to adaption.
Realistically you won`t replace every other tool-chain overnight, and
even if, there is also the infrastructure around
the build-systems.
I can`t say its the right or wrong direction (for whom), but the
troubles are there.

This is primary about the no 'half-out-of-tree' support thats used
quite often, the command-line can be worked around if necessary.
Just want to know you are aware of that, what you do with this
information is your issue, I am not demanding anything =)

Norbert