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

[Norbert Lange]

> I am not completely certain what's going on here, but I suspect you are
> trying to have the out directory inside src or some such. In build2 those
> should not be subdirectories of each other (one way or another).

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.

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.

In nothing else, add some helpful error message =)

> In the <src_root>/@<out_root>/ syntax the first is the source directory
> while the second is the output directory (inside it will have structure
> parallel to source).
>
> Some typical examples would be:
>
> $ ls
> build2-X.Y.Z/
>
> $ b-boot build2-X.Y.Z/@build2-build/ ...
>
> $ b-boot build2-X.Y.Z/@build/build2/ ...
>
> Let me also add that I realize this is all (unfortunately) undocumented
> so it's all our fault ;-).

Yes, I found out by your last message and some trial-and-error, I just
don`t agree with such a scheme.
It might read nice for some examples, but adds another escape
character (think scripting)
and if you depend on stat-ing the path its some more inconsistency on
functionality (or error),
depending on stuff outside parsing the command line.

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).
Easier to catch a mistake in the commandline with a concise reason aswell.

> Yes, it is safe to assume they will always be released in lock-step.
> The only variation could be in bugfix releases (e.g., 0.7.1 vs 0.7.0).
> Plus they can only be built together via a bootstrap process. So I
> would suggest using approach #1 if possible.

Ok, its the easiest anyway =)

Kind regards,
Norbert