You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ansible: install multiple versions of xcode on build machines #1358
we should install multiple versions of xcode on our build machines and implement xcode-select to allow us to switch between versions easily for builds. CC @mhdawson
@gdams can you comment with how long you think this might take. From nodejs/node#21079 (comment) sounds like 6.8 becomes stable on the Google side on the 24th.
I'm going to play around with this over the weekend. The main issue that I have right now is that it means that we will have to install non-default versions of xcode on macOS distributions which is much harder to source. We might have to stick an xcode dmg file on the public files server that we have for a few dependencies.
hmm so it appears that 6.8 requires Xcode 8.x or higher but unfortunately Xcode 8.x is not supported on macOS 10.10 and these is no workaround for this. We therefore will have to build on macOS 10.11.5 or higher.
That has 2 potential issues in respect to V8 6.8, our current support statement is
macOS | Tier 1 | >= 10.10 | x64
If we have to build on 10.11 I think that means we'd have to change it to >= 10.11 which I'm not sure we can do in 10.x. I think we could build on 10.11 and it would still run on 10.10, but people building themselves could no longer build on 10.10 which could force them to upgrade. @nodejs/build what's your interpretation of whether we can change this in shipped release line?
We'll need new machines to build on. We can start using MacStadium but as mentioned there is a potential issue on that front.
@gdams can you setup a machine in MacStadium we can use for the release machine so we are ready to go when we decide what to do.
@nodejs/build what's your interpretation of whether we can change this in shipped release line?
I don't think we have ever given a guarantee of what level you can build Node on, so I'd be fine with changing that. I think I remember @bnoordhuis saying this at some point.
It'd be difficult to be sure that it actually runs on 10.10 though if we can't build on that level.
@nodejs/build any issues if we start building master/nightlies on 10.11? The implications might be:
People will soon not able to build on 10.10 anymore (since we know a change is coming in V8 6.8 that will prevent this)
We will have taken a dependency on MacStadium for releases (at least nightlies)
After we answer this question we'll then have to separately decide if we are ok with the same for 10.X, but doing this for master should be the easier decision.
And this has consistently done the trick for us in getting binaries that are widely supported. I have a high degree of confidence in Xcode's ability to produce portable binaries and I'm not too concerned about compiling Node on newer versions over time; at least nowhere near as concerned as with Linux.
So, two purposes of having different versions of Xcode might be:
Compiling builds with newer versions, like for this V8 6.8 problem
Testing builds against multiple versions so we maintain compatibility with various versions of Xcode that may be in the wild.
I think 1 is probably less of a concern and I wouldn't be opposed to trying to shift our releases to newer macOS and newer Xcode, with -mmacosx-version-min=10.7 doing all of the heavy lifting (we probably should raise that too..). We'd want to test and confirm that it all works properly but I reckon we could shift all of our release lines to newer macOS and newer Xcode.
2 might be a bit more interesting, but I don't think we've ever had much concern about Xcode compatibility, at least in recent years? This V8 6.8 limitation also throws a spanner in the works because it suggests that we're going to have to just put a higher limitation on it anyway.
So, overall, I'm not too concerned about Xcode versions, if someone wants to do the work to expand the matrix then you're welcome to. But be aware that our macOS machines are a finite resource and may become more limited over time rather than less. I think for now we'd be better off working on moving toward the latest Xcode and macOS for all our release builds, including the testing effort that needs to go into that.
@nodejs/build anybody with time to do the testing effort needed to make sure we are safe on previous versions?
At this point we have one release machine and test machines with OSX10.11 so I think moving master up is probably not too much work. I might be able to fit that in in a reasonable timeframe but I won't have time to worth through all of the other levels.
Tests pass 💯 (binary built on 10.11, tested on 10.10)
Also for now the only breaking change is in torque which is a tool used to generate code during the build. I looking for ways to cache the output, that way we might be able to even keep building on 10.10 for a while longer.
I think we can close this. IMHO after the trip V8 6.8 and macOS 10.10 took us we can converge on a one toolset per platform-version paradigm (for the foreseeable future)
Activity
mhdawson commentedon Jun 18, 2018
This may be a blocker for updating the v8 level @targos can you post the related issue here?
targos commentedon Jun 18, 2018
nodejs/node-v8#63
nodejs/node#21079 (comment)
mhdawson commentedon Jun 19, 2018
@gdams can you comment with how long you think this might take. From nodejs/node#21079 (comment) sounds like 6.8 becomes stable on the Google side on the 24th.
mhdawson commentedon Jun 19, 2018
This is also related #1264
gdams commentedon Jun 22, 2018
I'm going to play around with this over the weekend. The main issue that I have right now is that it means that we will have to install non-default versions of xcode on macOS distributions which is much harder to source. We might have to stick an xcode dmg file on the public files server that we have for a few dependencies.
gdams commentedon Jun 22, 2018
gcc versions for reference:
macOS 10.10
administorsMac3:~ administrator$ gcc --version Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 7.0.2 (clang-700.1.81) Target: x86_64-apple-darwin14.5.0 Thread model: posixmacOS 10.11
adminisorsMac14:~ administrator$ gcc --version Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 8.0.0 (clang-800.0.42.1) Target: x86_64-apple-darwin15.0.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bingdams commentedon Jun 22, 2018
hmm so it appears that 6.8 requires Xcode 8.x or higher but unfortunately Xcode 8.x is not supported on macOS 10.10 and these is no workaround for this. We therefore will have to build on macOS 10.11.5 or higher.
https://en.wikipedia.org/wiki/Xcode#8.x_series
mhdawson commentedon Jun 22, 2018
@gdams thanks for figuring that out.
That has 2 potential issues in respect to V8 6.8, our current support statement is
If we have to build on 10.11 I think that means we'd have to change it to >= 10.11 which I'm not sure we can do in 10.x. I think we could build on 10.11 and it would still run on 10.10, but people building themselves could no longer build on 10.10 which could force them to upgrade. @nodejs/build what's your interpretation of whether we can change this in shipped release line?
We'll need new machines to build on. We can start using MacStadium but as mentioned there is a potential issue on that front.
@gdams can you setup a machine in MacStadium we can use for the release machine so we are ready to go when we decide what to do.
gibfahn commentedon Jun 22, 2018
I don't think we have ever given a guarantee of what level you can build Node on, so I'd be fine with changing that. I think I remember @bnoordhuis saying this at some point.
It'd be difficult to be sure that it actually runs on 10.10 though if we can't build on that level.
Trott commentedon Jun 23, 2018
If it matters, 10.10 is unsupported by Apple as of September 2017, so it may not be a big deal to stop supporting it...
mhdawson commentedon Jul 9, 2018
@nodejs/build any issues if we start building master/nightlies on 10.11? The implications might be:
After we answer this question we'll then have to separately decide if we are ok with the same for 10.X, but doing this for master should be the easier decision.
rvagg commentedon Jul 17, 2018
In common.gypi we have:
And this has consistently done the trick for us in getting binaries that are widely supported. I have a high degree of confidence in Xcode's ability to produce portable binaries and I'm not too concerned about compiling Node on newer versions over time; at least nowhere near as concerned as with Linux.
So, two purposes of having different versions of Xcode might be:
I think 1 is probably less of a concern and I wouldn't be opposed to trying to shift our releases to newer macOS and newer Xcode, with
-mmacosx-version-min=10.7doing all of the heavy lifting (we probably should raise that too..). We'd want to test and confirm that it all works properly but I reckon we could shift all of our release lines to newer macOS and newer Xcode.2 might be a bit more interesting, but I don't think we've ever had much concern about Xcode compatibility, at least in recent years? This V8 6.8 limitation also throws a spanner in the works because it suggests that we're going to have to just put a higher limitation on it anyway.
So, overall, I'm not too concerned about Xcode versions, if someone wants to do the work to expand the matrix then you're welcome to. But be aware that our macOS machines are a finite resource and may become more limited over time rather than less. I think for now we'd be better off working on moving toward the latest Xcode and macOS for all our release builds, including the testing effort that needs to go into that.
mhdawson commentedon Jul 17, 2018
@nodejs/build anybody with time to do the testing effort needed to make sure we are safe on previous versions?
At this point we have one release machine and test machines with OSX10.11 so I think moving master up is probably not too much work. I might be able to fit that in in a reasonable timeframe but I won't have time to worth through all of the other levels.
build: increase macOS minimum supported version
refack commentedon Jul 25, 2018
I'll try to test this. Although I have a sense that
might mean we need OS level support...
Though SO has an anecdote about it working.
Ref: https://stackoverflow.com/questions/23791060/c-thread-local-storage-clang-503-0-40-mac-osx
refack commentedon Jul 25, 2018
Tests pass 💯 (binary built on 10.11, tested on 10.10)
Also for now the only breaking change is in
torquewhich is a tool used to generate code during the build. I looking for ways to cache the output, that way we might be able to even keep building on 10.10 for a while longer.build: increase macOS minimum supported version
refack commentedon Aug 10, 2018
I think we can close this. IMHO after the trip V8 6.8 and macOS 10.10 took us we can converge on a one toolset per platform-version paradigm (for the foreseeable future)