On Thu, Oct 8, 2009 at 9:49 AM, Evan Martin <[email protected]> wrote:
> On Wed, Oct 7, 2009 at 7:06 PM, Antoine Labour <[email protected]> wrote: > > If you don't care about gyp or cross-compiling, you can skip this > message. > > I've been experimenting with adding host support for cross-compiling into > > gyp. By this, I mean being able to use the cross-compiler to build > Chrome, > > but still using the host compiler for build tools. "Regular" Chrome, with > v8 > > snapshotting and nacl disabled doesn't currently need this but for > example > > if you enable nacl, or compile the chromeos version you end up building > > tools necessary to generate headers or source files needed for the target > > (e.g. protocol buffer compiler). Currently if you use a cross-compiler, > > those tools are built for the target, so you can't run them. > > What I've done is tweak the make generator to add an option on every > target > > to compile it for host, target or both. > > Funny how these quick hacks (the make generator) grow over time... > > > Here are the CLs: > > - chrome side: http://codereview.chromium.org/265031 > > - gyp side: http://codereview.chromium.org/271019 > > Basically on the make generator side, every rule can be duplicated, for > the > > host version and the target version, based on a parameter on the gyp rule > > (default is target only). Furthermore, cflags, ldflags and libraries are > cut > > into a common part, a host-specific part and a target-specific part. It > > keeps target objects and host objects in separate trees. > > It's very crude, but it solves the problem for the protobuf compiler, > which > > is promising. Also, it makes the changes to the gyp definitions extremely > > simple an non-intrusive (see chrome-side patch) - one of the simplest > > methods I've ever seen for this sort of things. I think this solution > should > > also fix the nacl issues. I'm not yet sure about v8 snapshotting. > > Several issues: > > 1- It's basically a big hack. The level of control between host and > target > > compiles boils down to compile and link flags (and compiler/linker). No > way > > to have different dependencies, different files to compile etc. > > 2- Generally, target rules depend on other target rules, host rules > depend > > on other host rules. The way you make the bridge (when you need a target > > rule to depend on executing the host tool) is by having the host tool > > installed at a particular location, and have the target rule depend on > that > > file (which is the way the protobuf compiler is called now, but that's > very > > limited). > > 3- Well, it only works for the make build. The current patch probably > breaks > > the scons one. XCode and MSVS should be mostly unaffected - but won't > > supposrt this, which I don't think is a big deal. > > How about 32/64-bit binaries from MSVS? Is that considered > cross-compiling? (I know pretty much nothing about the VS toolchain.) > What I meant is that my change doesn't intend to support cross-compiling in xcode/msvs, but it could be a base to support it there. I don't know how 32/64-bit works in the win32 world either. > > > Anyway I'm looking for feedback on the above, and guidance on the > following: > > What I'd like to do is find a way to keep a similar syntax for host vs > > target selection, but change the way cflags etc. differences are dealt > with > > into something that looks more like conditions which would allow more > > control over deps, sources, etc. which would make it I think a very > powerful > > and general way of dealing with this whole thing. > > To you gyp gurus, do you see a simple way of doing this ? > > I don't quite understand what you're saying here, but I'll throw in a > bug that is perhaps related to the problem of building host-vs-target > stuff. It feels similar to the trickiness in building mksnapshot: > > When building our test plugins on 64-bit, we need to compile them with > -fPIC. But (I think?) they use code that is also used by the main > build which *doesn't* use -fPIC. This means we'd ideally compile that > code twice for the different targets. > Mmh, they're both "target" code, so my patch as is wouldn't work. If you make it more general to have more than "host" vs "target" (e.g. "host", "target", "target_pic" or something that makes sense), the dependency tracking that already exists would indeed make the code compile twice for the different targets. I wanted to avoid the complexity associated with that amount of generality, but if you think it can be useful, I can look further into it. Antoine --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
