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