Pebaz / nimporter

Compile Nim Extensions for Python On Import!
MIT License
821 stars 33 forks source link

use python with mingw on windows #59

Closed retsyo closed 2 years ago

retsyo commented 2 years ago

The closed issues made a change as

    - (['--cc:vcc'] if sys.platform == 'win32' else [])
    + (['--cc:vcc'] if shutil.which('vccexe') else [])

which looks reasonable, but should it be( sorry I have not use MSVC for a long time, cl.exe is valid for VC 6.0)

    - (['--cc:vcc'] if sys.platform == 'win32' else [])
    + (['--cc:vcc'] if shutil.which('cl.exe') else [])

however in current code, this change is lost again:

    NIM_CLI_ARGS = [
                       '--opt:speed',
                       '--parallelBuild:0',
                       '--gc:refc',
                       '--threads:on',
                       '--app:lib',
                       '-d:release',
                       '-d:strip',
                       '-d:ssl',

                       # https://github.com/Pebaz/nimporter/issues/41
                       '--warning[ProveInit]:off',

                   ] + (['--cc:vcc'] if 'MSC' in sys.version else [])

which is definitely wrong because sys.version tells which C compiler is used to compile the python.exe, but can not tell whether python.exe runs in MSVC or mingw circumstance

Pebaz commented 2 years ago

The vccexe program comes with Nim for Windows and it goes through all the trouble of finding an MSVC installation for you. I did some digging and it looks like that is the same strategy that other languages have taken in the past (like Jai). It looks like the alternative is to require the user to run Python programs using Nimporter from the "Developer Command Prompt" which is not very user friendly.

As for the Python using MSVC but Nimporter using MinGW, I actually specifically designed against that use case when I wrote Nimporter because of all the issues that could crop up because of mixing two different compilers (which shouldn't be a problem I know but C software has a ton of incompatibility and strange "implementations are free to ..." issues because of the C spec).

Now, to get you up and running, you could access the NimCompiler.NIM_CLI_ARGS list directly and modify it as you see fit. In fact, I think I will add that to the README as a viable way of controlling the default arguments. It's even in Python so you get to do custom arguments per platform. Just remember to do this prior to importing any Nim extension modules.

An example would be:

import sys
import nimporter

if sys.platform == 'win32':
    nimporter.NimCompiler.NIM_CLI_ARGS = [...]
else:
    nimporter.NimCompiler.NIM_CLI_ARGS = [...]

import the_extension_module

Although, another route would be to use the nim.cfg mentioned here.

Let me know if that doesn't fit your use case and I'll see what could be done. :)

retsyo commented 2 years ago

Thanks for reply. It seems feasible to mention something in README like

import sys
import nimporter

if sys.platform == 'win32':
    nimporter.NimCompiler.NIM_CLI_ARGS = [...]
else:
    nimporter.NimCompiler.NIM_CLI_ARGS = [...]

import the_extension_module