(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
-~--~~~~--~~--~--~---
