On 16. 3. 26 20:41, Timofei Zhakov wrote:
On Sun, Mar 15, 2026 at 11:24 PM Branko Čibej<[email protected]> wrote:
On 15. 3. 26 17:21, Timofei Zhakov wrote:
Hi All,
Building Serf 1.3.10 on Windows with MSVC 14.5 using SCons build system
currently fails because the "MSVC version is not recognised". Also the
error is only generated when making a Debug build.
The error message looks like this:
[[[
scons: *** Invalid value for enum variable 'MSVC_VERSION': '14.5'. Valid
values are: ('14.3', '14.2', '14.1', '14.0', '12.0', '11.0', '10.0', '9.0',
'8.0', '6.0')
]]]
After some investigation, I found that there is an explicit list of what
versions are supported [1]. However, I didn't find any references to the
variable it sets (MSVC_VERSION).
I'm not an expert in scons. Perhaps someone else could point out how this
actually works, but from my perspective I don't see a reason for this
parameter to exist in the first place. If it's a scons thing, that it
requires that variable to be pre-configured, at least I don't
think we should explicitly limit compiler versions to a specific collection
of values.
With MSVC, you never know...
That's what it's consistent at..
Although if anything breaks with a change of a compiler, it would not
be the serf's fault. The codebase follows the C language standard. If
any implementation violates it in any way, then it's *their* problem.
The library itself should whitelist all compilers that we specifically
tested on and can assure that it works for us. In my opinion, the
distribution is responsible to deal with that in such a case.
I think a minor change update of the compiler should not be
causing a well-functioning build configuration to suddenly start failing.
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.
As the saying goes, premature optimisation is the root of all evil.
-- Brane
