Den ons 6 maj 2026 kl 09:53 skrev Branko Čibej <[email protected]>: > > On 6. 5. 26 08:58, Timofei Zhakov wrote: > > The cmake build currently requires a generated by gen-make.py script > file where all the targets are defined. I think we might now consider > moving towards more conventional design where those are hand written > and directly. > > Why is this helpful? As the build configuration grows, we get more > special cases that are much easier to express in cmake directly. > > However, this decision would also mean supporting two lists of targets > at once (the build.conf and cmake) that might cause the build to > differ. I believe cmake might replace vcnet generator but I'm certain > that we would still maintain autoconf for a long while. > > > We will maintain the Autotools build for quite a bit longer than a long > while, IMO. > > We might instead hand-write the complex parts (like for example swig > binding) in cmake directly but keep targets.cmake design for libs, > tools, and tests. > > > We want one place that defines dependencies, regardless of which build system > is used. Anything else will quickly go out of sync. > > Alternatively, this would probably be helpful to have targets.cmake > tracked in the repository. This way it's probably more convenient for > users to compile the trunk. But also every time a C file is created or > either build.conf or build/generator/gen_cmake.py is changed, one > should rerun gen-make before committing. On the other hand, if an > unintentional change in targets.cmake is accidentally made, we have an > easy way to spot why and when it happens. > > What do you think? > > > We shouldn't commit targets.cmake for the same reasons we don't commit > build-outputs.mk: they're generated files and except in very limited cases, > we don't commit those. > > -- Brane >
(GMail doesn't seem to understand the quoting used by Brane's MUA. Thus it is difficult to discern which parts above are written by Timofei and which are written by Brane. https://lists.apache.org seems to do the right thing). I would love to reduce the complexity of the build system and I think I understand the issues of generating the targets.cmake from the ezt template. However I agree with Brane that we want ONE place to define dependencies and relationships. That said, I don't see a problem to add extra properties to build.conf that help controlling the CMake build system. If it helps, we might create different modules if it helps simplify the generation of targets.cmake (possibly creating several targets_X.cmake files if it makes the EZT templates simpler). Kind regards, Daniel
