@inducer -- here is the ref: travis-ci/travis-ci#6765 (comment)

Other relevant references.

• Travis CI changes default to Mac OS 10.11 XCode 7.3
• Travis CI image restructuring
• Currently available Travis CI OS X images
• Details on Mac OS 10.9 XCode 6.1 supports 10.9 and 10.10
• Details on Mac OS 10.10 XCode 6.4 supports 10.9 and 10.10
• Setting OS X deployment target

We never have had support for these as we were always using the beta-xcode6.1 image, which only has the 10.9 and 10.10 SDKs.

Also in need of this image are

• Apache Arrow
• libdynd

Would link this PR ( conda-forge/staged-recipes#1094 ).

Simply need to change this line. So also easy. 😄

Should be 10.10 as it doesn't have the 10.11 SDK FWICT.

We have until January 20th, 2017. Would actually include that date verbatim as I don't think many people know this.

Noted below.

Don't think this is required. However, the most recent document I can find on C++ ABI compatibility is discussing 10.3.8 and before vs. 10.3.9 and after. Those OSes (and their associated compilers) are so ancient this seems irrelevant, but have included the link anyways.

xref: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/CPPROverview.html

Probably should add this recent one too.

xref: https://blog.travis-ci.com/2016-11-17-retiring-some-osx-images/

"by hand" is perhaps an overstatement - the toolchain package (mentioned above) already does this, and staged-recipes already includes a note in the build section that any package that compiles things should pull in toolchain as a build dependency.

After some discussion at our meeting yesterday, we have added PR ( conda-forge/conda-forge-build-setup-feedstock#46 ), which forces the minimum build target on OS X to 10.9. While personally I still recommend the toolchain package and it does have broad usage throughout conda-forge, having the deployment target set in conda-forge-build-setup guarantees that everything builds in a compatible way. This should help further reduce the burden on feedstock maintainers by setting compatibility at the beginning of each build.

@ocefpaf - I'd appreciate your input on this point.

I am against the use of any un-versioned package that can change the build characteristics like that. We already have have feedstocks that have to override those variables to build properly. IMO those belong in the recipe and are, ultimately, the maintainers decision.

With that said I no longer have a stake on this as we diverged from conda-forge a long time ago, since the toolchain was first added. Unfortunately most of earth-science software we build locally must use gcc and must provide libgomp and others at run time to ensure they will run anywhere.

So what do you suggest? Would you prefer a versioned dependency on toolchain? (And isn't each maintainer still at liberty to decide whether they want a versioned or unversioned dependency?) Or should each maintainer figure out setting things like the build target by hand? (And who catches it if someone forgets?)

`> So what do you suggest?

Recommend but do not enforce. Many add the toolchain without even knowing what is the impact of those flags to the builds.

And who catches it if someone forgets?

Correct me if I am wrong but the build target is not too bad if an old one is used, right?

Anyways, like I said above, I no longer have a stake on this and I don't really care what is decided here. I am following @pelson's own workflow to re-build everything for my day job. Also, many of the users that had issues with the toolchain, that broke the GIS stack, already left conda-forge.

I still advocate the toolchain and it is versioned. We can pin the versions in the feedstocks. We can even add the pinned version to the pinning script. That all being said, I feel like Filipe and I have had this exact conversation over and over without a different result. So am not eager to dive into it again.

Instead I would like to find a reasonable middle ground that everyone can agree on and is easy to implement. As we do actually need to set the Mac OS X deployment target. My proposal would be to set the MACOSX_DEPLOYMENT_TARGET in conda-forge-build-setup as show in PR ( conda-forge/conda-forge-build-setup-feedstock#46 ). @msarahan helped me with a PR to whitelist the MACOSX_DEPLOYMENT_TARGET in conda-build. So this will work with conda-build 2.0.12+.

I think this proposal is nice for a few reasons. First it sets the deployment target everywhere immediately. So we don't have to worry about people who are unaware of this change accidentally breaking compatibility. Second it consolidates the effort between upgrading to conda-build 2 and upgrading the Travis CI image. We need conda-build 2 to leverage this feature. So the two efforts should not be "competing" for time, but working together. Third it moves the discussion away from compiler preferences to maintaining compatibility of binaries. As compatibility is the real concern we are dealing with here, it makes sense to make that the focus and this seems to the easiest most straightforward way to do that.

👍 I've removed the toolchain wording and replaced it by a summary of what you've suggested.

Thanks @inducer .

Could you add a one-sentence context that summarises the need?

Done.

Do we need to change the status?