(m...@chromium.org, please - that's the address that I can post to mailing lists from.)
There was a chromium-dev thread on this on Friday. http://groups.google.com/group/chromium-dev/browse_thread/thread/932a19ed777b9bb4 Between your two choices, I have a slight preference for option 1. Option 2, while it has an identical result, is confusing in that it results in .cc files that aren't used directly as compiler input. Putting them into a .gyp file's 'sources' section would then require custom excludes in 'sources!' or 'sources/' to keep the compiler from trying to crunch them. Mark Brad Nelson wrote: > Hi Mark, > So the nacl guys have a use case where they would be tempted to have > per-configuration sources, if it were supported. > Since this is particularly hairy for xcode, I wanted to see if you could > offer some guidance as to how they should tackle this. > Currently they are porting base + app to 64-bit for windows. > They only need a limited subset of functionality for nacl, so they have only > made some source files 64-bit clean. > They would like to simply disable the rest for 64-bit (at least for now). > With gyp's current limitations, they appear to have a limited set of option, > all of which will affect others: > 1. Surround each of the several dozen source files with #ifdefs gated on > some 64-bit windows define. > 2. Add app.cc, base.cc which #includes all the other .cc files, and gates > them en-mass on some 64-bit windows define. > 1 seems better to me, though a bit tedious. > How would you suggest they proceed? --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
