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

Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
From: Domen Vrankar (domen.vrankar_at_[hidden])
Date: 2017-12-02 08:58:08

2017-12-02 1:00 GMT+01:00 Stefan Seefeld via Boost <boost_at_[hidden]>:

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

There is another side of the medallion here. I tend to move away from
libraries
which use custom build tools (python based or b2) if at all possible - even
when
it comes to autotools and CMake projects I'll always prefer the CMake ones
as they both may fail and for CMake + Makefiles I can fix the problem myself
while with autotools I can't (and I really hate to ask what's wrong and
hate a
bit less googling what the solution is). CMake allows me to use the tools
that
I'm familiar with (e.g. Make instead of Ninja).

It's a difference between being able to fix it myself or whining to the
others or simply
abandoning the library (with Boost the last option is a bit hard from time
to time).

There are of course people who don't have the knowledge about build system
on their platform of choice but I'd guess that they'd use binaries if at
all possible
and not go into the compiling the library land.

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

I may have too little experience but from where I stand you are exaggerating
this point quite allot (while I do agree that Boost libraries are quite
often pushing
the compilers and error reports to the limit so it may be a valid
exceptional point).

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

One reason for why would be that there is not the latest version in my
distro
and I need it.

And no I wouldn't bother to learn a new build system just for the sake of
contributing
to one project (unless really forced to) and I keep wondering how many
others are
like me.

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

Again  I disagree here. This puts an overhead on me that my meta build
system
could solve but can't due to the choices of other authors.

My point is that I like the fact that different build systems exist and
compete with
each other but want a meta build system to support them so when I choose one
over the other I don't have to reinvent the entire build structure of my
projects.

Regards,
Domen