[
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 18:54, Liviu Ionescu <ilg@xxxxxxxxxx> wrote:
>
> ... project configuration.
What I poorly tried to explain is that this is a complex subject; some tools (like cMake) try to combine it with the builder; other tools may choose to split some functionality to a separate tool.
The configuration step may include one-time pre-build operations (like auto-detecting system capabilities, or choosing one of multiple cross tools for different architectures), but also application options, that can be changed at any moment during the project life time (like thread stack sizes, queue sizes, etc).
Changing some of these options are reflected only in the content of some header files included in the build, and the builder should be perfectly able to handle the dependencies, but some changes may be reflected in different files being added to/removed from the build, for example when building a portable project for different platforms/architectures.
To be noted that the pre-build system capabilities auto-detecting step (introduced by autotools, and took to the extreme by cMake) is not a mandatory step. The other choice is the npm/xPack philosophy: instead of detecting the existing capabilities and trying to make the best use of them by 'bending' the project after them, it is easier to compose the project from mandatory packages (executables and sources) and have a dependency mechanism bring into the project exactly the needed versions.
---
These are generally tricky issues, and the exact demarcation line between tools is hard to draw.
In brief, a build system must acknowledge that project configuration should be addressed somehow, either internally or externally.
Regards,
Liviu
