On Mon, Dec 7, 2009 at 1:43 PM, Bradley Nelson <bradnel...@google.com>wrote:
> 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.
>
Have you looked at using some of the infrastructure used by the
cross-compile builds on linux (the toolset stuff) ? It's basically a way to
implicitly duplicate gyp targets and manage dependencies between them.
Beyond host vs target, I had in mind the ability to more generically use
different tools to build the same target, though never got around to
implement it really. E.g. PIC vs not PIC for linux x64 builds. It may be the
right abstraction for the win x64 stuff, though I don't know the details of
how that works on windows.
Antoine
>
> -BradN
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
