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

Subject: Re: [Boost-build] cross compiling linux boost libraries
From: Moritz Hassert (mhassert_at_[hidden])
Date: 2010-07-12 06:46:37

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.

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.
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".

But if you say all this is not intended behavior but bugs I'd be happy to file 
it in the tracker.

Greetings
Moritz

PS:
Even if it sounded that way. I don't want to rant about boost.build here in 
general. I'm still perfectly happy with my switch to boost.build. I 'm only 
hitting those problems when I start doing things I never could have done with 
my previous make-based system in the first place.

Geschaeftsfuehrer: Dipl.-Inform. Christopher Asp
Amtsgericht Mannheim HRB 105845