[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Future of Managed Build
|
> On 1 Feb 2020, at 12:06, Alexander Fedorov <alexander.fedorov@xxxxxxxxxx> wrote:
>
> Ideally the "base builder" should update "derived" (most probably generated) build manifests for a third-party tools (ninja, why not), run it and utilize the output.
I'm not sure what this means, so, if you plan to write some wiki pages, probably you should start by defining the terms.
---
In my tools I differentiate between a 'basic project builder' and a 'full build generator'. The later is an all purpose tool, that uses both structured files (JSONs) and scripting (JavaScript) to construct the build graph and finally to generate a builder configuration (like ninja.build).
The basic builder (xpbuild) is more like a CLI version of the current CDT MBS, which takes a set of source folders plus simple rules (like based on file extensions) and builds artefacts of predefined types (like executables and libraries). The simplicity of the basic builder should be reflected in the JSONs used to store the configurations (which should not require a PhD to write by hand, like cMake configurations).
I think that a basic builder should cover the majority of projects (75-80%?). Adding support for simple pre/post actions may increase this to, let's say, 90+%.
Scripting support in the full builder should cover the rest.
I think that a good example of a complex project is clang, which uses cMake to generate a (quite large) ninja file, then runs a parallel build faster than anything else I could see.
My design is no there yet, but I think that trying to cover the clang use case would be a good starting point.
---
There is one more design detail that I would like to mention, which is project configuration.
This is a vast topic, that covers functionality from autoconfig/automake (which I plan to support in the full builder, via scripting), but also from tools like kconfig (which I plan to support via a separate tool, xpcdl, inspired by eCos CDL).
Regards,
Liviu
