[chromium-dev] Re: eliminating build/build_config.h -- need help on mac
+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 m...@chromium.org 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: eliminating build/build_config.h -- need help on mac
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 da...@chromium.org 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 m...@chromium.org 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: eliminating build/build_config.h -- need help on mac
I didn't mean to pick on the Mac, it was just the easiest one to grab all the defines out of. :) On Tue, Feb 17, 2009 at 10:45 AM, Mike Pinkerton pinker...@chromium.org wrote: 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 e...@chromium.org 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 da...@chromium.org 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 m...@chromium.org 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 pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: eliminating build/build_config.h -- need help on mac
On Mon, Feb 16, 2009 at 1:45 PM, Evan Martin e...@chromium.org wrote: 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. I support the idea of getting rid of build_config.h as an explicit include. However, build_config.h defines more than just OS_XXX. Why not pass -include ../build/build_config.h to GCC? AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: eliminating build/build_config.h -- need help on mac
On Mon, Feb 16, 2009 at 4:00 PM, Adam Langley a...@chromium.org wrote: On Mon, Feb 16, 2009 at 1:45 PM, Evan Martin e...@chromium.org wrote: 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. I support the idea of getting rid of build_config.h as an explicit include. However, build_config.h defines more than just OS_XXX. Why not pass -include ../build/build_config.h to GCC? My reasoning was that we don't want to litter the preprocessor namespace with defines, and the OS_* ones are 99% of the reason to include the header. My (implied) plan was that build_config.h could become compiler_config.h or whatever once it's seen where it's needed. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: eliminating build/build_config.h -- need help on mac
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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
