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 direc
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
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 t
2019 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"
', "$libdir/$file", $fullfile))
> {
> $suppress = 0;
> $trailer = "\nerror while copying";
> }
> - Dan
>
> On Sat, Aug 31, 2019 at 5:17 PM Bruce Korb wrote:
> >
> > Hi,
> >
>
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:
H
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
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:
>>
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 $LDFLA
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 binar
Hi Dave, Stefano,
On Thu, Nov 8, 2012 at 11:40 AM, Dave Goodell 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
>> issue
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 `.'
> autore
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-a
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-
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 `installc
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 a
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) \
&&
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 autog
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 thin
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,
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 satisfactory,
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 `.am2
On 02/03/11 11:46, Ralf Wildenhues wrote:
> Hello Vincent,
>
> * Vincent Torri wrote on Thu, Feb 03, 2011 at 04:32:36PM CET:
>> I'm trying to improve the autotools of he openjpeg project. The lead dev
>> wants me to display in the terminal what has been installed.
>> Is there a smarter way to do
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 w
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: h
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
>> ^^
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
>>
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; e
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
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 = -M
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
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 usable for
>> > al
Hi Ralf,
On Sat, Jun 26, 2010 at 12:19 PM, Ralf Wildenhues
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)
>&
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 \
> /old-home
On 04/27/2010 03:49 PM, NightStrike wrote:
> On Tue, Apr 27, 2010 at 4:20 PM, Matěj Týč 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 to add foo.d
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
audit-trail&datab
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 `/home/bkorb/ag/a
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 po
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
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
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
Hi,
The Fedora Core folks asked me to tweak my package so that "make install"
did not install any of the library stuff. To accommodate their needs,
I was putting installable object names into Makefile variables whose values
varied based on an AM_CONDITIONAL. viz.:
if INSTALL_AUTOOPTS
INST_MAN
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 1>&2
echo "Command fail
Thanks for the vote of confidence, Harlan. The question
unanswered, tho, is, "Why bother?"
Just so this can be documented, this did work for me.
dist_man_MANS = cgdb.1
# Autogenerate the man page using help2man. This happens whenever the
# user modifies either configure.in or usage.c, wh
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 d
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 cou
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 ju
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 t
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 wr
d in the test directory:
$(TESTS) : cc.defs
cd .. ; $(MAKE) 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
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 Makef
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 tst_h_
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
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-missin
; does its thing.
On Saturday 09 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:2
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 Goo
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 `/home/bkorb/ag/ag/auto
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 buil
Hi Aaron,
Aaron wrote:
Hey Bruce,
One more bug in pre12...
Running 'make dist-gzip' or any other 'dist-*' causes a blow up in the
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 o
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 m
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: s
On Monday 21 February 2005 04:08 am, Gary V. Vaughan wrote:
> Hallo Bruce!
>
> Cc:ing automake list incase I need to be corrected here...
> Automake generates the -rpath flags for libtool automagically, so you
> shouldn't try to add your own. The key is in how the libraries are linked,
> and whe
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
&
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 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 use
On Saturday 29 January 2005 11:31 am, Alexandre Duret-Lutz wrote:
> On Sat, Jan 29, 2005 at 11:12:49AM -0800, Bruce Korb wrote:
> > What does this mean?
>
> The same as the last time you asked, I guess.
> http://lists.gnu.org/archive/html/autoconf/2003-06/msg00085.html
You ar
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
er
On Tuesday 25 January 2005 01:47 pm, Alexandre Duret-Lutz wrote:
> Bruce> Um, okay, but if automake is going to emit the message, then it only
> Bruce> makes sense (to me) that automake include the documentation.
>
> That would make sense to me too. However automake is not
> emitting the mess
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
> $ 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/ahAqZ
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
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 be
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 `i
The problem is is that XXX *DOES* actually appear in an AM_CONDITIONAL.
Right in the "configure.ac" file, actually. So, obviously, it is having some
problem actually finding the AM_CONDITIONAL not not being clear enough
for me to fix the issue. Is it necessary to macroize the text and only use
th
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
Someon
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 co
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 AC_PROG_L
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 fro
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_MAN
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 t
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/
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 associat
"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
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 whi
"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 follow
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
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?
>
>
Simon Richter wrote:
> > I don't think this is true in general, a texinfo file could @include a
> > file that is built during the build phase.
>
> True, however that's a bad thing IMO, as it requires the user to have a
> working texinfo installation.
>
> > (For example, I generate Texinfo code do
e contrib/gcc_update script does: handles the shortcomings
of CVS. Package distributors cannot distribute a package with out of date
stamps and folks that draw generated sources from CVS have to understand
that CVS has some limitations. Nothing new.
Ralph wrote:
> Bruce Korb writes:
> >
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
Karl Berry wrote:
>
> We seem to be operating from different starting places.
Always true ;-), but I also understood your intent
> Having configure options such as --enable-doc-html is fine, if for some
> reason installers want to (re)generate the files.
Maybe I'm overloading the meaning of tha
Bob Friesenhahn wrote:
> I am against having separate install targets because GNU makefiles
> normally install everything by default and that is what users should
> expect. Installing everything is not a problem for distribution
> maintainers since they decide which files to package using their
>
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
Alexandre Duret-Lutz wrote:
> How many people would be annoyed by this?
Not me :-)
> Is there any reason why this would be a very bad idea?
It is inconsistent? The auto* tools (viz. autoconf) still
assumes a shell that has no functions. This makes the config
script incredibly larger and slow
1 - 100 of 197 matches
Mail list logo
