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
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:
> 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:
-- -- 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk