|
Boost : |
Subject: Re: [boost] Announcement: Faber, a new build system based on bjam
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-11-21 20:35:59
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...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk