gmane.comp.sysutils.autoconf.general

Re: test for CXXLD

Nicolas Bock — 2013-06-19T18:30:37

Good point. Thanks,

nick


On Wed, Jun 19, 2013 at 12:25 PM, Robert Boehne <robertb< at >trdlnk.com> wrote:

Re: test for CXXLD

Robert Boehne — 2013-06-19T18:25:49

Since the syntax you're using will only support one compiler anyway,
you might consider creating a shell script to do the actual configure run.

it might look something like this:

#!/bin/sh
mkdir -p build
cd build
../configure --prefix=/path/ferinst  --other-arguments LDFLAGS='-Xlinker 
"-languae charm++"'

Since it's not going to be portable you may as well skip the AM_ 
variables and go this route.

HTH,

Robert B

On 06/19/13 13:16, Nicolas Bock wrote:

Re: test for CXXLD

Nicolas Bock — 2013-06-19T18:16:02

Thanks for the reply. I ended up using

AM_LDFLAGS = -Xcompiler "-language charm++"

For some reason CXXLDFLAGS was not added to the linker command in Makefile.

Thanks again,

nick



On Thu, Jun 6, 2013 at 4:40 PM, Gavin Smith <gavinsmith0123< at >gmail.com>wrote:

Re: Documentation issues

Bruce Korb — 2013-06-16T20:53:30

Must have been.  I fixed them both at once (replacing that with
"AC_HELP_STRING", which seemed more correct).  Now I see that
AS is preferred.  I think it weird, but I'm sure there's a reason
somewhere....

Thanks.

Still the teeny quoting niggle. :)

Re: Documentation issues

Zack Weinberg — 2013-06-16T19:44:29

...

Typo?  AC_ARG_WITH, not AC_ART_WITH.

This might also explain the AS_HELP_STRING error.

zw

Documentation issues

Bruce Korb — 2013-06-16T17:46:11

Autoconf
********

This manual (24 April 2012) is for GNU Autoconf (version 2.69), a
package for creating scripts to configure source code packages using
templates and an M4 macro package.

    Copyright (C) 1992-1996, 1998-2012 Free Software Foundation, Inc.
[...]
15.2 Working With External Software
===================================
[...]
           AC_ARG_WITH([readline],
             [AS_HELP_STRING([--with-readline],  <<<=== invalid macro
               [support fancy command line editing < at ><:< at >default=check< at >:>< at >])],
             [],
             [with_readline=check])

           LIBREADLINE=
           AS_IF([test "x$with_readline" != xno],
             [AC_CHECK_LIB([readline], [main],
               [AC_SUBST([LIBREADLINE], ["-lreadline -lncurses"])
                AC_DEFINE([HAVE_LIBREADLINE], [1],
                          [Define if you have libreadline])
               ],
               [if test "x$with_readline" != xcheck; then
                  AC_MSG_FAILURE(
                    [--with-readline was given, but test for readline failed])
                fi
               ], -lncurses)]) <<<=== needs quoting


configure.ac:40: the top level
configure.ac:43: error: possibly undefined macro: AC_ART_WITH
       If this token and others are legitimate, please use m4_pattern_allow.
       See the Autoconf documentation.
configure.ac:44: error: possibly undefined macro: AS_HELP_STRING

Re: Specify target in Makefile.am file

Eric Blake — 2013-06-15T10:09:16

Makefile.am is managed by automake, not autoconf.  You might get better
answers by asking on the automake list.

Re: Specify target in Makefile.am file

Avneet Kaur — 2013-06-12T17:53:42

For this, DIST_SUBDIRS is a right solution?


--
Avneet Kaur
www.avneetkhasla.wordpress.com

Specify target in Makefile.am file

Avneet Kaur — 2013-06-12T17:06:31

We use SUBDIRS to specify the sub directories in Makefile.am file like

SUBDIRS = src doc examples bindings

Run "make" will compile the makefile under these directories by default.

But I want to remove doc from default option like it will run by "make
doc" target only.

This is looking for what step or variable??
Wiating for your response.


--
Avneet Kaur
www.avneetkhasla.wordpress.com

Re: implement workaround for header files

Peter Johansson — 2013-06-10T23:15:43

Hi Gavin,

Yes, unfortunately the boost header file is included in an installed 
header file. The functionality is not used by users directly though, but 
inclusion is required because the Class holds a private 'boost::mutex'. 
I could probably have changed that by hiding the members in a pimpl 
pattern. But I've already implemented a fix that installs the patched 
header files and uses the original header file if possible

http://dev.thep.lu.se/yat/changeset?reponame=&new=3045%40trunk%2Fyat%2Futility%2Fboost_exception_ptr.h&old=3044%40trunk%2Fyat%2Futility%2Fboost_exception_ptr.h

Cheers,
Peter

Re: implement workaround for header files

Gavin Smith — 2013-06-09T17:41:40

Do users of your library have to use what is declared in
<boost/exception_ptr.hpp>; equivalently, do they have to include this
file to use your library? If not, there wouldn't be a problem - the
source for your library could include an alternative header file, but
it wouldn't have to be installed - it is only needed when the library
itself is compiled.

Re: implement workaround for header files

Peter Johansson — 2013-06-09T02:24:29

Hi Jeff,

Thanks for your input. Yes, I think I prefer to implement a compilation 
test rather than try to set up some rules based on GCC versions and 
Boost version (although I'm pretty sure problem only occurs for Boost 
v1.41). Yet working out which versions of GCC are problematic seems tedious.

Thanks,
Peter

Re: process result code in if

Miles Bader — 2013-06-07T22:11:08

Hmmm, I can never remember which is the portable one, but from the
autoconf docs, one should usually use "if test ! ..." instead :

     It is safe to use `!' as a `test' operator.  For example, `if
     test ! -d foo; ...' is portable even though `if ! test -d foo;
     ...' is not.

However in this case, because he wants specific behavior for the case
where test gives a syntax error, I guess it's better to instead use
"if test ... then : ; else ..."


-miles

RE: implement workaround for header files

Daily, Jeff A — 2013-06-07T15:35:08

Peter,

I'm not an experienced boost user, but I am aware that much of boost is header-only libraries.  And it sounds like from your description above that your library installs headers which also include this potentially broken header <boost/exception_ptr.hpp>.  The community would need to chime in here, but for my projects I don't install the generated config.h or a subset public_config.h like you have done, but since you already have that capability it would probably be little effort for you to extend public_config.h with an AC_DEFINE of the result of your test and then include your public_config.h from the top of your installed headers.

As an alternative, doesn't GCC provide version preprocessor macros?
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
You could test for the version of GCC that doesn't work with this header and then include your replacement instead.  Of course this will only work with GCC compilers and perhaps other non-GCC compilers which claim to accept the GNU C dialect, but those non-GCC compilers might not have the same problem and then the configure test would be the better way to go since you test for the feature rather than a GCC version.

__________________________________________________ 
Jeff Daily 
Scientist 
Pacific Northwest National Laboratory

Re: process result code in if

Andres Perera — 2013-06-06T22:56:55

yea, forking for grep is probably going to make your script significantly slower


i've found through benchmarks that certain shells (dash and bash and
ksh) are optimized towards if statements over case ones

i would parse the number like this for best performance, but make a
copy for $var because it's destructive:

trim()
{
    n=$1 v=$2
    while [ ${#v} -ne $n ]
    do
        v=${v%?}
    done
    echo $v
}

if [ -z "$var" ]; then
    echo "ENOTNUM $var" >&2
    exit 2
fi

if [ $(trim 1 $var) = '+' ]; then
    echo "we got a signed number; begin normalizing procedure"
    var=${var#?}
fi

while [ ${#var} -ne 0 ]
do
    if [ ${var%${var#?}} = '0' ] || [ ${var%${var#?}} = '1' ] || [
${var%${var#?}} = '2' ] || [ ${var%${var#?}} = '3' ]; then
        echo "digit is base 4"
    else
        echo "ENOTNUM $var" >&2
        exit 2
    fi
    var=${var#?}
done

Re: process result code in if

Tim Rice — 2013-06-07T13:34:26


"if ! test ..."  is definitely not portable.

Re: process result code in if

Miles Bader — 2013-06-07T06:46:44

Incidentally, test should never produce any output on stdout, so you
can just use "2>/dev/null" instead of "> /dev/null 2>&1"... :]

-miles

Re: process result code in if

A.P. Horst — 2013-06-07T06:08:09

On 7-6-2013 5:13, Miles Bader wrote:

Thanks for all the great input! Seems google isn't always your best 
friend, at least not when it comes to autoconf. The solution with the 
test command is very elegant and readable.
I ended up using this:
if ! test $var -gt 0 > /dev/null 2>&1; then
     <not a positive integer>
fi

This works also when something else than a number or nothing at all is 
given.

I will try to remember autoconf also eats brackets.

arie

Re: process result code in if

Miles Bader — 2013-06-07T03:13:24

I dunno, test here (both coreutils test, and the bash builtin) seems
to handle negative numbers just fine using "test $x -gt 0" ...

[I suppose maybe there are broken versions of test out there, the
usual issue with just about anything in autoconf... typically Sun... >< ]

-miles

Re: process result code in if

Gary V. Vaughan — 2013-06-07T02:25:09

On 7 Jun 2013, at 08:41, Miles Bader <miles< at >gnu.org> wrote:

You mean "test 0 -lt $x", otherwise if x starts with a hyphen (e.g -1) things will go awry!

Cheers,

Re: process result code in if

Miles Bader — 2013-06-07T01:41:26

Wait, why can't you use "test $x -gt 0"...?

-miles