Re: [boost] Announcement: Faber, a new build system based on bjam

Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-12-02 00:00:41

On 01.12.2017 18:14, Roger Leigh via Boost wrote:
> On 01/12/2017 22:09, Stefan Seefeld via Boost wrote:
>
>> On a more philosophical level, I think that CMake is an attempt to patch
>> over the fact that the underlaying build systems aren't portable. So the
>> real fix to that problem obviously is to write such a portable build
>> system that would obsolete the need for something like CMake.
>
> No, I think this is missing the major selling point of why people use
> CMake.  It's glue which can integrate with all the major extant build
> systems on all the major platforms.

Yes, no doubt, that's the selling point. But does it truly deliver on
this promise ? As I said, it works until it fails. And when it fails,
who will have to help users figuring out what the cryptic error messages
mean ? The problem is of course all about division of labour. Some
people are platform experts, others are application domain experts. So
ideally they collaborate in that the latter write abstract and portable
build logic for their respective applications (or libraries as the case
may be), while the former make sure that this high-level
platform-agnostic logic maps correctly to platform-specific tool
invocations.

And while this separation of work is sound and useful, the way this is
spelled out with CMake injects an extra layer in the middle, so the
whole system requires expertise in three domains:

* the application domain
* the target platform (including target build system)
* the CMake mapping logic

In an ideal world CMake would hide everything else underneath it. But in
reality, the encapsulation leaks like a sieve, so users are forced not
only to understand the target logic but also the mapping logic.

> Â  As a library and program author, my end users all want to have my
> software integrate with their existing systems.  They wouldn't be
> happy if I dictated they use some spiffy but nonstandard and
> incompatible system.  But that's basically what Boost does with b2,
> and this tool.

"Integration" may mean different things. In Unix dependencies are
typically dealt with via (binary) installations, i.e. tools like
autoconf or pkg-config (which you mention yourself) are useful in
detecting those, and providing flags I need to use to build *my* code
using such third-party libraries.
If you really want to build my library from source, you'll have to use
the build logic of my choice, there is no way around that, as I can't
maintain a build system I don't understand. But then again, who would
want to build my library from source, other than potential contributors
who are willing to understand the build system (which hopefully isn't
too cryptic, hence my work on "this tool", as you prefer to name it,
rather than using b2).

>
> Some users want to build with make on Unix.  Others want to build and
> edit within Visual Studio on Windows.  Or use CLion.  Or Xcode, or
> Eclipse.  Or use MinGW or Cygwin on Windows, with the tool of their
> choice.

Now you are mixing different categories of things. Building with
different compilers (the MSVC command line tools, mingw, cygwin, etc.)
should of course work (and does, with b2 and Faber). That's what
"portable build system" means. But using different build *systems*
(including IDEs such as Visual Studio or Eclipse) is an entirely
different thing. If people want build integration with other tools, they
need to maintain that logic themselves. I have seen enough error reports
which I don't have any clue how to resolve that I came to the conclusion
that CMake goes after the problem in a very wrong way.

Regards,

Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...