At Monday 2005-04-18 05:44, you wrote:
Rene Rivera <grafik.list@redshift-software.com> wrote:
Walter Landry wrote:
Bjørn Roald <bjorn@4roald.org> wrote:
My experience installing boost the first time was quite pleasant even if I had to learn a few things about a tool called bjam and get it installed first.
My view is very different from yours. The last thing that I want to do when I am installing a new program is learn about a new build system. On Unix, the install procedure should really be "configure ; make ; make install". There is really no excuse for that not to be the case.
Here are some reasons, none of them are excuses, why it's not "configure; make install"..
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
Given the response, I am not surprised that there is no autoconf support in Boost.
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.
does it work on Windows? and the book on autoconf / automake is the least scrutable book ever written in the English language.
3. Other than historical familiarity, one of the UI intuitive factors,
Don't knock it.
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.
or install autoconf
It would also have a chance of working properly. On my system, bjam could not find the development headers for my python install, and it spits out annoying warning if I use a new version of gcc. This is a bit ridiculous.
on my system autoconf results in: T:\boost\include\boost-1_32\boost>autoconf 'autoconf' is not recognized as an internal or external command, operable program or batch file. and the last time I -did- have it installed, it got run 5 times by an install script and tested the same damned stuff over and over and over. IMO a worthless piece of junk.
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".
as I said, "configure" don't exist on my systems, and like it or not, *nix is a _very_ small portion of the market.
Cheers, Walter Landry wlandry@ucsd.edu
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"