[build2] Build system reorganization (heads-up to distribution packagers)

[Boris Kolpackov]

We are a couple of weeks away from the 0.12.0 release and I wanted to
give heads-up to distribution packagers (and anyone else interested)
about the major reorganization in the build system (the `build2`
package).

Before this release the build system was all in the `b` executable.
Now it is split into `libbuild2` (build system core), a bunch of
build system modules (`libbuild2-bin`, `libbuild2-cxx`, etc; called
bundled modules) and the `b` executable (build system driver). With
this arrangement, someone else (e.g., an IDE author) can write their
own build system driver with their own set of modules, etc.

The core library and the build system modules are now in the
`libbuild2/` subdirectory of the `build2` package with modules
residing in its subdirectories (e.g., `libbuild2/bin/` for the
`libbuild2-bin` module). The build system driver is still in
`build2/` (you may notice there is also `build2/cli/` -- it
is there temporarily until we factor it out to an external
build system module).

A bit of background on build system modules: they are libraries
that can be either linked statically, linked dynamically, or
loaded dynamically (with dlopen() or equivalent). We call it
the "library first" model meaning that they are normal libraries
that happen to additionally be usable via dynamic loading. As a
result, they should be installed into `$prefix/lib/` rather than
`$prefix/libexec/`.

Once the `build2-0.12.0` package is installed, the resulting tree
will look like this:

$prefix
├── bin/
│   └── b
├── include/
│   └── libbuild2/
│       ├── bin/
│       │   └── ...
│       ├── cxx/
│       │   └── ...
│       └── ...
└── lib/
    ├── libbuild2.a
    ├── libbuild2-0.12.so
    ├── libbuild2.so                 -> libbuild2-0.12.so
    ├── libbuild2-bin.a    
    ├── libbuild2-bin-0.12-0.12.so
    ├── libbuild2-bin-0.12.so        -> libbuild2-bin-0.12-0.12.so
    ├── libbuild2-bin.so             -> libbuild2-bin-0.12.so
    ├── libbuild2-cxx.a    
    ├── libbuild2-cxx-0.12-0.12.so
    ├── libbuild2-cxx-0.12.so        -> libbuild2-cxx-0.12-0.12.so
    ├── libbuild2-cxx.so             -> libbuild2-cxx-0.12.so
    └── ...

One thing that you may notice is the strange-looking `0.12-0.12`
suffix in the module libraries as well as the extra intermediate
symlink with just one `0.12`:

libbuild2-cxx-0.12-0.12.so
libbuild2-cxx-0.12.so       -> libbuild2-cxx-0.12-0.12.so
libbuild2-cxx.so            -> libbuild2-cxx-0.12.so

This is because module libraries contain two versions: the build
system core (`libbuild2`) interface version as well as the module
version. Because the above modules are bundled, the two version are
the same. But if it were an external module, then they would normally
be different, for example:

libbuild2-hello-0.12-0.1.so
libbuild2-hello-0.12.so       -> libbuild2-hello-0.12-0.1.so
libbuild2-hello.so            -> libbuild2-hello-0.12.so

The intermediate symlink (`libbuild2-hello-0.12.so`) is what we call
a "load name" (as opposed to `libbuild2-hello.so` which is the "link
name"). It is the name that the build system core will use to
dynamically load modules ensuring that they are compatible. It is
also a way for us to have multiple versions of the build system core
and corresponding modules installed in the same location (e.g.,
`$prefix/lib`).

There is a test external module if you would like to play with this:

https://github.com/boris-kolpackov/libbuild2-hello

Let me know if you have any questions of concerns.