I edited in the "set -x ; " so I could see what actually happened when
the scriptlet ran. Since the "top_srcdir" is ../../.., it goes into the
source tree's "doc" directory and tries to make a backup directory. That
doesn't work in "make distcheck". Also, "complexity.texi" is in the
build
In 9/9/20 11:37 AM, Bruce Korb wrote:
So in the years since I last rebuilt my project, it seems the world
has changed. What should I be looking for?
OK. I've made some progress without any hints. Now I'm hitting this that
I've never seen before:
$ grep do_not_make_me au*bld/autoopts
So in the years since I last rebuilt my project, it seems the world
has changed. I spent two days pounding on configury stuff just to get
it to the point where bootstrapping once again succeeds and the
project built and ran "make check". With more fiddling, I got it to
roll up a distribution, but
at 4:39 PM Bruce Korb wrote:
>
> Long, long ago I learned that the safest thing is to purge my build
> directory and create a new one.
> After that, I link in all of my managed sources and then create any
> derived sources I need.
> After doing that, I run "autoreconf
)
> {
> $suppress = 0;
> $trailer = "\nerror while copying";
> }
> - Dan
>
> On Sat, Aug 31, 2019 at 5:17 PM Bruce Korb wrote:
> >
> > Hi,
> >
> > Googling doesn't get me any answers and
Hi,
Googling doesn't get me any answers and I cannot rebuild until
autoreconf is gotten working.
The embedded autoreconf step that fails is automake. I have no idea at
all what the message is really trying to say. Help, please?
$ automake --add-missing --no-force
Makefile.am: error: installing
An additional data point:
On Sat, Aug 4, 2018 at 12:29 PM Bruce Korb wrote:
>
> I ask because after printing this:
>
> > =
> > autogen-5.18.15 archives ready for distribution:
> > autogen-5.18.15.tar.gz
I ask because after printing this:
> =
> autogen-5.18.15 archives ready for distribution:
> autogen-5.18.15.tar.gz
> autogen-5.18.15.tar.xz
> =
I get this message:
> CDPATH="${ZSH_VERSION+.}:" && cd
On 05/06/15 01:58, Michael Haubenwallner wrote:
Trivial patch for fixincludes.
A) sufficiently trivial that explicit permission ought not be required
B) it is now officially blessed that we can coalesce year lists.
Let's do so, okay?
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
On 05/03/13 02:27, Stefano Lattarini wrote:
retitle 14337 Uncleer error messages when a test script is missing
severity 14337 minor
tags 14337 wontfix
thanks
Meets _my_ expectation... :)
Never mind. I think the test driver code should say something
useful, however. I neglected to notice
It's taken me a few hours to unwind all this stuff, but the bottom line
seems to be that make check doesn't think it needs to do anything to
make the test log file.
Googling for: making test-suite.log: failed to create log nothing to be done
for
did not yield any useful hints.
Help, please?
On 05/02/13 16:58, Bruce Korb wrote:
Help, please?
P.S. this only happens for srcdir != builddir builds
and the xtrace output below is triggered by manually inserting
set -x into the $(TEST_SUITE_LOG): rule.
===
$ make check
[.]
bash make base.log
make[3
On 02/19/13 03:09, Stefano Lattarini wrote:
How can I fix this error?
Automake doesn't have nor provide any 'autogen.sh' file itself; so you'll
have to report this to the developers of the package you are trying to
bootstrap.
Autogen is also a project that I maintain, so were you to use
a sharutils test. I needed a large tree to archive into a split up
archive that I then unroll and validate. What would be more convenient
than to create a temporary directory and archive all of
cd ${top_builddir}
Worked like a charm. It is huge and has to be split up and has
a mixture of
What might induce configure to insert a space after -g and before gdb3?
configure:15849: result: no
configure:15864: checking whether uname(2) is POSIX
configure:15880: /usr/bin/gcc -std=gnu99 -o conftest -ggdb3 conftest.c -ldl
5
+ eval '$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS
On 01/06/13 10:33, Bruce Korb wrote:
diff -r /u/gnu/proj/sharutils-bld/sharutils-4.13.3/_build/tests/shar-3.log
shar-3.d/tests/shar-3.log
1d0
Only in
/u/gnu/proj/sharutils-bld/sharutils-4.13.3/_build/doc/sharutils.t2d/sharutils.t2d:
tex_help
It seems the build tree wiggles while
automake is trying to tell me something, but I cannot make out exactly what.
The literal meaning of the messages is pretty clear, but what they caution
about are things that appear to me to be correct.
autoreconf --force --install --verbose --symlink
autoreconf: Entering directory `.'
Hi Dave, Stefano,
On Thu, Nov 8, 2012 at 11:40 AM, Dave Goodell good...@mcs.anl.gov wrote:
On Nov 8, 2012, at 1:19 PM CST, Stefano Lattarini wrote:
On 11/08/2012 07:56 PM, Bruce Korb wrote:
I'd expect its definition to be brought in by the 'libtoolize' call
issued by autoreconf; but then I
On 03/31/12 01:34, Stefano Lattarini wrote:
Is this a known problem or do I need to investigate further?
The issue you're facing sounds new to me, so I say some more investigations
are warranted. Could you maybe post a minimal reproducer of the issue here,
so that we can decide whether it is
On 03/31/12 09:24, Bruce Korb wrote:
installcheck-recursive test -f xml2ag/Makefile
installcheck-recursive test no = no
installcheck-recursive make installcheck-am
GNU Make 3.82
[]
Must remake target `installcheck'.
Successfully remade target file `installcheck'.
$ ls xml2ag/Make*
ls
On 03/31/12 13:44, Bruce Korb wrote:
I didn't see it at first because of the comment that made it look like
something different from the installcheck-am rule. The problem
is a *partially* commented out maintainer-clean rule.
installcheck-am:
#maintainer-clean: maintainer-clean-recursive
On 03/31/12 13:58, Bruce Korb wrote:
On 03/31/12 13:44, Bruce Korb wrote:
I didn't see it at first because of the comment that made it look like
something different from the installcheck-am rule. The problem
is a *partially* commented out maintainer-clean rule.
installcheck-am:
#maintainer
On 03/29/12 16:37, Bruce Korb wrote:
My tool versions, an edited transcript with the failure message and then a help
request.
I modified the top level Makefile thus:
test -f xml2ag/Makefile \
$(MAKE) $(AM_MAKEFLAGS) \
test -f xml2ag/Makefile
My tool versions, an edited transcript with the failure message and then a help
request.
$ for f in autoconf automake libtool ; do $f --version | head -1 ; done
autoconf (GNU Autoconf) 2.68
automake (GNU automake) 1.11.1
libtool (GNU libtool) 2.4
chmod -R a-w autogen-5.16pre15; chmod a+w
This is a autoconf, automake and make question, rebuffed in gnulib.
It's partly autoconf because autoconf stages dummy dependency files
so the make include function won't choke. It is partly make because
I find it a bit tricky getting the dependencies just right. It is,
I think, mostly an
Let's see if these are the right lists
It's partly autoconf because autoconf stages dummy dependency files
so the make include function won't choke. It is partly make because
I find it a bit tricky getting the dependencies just right. It is,
I think, mostly an automake question since I
PING:
The bison accepts the option, --header-file=whatever.h
ylwrap is a wrapper script meant to canonicalize the invocation
of yacc and bison. True enough, if you use --header-file you
had better be using bison, but here is the problem:
I am working on a project that will only build in a GNU
On 10/17/11 10:35, Bruce Korb wrote:
The --header-file=whatever fails to preserve the header file.
ylwrap builds in a subdirectory and removes it. I don't know
what the easiest fix is. For now, I've hacked ylwrap to look
for a header with a name other than y?tab.h and, if it exists,
move it up
The --header-file=whatever fails to preserve the header file.
ylwrap builds in a subdirectory and removes it. I don't know
what the easiest fix is. For now, I've hacked ylwrap to look
for a header with a name other than y?tab.h and, if it exists,
move it up one directory. Not very
On 10/14/11 09:31, Dave Goodell wrote:
Having pondered this issue a lot for my playtime toy:
http://www.gnu.org/software/autogen
my solution was to implement -M options, a la gcc.
That's fine for that thing, but it leads me to what is likely
a proper ultimate solution for multi-output tools:
On 02/03/11 12:51, Ralf Wildenhues wrote:
Hi Bruce,
* Bruce Korb wrote on Thu, Feb 03, 2011 at 09:48:25PM CET:
P.S. in researching this, I found in my own logs a bunch of these:
rm -rf $backupdir; exit $rc
mkdir: cannot create directory `.am21666': Permission denied
make[3]: Leaving
Hi Ralf, Dave,
5.11.5 was released December 13 and does not have this problem.
Thanks for letting me know!!
Regards, Bruce
On Wed, Jan 19, 2011 at 10:21 AM, Ralf Wildenhues
ralf.wildenh...@gmx.de wrote:
diff -ru am-libopts-subpkg/subproj/libopts/m4/liboptschk.m4
Hi Eric,
Thank you. automake list folks -- the main question is
Why are .m4 files being installed and how can I prevent it?
Original Message
Subject: [Bug 347095] sys-devel/autogen installs colliding \
m4 macros which break random packages
Clear-Text:
On 12/07/10 01:54, Schwarz, Konrad wrote:
as well as listing in the rationale examples such as $($(@)_FLAGS) and
$(V$O) that are unspecified.
$($...@_flags) is a very useful, as it allows target-specific
flags.
For all targets whose name conforms to make macro name requirements.
It would
On 11/16/10 23:28, Ralf Wildenhues wrote:
* Bruce Korb wrote on Tue, Nov 16, 2010 at 10:18:50PM CET:
On 11/16/10 12:45, Ralf Wildenhues wrote:
This comes probably from autoreconf, not from aclocal.
That is rather difficult to discern. Either way, the
controlling program needs to say:
I
On 11/17/10 07:35, Eric Blake wrote:
On 11/17/2010 08:11 AM, Bruce Korb wrote:
OK. I don't see where it should come from in Autoconf nor Automake.
Any case the package at hand contains m4_esyscmd in configure.ac that
^
contains a buggy sed
What is it really trying to say?
I'm not a real perl expert.Thank you!
$ autoreconf --force --install --verbose --symlink
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
sed: invalid option -- 'q'
Usage: sed
On 11/16/10 12:45, Ralf Wildenhues wrote:
This comes probably from autoreconf, not from aclocal.
That is rather difficult to discern. Either way, the
controlling program needs to say:
I was running this script:\n%s\nAND:\n%s
which might get wrapped again by autoreconf (or not).
(echo 1; echo
Hi Ralf,
In the end, this is where I wound up:
1. In configure.ac, ensure that there is some compilation language
a la AC_PROG_CC that enables the ``if AMDEP'' machinery
(i.e. AM_SET_DEPDIR gets invoked).
2. in Makefile.ac you have something like this:
if AMDEP
DEP_ARG =
Hi Ralf,
I'm at work now, so not too much play time available.
But some.
On Mon, Jun 28, 2010 at 10:02 PM, Ralf Wildenhues
ralf.wildenh...@gmx.de wrote:
Do you
intend to write a patch for Automake, or is this something purely
external for one specific project, or to be more generally
Hi,
I've fiddled my playtime tool autogen to emit dependency info:
AUTOGEN_opts_TList := \
opts.h \
opts.c
AUTOGEN_opts_SList := \
opts.def \
/old-home/bkorb/ag/ag/autoopts/options.tpl \
/old-home/bkorb/ag/ag/autoopts/optlib.tpl \
Hi Ralf,
On Sat, Jun 26, 2010 at 12:19 PM, Ralf Wildenhues
ralf.wildenh...@gmx.de wrote:
Hi Bruce,
* Bruce Korb wrote on Sat, Jun 26, 2010 at 06:30:29PM CEST:
I've fiddled my playtime tool autogen to emit dependency info:
stamp-opts : $(AUTOGEN_opts_SList)
$(AUTOGEN_opts_TList) : stamp
On 04/27/2010 03:49 PM, NightStrike wrote:
On Tue, Apr 27, 2010 at 4:20 PM, Matěj Týč matej@gmail.com wrote:
Hello,
I use GNU Autogen to generate files to my project.
What I would like to have is some integration of autogen with autoconf
like YACC and LEX have.
Fundamentally, you want
Hi,
Looking through my own thread from 5 years ago doesn't lead
anywhere: http://www.mail-archive.com/automake@gnu.org/msg10373.html
There are other bug reports:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456632
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view
Ralf Wildenhues wrote:
Please just post all of the output, it is often much easier for me to
see then what went wrong.
Hi Ralf,
Okay, here's my (I'd guess different) problem. Beats me. :(
Thanks for any hints! :) Cheers - Bruce
Making dvi in doc
make[2]: Entering directory
On Nov 27, 2007 9:54 AM, Olly Betts [EMAIL PROTECTED] wrote:
In fact, none of the real examples I have to hand fit into the mould of
a collection of implicit rules with a common basename.
Cheers,
Olly
Just to toss a couple more pennies into the pot, I am currently working
on a poject
Not knowing the guts of this, my only complaint has to do
with the help text for ``--clean'' and the lack of consistency
WRT ``-c'' being an acceptable alias for it.
Benoit Sigoure wrote:
Index: autoconf/bin/autoconf.as
===
RCS
Benoit Sigoure wrote:
Quoting Bruce Korb [EMAIL PROTECTED]:
Not knowing the guts of this, my only complaint has to do
with the help text for ``--clean'' and the lack of consistency
WRT ``-c'' being an acceptable alias for it.
Yeah you're right, the message should be consistent
Hi Ralf,
I've followed some of this thread. From my perspective:
* I'm okay what whatever is decided, as long as maintainer-clean
semantics do not change. New semantics - new name, just like
the way any other interface change should work
* I don't particularly care for the autogen.sh
Once upon a time, I had a working web page:
http://autogen.sourceforge.net/conftest.html
(It is down because the underlying OS was upgraded and it
was a nuisance to find a build platform that produced binaries
that worked correctly on the current platform. I've since learned
how to do it, but
Brendon Costa wrote:
Seems pretty reasonable to me, but I'd suggest a little tweak:
#! /bin/sh
#
DESCRIPTION=$1
COMMAND=$2
shift
shift
echo $DESCRIPTION
$COMMAND $* /dev/null
---
output=`$COMMAND ${1+$@}`
RESULT=$?
if test $RESULT -ne 0; then
exec 12
echo Command failure:
Hi Brian/Ralf,
Ralf Wildenhues wrote:
If you're ultimately out to set the AC_INIT version argument, you may
want to read this thread (completely!)
http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/6129 esp.
http://article.gmane.org/gmane.comp.sysutils.autoconf.general/6169
and then
Brian Dessent wrote:
We have an application where the version number (for the purposes of
creating a dist tarball) is determined by grepping for $Revision $ in
the toplevel ChangeLog. Because this is not a static value, it means we
can't just set VERSION when running automake, since a commit
Peter Ekberg wrote:
Hello!
I have the following needs:
1. Extract some data from a list of files using script foo.
2. Process the data further using a second script bar.
3. Concatenate the processed data.
4. Run a third script foobar on the concatenation to
produce a .c file.
5. Distribute
Stepan Kasal wrote:
That principle could rather be achieved by omitting the *.c file
from the distribution, supposing that every customer can install
the tools which are required to generate it.
Not every customer wants to install developer tools. In general,
people who install a project
Adnan Shaheen wrote:
Hi there,
I want to know how can i define macros in my configure.ac file.
If i can do it how i will define a macro TESTING in the configure.ac
For my code as
#ifdef TESTING
do this
#else // if not defined TESTING
do that
#endif // TESTING
Hi Adnan,
You're speaking the
Hi,
I need to be able to create a source file and compile the thing
in my make check testing. Unfortunately, I have no need for
compiling anything in the test directory via make, so the
Makefile.am has no: mumble_PROGRAMS stuff in it. Consequently,
there are no compile rules in the Makefile,
) test/cc.defs
and then use ${COMPILE} and ${LINK} in my test scripts? :)
I don't like it, but I think it ought to work
How reasonable is that? Thanks - Bruce
Bruce Korb wrote:
Hi,
I need to be able to create a source file and compile the thing
in my make check testing. Unfortunately, I
Ed Hartnett wrote:
Howdy all!
I am using automake to build my library, and I have a slew of test
programs:
# These programs are all built for make check in this directory.
check_PROGRAMS = tst_h_files tst_h_atts tst_h_vars tst_h_grps \
tst_h_compounds tst_h_wrt_cmp tst_h_rd_cmp
Antonio Coralles wrote:
I'm currently working on a small library. I only want the contents of
the 'examples' directory to be built if configure .
My toplevel Makefile.am contains:
if EXAMPLES
MAYBE_EXAMPLES = examples
endif
SUBDIRS = $(GENERIC_LIBRARY_NAME) $(MAYBE_EXAMPLES)
SUBDIRS =
On Sunday 10 July 2005 12:40 pm, Bruce Korb wrote:
I'm not sure I understand. The file doesn't have to exist, it only has
to be listed as a distributed file in Makefile.am.
It should be enough to get the rule in Makefile.in.
Wrong. Sorry :-(
P.S. don't sweat it. It was a good guess
On Sunday 10 July 2005 10:32 am, you wrote:
Hello,
Hi again :)
I'm not sure I understand. The file doesn't have to exist, it only has
to be listed as a distributed file in Makefile.am.
It should be enough to get the rule in Makefile.in.
Wrong. Sorry :-(
+ automake --gnu --add-missing
Hi,
I am sure that this is some config issue, but Google gives no help
on this one. make and make check are all happy, but when I
get to make distcheck it dies in the doc directory doing strange
things that I cannot even speculate about.
make[2]: Entering directory
It was the macros going into the *source* directory in order to
build its products. Bad. But anyway, the cause was a minor
misordering of build functions. Thank you. :)
On Saturday 09 July 2005 02:26 pm, Bruce Korb wrote:
Hi,
I am sure that this is some config issue, but Google gives
July 2005 02:44 pm, Bruce Korb wrote:
It was the macros going into the *source* directory in order to
build its products. Bad. But anyway, the cause was a minor
misordering of build functions. Thank you. :)
On Saturday 09 July 2005 02:26 pm, Bruce Korb wrote:
Hi,
I am sure
Alexandre Duret-Lutz wrote:
Bruce == Bruce Korb [EMAIL PROTECTED] writes:
libopts tear off. The problem is that EXTRA_DIST in the Makefile.am
includes the directory 'autoopts' which I think it confuses into
beliving it should build a binary of the same name using autoopts.c
Bruce
Hi Gary!
The solution is at the bottom. I stumbled onto it by playing
around with env - prefixes on various commands.
On Wednesday 23 February 2005 04:15 am, Gary V. Vaughan wrote:
Hallo Bruce!
You only need -export-dynamic if you are going to use lt_dlopen (NULL)
to get a reflective
I have now changed the Makefile.am thus:
autogen_LDADD = $(top_builddir)/autoopts/libopts.la $(LIBGUILE_LIBS)
and autogen_LDFLAGS = -export-dynamic. The net result:
+ /home/bkorb/ag/ag/agen5/autogen \
-L/home/bkorb/ag/ag/autoopts argument.def
/home/bkorb/ag/ag/agen5/.libs/lt-autogen:
On Tuesday 25 January 2005 01:47 pm, Alexandre Duret-Lutz wrote:
$ autoreconf
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not
AM_GNU_GETTEXT_VERSION
1. The automake example of AM_GNU_GETTEXT does not show
AM_GNU_GETTEXT_VERSION being used in conjunction with
That section says:
Many packages come with a script called `bootstrap.sh' or
`autogen.sh', that will just call `aclocal', `libtoolize', `gettextize'
or `autopoint', `autoconf', `autoheader', and `automake' in the right
order. Actually this is precisely what `autoreconf' can do for you.
On Sunday 30 January 2005 03:53 pm, Andreas Schwab wrote:
Bruce Korb [EMAIL PROTECTED] writes:
In fiddling with sharutils, I discovered that it is too early to encourage
the dropping of bootstrap scripts just yet. autoreconf does not provide
a way of convincing automake to run
What does this mean? I went and updated to a full SuSE 9.2 distribution.
Thanks! - Bruce
+ aclocal -I config
NONE:0: /usr/bin/m4: `m4_symbols' from frozen file not found in builtin table!
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: autom4te failed with exit status: 1
+ exit 1
On Tuesday 25 January 2005 01:37 am, Noah Misch wrote:
On Sun, Jan 23, 2005 at 09:28:36AM -0800, Bruce Korb wrote:
$ autoreconf
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not
AM_GNU_GETTEXT_VERSION
1. The automake example of AM_GNU_GETTEXT does not show
$ autoreconf
autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not
AM_GNU_GETTEXT_VERSION
autoreconf: cannot empty /tmp/ar0.4849: Is a directory
$ find /tmp/ar0.4849
/tmp/ar0.4849
/tmp/ar0.4849/am4tu48Whq
/tmp/ar0.4849/am4tCpTneD
/tmp/ar0.4849/am4tiZINdq
/tmp/ar0.4849/ahAqZXRx
Hi Stepan,
On Monday 10 January 2005 06:00 am, Stepan Kasal wrote:
So it's usually enough to write
Well, I'd use
if [some-shell-script-test]
then
...
AM_CONDITIONAL([XXX], [true])
else
...
AM_CONDITIONAL([XXX], [false])
fi
This is more-or-less exactly what is going on,
RTFM:
The shell CONDITION (suitable for use in a shell `if' statement)
is evaluated when `configure' is run. Note that you must arrange
for _every_ `AM_CONDITIONAL' to be invoked every time `configure'
is run - if `AM_CONDITIONAL' is run conditionally (e.g., in a
shell
On Saturday 08 January 2005 01:53 pm, Alexandre Duret-Lutz wrote:
Bruce == Bruce Korb [EMAIL PROTECTED] writes:
Bruce The problem is is that XXX *DOES* actually appear in an
AM_CONDITIONAL.
But these macros are not evaluated because of your quoting, so
effectively XXX is not defined
Hi Stepan,
The solution is to not list the file in the list of files to be configured.
Instead, in your Makefile.am:
mumble-sh.in : $(mumble_PREDECESSORS)
create-mumble-sh-in
mumble.sh : mumble-sh.in
$(SHELL) $(top_builddir)/config.status --file mumble.sh:mumble-sh.in
Maybe someone can figure out a better error message, please?
For those that found *this* message because of the subject line:
http://lists.gnu.org/archive/html/bug-automake/2004-07/msg00083.html
Stephan although AC_PROG_LIBTOOL _is_ present in configure.ac.
Therefore it means
On Monday 06 December 2004 01:18 pm, Stepan Kasal wrote:
Hi,
On Mon, Dec 06, 2004 at 12:57:50PM -0800, Bruce Korb wrote:
Subject: 29,
900 English pages for Libtool library used but LIBTOOL is undefined
google is exaggerating, of course.
Of course it is. That doesn't mean
Leonardo Boiko wrote:
Maybe you could add a small clarification: that LDADD and LIBADD are
automake-specific variables. As far as I understand, there is a
mumble_LDADD and a LDADD, but not an AM_LDADD, and plain LDADD is not
from the user. Thus LDADD and LIBADD are entirely different from
Hi Alexandre!
Alexandre Duret-Lutz wrote:
gmake[5]: Warning: File `autogen' has modification time 1.8 s in the
future
[...]
I suggest you complain to your system administrator.
I have. They don't want to set up the ntpd. In any event, even
when I build on the NFS server, I get the
I decided to see what would happen when I changed:
man_MANS = autogen.1
into:
nodit_man_MANS = autogen.1
I got some curious stuff:
install-man1: $(man1_MANS) $(man_MANS)
@$(NORMAL_INSTALL)
test -z $(man1dir) || $(mkdir_p) $(DESTDIR)$(man1dir)
@list='$(man1_MANS)
Hi all,
This is new behavior with the latest released automake, and it happens
on Solaris but not Linux. The Makefile.in produced causes Solaris
make to choke and GNU make to think it is happy but do the following:
/bin/ksh ../libtool --mode=link /net/megami/opt/apps/forte62/SUNWspro/bin/cc
Scott James Remnant wrote:
On Wed, 2004-11-10 at 14:57 -0800, Paul Eggert wrote:
As a special exception to the GNU General Public License, if you
distribute this file as part of a package that automatically derives
from this file a configuration script (and perhaps some associated
Gary V. Vaughan wrote:
Here's another:
And another:
``The following specific files are hereby deemed public domain and
you may use them any way you see fit.''
After all, these things are only useful with the Auto* tools and
I do not believe that any of them are state secrets, so why spend
a
Bob Friesenhahn wrote:
Any recipient of the package should have the ability to become a
package maintainer without removing site/developer specific hacks.
I hadn't considered a make dist for copying around a locally fixed
version. Certainly, one cannot really maintain a package for which
they
Deneys S. Maartens wrote:
Hi Bruce
When compiling the autogen source without having libxml2 available, and
then doing a `make dist' creates a broken distribution package which
does not include the xml2ag/ subdirectory.
A configure of the broken dist package fails with the following error
John Ling wrote:
Hello, I want to be able to read/check the value of an environment
variable in my Makefile.am. This would be a variable that I set as part
of the an [action-if-found] in the AC_SEARCH_LIBS method, that I set in
configure.ac.
How do I reference such a variable?
In
John Ling wrote:
I think I've figured out the way to do it:
In my Makefile.am I put in a line like 'export CONFIGURE-TIME_LIBS=$(LIBS)'
Then in my Makefile.loader I put in my LIBS definition:
LIBS = $(CONFIGURE-TIME_LIBS) ...
You might have better luck with CONFIGURE_TIME_LIBS ;-)
Karl Berry wrote:
Hi folks,
The obvious directory would be $(datadir)/html by analogy with
$(datadir)/info, but it seems a bit arrogant to use such a generic name
Not arrogant so much as conflicting with where folks might want to
stash their own stuff.
for something which only relates to
Karl Berry wrote:
1. Please shorten to html (as is done for ps)
I'm not sure. By Bob's argument, `html' could be useful to stand for
any sort of HTML generation, if there is non-Texinfo documentation involved.
Yeah! That's the idea! Type in, ``make html'' and any html-making
gets
Laurence Finston wrote:
The problem is that make makes certain assumptions that don't apply when CWEB
is used. `ctangle filename.web' creates filename.c. Additional files can
also be written. In 3DLDF, each filename.web also writes filename.h.
[...] However, not all changes
to a .web file
Paolo Bonzini wrote:
I understood the problem was with snprintfv, not with autogen. What are you using
INFO_DEPS for? I think it is undocumented and internal to automake, maybe
autogen_texi_DEPENDENCIES or something like that works (but I do not know if it
actually exists...).
My guess is
Gary V. Vaughan wrote:
Hi Paolo,
(Hi Bruce, how's it going?)
Hi, again, Gary - another autogen is pending -- i18n getopt_long stuff
Paolo Bonzini wrote:
| I've finally managed to put on CVS the last 1.1 prerelease,
Hi Paolo,
I can't get it. I keep getting invalid data from server tho
Bob Friesenhahn wrote:
On Thu, 4 Dec 2003, Gary V. Vaughan wrote:
I would be happy if I could do this:
I tend to disagree with you on this point. I will agree if the system
has three levels plus a way to provide overrides..
Automake should support
o inheritance of standard
Mohan Embar wrote:
Hi Alexandre,
I'm not all that surprised your C program is much faster that the
shell script. For starters, it fails to support all of libtool's
configure-time options, such as --disable-static, --disable-shared,
--with-pic, as well as their per-compilation equivalent
Richard Dawe wrote:
The problem, with html, is that nobody agree about what the
ouput should be. I'd say that if we support html, we should
use the default makeinfo output (which is to split on nodes),
and let the user say `AM_MAKEINFOFLAGS = --no-split' when wanted.
This is what we do
Paul Eggert wrote:
Alex Hornby [EMAIL PROTECTED] writes:
On a related note, does the restriction of not using shell functions in
autoconf macros still remain,
For Autoconf itself, we still avoid shell functions. But of course
you can use shell functions in your own macros, if you
Charles Wilson wrote:
I think the winning argument was as follows:
for archaic systems whose shell does not support shfuncs, 'somebody'
should create a snapshot of bash with a frozen autotool version
That's the argument that has been put forth over and over for years.
I couldn't
1 - 100 of 174 matches
Mail list logo
