Re: [boost] Re: Boost to the rescue

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-04-18 09:24:50

Walter Landry wrote:
> Rene Rivera <grafik.list_at_[hidden]> wrote:

>>1. Nobody has volunteered the time and expertise to support such a system.
> 
> You must have missed the enormous flamewars when people suggested
> using autoconf.  For example
> 
>   http://lists.boost.org/MailArchives/boost/msg25583.php

No I didn't didn't miss it. And if you had read that thread you would 
have seen my replies in that thread for example:

http://article.gmane.org/gmane.comp.lib.boost.devel/63354

> Given the response, I am not surprised that there is no autoconf
> support in Boost.

Is that "not surprised" because of my response or the thread you referenced?

>>2. Such a system would be unusable to Boost developers which have to
>>work with a variety of compilers and systems, usually at the same
>>time.  Hence it would be a user only UI; so there is less incentive
>>to support something like autoconf.
> 
> You are confusing me.  The whole point of autoconf is to deal with a
> variety of compilers and systems.

Autoconf is about dealing with *one* compiler and *one* system. Boost 
developers often switch between compilers, and sometimes compile for 
multiple compilers at the same time. That is something that is 
cumbersome to do with autoconf.

>>3. Other than historical familiarity, one of the UI intuitive factors,
> 
> Don't knock it.

I wasn't.. But it's a weak reason to pick between two alternatives ;-)

>>it's doesn't give users any improvements on functionality or ease of use
>>than the current: "bjam install".
> 
> Except that you don't have to install bjam. 

Only because autoconf is already installed on most system. That is 
something that is becoming true for bjam as well.

> It would also have a
> chance of working properly.  On my system, bjam could not find the
> development headers for my python install,

You mean Boost.Build could not find the headers.

> and it spits out annoying
> warning if I use a new version of gcc. 

Which has nothing to do with Boost.Build or bjam. But with Boost.Config. 
-- Just clarifying.. not criticizing :-)

> This is a bit ridiculous.

>>If people are willing to devote some effort we'd welcome what I would
>>consider the optimal solution of just: "install". Which would use a
>>system similar to the Linux Kernel configurator of providing a UI,
>>graphical or curses, to select parts to install, to build, and to install.
> 
> I don't need that much.  Just "configure; make; make install".

For that we could just shell scripts at the boost root with:

----configure---
#!/bin/sh
----configure---

----make---
#!/bin/sh
p=${PWD}
cd tools/build/jam_src
export LOCATE_TARGET=bin
sh ./build.sh
cd ${p}
./tools/build/jam_src/bin/bjam "$@"
---make---

:-)

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org