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
Next round of X.org libraries #2214
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
I *think* the way I've done it, conda will not become convinced that the package needs to be built for multiple Python versions? Let's find out.
You know, I noticed that I overlooked the '|lower' but I thought to myself that there was NO way that would ever come back to bite me. Well, here we are.
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
Looks like I need toolchain packages, and I need to build for all of the Visual Studio variants.
Windows builds delegate to the build.sh script, but that meant that build.sh was getting environment variables like $PREFIX with Windows-style paths. Problems if they were ever echoed, etc. Transform the key paths in bld.bat, then. We also add the -x option when running bash on the build script so we can trace it better.
Since where are things that basically do `echo $(which programname)` in configure scripts. I wonder whether our setting of %PATH% in the batch script will mess it up? Let's find out.
Kicking CI; key AppVeyor build seems not to have gotten registered. |
Also I highly suspect that you have to add Python as a build-time dep to get the builders to matrix across the different 'vc' versions.
Not optimistic this will fix my current build error, but if the Cairo experience is right, this change is important anyway.
xtrans.m4 checks for being on Windows by looking for mingw, not msys, so its defaulting doesn't work.
So it turns out that on Windows alone, libICE depends on libX11 to build. So I need to do a different direction down the stack to get those things going. So let's just get the next three packages in for now.
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
Finally! We laughed, we cried, we learned. Should be good to merge. |
- m2w64-pkg-config # [win] | ||
- pkg-config # [not win] | ||
- posix # [win] | ||
- python >=2.7,<3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar question. Can we add skips for these versions of Python. Also, does it not build with Python 3?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Python code does not appear to be compatible with Python 3 — print
is used as a keyword in xcbgen/xtypes.py
.
As with gobject-introspection
, I'm pretty sure that the builders don't matrix over the Python versions as-is, so I don't think a versioned skip would be helpful? If I'm understanding your question correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the skip statement above you don't really need this here. But it does not hurt to leave it there.
Impressive. Just the Python version question |
090b44e
to
5e457b0
Compare
CI finally finished; should be good to merge. |
Thanks @pkgw! |
These are a bit more complex to build than the proto packages but I've checked out their internals and I think I have their dependencies right.