Re: [Boost-build] cross compiling linux boost libraries

Subject: Re: [Boost-build] cross compiling linux boost libraries
From: Vladimir Prus (ghost_at_[hidden])
Date: 2010-07-12 08:45:07

On Monday 12 July 2010 14:46:37 Moritz Hassert wrote:

> Am Montag, 12. Juli 2010, um 09:48:08 schrieb Vladimir Prus:
> > > > [...]
> > > 
> > > The odd thing with boost-build is that it sometimes does not bail out
> > > with an error when it can't fullfill your exact request. Instead it
> > > tries to something that it considers 'a good alternative'. At least
> > > thats my experience.
> > > 
> > > In your case the toolset 'gcc-mips' is most likely not known to
> > > boost-build. That is, it does not have a gcc with version 'mips'
> > > configured. But instead of complaining it tries to auto-configure that
> > > compiler. And if it cannot find an executable  'g++-mips' or something
> > > like that it will fall back to the default command for toolset gcc,
> > > which is of cause 'g++'.
> > 
> > That's an outright bug, I guess. Care to file it in the tracker?
> 
> I'm suprised you call it a bug. I always thought it's one oft those places 
> where the "do the right thing" - policy of boost.build hits you in the head. 
> (I think I remember reading somewhere you talking about that policy)
> 
> Using the default gcc sure is a sane default for the average boost user who 
> "just wants to compile boost". But as in many cornerplaces of boost.build it 
> seems no one considered such "strange" things as cross-compiling. And I would 
> have never considered it a bug, as the gcc.jam code (as far as I understand) 
> explicitly uses a default g++ for cases where the tool is not found.

Actually -- not when it's not found, but rather when it's not specified. The
bug, IMO, is that given toolset=gcc-foo when 'foo' is not a known version of
gcc, we try to configure 'gcc-foo', even though in 99% in cases user add 'foo'
for some reason, and there's no code to respect whatever request user is making.

> Just another example: As far as I understand from googling and my experience, 
> the target alternative selection depending on feature properties selects the 
> "most fitting" alternative even if that one is not fitting at all. It just has 
> to be "more fitting" than all the others. I think I remember reading that this 
> is by design.

I think it's the other way around. All properties in a target alternative must
match exactly. It's only for a target with a single alternative, requirements do override
properties.

> Of cause, an end user compiling software (boost) for his local machine doesn't 
> really care if libs are linked static or dynamic as long as his program runs 
> fine. But as a developer I want to specify exactly what is to be done and I 
> want it to be done exactly that way or not at all. I like errors. I even 
> switch on warnigs when compiling :)
> 
> I even managed have a <build>no target to get happily built into a subdir 
> .../build-no/... :(
> Why? I guess because it was a lib target and there was a exe target (without 
> <build>no) depending on it. As there where no other targets of that name it 
> was the best alternative and "had to be build".

Well, this is probably a bug, too.

Thanks,

--
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build: http://boost.org/boost-build2