Just copying over things form unix/mpconfigport isn't ideal imo. Things like setting MICROPY_ASYNC_KBD_INTR to 1 make little sense because the code using that doesn't even get compiled on windows. How about just adding what you actually need?

Things like setting MICROPY_ASYNC_KBD_INTR to 1 make little sense because the code using that doesn't even get compiled on windows.

Valid point, I do need to go through them each and make sure they work. Many things did look like they do work correctly with the config setting though (like float/maths functions).

I would really like the windows port to be a first class citizen alongside UNIX with as close as possible to feature parity, ideally running the same full test suite.

At the moment pretty much every time I want to use it for something that works out of the box on Linux it needs a custom build with extra settings.

I know there are a few big ticket items missing and signals and select are always going to be limited, but I'm in the middle of thread support currently, then I just need VFS to feel like it's pretty close.

I've been going through all the settings I copied and stripped out the ones that aren't used on windows, thankfully there weren't too many. I'll push this change up once I've consolidated it with some of my other current PR's.

I haven't figured out how to make this easily translate to msvc build though, it's much easier with make.
I'd be inclined to look at cmake now as it's used in some of the other ports, at least that lets you generate build projects for msvc and mingw from the one common set of config files? That would then take us further away from parity with unix build system though.

I haven't figured out how to make this easily translate to msvc build though, it's much easier with make.

I can have a go at that, should be fairly straightforward since it's just a matter of altering some paths, I think; just to make sure: what we want here is that it's possible to have e.g.

msbuild micropothon.vcxproj /p:VARIANT=somevariant

or the counterpart in VS (by setting these in directory.build.props or msvc/user.props or an environment variable or ...)

And then likewise for VARIANT_DIR and BUILD and PROG etc.

I've been going through all the settings I copied and stripped out the ones that aren't used on windows, thankfully there weren't too many.

Could you make it such that this PR is only 'add support for variants' so excluding consistency changes with unix port? Perhaps also separate commits for purely the VARIANT stuff, and the other (manifests etc)? That's easier to reason about and see what needs to be done for msvc.

I'd be inclined to look at cmake

From what I remember when I actively used it (many versions ago though) it was sometimes problematic to get custom things going. E.g. if you look at micropython.vcxproj at the bottom we import files and add a target for generating headers etc; would it be possible to instruct CMake to add that into the project file in the correct spot? Likewise: either we'd have to port everything in the msvc/*.props files or find a way to have them included. Or go for a hybrid solution where CMake is basically used to generate a file with the correct selection of source files and some options and have a 'driver' vcxproj which then adds the custom bits.

I haven't figured out how to make this easily translate to msvc build though, it's much easier with make.

I can have a go at that, should be fairly straightforward since it's just a matter of altering some paths, I think; just to make sure: what we want here is that it's possible to have e.g.

msbuild micropothon.vcxproj /p:VARIANT=somevariant

or the counterpart in VS (by setting these in directory.build.props or msvc/user.props or an environment variable or ...)

And then likewise for VARIANT_DIR and BUILD and PROG etc.

Ah that's great to hear that something like this should be possible with msbuild - I'm hoping there's a strategy we can use to minimise duplication of effort between the msbuild / mingw build systems. Alternatively, a couple of paragraphs of developer docs might suffice too to just describe what aspects need to be copied between makefile / vcxproj snippets.

I've been going through all the settings I copied and stripped out the ones that aren't used on windows, thankfully there weren't too many.

Could you make it such that this PR is only 'add support for variants' so excluding consistency changes with unix port? Perhaps also separate commits for purely the VARIANT stuff, and the other (manifests etc)? That's easier to reason about and see what needs to be done for msvc.

You're right, that makes far more sense - I'll definitely do that.

I'd be inclined to look at cmake

From what I remember when I actively used it (many versions ago though) it was sometimes problematic to get custom things going. E.g. if you look at micropython.vcxproj at the bottom we import files and add a target for generating headers etc; would it be possible to instruct CMake to add that into the project file in the correct spot? Likewise: either we'd have to port everything in the msvc/*.props files or find a way to have them included. Or go for a hybrid solution where CMake is basically used to generate a file with the correct selection of source files and some options and have a 'driver' vcxproj which then adds the custom bits.

Yeah it's been a good few years since I've used cmake too - I only suggest it as I know a couple of other ports have had to bring in some usage of it lately, and it's a build system that works with both of these compilers. But yes there's a lot of build infrastructure in the existing systems that would likely be a fair bit of work to re-write in cmake, or anything else for that matter.

I've trimmed this PR down to include just the basic variant support, the other things that were previously here will be cleaned up and pushed to their own commits when ready.

Ok so I forgot that variants also have .mk files. To get the same with msbuild there are 2 viable options:

• separate file with the msbuild xml to do the same
• assume that these .mk will only contain simple variable (?)= value lines, parse them and convert to msbuild

The latter seems very doable and means only one file to control options, but is also a bit of a trick and might break at some point. And doesn't allow differences between msvc and mingw variants. So I'll go for the former.

@stinos does @andrewleech need to respond to your comments, or is everything addressed by your #8032?

Can I just merge this as-is and then also just merged #8032? If not, what needs to be done?

Since this is new code it's better to get it right from the start (instead of adding a commit just next to it to fix it) so most comments should still be addressed; at least removing the .exe in mpconfigvariant because that actually breaks things, the rest is more cosmetic (missing newline, using 'unix' instead of 'windows') but would be nicer to also have that correct.

@andrewleech please let us know when this is ready for re-review.

Thanks for the review @stinos they were some really good points. Should be all addressed now @dpgeorge

@andrewleech looks good but since I rebased my commits onto the last version here the build fails with:

  File "../../tools/makemanifest.py", line 374, in <module>
    main()
  File "../../tools/makemanifest.py", line 283, in main
    include(input_manifest)
  File "../../tools/makemanifest.py", line 70, in include
    exec(f.read(), globals(), {"options": IncludeOptions(**kwargs)})
  File "<string>", line 1, in <module>
  File "../../tools/makemanifest.py", line 65, in include
    with open(manifest) as f:
FileNotFoundError: [Errno 2] No such file or directory: 'C:/projects/micropython/ports/windows/variants/manifest.py'
make: *** [../../py/mkrules.mk:148: build-dev/frozen_content.c] Error 1

My mistake IIRC since I asked if that file could be removed :)
Don't know what is best here? Remove variants/dev/manifest.py as well, or make it not include variants/manifest.py, or restore the latter by means of example?

My mistake IIRC since I asked if that file could be removed :) Don't know what is best here? Remove variants/dev/manifest.py as well, or make it not include variants/manifest.py, or restore the latter by means of example?

I had a failure on my first push without the manifest file too, thought it was resolved by follow up push where I removed the reference to it in the makefile.

Oh, I see, yes it's because the variant file is importing that as the base file.

Yeah for consistency maybe it is best to put back the (empty) file for now to maintain the overall structure.

Yeah for consistency maybe it is best to put back the (empty) file for now to maintain the overall structure

Yes I think that's the best option, to create an empty variants/manifest.py. At least then it matches the unix port's structure.

I think that's the only remaining point.

Yes I think that's the best option, to create an empty variants/manifest.py. At least then it matches the unix port's structure.

Done

The appveyor build is failing:

Build FAILED.
       "C:\projects\micropython\build.proj" (default target) (1) ->
       "C:\projects\micropython\ports\windows\micropython.vcxproj" (default target) (4) ->
       (MakeQstrDefs target) -> 
         C:\projects\micropython\ports\windows\mpconfigport.h(30): fatal error C1083: Cannot open include file: 'mpconfigvariant.h': No such file or directory [C:\projects\micropython\ports\windows\micropython.vcxproj]
         C:\projects\micropython\ports\windows\msvc\genhdr.targets(79,5): error MSB3073: The command "cl.exe /nologo /IC:\projects\micropython\ /IC:\projects\micropython\ports\windows\ /IC:\projects\micropython\ports\windows\build\ /IC:\projects\micropython\ports\windows\msvc /D_USE_MATH_DEFINES /D_CRT_SECURE_NO_WARNINGS /D_CRT_NONSTDC_NO_WARNINGS /D_MBCS /DNO_QSTR /FiC:\projects\micropython\ports\windows\build\genhdr\qstr\py\argcheck.pp /P C:\projects\micropython\py\argcheck.c" exited with code 2. [C:\projects\micropython\ports\windows\micropython.vcxproj]
    0 Warning(s)
    2 Error(s)

Maybe there needs to be some include path added somewhere to the micropython.vcxproj file?

Yes, that gets fixed in first commit in #8032. I'm fine with that one getting merged with this one to get one commit which builds correctly.

Yes, that gets fixed in first commit in #8032. I'm fine with that one getting merged with this one to get one commit which builds correctly.

Ok, thanks, I'll do that.

Merged in 05ed19e, with first commit from #8032.