Den tors 7 maj 2026 kl 23:37 skrev Branko Čibej <[email protected]>: > > On 7. 5. 26 20:52, Daniel Sahlberg wrote: > > 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). > > > One way to make the build simpler is to remove all the EZT msbuild/Visual > Studio generators once the CMake build is considered stable on Windows. > > That said, the build generator is notoriously hard to maintain. I was > reminded of that just recently when I saw how much effort was avoided by > open-coding certain JavaHL build specifics in Makefile.in instead of > extending the generator. A lot of that is due to EZT being anything but EZ to > read and maintain. Sorry, Greg. :) > > On the other hand, replacing EZT with anything else (Jinja2 comes to mind) is > not likely to be an improvement; generic templates are hard, not just in C++ > ...
+1 to all (four) of these! @Timofei Zhakov and @Jun Omae: You seem to be our most experienced developers on Windows. What is your take on CMake versus Visual Studio? Speaking as part of the TortoiseSVN community: We have our own build system based on nant, where all dependencies are manually hardcoded. For TortoiseSVN it doesn't matter what build system Subversion ship. Kind regards, Daniel
