Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

meson: Don't call find_program objects with python #100

Merged
merged 1 commit into from
Feb 8, 2017

Conversation

nirbheek
Copy link
Contributor

On UNIX-like OSes, the OS will read the shebang and use the correct interpreter, and on Windows, Meson will read the shebang and use the correct interpreter.

Adding it manually will cause python to try to interpret python.exe

With this change, libepoxy builds and the tests pass with MSVC on Windows for me.

On UNIX-like OSes, the OS will read the shebang and use the correct
interpreter, and on Windows, Meson will read the shebang and use the
correct interpreter.

Adding it manually will cause python to try to interpret python
@ebassi
Copy link
Collaborator

ebassi commented Jan 28, 2017

Interesting; I did add the explicit Python call because of MSYS2 build errors. Can you confirm that it still builds with Meson 0.37 on MSYS2?

@nirbheek
Copy link
Contributor Author

I tested this on native Windows and on MSYS, but not on MSYS2 since I don't use it. However this is how we do things in GStreamer too and other people have tested that it works there. Will confirm and report back though!

You might also see a PR adding AppVeyor CI support to build with MSVC and MinGW. :)

@nirbheek
Copy link
Contributor Author

So it doesn't work on MSYS2, because there Python 3.5 is called python3.exe and python3.5.exe but not python.exe. So #!/usr/bin/env python in the gen_dispatch.py can't find python.

The fix is to use #!/usr/bin/env python3 as the shebang, but that will not work on native Windows with Meson 0.37.1 since Python 3 installs itself as python.exe with the Windows installer. However, Meson 0.38 will correctly use sys.executable on Windows when it encounters python3 in a shebang, so it should be ok to do that in the long run.

@nirbheek
Copy link
Contributor Author

I will note that this same problem also occurs on Linux distros since no one ships Python 3 as python.exe. Essentially Python 2 is required on all platforms for building libepoxy, and if you install Python 2 inside MSYS2 it builds just fine.

@ebassi
Copy link
Collaborator

ebassi commented Feb 7, 2017

Ideally, no: Epoxy should build with Python 3.

The only reason why Python 2 may be used is because of older, enterprise-y environments — see issue #43.

I guess we need to change gen_dispatch.py to take the right version of Python in the shebang line, i.e. using something like:

#!/usr/bin/env @PYTHON@

and then replacing @PYTHON@ with either python3 or python depending on the environment. Older OSes can still use the autotools build until they ship with Python 3.4.

@nirbheek
Copy link
Contributor Author

nirbheek commented Feb 7, 2017

I was hoping there's a way to avoid that, but such is life. ;)

@ebassi
Copy link
Collaborator

ebassi commented Feb 8, 2017

Okay, so I kind of changed my mind, given that Epoxy has to build on platforms without Python 3, which means we're going to keep gen_dispatch.py compatible with Python 2 for the foreseeable future.

I'll merge this PR, and then update the documentation to say that we require Python 2 for building Epoxy.

@ebassi ebassi merged commit 5c4a907 into anholt:master Feb 8, 2017
@nirbheek nirbheek deleted the fix-find_program branch February 8, 2017 16:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants