It seems like another approach would be to use the target types to indicate if the library or executable is for the host or native (ie-add types for host vs. target), then you could use target_conditions to have different flags. TVL
On Wed, Oct 7, 2009 at 10: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. > > 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. > > 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 ? > > Thanks, > Antoine > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
