Den tors 19 mars 2026 kl 21:37 skrev Timofei Zhakov <[email protected]>:
> On Wed, Mar 18, 2026 at 1:27 AM Branko Čibej <[email protected]> wrote: > > > > On 17. 3. 26 21:35, Timofei Zhakov wrote: > > >>>> Just add 14.5 to the list. And probably remove anything older than, > > >>>> what, 10? I don't think the versions of Windows that used those > > >>>> compilers even exist any more, except possibly in some strange > airgapped > > >>>> environment that may as well use an older version of Serf. > > >>> I'm concerned that by just adding it to the list, because as a new > > >>> version (of MSVC) comes out, it will break the build once again. This > > >>> at least "patches" the problem so I'm still planning to prepare a fix > > >>> for that. > > >>> > > >>> I believe there should be a more elegant and generalised solution for > > >>> the issue of detecting the compiler. > > >> We're not detecting the compiler. This appears to be a cross-check > > >> between MSVC version and SCons support for it. See SConstruct around > > >> line 187 `if sys.platform == 'win32':`. > > >> > > >> The last changes in this area were in r1909315 and r1909316. I think > we > > >> can handle one commit every 2 years to track this. We can look for a > > >> better way once we decide which build system to keep, CMake or SCons. > > > Okay, can serf release a patch to the build system in a few weeks > > > after a new version of MSVC is out? I honestly don't think so. > > > > > >> As the saying goes, premature optimisation is the root of all evil. > > > That is true, but this is not an optimisation but a design problem. > > > > > > By the way, I found a related issue on scons' github with ~100 > > > comments [1]. They don't seem to come up with a canonical solution. > > > However, I could have missed something from it. > > > > > > [1]https://github.com/SCons/scons/issues/3664 > > > > That's an "interesting" read. > > > > Maybe try removing the MSVC_VERSION completely? But that would break > > older SCons versions... > > Can we perhaps remove the mapping for the existing versions of Visual > Studio per its MSVC version? > > This would revert r1712131 which was justified as: > > [[[ > * SConstruct > Let scons generate the valid options. > Add the most likely next version of Visual Studio to the list. > ]]] > > -- > Timofei Zhakov > A bit late to the party, sorry about that! >From what I understand, this was initially added in r1699590: "Allow specifying which Visual C++ compiler to use when multiple versions are installed.". Already at that time there was a specific allowed_values-list. SCons seems to support a specific list of MSVC versions (see [1]). The map is only to allow you to say MSVC_VERSION=2022 and have SCons change to the internal value of 14.3. I don't see why we should restrict Serf to a specific MSVC version as long as SCons support it. Thus I suggest that we remove the allowed_values argument. Anyone disagree? As for the map, maybe it is a "nice to have" to say MSVC_VERSION=2022 (if you also have 2019 installed) but as Timofei correctly noted, we have to do a new release to support MSVC_VERSION=2026 (=>mapping to 14.5). We could remove the map as well and force the users who have multiple MSVC versions installed to figure out the correct SCons internal version number. Kind regards, Daniel [1] https://scons.org/doc/production/HTML/scons-user.html#cv-MSVC_VERSION
