-
-
Notifications
You must be signed in to change notification settings - Fork 12.1k
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
gdal: update proj dependency #94807
gdal: update proj dependency #94807
Conversation
Dependencies |
We're in a bit of bind here. I was able to migrate all dependents of
Any thoughts on the best solution here? |
We can probably update For |
I've looked into how Linux distros have handled I was looking at the project timeline for |
It could be that they just have a stricter definition of "stable" than the one we usually use. It might mean "bug fixes only, no changes at all to the API", which is not uncommon. |
Debian and Fedora ship spatialite-gui 2.1.0-beta. I think we can do the same. |
For what it is worth, here's the librasterlite website - https://www.gaia-gis.it/fossil/librasterlite/index. Two things to note. 1. is that it is no longer maintained and advises using librasterlite. 2. librasterlite and spatialite are done by the same author. spatialite guide website is here - https://www.gaia-gis.it/fossil/libspatialite/index. spatiallite proper is here - https://www.gaia-gis.it/fossil/libspatialite/index. Its current version is 5.01 released in 2021. |
I was leaning towards doing that. I'm going to formula rename of I'm also going to disable |
On second thought, maybe it's better to create |
I was able to successfully build both
Given how deeply this PR has dragged us into dependency hell, I'm inclined now to try to get UPDATE All of the above issues have been fixed except |
As suggested in #95481, we will update
|
mkdir "build" do | ||
system "cmake", "-DWITH_LUAJIT=ON", "..", *std_cmake_args | ||
system "cmake", "-DWITH_LUAJIT=ON", "-DUSE_PROJ_LIB=6", "..", *std_cmake_args |
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.
Where does the 6
come from?
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.
As described here: osm2pgsql-dev/osm2pgsql@552e4bc, the old API for PROJ was actually implemented in PROJ 4, and the new API debuted in PROJ 6. Both APIs were supported in PROJ 6 and 7, but in PROJ 8, the old PROJ API was removed. So the number here is referring the version in which the API was first implemented, not the version currently being used.
May need to check compatibility with PROJ 9, which will be merged with #96103 |
I'm going to disable |
…and librasterlite
It looks like the only thing needed for |
livecheck do | ||
url "https://www.gaia-gis.it/gaia-sins/spatialite-gui-sources/" |
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.
In separate PR, we may want to relax livecheck regex to allow for -beta
versions to avoid warnings until 2.x is out of beta.
sha256 "37f71f3cb2b0b9649eb85a51296187b0adf2972c5a1d3ee0daf3082e2c35025e" | ||
end | ||
uses_from_macos "curl" | ||
uses_from_macos "libxml2" |
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.
Not too important, but Homebrew's libxml2
is getting linked rather than using macOS version. Probably pulled in via libspatialite
.
Shouldn't be an issue as indirect dependency avoids broken linkage. In future, may want to check if libspatialite
truly needs a newer copy of libxml2
than what is provided by system.
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.
I don't see any issues blocking merge.
Can wait for @carlocab to also take a look.
This is needed after Homebrew#94807.
brew install --build-from-source <formula>
, where<formula>
is the name of the formula you're submitting?brew test <formula>
, where<formula>
is the name of the formula you're submitting?brew audit --strict <formula>
(after doingbrew install --build-from-source <formula>
)? If this is a new formula, does it passbrew audit --new <formula>
?