Note these are only for building WebKit, not any of the Chromium files. I think Win does something similar, no?
On Tue, Feb 17, 2009 at 1:42 PM, Evan Martin <[email protected]> wrote: > > I agree with this in principle, but we're long past that, I think? > From one of the Mac build files: > > FEATURE_DEFINES = "ENABLE_DATABASE=1 > ENABLE_DASHBOARD_SUPPORT=0 > ENABLE_JAVASCRIPT_DEBUGGER=0 ENABLE_JSC_MULTIPLE_THREADS=0 > ENABLE_ICONDATABASE=0 ENABLE_XSLT=1 ENABLE_XPATH=1 ENABLE_SVG=1 > ENABLE_SVG_ANIMATION=1 ENABLE_SVG_AS_IMAGE=1 ENABLE_SVG_USE=1 > ENABLE_SVG_FOREIGN_OBJECT=1 ENABLE_SVG_FONTS=1 ENABLE_VIDEO=0 > WEBCORE_NAVIGATOR_PLATFORM_=\"FixMeAndRemoveTrailingUnderscore\" > USE_GOOGLE_URL_LIBRARY USE_SYSTEM_MALLOC=1 > XP_MACOSX=1\nENABLE_DATABASE=1 ENABLE_DASHBOARD_SUPPORT=0 > ENABLE_JAVASCRIPT_DEBUGGER=0 ENABLE_JSC_MULTIPLE_THREADS=0 > ENABLE_ICONDATABASE=0 ENABLE_XSLT=1 ENABLE_XPATH=1 ENABLE_SVG=1 > ENABLE_SVG_ANIMATION=1 ENABLE_SVG_AS_IMAGE=1 ENABLE_SVG_USE=1 > ENABLE_SVG_FOREIGN_OBJECT=1 ENABLE_SVG_FONTS=1 ENABLE_VIDEO=0 > WEBCORE_NAVIGATOR_PLATFORM_=\"FixMeAndRemoveTrailingUnderscore\" > USE_GOOGLE_URL_LIBRARY USE_SYSTEM_MALLOC=1 XP_MACOSX=1"; > > (PS: Now that I look, XP_MACOSX is in there twice -- maybe the > embedded \n made the first one go through.) > > On Tue, Feb 17, 2009 at 10:30 AM, Darin Fisher <[email protected]> wrote: >> +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. >>> >>> >> >> >> > > > > -- Mike Pinkerton Mac Weenie [email protected] --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
