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
