Re: Boost.Build on IBM, SGI & HP

From: bdawes_at_[hidden]
Date: 2001-10-11 13:45:17

--- In boost_at_y..., Petr Ovchenkov <ptr_at_P...> wrote:
> >>>>> "DA" == David Abrahams <david.abrahams_at_r...> writes:
> 
>  >> But when we need to build library, I prefer approach like use
>  >> Boris Fomichev in STLport (I hope you familiar with STLport, and
>  >> build it):
> 
>  DA> http://www.stlport.org/doc/thanks.html
> 
> Wow! Excuse me. My position in this list is much lowly...
> 
>  >> As for me, I had first trouble with building jam (jam's build
>  >> isn't clear in second pass, problem come from Jamfiles).
> 
>  DA> Sorry, I didn't understand that. What did you do, and what 
result
>  DA> did you get?
> 
> That's Jam's issue. Not here.
> 
>  >>  May be the solution is to have two build structures, Jam- and
>  >> make-based? And everybody will use what he/she like?
> 
>  DA> Are you volunteering? I don't think it's a good idea to have
>  DA> redundant build systems, but I would be happy if someone would
>  DA> supply a different system which satisfies all or most of the
>  DA> goals described at
>  DA> 
http://www.boost.org/tools/build/build_system.htm#design_criteria. I
>  DA> would simply retire Boost.Build if the alternative were easier 
to
>  DA> use and maintain.
> 
> You right, I can provide not all items of
> http://www.boost.org/tools/build/build_system.htm#design_criteria
> (and you too). But most.
> 
> Really I can design core schema and real build for gcc (Linux,
> Solaris). And, may be, build for VC6 with nmake. Also I can write
> options for aCC compiler (HP's, HP-UX), but can't check now
> whether it really work.
> 
> If this has some sense, I can start.

Peter, if you have some special skills with make that allows you to 
solve problems that others have failed to solve, then by all means 
give it a try.

But otherwise it is likely to be a waste of your time.  We at Boost, 
and the Jam, Cons, ScCons, etc. folks didn't just arbitrarily give up 
on make.  A lot of effort went into trying to make "make" work.  The 
conclusion is that make just can't do the job across lots of 
platforms and lots of developers.

The single most important point for me is that when a developer gets 
a jamfile running on his or her platform, that jamfile really does 
work without change across all platforms.  Maybe some of the compiler 
related stuff has to be adjusted for another platform, but that is a 
separtate issue that can be dealt with by those who know the 
platform.  The original developer never needs to know anything about 
an unfamiliar platform.  That doesn't to be the case with make.

--Beman