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

CI: Fix MacOS vcpkg libgeotiff build #69

Merged
merged 17 commits into from
Apr 20, 2022
Merged

Conversation

brendan-ward
Copy link
Member

No description provided.

@brendan-ward
Copy link
Member Author

Something about the update of libgeotiff from 1.7.0#1 to 1.7.1 is breaking on MacOS on CI, even though it builds fine for me on local MacOS 10.15:

Contents of libgeotiff/config-x64-osx-dynamic-rel-err.log:

CMake Error at /usr/local/share/vcpkg/installed/x64-osx-dynamic/share/unofficial-sqlite3/unofficial-sqlite3-targets.cmake:55 (set_target_properties):
  The link interface of target "unofficial::sqlite3::sqlite3" contains:

    Threads::Threads

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Call Stack (most recent call first):
  /usr/local/share/vcpkg/installed/x64-osx-dynamic/share/unofficial-sqlite3/unofficial-sqlite3-config.cmake:7 (include)
  /usr/local/share/vcpkg/scripts/buildsystems/vcpkg.cmake:816 (_find_package)
  /usr/local/Cellar/cmake/3.23.0/share/cmake/Modules/CMakeFindDependencyMacro.cmake:47 (find_package)
  /usr/local/share/vcpkg/installed/x64-osx-dynamic/share/proj/proj-config.cmake:13 (find_dependency)
  /usr/local/share/vcpkg/scripts/buildsystems/vcpkg.cmake:816 (_find_package)
  CMakeLists.txt:118 (FIND_PACKAGE)

@jorisvandenbossche
Copy link
Member

I can't directly help with the build failure on Mac (I would maybe report the build failure upstream at https://github.com/microsoft/vcpkg, since it worked before; it's a bit a pity that the dynamic osx build it not one of the built-in triplets, which would make it less likely to get broken).

But, maybe we should try to pin the build to an exact "baseline" for which we know it works (https://devblogs.microsoft.com/cppblog/take-control-of-your-vcpkg-dependencies-with-versioning-support/#baselines), and then only from time to time manually update the version.

@brendan-ward brendan-ward marked this pull request as ready for review April 12, 2022 15:30
@brendan-ward brendan-ward marked this pull request as draft April 12, 2022 16:23
@brendan-ward brendan-ward marked this pull request as ready for review April 13, 2022 01:01
@brendan-ward
Copy link
Member Author

This should now be using the vcpkg manifest approach for all builds, which includes a baseline commit in the vcpkg repository (set to just before libgeotiff 1.7.1 was merged), and a pinned version of libgeotiff that works. We'll occasionally need to bump this version / baseline commit.

The instructions weren't particularly clear; given the basline that I set, it shouldn't have tried to install libgeotiff 1.7.1 at all, but it did so until I added an override to pin that to a prior version.

I couldn't reproduce the libgeotiff error locally, so hopefully that will be fixed at a later point. I'm not seeing anything obvious to call attention to in the vcpkg setup for it, so I'm not sure what we would log out there as an issue other than it doesn't build in our specific environment.

@brendan-ward
Copy link
Member Author

Since this worked on last test of building the wheels, I'm going to go ahead and merge this so we can get closer to cutting an 0.4.0 release that builds wheels. We can add future PRs to fix things here if needed.

@brendan-ward brendan-ward merged commit 9ed3e5a into main Apr 20, 2022
@brendan-ward brendan-ward changed the title CI: Try to fix MacOS vcpkg libgeotiff build CI: Fix MacOS vcpkg libgeotiff build Apr 20, 2022
@brendan-ward brendan-ward deleted the fix_macos_vckpkg_libgeotiff branch April 20, 2022 18:32
@jorisvandenbossche
Copy link
Member

jorisvandenbossche commented Apr 20, 2022

Sorry for the late review here, and thanks a lot for fixing this! Adding a few questions inline.

@jorisvandenbossche
Copy link
Member

In any case it is a nice solution!

@brendan-ward
Copy link
Member Author

Until it broke on CI, at time of merge. Because CI is... fun... (investigating now, further fixes will be a in a different PR)

run: |
vcpkg install gdal[core] --overlay-triplets=./ci/custom-triplets
echo "VCPKG_INSTALLATION_ROOT: ${VCPKG_INSTALLATION_ROOT}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a debugging left-over? (the variable is documented by github actions about what it is)

--overlay-ports=opt/vcpkg/custom-ports \
--feature-flags="versions,manifests" \
--x-manifest-root=opt/vcpkg \
--x-install-root=opt/vcpkg/installed && \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: the reason that it is now needed to mention the install-root, is that because using manifest mode changes that? (it would now try to install inside the project, instead of in the vcpkg root?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, using manifest mode changes this, and would have put it in ci/vcpkg_installed/ which then would have required other updates here to use that path.

"overrides": [
{
"name": "libgeotiff",
"version": "1.7.0"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have expected that only the baseline would be sufficient? (assuming the baseline is from a commit where libgeotiff is still at 1.7.0?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Provided I did it correctly (I picked commit immediately prior to 1.7.0 being merged), I would have expected the same. However, I found it went ahead and tried to install 1.7.1 anyway, without setting this override.

I don't know that it is necessarily a problem for us to explicitly list it as a pinned version though - if only for documentation purposes, since this was the root of the problem.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know that it is necessarily a problem for us to explicitly list it as a pinned version though - if only for documentation purposes, since this was the root of the problem.

Indeed

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jorisvandenbossche @brendan-ward I am finding vcpkg manifests difficult to use. Do you know if there is a vcpkg mode that will fail if no vcpkg.json is found? I suspect it's continuing without one in my case, but can't verify that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sgillies I think you are missing a "manifests" feature flag. Assuming this is about rasterio/rasterio-wheels#90, will comment over there

@jorisvandenbossche
Copy link
Member

Until it broke on CI, at time of merge. Because CI is... fun... (investigating now, further fixes will be a in a different PR)

But the Mac build passed :)

@jorisvandenbossche
Copy link
Member

jorisvandenbossche commented Apr 20, 2022

The GDAL data files probably changed again location on windows ..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants