Hello All,
Last week I re-landed a change to split off parts of chrome.gyp into .gypi's
in the same directory.
I had done something similar a couple weeks back, but took it out because
concern was raised about merge conflicts in m4.
I put it back in because I got the all clear on m4.
The goal is to reduce contention on chrome.gyp which has gotten quite large
- 7000+ lines.
The current division is:
chrome_tests.gypi - 1793 (all tests)
chrome_browser.gyp - 2384 ('browser' target)
chrome.gyp - 2873 - (everything else)
The reason for using .gypi's rather than normal .gyp files is that the xcode
generator emits one xcodeproj per .gyp file.
Finer granularity would mean xcode users would get an overly myopic view of
the total project.
To avoid this, I've just pulled out larger targets into neighboring gypi's,
but they are still effectively a part of chrome.gyp. Targets behave the same
in an ancillary gypi file as they would if they were in the 'targets' list
in the main gyp file.
In a related theme, gregoryd is in the process of trying to produce 64-bit
builds of base, app, and a few other targets for use in nacl's 64-bit shim.
Without going into too much detail, in order to work correctly, even as a
part of a 32-bit build of chrome, a 64-bit shim which depends on base, app,
etc. needs to be built along side on windows. The best solution we've been
able to come up with is to use 'target_conditions' inside a gyp file to
allow a 'base' and 'base_nacl_win64' to share common files and settings. And
then use a facility in the msvs gyp generator to have some targets within a
32-bit sln configuration actually be 64-bit . This unfortunately somewhat
obscures which parts of the .gyp are relevant to which target. To make the
relationship more clear, we've come up with the idea of breaking out the
'magical' targets into separate .gypi files. You can see this in action in
the current state of base.gyp and base.gypi.
We've considered a number of alternatives: duplicate the contents of each
target for x64, enhance gyp to support target 'inheritance', wrap the whole
thing up in a python script to build things multiple different ways. The
advantage of the current approach is that nothing changes from the point of
view of someone building in the IDE.
Some concern has been raised as to the readability of the resulting gyp
files. We'd like to find something that meets everyones needs, so please let
me know if you've got ideas on how to do this more cleanly.
-BradN
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
