configure (Was: Building Boost 1.34.0 libraries with bjam)
Richard Hadsell wrote: [moving from boost-users]
I have made several attempts to persuade bjam to use /opt/gcc344/bin/g++344, and I finally discovered a solution for this part of the problem. I followed the Boost.Config doc the describes setting environment variables and running the configure script:
setenv CXX /opt/gcc344/bin/g++344 setenv CXXFLAGS "-m64 -fPIC" setenv LDFLAGS "-m64 -fPIC" configure
Then I looked at the resulting Makefile and user-config.jam.
First, the environment variables seemed to have no effect on the user-config.jam. When I ran bjam afterward, it still used the default installed g++ on my system. So in user-config.jam I changed 'using gcc ;' to 'using gcc : 3.4.4 : /opt/gcc344/bin/g++344 ;'. (This was similar to a 'using' statement that I saw in a comment in tools/build/v2/user-config.jam.)
I'm starting to wonder if "configure" script being shipped with Boost is a good idea. The idea is to make standard "./configure && make" work, however, as above posting shows, "configure" is associated with various expected behaviour, and unless we want to duplicate all such behaviour, we can end up confusing users. - Volodya
On Apr 30, 2007, at 3:29 PM, Vladimir Prus wrote:
Richard Hadsell wrote:
First, the environment variables seemed to have no effect on the user-config.jam. When I ran bjam afterward, it still used the default installed g++ on my system. So in user-config.jam I changed 'using gcc ;' to 'using gcc : 3.4.4 : /opt/gcc344/bin/g++344 ;'. (This was similar to a 'using' statement that I saw in a comment in tools/build/v2/user-config.jam.)
I'm starting to wonder if "configure" script being shipped with Boost is a good idea. The idea is to make standard "./configure && make" work, however, as above posting shows, "configure" is associated with various expected behaviour, and unless we want to duplicate all such behaviour, we can end up confusing users.
While we should probably fix this behavior of "configure" to do the same thing as an autoconf-generated "configure", I don't think that this problem makes having a "configure" script any less of a good idea. The "configure" script handles the common case very well; it's much easier for people accustomed to *nix software than bjam will ever be. Let me put it this way: since I wrote the "configure" script for Boost, the number of times I've been told that Boost is too hard to build (e.g., at conferences and workshops) has decreased *drastically*. bjam is powerful, but it's non-traditional. For all of the failures of autotools (and there are many!), *nix programmers understand how to build autotools-based projects and can do it very, very easily. "./configure && make && make install" is enough for the vast majority of the open source projects in the world. - Doug
In article <0CB5B4BF-D924-4605-B47D-3B5EEB38B7EA@osl.iu.edu> Doug Gregor <dgregor@osl.iu.edu> wrote:
While we should probably fix this behavior of "configure" to do the same thing as an autoconf-generated "configure", I don't think that this problem makes having a "configure" script any less of a good idea. The "configure" script handles the common case very well; it's much easier for people accustomed to *nix software than bjam will ever be.
Agreed. Thomas
Doug Gregor wrote:
Let me put it this way: since I wrote the "configure" script for Boost, the number of times I've been told that Boost is too hard to build (e.g., at conferences and workshops) has decreased *drastically*. bjam is powerful, but it's non-traditional. For all of the failures of autotools (and there are many!), *nix programmers understand how to build autotools-based projects and can do it very, very easily. "./configure && make && make install" is enough for the vast majority of the open source projects in the world.
I agree. It's probably fine for common cases. I only think the docs should not offer hope of configuring with an alternate compiler (at least, one that is not in the user's path) by describing environment variables that seem to have no effect. BTW, it did the job of finding the installed Python, which is in itself an improvement. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
on Tue May 01 2007, Richard Hadsell <hadsell-AT-blueskystudios.com> wrote:
Doug Gregor wrote:
Let me put it this way: since I wrote the "configure" script for Boost, the number of times I've been told that Boost is too hard to build (e.g., at conferences and workshops) has decreased *drastically*. bjam is powerful, but it's non-traditional. For all of the failures of autotools (and there are many!), *nix programmers understand how to build autotools-based projects and can do it very, very easily. "./configure && make && make install" is enough for the vast majority of the open source projects in the world.
I agree. It's probably fine for common cases. I only think the docs should not offer hope of configuring with an alternate compiler (at least, one that is not in the user's path) by describing environment variables that seem to have no effect.
BTW, it did the job of finding the installed Python, which is in itself an improvement.
FWIW, Boost.Build itself now has very sophisticated "installed-Python-finding" code. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com Don't Miss BoostCon 2007! ==> http://www.boostcon.com
Doug Gregor wrote:
On Apr 30, 2007, at 3:29 PM, Vladimir Prus wrote:
Richard Hadsell wrote:
First, the environment variables seemed to have no effect on the user-config.jam. When I ran bjam afterward, it still used the default installed g++ on my system. So in user-config.jam I changed 'using gcc ;' to 'using gcc : 3.4.4 : /opt/gcc344/bin/g++344 ;'. (This was similar to a 'using' statement that I saw in a comment in tools/build/v2/user-config.jam.)
I'm starting to wonder if "configure" script being shipped with Boost is a good idea. The idea is to make standard "./configure && make" work, however, as above posting shows, "configure" is associated with various expected behaviour, and unless we want to duplicate all such behaviour, we can end up confusing users.
While we should probably fix this behavior of "configure" to do the same thing as an autoconf-generated "configure", I don't think that this problem makes having a "configure" script any less of a good idea. The "configure" script handles the common case very well; it's much easier for people accustomed to *nix software than bjam will ever be.
Let me put it this way: since I wrote the "configure" script for Boost, the number of times I've been told that Boost is too hard to build (e.g., at conferences and workshops) has decreased *drastically*. bjam is powerful, but it's non-traditional. For all of the failures of autotools (and there are many!), *nix programmers understand how to build autotools-based projects and can do it very, very easily. "./configure && make && make install" is enough for the vast majority of the open source projects in the world.
I'm not sure "./configure && make && make install" as it is now is better than providing a single "build.sh" script. At least, name "build.sh" does not come with (implied) promise to be like configure in any respect. For another example, trying to use Boost's configure in buildir != srcdir scenario, that is going to some directory and saying "<boost-src-dir>/configure" does not seem to work either, and this is commonly used feature of auto*. - Volodya
participants (5)
-
David Abrahams -
Doug Gregor -
Richard Hadsell -
Thomas Witt -
Vladimir Prus