On Fri, Oct 17, 2008 at 3:33 PM, Steven Knight <[EMAIL PROTECTED]> wrote:
> 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 > > Did you consider putting the target-specific scons files in a subdirectory? Maybe in a subdirectory named build? Or, does having them at the root of net/ like this make some things better? What is the difference between net.scons and net_lib.scons in this example? -Darin > > 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. > > +1 :) > > - > > > - 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 chromium-dev@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
