I opened a PR at virtualenv to get things working smoothly.

It seems virtualenv is in the middle of a major rewrite so it won't be fixed for python 2 for at least 1-2 months.
I think providing a way to test what's built, even if only in python 3, it's better than nothing.
Opening for review.

If there is an option for omit this test? Package may depend on 64 bits only library (compiled external). And there is no option for change python installer on 64-bits without fork.

If there is an option for omit this test? Package may depend on 64 bits only library (compiled external). And there is no option for change python installer on 64-bits without fork.

If a package depends on 64 bits only library, then it should not be deployed as an intel wheel (condition to trigger 32-bit tests). IMHO, if cibuildwheel fails to prevent such an upload, it's a major failure of cibuildwheel. I don't even know if such a wheel can be built... maybe you have more insight on that matter.

That being said, if such a wheel can be built, I think you're right in wanting to propose an alternative but that would be another PR. Probably something in the like of having an option to target only x86_64 (even with intel installers like 3.5 where there are no alternative installers, maybe through a delocate option, might need a PR there).

@mayeut But this is current situation. I ask about this in dealocate repository matthew-brett/delocate#56 (comment)

Current revision of cibuildwheel do not allow to choose only 64 bits for macos. And I think that these need to be introduced before merge this PR.

Also I remember that in #156 there shown suggestion to drop intel tag when drop python 3.5.

@YannickJadoul Check your cmake build project if it is multiarch.

But this is current situation. I ask about this in dealocate repository matthew-brett/delocate#56 (comment)

Thanks for the reminder

Current revision of cibuildwheel do not allow to choose only 64 bits for macos. And I think that these need to be introduced before merge this PR.

That I can agree with.

Also I remember that in #156 there shown suggestion to drop intel tag when drop python 3.5

Right, but maybe we can do something in the meantime.

I'll check if I can add a quick test building a 64-bit only wheel.

@YannickJadoul Check your cmake build project if it is multiarch.

Interesting, yes, thanks! Any idea how to best test this? Just run python-32 and try importing?

I see three options:

• Run all tests with python-32.
• Run verbose compilation and check if there are two -arch in flags.
• Run otool -f on all library files.

I found a way to build x86_64 wheel with python 3.5 intel installer. Will be tomorrow for the PR though, it's getting late.
Proposition: the other PR adds an option for targeting x86_64 only on macOS, then this PR can always run tests when intel is found in the wheel name. My fear is that it will clash with @Czaki PR. Given that his wheel PR has been merged, maybe we can hope for something soon and merge those PRs after #156.

@Czaki

Run all tests with python-32.

Grrrrmbl, I imported it and get an error :-( Thanks for mentioning this!

EDIT: It would be nice if delocate had noticed this, but OK...

@YannickJadoul you can participate in this discussion matthew-brett/delocate#56
I think that in future release dealocate with deal with it.

@Czaki Thanks. But it's maybe my own fault/problem, if I'm calling CMake. Btw, do not that I'm still calling wheel and setup.py and only then CMake (through a custom build_ext in setup.py). So the file and wheel names etc are nicely handled by setup.py :-)

@YannickJadoul Ia all libraries on which you depend is build by your cmake, or you have some external dependencies (if the folder .lib in wheel is empty? - it may be hidden)?

@Czaki No, I don't think so. Everything is just included in the compilation.

blocked waiting for #220

What did you think to use --require-archs option in delocate? https://github.com/matthew-brett/delocate/blob/3e2364bd4e92b9d4ca35e8ce46510925d38befc2/delocate/cmd/delocate_wheel.py#L40-L43

@Czaki, yes, I saw that and I'm going to add it to the PR on intel vs x86_64 option

Closing in favor of #220 (only build x86_64)