Closed mfansler closed 1 month ago
Version 2.0.3 will use a vendored version of GLPK is the header is not found.
@szhorvat thanks for the heads up. I gave it a try, but to no avail. Due to our old infrastructure, we still rely on the Makevars.win
and that didn't seem to fallback to vendoring. If interested, the failed run using the packaged Makevars.win
was here: Azure run.
Since that will purge in 1 month, here's a copy of the build log:
For now, I am merging v2.0.3 without a Windows build, since it has been sitting for 6 weeks already.
Thanks for looking into it! You are right, I forgot that this only worked when the configure script could run, meaning not on Windows.
Thanks for looking into it! You are right, I forgot that this only worked when the configure script could run, meaning not on Windows.
Actually, that was what was initially done. The original recipe here simply runs the the configure
script and then copies the result from that over the Makevars.win
. That did in fact appear to use the vendored GLPK, but instead had issues with not finding the libxml2
headers. That may still be the easier path to get builds going again.
Here is that log. I won't copy the full log, but the relevant build kickoff is here:
and the point of failure is here:
However, I should maybe disclose that when the R 4.4 migration rolls out in the next few weeks it is very likely that the decision will be made to drop Conda Forge R Windows support unless someone wants to build out the infrastructure to support R 4.3 and 4.4. Currently, we only support R 4.1 and compile with GCC 5.3.0. So, it may not be worth putting too much effort here.
Thanks for digging into this some more.
It is quite strange that -I/mingw64/include/libxml2
is passed to the compiler yet libxml/globals.h
is not found. Are you able to check whether the file /mingw64/include/libxml2/libxml/globals.h
exists?
Currently the configure script tries to get the libxml2 include paths either by running xml2-config --cflags
, or if that's not available, then using pkg-config --cflags libxml-2.0
. Is one of these (likely the first) returning incorrect values in the conda-forge build environment?
This might be worth looking into even if R on Windows support is going to be dropped. libxml2 is used for much more than just R packages.
when the R 4.4 migration rolls out in the next few weeks it is very likely that the decision will be made to drop Conda Forge R Windows support
@mfansler Is there any news on this?
Yes, actually. Some of the core devs made a significant effort to update the r-base feedstock to provide UCRT toolchain support, so not only will Windows not be dropped, but we will fully support R v4.3 and v4.4.
The migration has started now, so this will get updated once all its dependencies are completed.
I was trying to experiment in #60, but frankly I have no idea what I'm doing. Is there any documentation on how to go about adopting R 4.3/4.4? Perhaps it's better to just leave it until someone who understands the system gets to it, right?
I would just wait. Everything else needs a rebuild first and then this should automatically update. I can keep an eye out for when the PR comes through.
Thank you!
Everything built smoothly and passed the unit tests, so windows builds are back! 🚀
Windows builds were set to skip in #57 due to an issue with not finding GLPK include files. A PR to re-enable Windows support is welcome.