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

superenv: help Autotools with 10.13 SDK on 10.12 #3182

Merged
merged 1 commit into from Sep 21, 2017

Conversation

Projects
None yet
4 participants
@ilovezfs
Contributor

ilovezfs commented Sep 21, 2017

  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same change?
  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you written new tests for your changes? Here's an example.
  • Have you successfully run brew tests with your changes locally?

The GNU Autotools tests for whether futimens and utimensat are available reliably come to incorrect conclusions on 10.12 with the 10.13 SDK in Xcode 9. This overrides its decisions by forcing the right answer in superenv using ac_cv_func_* environment variables and setting them to "no" on 10.12.

superenv: help Autotools with 10.13 SDK on 10.12
The GNU Autotools tests for whether futimens and utimensat are available
reliably come to incorrect conclusions on 10.12 with the 10.13 SDK in
Xcode 9. This overrides its decisions by forcing the right answer
in superenv using ac_cv_func_* environment variables and setting them to
"no" on 10.12.
@ilovezfs

This comment has been minimized.

Show comment
Hide comment
@ilovezfs
Contributor

ilovezfs commented Sep 21, 2017

@andreygursky

This comment has been minimized.

Show comment
Hide comment
@andreygursky

andreygursky Sep 21, 2017

The GNU Autotools tests for whether futimens and utimensat are available reliably come to incorrect conclusions on 10.12 with the 10.13 SDK in Xcode 9.

Why do you think the autotools' conclusion is incorrect if SDK reports utimensat() is indeed available? This report from SDK is incorrect if you selected to build for e.g. 10.12, thus your workaround with forcing the availability to "no". I'd prefer to change the wording from "autotools ... incorrect" to "SDK 10.13 ... incorrect".

Have you selected, that you're going to build for 10.12? If it is not possible at all, the wording could be something like "SDK 10.13 doesn't support building for pre-10.13."

andreygursky commented Sep 21, 2017

The GNU Autotools tests for whether futimens and utimensat are available reliably come to incorrect conclusions on 10.12 with the 10.13 SDK in Xcode 9.

Why do you think the autotools' conclusion is incorrect if SDK reports utimensat() is indeed available? This report from SDK is incorrect if you selected to build for e.g. 10.12, thus your workaround with forcing the availability to "no". I'd prefer to change the wording from "autotools ... incorrect" to "SDK 10.13 ... incorrect".

Have you selected, that you're going to build for 10.12? If it is not possible at all, the wording could be something like "SDK 10.13 doesn't support building for pre-10.13."

@ilovezfs

This comment has been minimized.

Show comment
Hide comment
@ilovezfs

ilovezfs Sep 21, 2017

Contributor

@andreygursky because it's not actually in the libraries. See the linked issues. Note we do set deployment target so that's not the issue ;)

Contributor

ilovezfs commented Sep 21, 2017

@andreygursky because it's not actually in the libraries. See the linked issues. Note we do set deployment target so that's not the issue ;)

@hjmallon

This comment has been minimized.

Show comment
Hide comment
@hjmallon

hjmallon Sep 21, 2017

It 'weak-links' the symbols if the deployment target is older than the oldest for the symbol to be available.

hjmallon commented Sep 21, 2017

It 'weak-links' the symbols if the deployment target is older than the oldest for the symbol to be available.

@ilovezfs

This comment has been minimized.

Show comment
Hide comment
@ilovezfs

ilovezfs Sep 21, 2017

Contributor

Anyway feel free to search "superenv" and review the same pull requests from last year :)

Contributor

ilovezfs commented Sep 21, 2017

Anyway feel free to search "superenv" and review the same pull requests from last year :)

# reliably figure this out with Xcode 8 and above.
if MacOS.version == "10.12" && MacOS::Xcode.installed? && MacOS::Xcode.version >= "9.0"
ENV["ac_cv_func_futimens"] = "no"
ENV["ac_cv_func_utimensat"] = "no"

This comment has been minimized.

@MikeMcQuaid

MikeMcQuaid Sep 21, 2017

Member

If there's any more in a future PR let's make this a loop like below.

@MikeMcQuaid

MikeMcQuaid Sep 21, 2017

Member

If there's any more in a future PR let's make this a loop like below.

@ilovezfs ilovezfs merged commit 05bb353 into Homebrew:master Sep 21, 2017

1 of 3 checks passed

codecov/patch 33.33% of diff hit (target 67.11%)
Details
codecov/project 67.1% (-0.01%) compared to 5d888c0
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@chdiza chdiza referenced this pull request Mar 31, 2018

Closed

Xcode 9.3 breaks GNU detection of vasnprint #4008

5 of 5 tasks complete

@Homebrew Homebrew locked and limited conversation to collaborators May 4, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.