Build on Windows

[maedoc]

I'm trying to build this on Windows for Python 3.6, since I'd like to use Loopy in a project, where we ship packages to Mac, Linux & Win. I've started by trying to see if MSVC 14 could build ISL, but I'm becoming sceptical:

A few things I've done in isl/include/isl/ctx.h,

#define __attribute__(...)

and in isl/isl_arg.c:20 to

static struct isl_arg *help_arg;

Finally, I'm seeing at the end of the build

isl_hash.obj : error LNK2001: unresolved external symbol ffs
isl_stream.obj : error LNK2001: unresolved external symbol strcasecmp
build\lib.win-amd64-3.6\islpy\_isl_cffi.pyd : fatal error LNK1120: 2 unresolved externals

It looks like strcasecmp is a known one and ffs is a GCC builtin, so those can likely be mapped to Windows equivalents.

I'm worried that ignoring __attribute__ might hurt ISL correctness.

Another route would be to compile it all with GCC on MinGW 64, but I'm not sure how compatible this would be with the standard Python packages. Could that be used to produce wheels, etc?

edited to increase SNR

[maedoc]

And a workaround for ffs from Cairo,

#include <intrin.h>
#pragma intrinsic(_BitScanForward)
static __forceinline int
ffs (int x)
{
    unsigned long i;
    if (_BitScanForward(&i, x) != 0)
	return i + 1;
    return 0;
}

With that sprinkled in a few places, the project builds, fwiw.

[inducer]

I'm trying to build this on Windows for Python 3.6, since I'd like to use Loopy in a project, where we ship packages to Mac, Linux & Win.

Awesome. I'd also like to update https://github.com/conda-forge/islpy-feedstock to include Win support then.

I'm worried that ignoring attribute might hurt ISL correctness.

I don't think there's a worry there.

[inducer]

FWIW, conda-forge now has Windows builds of islpy: https://anaconda.org/conda-forge/islpy

[ahmet-umut]

I used @maedoc's 9ef49848c4d507816d39fc6106c435678a22fa4f commit and applied it to the current main branch of islpy -cloned in my local. Then proceeded with making necessary changes in order to create a pip-installable build that works in my Windows. I then made necessary changes to upload this to PyPI. It seems to work in my computer, but I have not made extensive tests since I have no idea how to use islpy. For the readers of this comment: Feel free to try it if you are desperate enough to install islpy or any dependent package in Windows and give me feedback...

You can use pip install islpy-windows to try it.

[inducer]

Thanks for all the work. That said, I think from a user's perspective, it would likely be better if Windows wheels were built within the existing cibuildwheel setup used to release islpy.

There is a decent chance that the isl-on-Windows patches in conda-forge would suffice to make that happen. I'm unlikely to work on this myself, but if anyone cares enough to create a PR, I would be happy to consider it.

[ahmet-umut]

Would you (or anyone) consider handling the cibuildwheel side, if I fork islpy and remake the necessary changes for it to build from source -with the right commands- for Windows (which I already have done before)? Because, I do not know about the cibuildwheel system. If anyone'd care enough for this to be done, I can collaborate.

[inducer]

#199 is a weak-sauce attempt at Windows support. It fails almost immediately. If you can tell me what needs to be fixed, I might be able to do that.

[ahmet-umut]

Please pardon my lack of knowledge about this concept -if any. I am observing a pull request here in the link, whose purpose is to merge to main. While I guess usually wheel builds use the main branch, I think for Windows, the needed changes -those I have done for myself- are so conflicting with the main branch that there may be a need to open a "windows" branch and make the necessary changes there to experimentally support Windows (I am telling "experimental" here only to say that I did not extensively test the build, but it seems to work nevertheless.). This might bear its own problems like the windows build may become outdated, but it will be a separate issue to solve.

So, can we use a separate branch for Windows builds? If you say so, I can collect and then provide you the necessary changes to that branch via a fork or similar, to continue.

I might be overcomplicating things here. Please tell me if so.

[inducer]

For a variety of reasons, using a git branch is logistically tricky. Instead, what the linked PR does is gather up the needed changes in a patch that is applied as part of the Windows build process.