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

[Matthew Krupcale]

On Thu, Oct 3, 2019 at 9:57 AM Boris Kolpackov <boris at codesynthesis.com> wrote:
> So I don't think it make much sense to split them into separate distribution packages.

Sounds good, I'll just make a single libbuild2 sub-package then.

> In the future we can use the platform-specific versioning for one
> of them, most likely the actual library version rather that the
> build system core version. So it will be:
>
> libbuild2-hello-0.12.so.0.1

Okay, that makes sense.

> BTW, the reason why we are going through all this trouble is GCC's
> early experience with their plugins: initially the plugins weren't
> versioned with the GCC version and this ended up in a big mess. We
> want to avoid this from the outset.

Okay, seems reasonable. From what I've heard regarding Red Hat's
annobin plugin, GCC plugins are indeed difficult to manage with
different versions of GCC.

> This scenario can never happen since the build system core will only
> load (BTW, this is who actually loads modules) a module with a matching
> build core interface version.

Okay, this certainly does make the issue easier and is more or less
equivalent to supporting the current "master" at any given time,
although old modules could work with their respective older versions
of build2.

Perhaps in the future though with increasing ABI stability of
libbuild2 (possibly including the use of symbol versioning), this
requirement could be relaxed.

> I don't have much experience with symbol versioning, but it sounds like
> we will have to carefully track changes to our ABI and adjust each
> symbol's version accordingly. I don't think it will practical in our
> case, at least at this stage.

It does require attention to ABI changes, but projects like abidiff[1]
can make this fairly easy (at least on Linux), and the result is that
users of libbuild2 can easily develop a module against basically any
version as long as symbols are maintained in future versions. Shared
libraries should probably monitor ABI closely anyways regardless of
whether they use (platform-specific) filename versioning or symbol
versioning, though.

> We have no plans to provide such a guarantee, probably ever ;-).

Yeah, that's a difficult guarantee to make without very careful
planning, so it's probably best to avoid loading multiple versions of
a library at once.

> What we have now is essentially how GCC handles plugins, which works
> reasonably well. The main difference is they version their plugins
> by installing them into the compiler version-specific directory while
> we embed the build system core interface version into the library
> name.

Okay, seems reasonable. I think this will certainly allow developers
to get started on writing modules for the latest libbuild2 as long as
they are able to rebuild them whenever a new release comes, but in the
long term, it might be good to relax this constraint through either
platform-specific or symbol versioning.

On the other hand, this dependency on "master" might encourage people
to upstream their modules instead, which could be better for build2
over the long term (see e.g. Linux kernel).

[1] https://fedoraproject.org/wiki/How_to_check_for_ABI_changes_with_abidiff