Walter Landry wrote:
Rene Rivera <grafik.list@redshift-software.com> 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: 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