Hi
For one of my projects I need to get the contents of
/etc/redhat-release during the configure process and assign the
contents to a variable. I'm currently using the following:
redhat_release=`cat /etc/redhat-release 2 /dev/null`
This works fine, but I was wondering if anyone had any
On Mon, Nov 19, 2012 at 12:36 PM, Eric Blake ebl...@redhat.com wrote:
You can avoid the command substitution fork by using read:
{ read redhat_release /etc/redhat-release; } 2/dev/null
Whether that's deemed any simpler, though, is a matter of taste. Not to
mention that use of 'read' like
On Mon, Nov 19, 2012 at 1:36 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
According to the Autoconf manual, the Tru64/OSF 5.1 sh might abort if
the above is run and the /etc/redhat-release file doesn't exist, since
that shell treats 'read' as a special (in POSIX sense) built-in.
Hi
I'm trying to add a check to my configure.ac to determine if clang is
being used, I have the following:
CLANG_CC=
if test $GCC = yes; then
if test `$CC -v 21 | grep -c 'clang version'` != 0; then
CLANG_CC=1
fi
fi
And I'm trying to use AS_IF instead, I've been reading to
On Thu, Jun 7, 2012 at 3:09 PM, Peter Breitenlohner p...@mppmu.mpg.de wrote:
according to the Autoconf manual (8.1 M4 Quotation) that should be
AS_IF([test $GCC = yes],
[AS_IF([test `$CC -v 21 | grep -c 'clang_version'` !=
0],[CLANG_CC=1])],
[CLANG_CC=])
i.e., exactly one level of
On Thu, Jun 7, 2012 at 4:04 PM, Eric Blake ebl...@redhat.com wrote:
AS_IF([test $GCC = yes],[
^
Unmatched [.
Thanks, I'd spotted that but it still doesn't seem to fix the problem
for me. I now have:
# check for clang
AS_IF([test x$GCC = xyes],
[AS_IF([test
On Thu, Jun 7, 2012 at 4:39 PM, Eric Blake ebl...@redhat.com wrote:
How so? It's poorly indented, but syntactically valid.
Damn it, it's been one of those days... but it's not setting CLANG_CC
when building with clang...
Cheers
Adam
___
Autoconf
Hi
Is there a way to change the default value of specific configuration
flags depending on whether the project is built from the development
repository or from a release tarball, i.e. built using make dist?
There are specific configuration flags that I would like to have
enabled by default when
Hi
In one of my macros I need to do one thing on linux platforms and
another on others, in the macro I have the followings:
if test x$build_os = xlinux; then
# case for linux
else
# other platforms
fi
I recently received a bug report that this wasn't working as the users
system
On Thu, Apr 7, 2011 at 12:02, Daily, Jeff A jeff.da...@pnl.gov wrote:
Try a case statement. I use the m4sh version e.g.
AS_CASE([$build_os],
[*linux*], [AS_ECHO([case for linux])],
[AS_ECHO([other platforms])])
Thanks, I didn't think about case. Thats seems the most
On Thu, Apr 7, 2011 at 12:14, Eric Blake ebl...@redhat.com wrote:
'test -o' is completely non-portable.
Best to avoid that then
case $build_os in
linux* | cygwin*) # case for linux, linux-gnu, and cygwin
;;
*) # other platforms
;;
esac
case seems like the appropriate solution.
On Tue, Nov 9, 2010 at 01:31, Gary V. Vaughan g...@gnu.org wrote:
The minimum m4 version is specified in the README for the version of autoconf
you wish to use. Currently the relevant section says:
You should install GNU M4 (version 1.4.6 or later is required
1.4.14 or later is
Hi
I'm trying to track down a strange build problem on an old Linux
system (Debian Woody), I think it may be related to an m4 issue. What
is the minimum version of m4 that is required for modern autotools
systems as I can't find anything in the release notes (apologies if
I've missed the
On Sat, Jul 3, 2010 at 14:51, Eric Blake ebl...@redhat.com wrote:
Eric
Does this (untested) patch fix things for you? I am
unfortunately not in a position to release 2.67 for another
2 weeks, but if this patch helps, I'm sure distros can
incorporate it if they choose to release a fixed 2.66
On Tue, Jun 29, 2010 at 03:36, Peter Breitenlohner p...@mppmu.mpg.de wrote:
Peter
Here the macro we are using in TeX Live for such tests (C and C++).
This seems to do the trick! Thanks, this is great!
Cheers
adam
___
Autoconf mailing list
On Sat, Jun 26, 2010 at 14:25, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
Ralf
I've been looking at these macros and they don't seem to be setting
the platform specific link flags, from the documentation:
Please ask about this on the gnulib list, I'm not sure if the macros are
supposed
On Wed, Jun 16, 2010 at 12:19, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
Is there a way the appropriate platform-specific options can be added
automatically?
You can use the gnulib module havelib and the macros it provides.
I've been looking at these macros and they don't seem to be
On Wed, Jun 16, 2010 at 12:19, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
Is there a way the appropriate platform-specific options can be added
automatically?
You can use the gnulib module havelib and the macros it provides.
Thanks Ralf, that seems as if it may do the job.
Cheers
Adam
On Tue, Jun 15, 2010 at 23:12, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
I'm not sure I understand this paragraph.
I'll try to be a bit clearer. One of our libraries liblalframe depends
on libframe, on our systems libframe is usually installed in
/opt/lscsoft/libframe, during the
Hi
One of the projects I work on is a series of different libraries and
we kept running into problems with users polluting their environments
so during the build process the headers and libraries from
dependencies do not match, i.e. the environment points to headers in
/path/master/include and
On Mon, May 24, 2010 at 18:41, Sam Shin samsill...@gmail.com wrote:
I am trying to print what a user would pass to a configure script. For
example:
./configure --enable-foo --enable-bar
I noticed that in config.log, the configure script will save a copy of how
it was called by the user. Is
Hi
One of the platforms I _need_ to support for development is CentOS 5,
which comes with very old versions of the autotools:
m4-1.4.5-3.el5.1
autoconf-2.59-12
automake-1.9.6-2.1
libtool-1.5.22-7.el5_4
I have tried to get approval to update to more recent versions to no avail.
I am currently
On Wed, May 19, 2010 at 10:46, Eric Blake ebl...@redhat.com wrote:
Eric
The latest version of autoconf depends on m4 1.4.6 or greater, because
m4 1.4.5 has bugs in translit that newer autoconf would trigger
(autoconf 2.59 did not trigger those bugs, so using stock tools on your
distro should
On Wed, May 12, 2010 at 12:05, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
Are the environment variables $EMACS or $TEST_EMACS set? If yes, please
let the user retry after unsetting them. If the error persists, please
post the output of
make SHELL='/bin/sh -x'
(adjust to the shell used
Hi
I am the maintainer for the autoconf port in MacPorts and a user has
reported a strange build error to me which I cannot duplicate:
Making all in emacs
WARNING: Warnings can be ignored. :-)
if test emacs != no; then \
set x; \
list='autoconf-mode.el autotest-mode.el'; for
On Tue, May 11, 2010 at 17:10, Eric Blake ebl...@redhat.com wrote:
Eric
Did they rerun autoconf?
No, the port will just run ./configure make make install (with
the appropriate options).
If so, what versions of autoconf and m4? I
know that m4 1.4.10 (several versions ago) was broken for
On Tue, May 11, 2010 at 17:45, Eric Blake ebl...@redhat.com wrote:
Eric
At this point, I would have to see the configure file (or at least the
relevant portion around the point where the error message occurs, about
touch not liking -b). But seeing as how the report was about building
emace,
On Mon, Jan 25, 2010 at 15:53, Adam Mercer ramer...@gmail.com wrote:
It seems to me that a better test would be check the output of
condor_compile gcc -print-prog-path=ld and act accordingly. I've
therefore been looking for a macro that gets the output from a given
command, but can't find
Hi
I while ago I posted to the libtool list [1,2] regarding a problem I
was having with a autotools based project and the condor workflow
management system [3]. With the help of Ralf and the Condor developers
a workaround, and more importantly a solution, was found. When
compiling code for use
On Thu, Oct 22, 2009 at 14:31, Ben Pfaff b...@cs.stanford.edu wrote:
I imagine that pkg-config has not been integrated into Autoconf
because it does not fit well into the Autoconf philosophy.
I use pkg-config quite heavily in one of my projects, I'm just
wondering is there a more autoconf way
On Mon, Oct 12, 2009 at 23:48, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
Thanks. The rebuild rule is generated alright, but nothing depends on
the output file. So adding
all-local: git_version
to lib/Makefile.am would be one possibility. In your case, you should
add git_version as
On Thu, Oct 8, 2009 at 16:03, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
Can you post configure.ac and the Makefile.am, or a small example
package that reproduces the issue?
I've attached a simple example package that reproduces the problem:
[...@mimir example]$ autoreconf
[...@mimir
Hi
As part of the configure process I generate a script, git_version,
from a file git_version.in specified in AC_CONFIG_FILES() so that an
appropriate python interpreter is used. However if I modify the
git_version.in file the git_version script is not regenerated when
running make. Is there
On Thu, Oct 8, 2009 at 13:59, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
Are you using Automake? If yes, and if the arguments to AC_CONFIG_FILES
are shell literals, then automake should produce a rule to regenerate
the file for you.
Yes I'm using automake, I believe the arguments to
On Wed, Jul 29, 2009 at 10:29, Steffen
Dettmersteffen.dett...@googlemail.com wrote:
you would have flag list redundant and it could happen someone will
forget to change one place when adding next flag...
so maybe just call a function?
I was thinking along those lines myself.
the withval
Hi
At the moment I have a --with argument that is off by default and I
would like to change this so that is on by default and users will need
to configure using --without-arg or --with-arg=no to disable the
feature, essentially adding a lot of strict warning flags. I currently
define the option
On Sun, May 24, 2009 at 14:28, Adam Mercerramer...@gmail.com wrote:
On Sun, May 24, 2009 at 01:22, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
* Adam Mercer wrote on Sat, May 23, 2009 at 11:57:35PM CEST:
In a project I am involved with we are in the process of moving from
ANSI C89 to C99
On Fri, Jun 5, 2009 at 12:24, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
Hello Adam,
* Adam Mercer wrote on Fri, Jun 05, 2009 at 04:42:08PM CEST:
I have now got this working; on systems where AC_PROG_CC_C99 is
available this is used, otherwise the local copy is used. I have
noticed
On Sun, May 24, 2009 at 01:22, Ralf Wildenhues ralf.wildenh...@gmx.de wrote:
Hi Ralf
* Adam Mercer wrote on Sat, May 23, 2009 at 11:57:35PM CEST:
In a project I am involved with we are in the process of moving from
ANSI C89 to C99, the first step in this transition was to use
AC_PROG_CC_STDC
39 matches
Mail list logo
