On Wed, Oct 7, 2009 at 7:46 PM, Thomas Van Lenten <[email protected]>wrote:
> 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 > That means duplicating every rule that is needed for host and target though. Antoine > > > 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 -~----------~----~----~----~------~----~------~--~---
