We're getting ready to start going live (really) with the Hammer build
configuration for Chromium. This is to give everyone a heads up, and allow
for feedback.
Testing the default SCons generation of Visual Studio project and solution
files turned up some usability issues, mainly around how you figure out
(from within Visual Studio) which SCons configuration file you have to edit
to affect the build of a specific target.
Out of this, we have some CLs teed up with some significant changes to the
overall structure of the SCons config files. The general goal is to make it
easier for people to work with the SCons configuration through Visual Studio
and XCode. If any of these changes seems problematic, let me know
(especially if already been working with the SCons build):
- Change the build output directory names from "Debug" and "Release" to
platform-specific names:
debug-linux
release-linux
debug-mac
release-mac
debug-win
release-win
The rationale here is that we need platform-specific build directory names
for builds in working directories cross-mounted on multiple platforms. All
lower case will be easier typing on case-sensitive systems.
The main impact here will be on the buildbots, but you would also have to
update personal scripts that hard-code references to "Debug" or "Release".
Let me know if that would cause a lot of pain.
- Change the names of "SConscript*" files to "*.scons" files. In
addition to being a little more flexible with the naming, this will let us
turn on syntax coloring in various IDEs for "*.scons" files.
- Have each "*.scons" file build one target, with one construction
environment per "*.scons" file. The current structure has (for example)
one "net\SConscript" file that builds "net.lib" and its various test
executables. This would get replaced with the following set of "*.scons"
files:
net\net.scons
net\net_lib.scons
net\net_resources.scons
net\net_perftests.scons
net\net_unittests.scons
net\crash_cache.scons
net\stress_cache.scons
The idea here, of course, is to make it easier to navigate to the proper
build configuration when you need to make a change to what gets linked in to
a specific target, or to what flags it's built with. As an additional
benefit, this makes the actual contents of the "*.scons" files much more
readable, because you don't have to distinguish between configuration items
for multiple targets all jammed into one location.
(Note that one-target-per-*.scons-file will be a guideline, not a
hard-and-fast rule. If there is a good reason to build several common
targets from one "*.scons" file, that'll be okay. This is all about
practicality.)
- We'll create "using_*.scons" files as analogues to the current "
using_*.vsprops" files. This cleans up and centralizes a lot of
configuration in the rest of the "*.scons" files.
Note that the Mac build currently uses fewer coarser-grained
"*.xcconfig" settings
for similar configuration. If it makes sense, we can always add a
analogous "*.scons" files to collect multiple settings in a similar way. I
think, however, that the finer-grained settings should end up working as
well on Mac as they will on Linux, say.
- We're going to change the project hierarchy on the SCons-generated
Visual Studio project and solution files. There seems to be reasonable
consensus that a project hierarchy that mirrors the file system will be
easier for people to navigate than the current App / Browser / Installer /
Libraries division. (The Mac team already structure their XCode projects
like the file system, for example.) We'll test it out, figure out if it
works well for people in practice, and adjust accordingly.
- Generated XCode project files are in the works and will follow (I hope
sooner rather than later).
Modulo feedback-induced changes, we'll be going ahead roughly as follows
(with some of these steps going on in parallel):
1. Check in the CLs that restructure the SCons config as described above
for the base, net and googleurl modules.
2. Get feedback on the Visual Studio experience from some early
tire-kickers.
3. Switch the "Modules*" buildbot slaves to build the SCons build, not
the legacy Visual Studio build. You'll still be able to use the legacy
Visual Studio project files, but this will start encouraging adoption of the
new build configuration.
4. Restructure the webkit and chrome SCons configs per above.
5. Switch the remaining buildbots to using SCons-generated config.
Any and all feedback welcome,
--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
-~----------~----~----~----~------~----~------~--~---
