On Mon, 6 Apr 2026 at 18:45, Daniel Sahlberg <[email protected]> wrote:
> 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? > > I am +1 to remove MSVC version mapping. -- Ivan Zhakov
