I think the best course of actions for now is to keep the current Visual Studio project manifest as-is, while ensuring that the new build system also works on Microsoft Windows. Investigating whether it is worth it to drop the handwritten manifest (either requiring developers to have the build tool configure a customized manifest or the possibility of generating a manifest that can be checked into VCS) can be done at a later date by someone with a Visual Studio license.
2 Likes
We’re not in comparable situations – you’re an expert on windows, a CPython core developer and an employee of Microsoft, I’m an unpaid volunteer with no clear path to get a something that’s a non-primary concern for CPython (unvendoring dependencies) into the bespoke windows build system here, and then keep it working.
It would be great to have a supported USE_SYSTEM_LIBS switch, but given the hurdles for that, the lowest energy state is to just keep fixing things minimally when rebasing our patches.
It makes sense to maintain the list of source files in the build configuration, and it makes even more sense to do it in one place, which is trivial[1] to do even if there are platform differences
foo_sources = [
'src/foo/bar.c',
... # can be a list of 100s of files
]
if host_machine.system() == 'windows'
foo_sources += ['src/foo/win_magic.c'] # likewise
else
foo_sources += ['src/foo/unix_magic.c']
endif
foo_lib = static_library('foo_lib', foo_sources, ...)
I appreciate the difficulty of changing a product. My point is that it’s putting the cart before the horse to let the trillion dollar company dictate its toolchain constraints to the FOSS project[2]. If python decided to make the change on its merits, Microsoft would be able to follow, even if the transition takes a while.
That said, I agree with the following, so probably best to table this discussion for now.
3 Likes
I was implicitly (too implicitly, clearly) offering help, and potential upstream changes to make it more accommodating 
I’m obviously in an “unfair” situation here, as the author of the current build system, but I intentionally made devendoring possible without directly patching the files, and possible for anyone running a build regardless of where they work.
No such thing can exist - these are not system libs on Windows, so there’s no more official convention for layout than what we’ve invented. What there is, is a “supported”/intentional override of the paths to find the sources. They do need to be the same shape as our source/binary packages, but that’s not too difficult (and the platform specifications are in the paths, so you can provide paths direct to DLLs). So you can generate a .props file specifying all the paths, or set all the environment variables matching the property names, and they’ll override the normal build.
This isn’t a Microsoft preference - it’s my preference having observed how contributors interact with our project (CPython), and having heard feedback over the years from people developing and debugging CPython. Including other core devs, who I won’t embarrass by outing them as Windows users, but there are a number who have clearly appreciated the simplicity of being able to open the project and build.
And once more, my preference is for the experience, not specific tools. Offer an equivalent (and equivalently accessible) experience and I’m not going to object.[1]
Or I’m only going to object over the transition process, and not the destination
↩︎
3 Likes
Thanks, I appreciate it!
It was a throwaway name (based on how other projects have named such variables). “Pick up libraries and headers from this PREFIX” would also work; for the .props file approach I’d need to see a more concrete example. Should we move this discussion to an issue?
We’re in agreement there. That’s what I meant by:
3 Likes
Some years ago, I wrote meson build files to be able to build
early python 3 releases.
They worked on linux to both compile a linux binary as well as
to cross compile a windows binary using mingw.
I was actually surpised by how easy it was to ‘convert’ the
makefiles to meson. The hardest part were the patches of
the source code to make cross compilation work.
It’s still available at :
But no longer maintained … we rewrote those parts of the code that needed cross compile to c++ …
1 Like
Well, but the person who said that isn’t a muon developer. At best, it can be read as an educated guess, not a promise of anything. Supporting a new platform is not trivial, especially in C.
It’s true that I don’t have a significant number of patches in Muon, but I do share work with them (I’m a Meson developer and have a fun hobby of a third Meson implementation, though nowhere near as complete as Muon). Muon came into existence specifically because of concerns about bootstrapping on Unix-like OSes, and most of the upstream devs share the view that it is incredibly useful to have an implementation that can be used for that purpose, and would be willing to do work to get there for major projects like CPython. I would.
3 Likes
As this discussion kind of fizzled out, let me summarize things that have come up since
- I have had informal “hallway track” discussions with a few Python developers and they at least would like to see this get done.
- I would be happy to help people with the transition and getting new features into Meson itself if needed.
- This feature needs someone inside the main development team to take the initiative to drive the work. This is the sort of change that has to come from within.
5 Likes