autoconf-like configure on RC_1_33_0 branch

I've placed an autoconf-like "configure" script on the RC_1_33_0 branch. If you're a *nix user and would like an alternative to directly using bjam, give it a try and send me some bug reports :) Typically one would just use: ./configure --prefix=/where/to/install make make install Run "./configure --help" for more options. Cheers, Doug

Do you feel like doing one for CMake - it would be a lot more useful in that it is cross-platform (*nix, Macs, QNX-Neutrino, Windows) and also generates the requisite IDE files eg. KDevelop3, Borland, Microsoft VC ? Andrew -----Original Message----- From: Doug Gregor [mailto:dgregor@cs.indiana.edu] Sent: Thursday, 27 October 2005 08:29 To: Boost mailing list Subject: [boost] autoconf-like configure on RC_1_33_0 branch I've placed an autoconf-like "configure" script on the RC_1_33_0 branch. If you're a *nix user and would like an alternative to directly using bjam, give it a try and send me some bug reports :) Typically one would just use: ./configure --prefix=/where/to/install make make install Run "./configure --help" for more options. Cheers, Doug

Andrew Maclean wrote:
Do you feel like doing one for CMake - it would be a lot more useful in that it is cross-platform (*nix, Macs, QNX-Neutrino, Windows) and also generates the requisite IDE files eg. KDevelop3, Borland, Microsoft VC ?
Oh, please yes! This (a configure script for CMake) would be most desirable, and I second this motion. Cheers, -- Manfred Doudar MetOcean Engineers www.metoceanengineers.com

"Andrew Maclean" <a.maclean@cas.edu.au> writes:
Do you feel like doing one for CMake - it would be a lot more useful in that it is cross-platform (*nix, Macs, QNX-Neutrino, Windows) and also generates the requisite IDE files eg. KDevelop3, Borland, Microsoft VC ?
I was afraid someone might ask that. There's a slippery slope here: we don't want to have to support N build systems for each of M libraries, which is where we were before Boost.Build. Boost.Build turns an NxM problem into an N+M problem. Ideally, Boost.Build could generate all these other build system formats (or at least, generate CMake format and let it do the rest). Patches welcome, as always. -- Dave Abrahams Boost Consulting www.boost-consulting.com

On Oct 27, 2005, at 5:48 AM, Andrew Maclean wrote:
Do you feel like doing one for CMake - it would be a lot more useful in that it is cross-platform (*nix, Macs, QNX-Neutrino, Windows) and also generates the requisite IDE files eg. KDevelop3, Borland, Microsoft VC ?
Nope :) The configure script is "autoconf-like" because it looks like autoconf, but it isn't. It's just a shell script that compiles bjam for you, converts autoconf-style options into bjam options, and produces a short Makefile that merely calls bjam with the right incantations. As David A. says, we don't want to duplicate the build system, but the demand for "./configure && make && make install" was too great to ignore. Doug

Douglas Gregor wrote:
On Oct 27, 2005, at 5:48 AM, Andrew Maclean wrote:
Do you feel like doing one for CMake - it would be a lot more useful in that it is cross-platform (*nix, Macs, QNX-Neutrino, Windows) and also generates the requisite IDE files eg. KDevelop3, Borland, Microsoft VC ?
Nope :)
The configure script is "autoconf-like" because it looks like autoconf, but it isn't. It's just a shell script that compiles bjam for you, converts autoconf-style options into bjam options, and produces a short Makefile that merely calls bjam with the right incantations. As David A. says, we don't want to duplicate the build system, but the demand for "./configure && make && make install" was too great to ignore.
On second thoughts, that's a really smart way to go - I'd not have thought of that - I like it. Cheers, -- Manfred MetOcean Engineers

I think it would be best that changes to RC_1_33_0 be confined to bug fixes detected in 1.33.1 and that new features be checked into the HEAD. I consider something like this to be a new feature. Robert Ramey Doug Gregor wrote:
I've placed an autoconf-like "configure" script on the RC_1_33_0 branch. If you're a *nix user and would like an alternative to directly using bjam, give it a try and send me some bug reports :)
Typically one would just use:
./configure --prefix=/where/to/install make make install
Run "./configure --help" for more options.
Cheers, Doug
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Wed, Oct 26, 2005 at 05:28:44PM -0500, Doug Gregor wrote:
... give it a try and send me some bug reports :)
When I first ran it (on a mac) it complained like this, over and over again: sed: -e expression #1, char 40: unterminated address regex sed: -e expression #1, char 36: unterminated `s' command These were in the expressions that extract the MACRO: and TITLE: stuff (see patch). Turns out the "sed" getting run was the sed in the "fink" installations, not /usr/bin/sed. Following patch fixes it (just change "sed" to "/usr/bin/sed", which is a reliable location for sed on all the unices I know of). Probably you would want to do this for all uses of seds, perhaps first check for /usr/bin/sed and then fallback to whatever sed is in the users' path, if any. Haven't looked at gnu autoconf to see how they do this kind of thing... I figured out what GNU sed's first complaint was, it doesn't like this: macroname=`cat $file | grep '^//[] []*MACRO:' | sed 's/.*MACRO:[] []*\([]_A-Z0-9[]*\).*/\1/'` but it does like this: macroname=`cat $file | grep '^//[] []*MACRO:' | sed 's/.*MACRO:[] []*\([_A-Z0-9]*\).*/\1/'` And I didn't get to figger the TITLE: problem. Dunno. -t diff -d -u -r1.28 configure --- configure 24 Jun 2005 11:48:11 -0000 1.28 +++ configure 31 Oct 2005 12:31:46 -0000 @@ -2172,8 +2172,8 @@ for file in $boost_base/libs/config/test/boost_no*.ipp; do basename=`echo $file | sed 's/.*boost_\(.*\)\.ipp/\1/'` - macroname=`cat $file | grep '^//[] []*MACRO:' | sed 's/.*MACRO:[] []*\([]_A-Z0-9[]*\).*/\1/'` - title=`cat $file | grep '^//[] []*TITLE:' | sed 's/.*TITLE:[] []*\([]^ [].*\)/\1/'` + macroname=`cat $file | grep '^//[] []*MACRO:' | /usr/bin/sed 's/.*MACRO:[] []*\([]_A-Z0-9[]*\).*/\1/'` + title=`cat $file | grep '^//[] []*TITLE:' | /usr/bin/sed 's/.*TITLE:[] []*\([]^ [].*\)/\1/'` namespace=`echo $macroname | tr [A-Z] [a-z]` #echo file = $file @@ -2312,9 +2312,9 @@ # for file in $boost_base/libs/config/test/boost_has*.ipp; do - basename=`echo $file | sed 's/.*boost_\(.*\)\.ipp/\1/'` - macroname=`cat $file | grep '^//[] []*MACRO:' | sed 's/.*MACRO:[] []*\([]_A-Z0-9[]*\).*/\1/'` - title=`cat $file | grep '^//[] []*TITLE:' | sed 's/.*TITLE:[] []*\([]^ [].*\)/\1/'` + basename=`echo $file | /usr/bin/sed 's/.*boost_\(.*\)\.ipp/\1/'` + macroname=`cat $file | grep '^//[] []*MACRO:' | /usr/bin/sed 's/.*MACRO:[] []*\([]_A-Z0-9[]*\).*/\1/'` + title=`cat $file | grep '^//[] []*TITLE:' | /usr/bin/sed 's/.*TITLE:[] []*\([]^ [].*\)/\1/'` namespace=`echo $macroname | tr [A-Z] [a-z]` # echo $file

troy d. straszheim wrote:
These were in the expressions that extract the MACRO: and TITLE: stuff (see patch). Turns out the "sed" getting run was the sed in the "fink" installations, not /usr/bin/sed. Following patch fixes it (just change "sed" to "/usr/bin/sed", which is a reliable location for sed on all the unices I know of). Probably you would want to do this for all uses of seds, perhaps first check for /usr/bin/sed and then fallback to whatever sed is in the users' path, if any.
Why not just bin/sed? There is a similar issue running bash on cygwin when you have find; it is trying to use the NT version. In this case, bin/find works. This then mirrors the #!/bin/sh usage. - Reece

On Mon, Oct 31, 2005 at 12:55:47PM +0000, Reece Dunn wrote:
Why not just bin/sed? There is a similar issue running bash on cygwin when you have find; it is trying to use the NT version. In this case, bin/find works. This then mirrors the #!/bin/sh usage.
I took a quick look around... on darwin and fbsd, /usr/bin/sed exists but not /bin/sed. Gentoo linux has /usr/bin/sed linked to /bin/sed, and a couple year old redhat distribution has /bin/sed only. So a path search for bin/sed isn't going to work everywhere (as typically one doesn't have /usr in PATH, no executables there), and weird path settings could still get you the wrong one. Maybe the best thing is to just check for them in /bin and /usr/bin manually. Anyhow it looks like I was looking at the wrong script (later in the thread...) -t

troy d. straszheim wrote:
I figured out what GNU sed's first complaint was, it doesn't like this:
macroname=`cat $file | grep '^//[] []*MACRO:' | sed 's/.*MACRO:[] []*\([]_A-Z0-9[]*\).*/\1/'`
but it does like this:
macroname=`cat $file | grep '^//[] []*MACRO:' | sed 's/.*MACRO:[] []*\([_A-Z0-9]*\).*/\1/'`
Doug, what are you trying to do here? If you're trying to extract "foo" from a line "<WHITESPACE>MACRO:<WHITESPACE>foo bar baz" then you should do it as: macroname=`sed -n ' /^[TAB ]*MACRO:/{ # Remove everything up to the beginning of # the first word after MACRO s/.*MACRO:[TAB ]*// # Remove everything after this word and # print to stdout. s/[^_A-Z0-9].*//p }' "$file"` where TAB is a literal TAB character Control-VControl-I. There's no need to invoke three process when you need only one and it's good practise to quote variables that expand to file names. Let me know if the above doesn't fit the bill and, if I can't figure it out myself I'll take it to the sed-users list. Regards, Angus

On Oct 31, 2005, at 7:43 AM, troy d. straszheim wrote:
On Wed, Oct 26, 2005 at 05:28:44PM -0500, Doug Gregor wrote:
... give it a try and send me some bug reports :)
When I first ran it (on a mac) it complained like this, over and over again:
sed: -e expression #1, char 40: unterminated address regex sed: -e expression #1, char 36: unterminated `s' command
I'm CC'ing John Maddock, who is in charge of the config library. It turns out that we're talking about two different "configure" scripts: I was referring to the new one in the Boost root directory, whereas you've found some issues with the one in libs/config. Sorry about the confusion! Doug

On Mon, Oct 31, 2005 at 10:15:49AM -0500, Doug Gregor wrote:
I'm CC'ing John Maddock, who is in charge of the config library. It turns out that we're talking about two different "configure" scripts: I was referring to the new one in the Boost root directory, whereas you've found some issues with the one in libs/config. Sorry about the confusion!
Hey Doug, The one in BOOST_ROOT doesn't work on platforms that have a real bourne shell and not bash in disguise (I'm guessing you wrote that on a linux box?). FreeBSD 5.4 doesn't like it, for instance... Bourne shell's comparison is a single =, not ==. diff -r1.3.2.2 configure 73c73 < if test $library == python; then ---
if test $library = python; then
79c79 < if test "x$requested_python" != xyes; then ---
if test "x$requested_python" != "xyes" ; then
93c93 < if test $library == python; then ---
if test $library = python; then
175c175 < if test "x$TOOLSET" == x; then ---
if test "x$TOOLSET" = "x" ; then 182c182 < if test "x$BJAM" == x; then
if test "x$BJAM" = "x" ; then 195c195 < if test "x$flag_show_libraries" == xyes; then
if test "x$flag_show_libraries" = "xyes"; then 213c213 < if test "x$EPREFIX" == x; then
if test "x$EPREFIX" = "x" ; then 217c217 < if test "x$LIBDIR" == x; then
if test "x$LIBDIR" = "x" ; then 221c221 < if test "x$INCLUDEDIR" == x; then
if test "x$INCLUDEDIR" = "x" ; then 226,227c226,227 < if test "x$flag_no_python" == x; then < if test "x$PYTHON_VERSION" == x; then
if test "x$flag_no_python" = "x" ; then if test "x$PYTHON_VERSION" = "x" ; then 233c233 < if test "x$PYTHON_ROOT" == x; then
if test "x$PYTHON_ROOT" = "x" ; then
244,245c244,245 < if test "x$flag_icu" == xyes; then < if test "x$ICU_ROOT" == x; then ---
if test "x$flag_icu" = "xyes"; then if test "x$ICU_ROOT" = "x" ; then
If you run ./configure --with-python=/no/such/python the script still runs to the end, like this: Building Boost.Jam with toolset gcc... tools/build/jam_src/bin.freebsd/bjam Detecting Python version... ./configure: /no/such/python: not found Detecting Python root... ./configure: /no/such/python: not found Unicode/ICU support for Boost.Regex?... no. Generating Makefile... FWIW, it might be nice to specify "#!/bin/sh -e" so that the script would not generate a makefile if there is an error... as far as I got with that is that "tools/build/jam_src/build.sh --guess-toolset" exits with status 1 even though it has correctly determined that the toolset here is "gcc", which then stops "configure". I could poke further if you like... -t

On Oct 31, 2005, at 11:00 AM, troy d. straszheim wrote:
On Mon, Oct 31, 2005 at 10:15:49AM -0500, Doug Gregor wrote:
I'm CC'ing John Maddock, who is in charge of the config library. It turns out that we're talking about two different "configure" scripts: I was referring to the new one in the Boost root directory, whereas you've found some issues with the one in libs/config. Sorry about the confusion!
Hey Doug,
The one in BOOST_ROOT doesn't work on platforms that have a real bourne shell and not bash in disguise (I'm guessing you wrote that on a linux box?). FreeBSD 5.4 doesn't like it, for instance... Bourne shell's comparison is a single =, not ==.
Mac, but the same issue exists. Thanks!
If you run ./configure --with-python=/no/such/python the script still runs to the end, like this:
Building Boost.Jam with toolset gcc... tools/build/jam_src/ bin.freebsd/bjam Detecting Python version... ./configure: /no/such/python: not found
Detecting Python root... ./configure: /no/such/python: not found
Unicode/ICU support for Boost.Regex?... no. Generating Makefile...
I now have it turning off Python support when Python can't be found. Thanks for reporting this! Doug
participants (9)
-
Andrew Maclean
-
Angus Leeming
-
David Abrahams
-
Doug Gregor
-
Douglas Gregor
-
Manfred Doudar
-
Reece Dunn
-
Robert Ramey
-
troy d. straszheim