Boost logo

Boost :

Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2017-11-30 12:50:11

replies inline

On 30 November 2017 at 13:28, Stefan Seefeld via Boost <
boost_at_[hidden]> wrote:

> On 30.11.2017 06:57, Richard Hodges via Boost wrote:
> > This discussion will eventually lead to the realisation that a
> cross-platform builder tool requires separate concepts for (amongst others):
> >
> > * source files
> > * libraries (dynamic and static)
> > * dependencies
> > * executables built for the target system
> > * executables built for the build host (i.e. intermediate build tools)
> > * scopes
> > * -D macro definitions
> > * abstractions of compiler options
> > * abstractions of build host fundamental operations (environment
> variables, file existence, file copying, file locks, spawning subprocesses
> etc)
> >
> > … and so on.
> What's your point ? I think everyone understands that.
My point is that I think it would be useful to focus on this reality in
priority to a wrapper around bjam.

> > To short-circuit the discussion I can offer the following observations:
> >
> > * bjam, clever as it is, is basically a form of makefile. It will never
> be a build tool It’s therefore not useful to anyone but boost maintainers
> or single-target projects.
> That sounds like a rather unsubstantial rant. Can you elaborate on what
> you mean by that ?

bjam does what makefiles do. It computes and executes configurable
dependency tree. It remains up to the developer know the specific flags,
tools, settings etc he needs to build for a given target on a given host.
This is also true of a makefile. bjam and make are functionally equivalent
in that they offer no abstraction in statement of intent.

> >
> > * makefiles are great for creating dependency graphs. They are suitable
> for the output or intermediate stages of a build tool. You build a makefile
> hierarchy from the build tool abstractions given a target toolset and
> options.
> >
> > We already have Scons and CMake, which are both awful in their own way.
> >
> > I really think that effort would be better spent retro fitting python
> (or javascript, or [insert well maintained scripting language here]) into
> cmake so that cmake becomes beautiful.
> >
> > Either that, or recreate cmake in python (or javascript), but cleanly,
> using the combined knowledge of several years of evolution.
> >
> > Why the cmake team chose to build their own godawful scripting language
> is a mystery to me. I suspect someone just wanted to write a DSL one day
> and it all got way out of hand (original poster, please take note!)
> >
> > R
> Sorry, but I still don't understand what you are trying to say. (I don't
> agree that CMake would be great if it used a better language. I think it
> is flawed on multiple levels. The fact that it wants to be a build
> system generator rather than a build system probably being the central
> issue.)

The abstract build system generator feature of cmake is what makes it
uniquely useful to me (and half* the world)

> But, to get back to the original topic (which was the Faber
> announcement): have you looked at it (either the docs or the code) ? Can
> you substantiate your claim that it doesn't meet the points in your
> shopping list above ?
> I have looked at the docs an the code. You cannot describe a c++ project
in abstract terms with faber, just as you cannot with bjam or make. You
still need to know the exact command line options to set for your
particular compiler and target system.

System discovery of build host and target is very important. This is why
gnu autotools was created. The complexity of gnu autotools I suspect was
the driver for the creation of scons and cmake. They are better, but not
good enough.

We don't need** another make. make et-al are good enough for managing
dependencies. We do need** a better, more intuitive means of describing a
project and its dependencies in a platform-agnostic manner.

> --
> ...ich hab' noch einen Koffer in Berlin...
> * "half the world" - is a rough finger-in-the-air estimate of the
population of c++ developers who need more than a simple makefile (i.e.
most of them).

** my opinion

> _______________________________________________
> Unsubscribe & other changes:
> mailman/listinfo.cgi/boost

Boost list run by bdawes at, gregod at, cpdaniel at, john at