Den sön 10 maj 2026 kl 21:12 skrev Timofei Zhakov <[email protected]>: > > 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]>: ... > > > 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? >
- Simplify by removing the msbuild/Visual Studio (=vsnet) generator once CMake is stable (and feature compatible) - Build generators hard to maintain. - EZT being anything but EaZy<sic> (and say Sorry Greg) - Replacing EZT with something else not likely to be a significant improvement. > > @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. Agree! Your plan LGTM. > > > 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 Cheers, /Daniel
