understand why anyone
is unable to update and use modern versions. Other
than policy dictates from a boss or project director,
is there any reason not to use the latest release?
--
William Pursell
___
Autoconf mailing list
Autoconf@gnu.org
http
).
--
William Pursell
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
,
as you're looking in the wrong place. The type of questions
you're asking are more appropriate for the package
management system, and you should be making changes to
your spec file and your debian/rules file, etc.
--
William Pursell
___
Autoconf mailing list
that if PKG_CHECK_MODULES were simply
expanded to invoke AC_LINK_IFELSE to check that
the contents of the .pc files are valid, then
there would be no issue at all.
--
William Pursell
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo
(or administrator) has supplied the correct
information.
--
William Pursell
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
of the build,
but less safety because no checks are
done during configure time to ensure
that libbar even exists, unless the
maintainer takes extra steps to do so
beyond invoking PKG_CHECK_MODULES. There
is an extra level of indirection available
to the user at configure time.
--
William Pursell
. The ordering
is as imposed by the author of configure.ac. @FOO_LIBS@ @BAR_LIBS@
leads to -L/foo -L/bar, while @BAR_LIBS@ @FOO_LIBS@ leads
to -L/bar -L/foo.
--
William Pursell
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo
I have many generated files to set as executable, is there a
quicker way than to have an AC_CONFIG_FILES([...], [chmod +x ...])
instruction for each file?
You can do:
m4_esyscmd([for f in foo bar;
do echo AC_CONFIG_FILES([$f],[chmod +x $f]); done])
Eric, is that safe?
--
William
collect chmod +x collect
You probably want $srcdir/collect.rb. (Sorry,
that doesn't answer your question, but your
current setup won't allow a VPATH build.)
--
William Pursell
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman
Alex Katebi wrote:
I need to check for libraries that are installed in /usr/local/lib or
/opt/lib. The AC_CHECK_LIB does not look into these dirs.
Is there a path variables for the library checking that can be set? What are
my options?
configure LDFLAGS=-L/usr/local/lib
--
William Pursell
* doc/autoconf.texi (Using the System Type): Use AS_CASE in
example instead of raw case.
Signed-off-by: William Pursell bill.purs...@gmail.com
---
ChangeLog |6 ++
doc/autoconf.texi | 10 +-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/ChangeLog b
it be better to change the wording to:
checking whether to disable assertions...no
since defining DNDEBUG to turn them off is
the action?
--
William Pursell
), and not 1.4.8 or newer, so I'm guessing either 1.4.6 or 1.4.7.
I'm using 1.4.6
--
William Pursell
Eric Blake wrote:
According to William Pursell on 12/7/2008 12:11 AM:
+Fix AC_HEADER_ASSERT to honor --enable-assert, rather than
+treat --enable-assert and --disable-assert equivalently.
+* lib/autoconf/headers.m4
+
Thanks for the idea; it is certainly a step in the right
diff --git a/ChangeLog b/ChangeLog
index a250ee2..bde246f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2008-12-06 William Pursell [EMAIL PROTECTED]
+
+ Fix AC_HEADER_ASSERT to honor --enable-assert, rather than
+ treat --enable-assert and --disable-assert equivalently
. You should include the file @file{stamp-h.in} in your
package's distribution, so that @command{make} considers
@file{config.h.in} up to date. Don't use @command{touch}
(@pxref{touch, , Limitations of Usual Tools}); instead, use
--
1.6.1.rc1.37.g83daf.dirty
--
William Pursell
)/testsuite.at
+$(TESTSUITE): $(srcdir)/package.m4 $(srcdir)/testsuite.at
$(AUTOTEST) -I '$(srcdir)' -o $@@.tmp $@@.at
mv $@@.tmp $@@
@end example
--
William Pursell
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo
Eric Blake wrote:
According to William Pursell on 10/13/2008 1:06 AM:
Thirdly, is there any standard way to take a file
foo.c and generate an autoconfiscated tree structure?
Not that I know of. What tree structure are you proposing?
I suspect that would be a contentious issue
Eric Blake wrote:
Furthermore, your patch still has some portability problems. For example,
... you cannot rely on the existence of mktemp.
I don't want to consume a lot of your time answering ignorant
questions from a newbie, but why is it that AS_TMPDIR is
able to use mktemp?
--
William
This may be a controversial patch, but I think that
of all the times I have ever run configure --help
without appending |less it was either because I
piped the output through more or because I forgot
to paginate completely.
--
William Pursell
diff --git a/lib/autoconf/general.m4 b/lib/autoconf
I'm curious about the fact that when I run autoscan, it generates
a configure.scan with the line:
AC_PREREQ(2.61)
Should that be AC_PREREQ([2.61])?
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
I just cloned a8eb8963bbcb4d7f278ab8fece54f64e1334
from Savannah and ran into a problem building. Following
the directions in README-hacking, I ran:
$ ./configure
$ make
$ ( PATH=`pwd`/tests:$PATH; autoreconf -vi )
Which failed with:
...
configure.ac:21: error: Autoconf version 2.60 or
Recently, Sam Steingold wrote:
AC_DEFUN([CL_FFCALL],[dnl
AC_ARG_WITH([ffcall],
[AC_HELP_STRING([--with-ffcall],
the idiom of using dnl to suppress the newline is common,
as is the lack of indentation to prevent m4 from inserting
unwanted white space. Is there any mechanism in m4 to allow
Christopher Key wrote:
I've a package for which I'd like to include some Doxygen created
documentation in the distributed tarball. I'm having some problems, I
think fundamentally because the way the documentation gets built doesn't
fit very well with the src and build tree ideas.
I can
Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to William Pursell on 9/29/2007 11:14 AM:
I'm talking about those files named $cache_file in
my $CONFIG_SITE. Since they hold lines of the form:
ac_cv_func_foo=${ac_cv_func_foo=yes}
the cache is invalid if I remove
Bob Proulx wrote:
William Pursell wrote:
I often find myself removing a package and then deleting
all of my cache files, but I have a tendency to forget
to delete the cache files until a configure invocation
noticeably misbehaves.
Autoconf cache files? As in the 'autom4te.cache' directories
Originally, I was planning to post this question to one of the
Debian lists, but the second part of the question is more
appropriate here, so I thought I would just start here.
I often find myself removing a package and then deleting
all of my cache files, but I have a tendency to forget
to
Aslak Johannessen wrote:
I have recently been putting all of the relevant information in
configure.ac, and letting configure build the package files.
For example, debian/control.in will hold lines of the form:
Description: @PACKAGE_SUMMARY@
@PACKAGE_DESCRIPTION_DEB@
Hi thanks for the answer,
Aslak Johannessen wrote:
To make autoconf automake and dpkg-buildpackage run one needs to edit
and type information into many different files. Mainly Makefile.am
configure.in and debian/control. Much of this information is duplicated
and the need for a centralized configuration file for each
[EMAIL PROTECTED] wrote:
* [EMAIL PROTECTED] wrote on Tue, May 08, 2007 at 02:46:53PM CEST:
When I use AC_CHECK_DECL, how can I prevent it from outputting to the
console for a specific message only? I don't want to supress all
messages, only one specific message (and replace it with my
30 matches
Mail list logo
