Subject: Re: [Boost-build] Cross-compiling
From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-09-30 06:36:09
On Tuesday 30 September 2008 06:32:05 Rene Rivera wrote:
> Woohoo! I've been contemplating making such changes for a while. For the
> sames reasons too :-) But...
> Vladimir Prus wrote:
> > I've checked in few patches
> > http://svn.boost.org/trac/boost/changeset/49010
> That one broke my builds :-( For the longest time I've had these lines
> one my root jam files:
> type.set-generated-target-suffix EXE : <target-os>linux : app ;
> type.set-generated-target-suffix EXE : <target-os>windows : exe ;
> I know the windows one is redundant. But I hate assuming, and hence
> relying, on default settings like this. And the "app" one just personal
> preference. Now I get this error:
> in find-replace from module object(property-map)@1
> error: Ambiguous key
> Which I verified is from the extra windows target suffix by commenting
> it out. It doesn't affect me terribly... But this error also means one
> can't override the default suffix. I.e. one can't do:
> type.set-generated-target-suffix EXE : <target-os>windows : run ;
> It seems like a bad idea to remove the ability to override defaults.
Well, I would say that ability to cross-compile to windows is a enough of
a big thing to justify breaking the ability to name EXEs with ".run" extension :-)
Feel free to create a ticket for this -- I think that property-map class in
property.jam is perfectly capable of replacing existing value, as opposed to
adding new, it's just a matter to coming up with interface to that -- assuming
you really need .run extension.
> > bjam toolset=gcc-4.2.1 target-os=windows threading=multi threadapi=win32 --with-thread
> > We probably can cut down on the number of things to say on command line,
> > but still, it works. Of course, I still have to document things.
> Hm, the cross-compile on MacOS for iPhone has the same "long command"
> problem. I end up running, with an alias:
> bjam toolset=darwin architecture=arm target-os=iphone
> How are you thinking of reducing things like that?
I think that threadapi=win32 should be just auto-detected from target-os.
There also be some way to map from toolset into target-os=windows. Heck,
we have 'toolchain requirements' so probably we can use those to add
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk