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

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

Stephan wrote:

> In case it isn't obvious: I very much welcome collaboration, so if you
> want to contribute (be it more tools or even entirely new
> functionality), I'd be happy to talk.

Nothing would please me more than to be able to dump the horrific syntax of
cmake. I have often thought that python would be the obvious language for a
replacement. There was of course a similar tool called SCONS once, which is
python also. It seems to have fallen by the wayside.

What has prevented me making a start on a conversion is having recently
used node and npm. It seems that the rest of the world has converged on
javascript as the development script tool of choice.

I am strongly of the view that c++ needs a standard tool for build, IDE
project generation, toolset selection, dependency management, testing and
deployment. I find it deeply disturbing that one cannot simply write a
project that pulls in 3 or 4 libraries and then cross-compile it for any
target with one command.

It really should be as simple as:

build install --target=iOS10 --build_dir=[auto]
--install_dir=installs/iOS10 # an auto build dir would be named using a
hash of the target toolset, etc.
build install --target=[this-host] --build_dir=[auto]
--install_dir=/usr/local
build install --target=fedora25-docker --build_dir=[auto]
--install_dir=installs/dockers/fedora25

-j <cores_on_this_host> should be implied unless specified

wouldn't it get wider update/support though if it were in javascript and
available on npm? In this case at lease the dependency management of source
code is handled already?

On 21 November 2017 at 21:35, Stefan Seefeld via Boost <
boost_at_[hidden]> wrote:

> On 21.11.2017 15:02, Richard Hodges via Boost wrote:
> > The hard questions:
> >
> > 1. Can it cross-compile to iOS, android, OSX, linux and windows out of
> the box? (i.e. without me having to specify any magic command line options,
> environment variables or write any nasty scripts in some new syntax)
>
> Yes. (In principle, that is: So far I have focused on the design and
> infrastructure. I know that it works, having (cross-)compiled with gcc,
> clang, msvc, on Linux and Windows. There are still a lot of holes that
> need to be filled by people who have access to the respective platforms
> and tools.)
>
> > 2. Can it identify, download and build dependencies automatically, using
> the correct toolset?
>
> I'm not a fan of automatic downloads, though I don't see any reason why
> such functionality couldn't be layered on top. All that is needed is a
> convention for storing and handling the associated meta-information.
>
> > 3. Will it create install scripts?
>
> Likewise: adding packaging logic is (mostly) just a matter of adding
> package meta-information as well as some tooling. The design fully
> supports that. (It might be a good idea to add some sample package
> generation logic to the next release, based on which other package
> formats could be added later.)
>
> > 4. Will it package executables and libraries for later consumption?
>
> Same answer.
> > 5. will it build and deploy directly into docker?
>
> Can you describe the workflow you have in mind ? I'd expect the above
> package building being the missing link. Everything beyond that seems
> out of scope for a build tool.
> > These are the only questions I have regarding a build engine.
> >
> > At the moment I use CMAKE with Hunter and Polly. Although it has a
> hideous syntax, this combination at least fulfils the basic requirements of
> a c++ cross-compiling build system in the modern age.
>
> As I mentioned earlier, Faber should be feature-compatible with
> Boost.Build. It's offering a different frontend language (Python), and
> simplified logic (no "meta targets" etc.).
> The main focus is easier use and extensibility than Boost.Build.
> Everything from configuration, to testing and packaging is fully in
> scope. But given that it can be used as a library, I'm sure that people
> can come up with very different use-cases. and simply embed it into
> other applications.
>
>
> In case it isn't obvious: I very much welcome collaboration, so if you
> want to contribute (be it more tools or even entirely new
> functionality), I'd be happy to talk.
>
> Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>