On Fri, May 8, 2026 at 9:43 PM Daniel Sahlberg <[email protected]> wrote: > > 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!
I think I miss it a little bit, but could you please clarify which four are you referring to? > @Timofei Zhakov and @Jun Omae: You seem to be our most experienced > developers on Windows. What is your take on CMake versus Visual > Studio? It was the idea with vcnet from the very beginning. If we get to the point where our cmake build can do everything that it used to, and everyone is familiar enough/got used to this build system, then it's a good time to drop it. However, I believe it's not really the case yet. I think we might go with a plan like this; CMake is "experimental" in 1.15, "recommended on windows" in 1.16, and "the only available on windows" in 1.17, assuming I'm not too optimistic. Also speaking of vcnet generator on its own, it's really a 1500+1000 lines of spaghetty that collects all the logic ever added throughout the entire lifetime of the project. That is not even remotely testable on non-windows environments. You can from say the same about autoconf, but since it's the baseline that everyone knows to work with, it's a good, although imperfect just like every other build system could be. I believe any step from this would be an improvement. > 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. Well, read the last paragraph... -- Timofei Zhakov
