This is a heads up, and a call for feedback:
Barring a really compelling reason to the contrary, we're going to go ahead
and make SCons the official build system on Windows next week.
A key goal here is to get out of the current holding pattern. Trying to
keep the SCons build-on-the-side current with all the changes that go in,
and still have time to actually improve and speed up the infrastructure,
isn't really working (despite the help of many of you who have been updating
the SCons build in your CLs). So rather than continue to wait for some
endlessly-postponed time when the SCons build is perfectly ready as a
drop-in replacement, the time has come to forge ahead and work out the
details in real time.
Tthere will be a flurry of check-in activity leading up to the switch as
last-minute details get taken care of (still working out some Webkit merge
effects, e.g.). Here's the general outline of what to expect:
- SCons will actually perform the build.
- Visual Studio will still be the supported IDE, but you'll use solution
and project files generated from the SCons configuration that call out to
SCons for the build steps.
- It looks like we'll still be able to use Incredibuild for parallel
compilation, using an Incredibuild hook in how the compiler gets spawned.
- The generated solution file(s) will have a different project hierarchy
than the current solutions. The goal, of course, if for it to be a net
improvement (the source structure mirrors the disk directory layout, for
example), but the proof, of course, will be once you actually try to
incorporate it into a daily workflow. (We're currently incorporating
initial feedback on the layout; if you'd like to take an early look and
weigh in, let me know--additional opinions would be much appreciated.)
- There are a couple of different ways we're (still) considering handling
bootstrapping the generated solution files. Right now, the best bet looks
to be checking in a stub solution file with a single target in a project
that generates the real solution+project files. Other possibilities include
extending gclient to generate them after an update (which might be the
mechanism for keeping working copies in sync without manual steps, anyway).
- We'll abandon the "Hammer" subdirectory name on Windows in favor of
using "Debug" and "Release" to (try to) minimize impact on the Buildbots and
TryServer.
-
- The Linux team have been having some performance issues, mostly related
to the long lists of -I directories used by Webkit. I intend to have
optimizations in place before launch. (This might be a blocking item,
depending on measurements on Windows.)
- The Mac build will wait to convert until later, when XCode project
generation is in place.
I'll send out more specific information when the details have firmed up
(including exact timing).
Let me know if you have specific issues or concerns to address, or
(especially) if you know of any reason next week would be a bad time to do
this.
--SK
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
