+1 Google style encourages including everything you need in the source. There should be no magic -include lines required to build the source.
This is why pre-compiled headers are disabled in release builds. If they were not, then over time people would only be able to build the source if they included the precompiled header on the command line. -Darin On Mon, Feb 16, 2009 at 8:11 PM, Mark Mentovai <[email protected]> wrote: > > I don't agree with this approach. I think that we should include what > we use, and that should extend to headers that provide nonstandard > macro definitions. I think that we should be expressing as much as > possible in code rather than in build environments. Most importantly, > I don't like the idea of globally polluting the macro namespace for > something like this. Our OS_* macros are ours (emphasis on "ours") > and I don't want to leak those defines to all of the other third-party > code that we build. > > Mark > > Evan Martin wrote: > > A few people I've talked to independently have expressed interest in > > getting rid of build/build_config.h. > > > > It is easy to forget to include, requires being included in a > > nonstandard place, and ends up being used everywhere anyway. It is > > easier to just define the few #defines we need in build scripts. (I > > think the compiler- and architecture- specific defines could move to a > > different file eventually, but we almost never use those.) > > > > http://codereview.chromium.org/21401 does this. It seems to work on > > Windows (I'd like an expert to doublecheck I did it the right way) but > > my wild guess at making Mac work is apparently wrong. If any Mac > > expert could help out, I'd appreciate it. > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
