Harlan Stenn wrote:
I guess it's time for me to chime in.
Dave Mills expect NTP to compile on anything he can get his hands on.
That's very nice. Why does he need to do this? I mean, the
compelling reason?
I've been lucky so far in that some of the older gear he has is breaking. I
do,
Dr. David Kirkby wrote:
Hi,
I've found in the past bugs in software are often found on one
platform that don't seem to get noticed on another. For this reason I
just tried to build gcc-2.0 on an old Sun SPARCstation 20 running
SunOs 4.1.4 (ie hardware/software about 10 years old) to
At the end of this log, you'll see lines like this:
cp: cannot create regular file \
`blocksort-1.4.2/libopts/.deps/save.Plo': Permission denied
It used to work, of course, but I was persuaded to upgrade
automake/autoconf/libtool again. Silly me. I should learn.
It's as aggravating as heck.
Alexandre Duret-Lutz wrote:
Bruce cp: cannot create regular file \
Bruce `blocksort-1.4.2/libopts/.deps/save.Plo': Permission denied
Simply don't distribute these files.
Distributing files marked read-only or in read-only directories
really ought not cause a distribution failure. It is
Why doesn't Automake support wildcards?
===
Developers are lazy. People often they would like to use wildcards
in `Makefile.am's so they don't need to remember they have to update
`Makefile.am's every time they add, delete, or rename a file.
Alexandre Duret-Lutz wrote:
Hi Bruce!
Hi, ALexandre! :-)
I think we agree. The last sentence in this section was meant
to imply such a patch would be considered, would someone mind
enough to work it out.
I missed that nuance. :)
Bruce We have philosophical differences.
Alexandre Duret-Lutz wrote:
What do people thinks about Automake's removal of core dumps?
I tend to think it's a misfeature.
Only 'cuz it's implemented for the wrong target.
For one thing, this doesn't match the documentation.
Quizz: which of the following targets do you think
Automake
Earnie Boyd wrote:
Thanks Bruce,
I used a modification of your suggestion:
configure.ac
if test x$target_os == xmingw32; then
WINSOCK=-lws2_32
fi
AC_SUBST(WINSOCK)
/configure.ac
Makefile.am
LDADD := @LTLIBINTL@ @WINSOCK@
/Makefile.am
Actually, your Makefile.in will contain
Ralf Corsepius wrote:
Am Mit, 2002-11-13 um 19.08 schrieb Earnie Boyd:
I need to add a library specific to a target_os. I've tried several
possible techniques and can't get cooperation from the tools.
What I want is something similar to:
target_os := target_os
ifeq
Alexandre Duret-Lutz wrote:
/bin/sh ../libtool --mode=link gcc -g -O2 -L/sw/lib -o autogen \
-export-dynamic -lguile *.o -L/sw/lib -lguile -lm \
-L../autoopts/.libs -lopts -ldl
ld: Undefined symbols:
_aopts_alloc
_aopts_realloc
_aopts_strdup
make[1]: *** [autogen] Error
David Bacher wrote:
Hi Bruce,
I'm having a problem building the latest autogen 5.4.6 on Mac OS X,
while the old autogen is installed.
When linking the new autogen executable, it finds the old (installed)
verison of libopts instead of the new (local) libopts library. This
causes
Paul J wrote:
I wish to produce a library from two xdr files, datarpc.x and
visualrpc.x. Originally, the following GNU make commands produced the
correct output files which, by means of a hand crafted makefile (using
g++ as the compiler), compiled the rpcgen produced files into .o's:
Matthias Dietrich wrote:
Unfortunately we run into a big problem. Automake assumes
that a library is built by calling ar cru and at least
one of our machine has a toolset where ar is not
available. We have another tool to build a library, it's not
called ar and it doesn't take cru as
So you are proposing to trade in end user convenience (package builds on
any system out of the box) for autotools maintainer convenience
(maintainers can assume a fixed environment). I don't think that's a good
idea. It goes completely contrary to the goals of the autotools.
In fact, I
Dean Povey wrote:
The easiest way would be for ./configure to find the C compiler and build
a simple utility binary from source, then use that for the rest of the
configuration.
Problem is that by the time you've figured out how to do that,
you're most the way done. Now, if you depended
Treeve Jelbert wrote:
stray 'no' in link spec
---
Hi Libtool ( automake?),
Here's the Configuration:
Source code location: .
Compiler: gcc
Compiler flags: -march=athlon -mmmx -m3dnow -O3
Host System Type: i686-pc-linux-gnu
Install path:
Tom Lord wrote:
* Maintaining the build tools (autoconf etc) is currently too hard.
The maintainers have to struggle to write portable shell code;
Those constraints really matter to a small number of packages (the
bootstrap packages) but could be reasonably relaxed for other
Pavel Roskin wrote:
For example, there are two libraries, A and B, and only one can be used.
There are at least (not counting --with-A=/path/to/A) 2 possibilities for
each library (present and absent) and 3 possibilities for each option,
(--with-A, -without-A, no option), which makes 36
This is great! All warnings/errors should be like this:-)
[[ I just loaded AM 1.7 ]]
agen5/Makefile.am:59: `YFLAGS' is a user variable, you should not override it;
agen5/Makefile.am:59: use `AM_YFLAGS' instead.
make[5]: Leaving directory `/home/bkorb/ag/ag/snprintfv/doc'
make[4]: Leaving directory `/home/bkorb/ag/ag/snprintfv/doc'
Oops :-(
I'm sure it's my fault for misusing something or other.
God only knows what it may be, though. It's not my code.
Bruce Korb first initial
As best as I can determine, there is no easy way to say, do
not optimize this particular module. The best way would be
with a #pragma around the problematical function, but I'll
be happy with anything that does not disable optimization for
the entire program and does not prevent someone from
Tim Prince wrote:
On Saturday 28 September 2002 16:05, Bruce Korb wrote:
As best as I can determine, there is no easy way to say, do
not optimize this particular module. The best way would be
with a #pragma around the problematical function, but I'll
be happy with anything that does
Thomas Dickey wrote:
In my opinion it is prohibitive and stupid
It's equally stupid to .
I think everyone knows that autoreconf is not ready for prime time.
From someone who gets cranky when working code breaks because
someone thought I shouldn't do things that way, let me say
Alexandre Duret-Lutz wrote:
Bruce My preference would be this:
Could you send this to the list?
Alright:
I would really like to see the auto* tools packages (autoconf,
automake and libtool) each adopt several of their worst
clients' packages for regression testing. As each release
is
Pavel Roskin wrote:
I won't object if this script is renamed to autogen.sh
I will, tho. :-)
Pavel Roskin wrote:
Hello!
At some point, make distcheck would simply call make dist and run the
standalone distcheck script with predefined DISTCHECK_FLAGS.
YES!
Tom Tromey wrote:
Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl but you can't do
adl if INSTALL_SNPRINTFV
adl pkgincludedir = something
adl endif
I've long thought that we should, eventually, support the latter use.
It seems to have a clearly defined meaning. And it is even
Akim Demaille wrote:
| Cool. Since we do not need amk 1.6.3 for our build,
| I will change the configure.ac requirement to 1.6.2,
| which does work.
What ... ??? The bug I'm referring to is only the
fact that the error message did not say `1.6.3 is a version of
Automake'. There is no
Alexandre wrote:
/usr/local/share/automake-1.6/am/header-vars.am: \
pkgincludedir was already defined in condition TRUE, \
which implies condition INSTALL_SNPRINTFV_TRUE
You are alowed to overwrite the variable if you want, but only
in the condition where it was initially defined.
Thien-Thi Nguyen wrote:
Thien-Thi Nguyen [EMAIL PROTECTED] writes (imprecisely):
you can process the headers on install.
sorry, i forgot to emphasize: the headers processed are those other than
config.h -- the horrible approach described does not require you to install
config.h.
Alexandre Duret-Lutz wrote:
Bruce Oh, PacBell seems to be eating my emails
This is over now, but I'll need to resubscribe to automake
Bruce So, here it [the patch] is:
Where?
:-) I got to writing and left off the patch.
Actually, even more absent minded, I was looking
at the
Why don't you simply use DIST_SUBDIRS?
Bruce 2. Even now that I've read it, using it would mean taking over
Bruce an automatable chore from automake.
I don't get this. Which chore should be automated?
Maintaining the contents of DIST_SUBDIRS. If I make an assignment
to it, then I am
Alexandre Duret-Lutz wrote:
Bruce SUBDIRS = MAYBE_BAR
Bruce EXTRA_DIST = NOT_MAYBE_BAR
Odd. I don't understand how you get duplicates this way.
It all has to do with configuring the Makefile incorporated
in the distributed subdirectory. There is no way to do it
conditionally.
Richard Boulton wrote:
automake will be able to calculate the correct value for DIST_SUBDIRS by
taking all possible values for SUBDIRS.
So:
if BAR
MAYBE_BAR = bar
fi
SUBDIRS = foo $(MAYBE_BAR)
DIST_SUBDIRS is automatically calculated as foo bar
Now it is clear to me. I did not
Richard Boulton wrote:
:-( Read the source, Luke
Hmm: that documentation is fairly unhelpful. It was last updated
13-Feb-98: I'm guessing that was before DIST_SUBDIRS was invented.
misleading is more than just unhelpful, though I do understand
that this is an unfunded project. Thanks
The log:
bootstrapping in /home/bkorb/ag/bs
RUN: rm -f config.cache
RUN: libtoolize --force
You should add the contents of `/usr/local/share/aclocal/libtool.m4' to `aclocal.m4'.
RUN: mv -f config.guess config.sub ltmain.sh cfg/.
RUN: aclocal -I cfg
RUN: autoheader
autoheader: `config-h.in'
Eric wrote:
Not sure whether this is relevent or not,
but it might offer a clue.
[[...]]
- automake --add-missing didn't think install-sh was in fact
missing, because it could find the copy in pkg-root, because:
[[...]]
Workaround: add this to pkg-root/distrib/configure.ac:
Sorry. Here is a possible answer about *how*.
build distdir
for f in $DIST_FORMATS; do
case $f in
gz)...
bzip2) ...
zip) ...
...
esac
done
erase distdir
gz is a suffix, bzip2 is the name of the program that
does the compression and zip
Eric Siegerman wrote:
On Tue, Jul 30, 2002 at 07:46:18AM -0700, Bruce Korb wrote:
[...] you still
need to have both [suffix and compressor-program name] be
specifiable so you are not boxed into
cutting a new release in order to support a combination
you didn't plan for.
for f
Robert Collins wrote:
On Sat, 2002-07-27 at 02:25, Bruce Korb wrote:
Akim Demaille wrote:
Would that be accepted? For some of my projects, I don't need nor
want the .gz, I just want the .bz2.
If you are going to parameterize it at all, then parameterize it
completely. e.g
Hi,
I *believe* I followed the documented procedures for permitting
the existence of regenerated distributed files. The result is this
warning message from find:
Makefile.am:
distcleancheck_listfiles = \
find -type f -exec sh -c 'test -f $(scrdir)/{} || echo {}'
Shell output from make
William Robertson wrote:
On 23 July 2002, Tom Tromey [[EMAIL PROTECTED]] wrote:
| William Good, except that configuration runs are abysmally slow.
|
| Have you enabled caching? That is the first thing I'd try. It will
| help but won't solve the problem; each configure script has a
Attached are three files:
1. automakefaq.def is a list of questions and answers. The list is
one question long. :-) It points into the automake documentation.
2. automakefaq.tpl facilitates pointing into the documentation by
adjusting symbolic names (e.g. Program and Library
' ) $
crude but effective.
Say, Tom, is there a FAQ for this? I don't see a faq
reference in http://www.gnu.org/software/automake/
Bruce Korb first initial + last name at gnu dot org
AG URL: http://autogen.sourceforge.net
Harlan Stenn wrote:
What about the ctags/etags example in the automake info pages?
What about putting a FAQ pointer on the software/automake
page that points to this kind of info? :-)
I just don't know how to use faq-o-matic stuff, or I'd
whip something up.
==
Bruce Korb first initial
Tom Tromey wrote:
Bruce == Bruce Korb [EMAIL PROTECTED] writes:
Bruce I would like to add this so I don't get in trouble for having
Bruce my own missing script:-)
Could you post some rationale explaining what you use this patch for
and why?
I want to use missing for programs
: *, ,'
+ done
+fi
;;
-v|--v|--ve|--ver|--vers|--versi|--versio|--version)
= =
Bruce Korb first initial + last name at gnu dot org
AG URL: http://autogen.sourceforge.net
Enrico Ng wrote:
I am trying to make an automake file to create libtool libraries.
The problem is that the libraries I would like to create depend on
header files that have to generated.
How do I do this in automake?
With normal make dependency rules. Below is my Makefile.am for
xml2ag.
Tom Tromey wrote:
The easiest way is to list your headers in BUILT_SOURCES.
Then write the rules to build the headers.
I've found that more problematic. I wind up with make files
that always rebuild certain targets.
Allan Clark wrote:
This is really not an issue;
There are a lot of sloppy people around.
I had a make check test divert its output to /dev/null,
only the test also changed the permissions of the output
file, too. Someone complained that /dev/null became r--r--r--.
It might be useful to choke
Tom Tromey wrote:
Alex == Alex Hornby [EMAIL PROTECTED] writes:
Alex I suppose automake could be enhanced so that it automatically
Alex knew which files are BUILT_SOURCES by looking back through the
Alex suffix rules. Then the small overhead of listing them twice
Alex would be removed.
-0400
Sender: [EMAIL PROTECTED]
Date: Sat, 04 May 2002 09:41:57 -0400
Sender: [EMAIL PROTECTED]
Date: Sat, 04 May 2002 09:47:26 -0400
Sender: [EMAIL PROTECTED]
Date: Wed, 27 Mar 2002 11:30:46 +
Date: Sat, 04 May 2002 10:32:08 -0400
Sender: [EMAIL PROTECTED]
==
Bruce Korb first initial + last
) -DSIM -c -o barsim.lo \
`test -f 'bar.c' || echo '$(srcdir)/'`bar.c
--
Bruce Korb first initial + last name at gnu dot org
AG URL: http://autogen.sourceforge.net
reliability
3. the versions we think are stable, but may yet bite.
Thanks, Alexandre...
- Bruce
--
Bruce Korb first initial + last name at gnu dot org
AG URL: http://autogen.sourceforge.net
!
You're ported to a new engine.
--
Bruce Korb first initial + last name at gnu dot org
AG URL: http://autogen.sourceforge.net
of approaches:
1. Use an IDE (like KDevelop) that builds skeletal infrastructure
for you automatically
2. Use a prototype project generator (like autoproj).
--
Bruce Korb first initial + last name at gnu dot org
AG URL: http://autogen.sourceforge.net
options. :-)
--
Bruce Korb first initial + last name at gnu dot org
AG URL: http://autogen.sourceforge.net
Akim Demaille wrote:
The Autoconf team is extremely pleased to announce Autoconf 2.53. We
hope it will address your problems, and make your life easier.
- Double quoting macros
AC_TRY_CPP, AC_TRY_COMPILE, AC_TRY_LINK and AC_TRY_RUN.
FYI: this will teach me for upgrading without
but
surprises, please.
... Conclusion, Akim is very patronizing
accommodating ?
in offering the fourth optional parameter in AC_INIT.
--
Bruce Korb first initial + last name at gnu dot org
AG URL: http://autogen.sourceforge.net
Thien-Thi Nguyen wrote:
i've added doc/ref/autoconf.texi, and @included it in Part II (both
stable and unstable). seems to be ok...
one weirdness, however: in doc/ref/Makefile.am, i tried adding only
autoconf.texi to guile_TEXINFOS (and omitting generated file
autoconf-macros.texi), but
Eli Zaretskii wrote:
Is it out of the question to discuss possible alternatives to your
current setup, so that the sources will be maintained in Texinfo?
That is what I was trying to do. :-)
BTW, Doxygen does not (yet) have a way to emit texinfo docs.
I am trying to fix that by making it
Bruce Korb wrote:
What do you think about this unanswered bug report:
http://sources.redhat.com/ml/bug-automake/2001/msg00423.html
(personally I'd vote for solution 5)
Personally, I think it came two or three years after I initially
raised the issue, but now I'll go have a look
Hi,
For years I have been maintaining this tool that extracts its own
documentation. Projects that use Doxygen and Java doc tools have
basically the same issue. The problem is that the makeinfo stuff
makes the erroneous assumption that mumble.texi is a source document.
From that bad
Eli Zaretskii wrote:
Can't you simply write a Make rule that will produce .info file
[...]
Am I missing something?
Yes. :-( Without endlessly convoluted change (dependency) checks,
the docs get rebuilt causing the .info to be rebuilt causing distcheck
to choke. So, without distcheck
Alexandre Duret-Lutz wrote:
Bruce What is the brokenness you are talking about? It is
Bruce simply that you have failed to add to
Bruce MAINTAINERCLEANFILES the name of a derived file.
It's not MAINTAINERCLEANFILES at all! It's CONFIG_CLEAN_FILES.
I found most of the non-removed files
Tom Tromey wrote:
Bruce == Bruce Korb [EMAIL PROTECTED] writes:
Bruce Why is this now necessary? It did not used to be. Is this
Bruce intended? Is there an upgrading README file kicking around?
It is probably a newly introduced bug.
You don't mention what version you are using
Tom Tromey wrote:
This bug report doesn't really have enough information in it for me to
respond to it. Nevertheless I will try.
Are you angry because automake tries to make sure that YACC is defined
as a configure variable?
I am not angry. I was. It was the end of a long session.
What is this? Maybe not everyone wants to use your
version of AC_PROG_YACC. I use my own: AG_PROG_BYACC
because I have a strong preference for BYACC. But,
your latest automake is making some sort of attempt
to be really rigorous and is sticking its nose into
my business. This is wrong. You
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Why is this now necessary? It did not used to be.
Is this intended? Is there an upgrading README
file kicking around?
Gary V. Vaughan wrote:
Any argument why that is how it is?
See my last mail.
I can think of two ways around this. Either
[[...]] or libtool would need to build a wrapper program on Windows
which would call the wrapper script to set the environment up to load the
correct DLLs and
Paul Martinolich wrote:
I am using automake/autoconf and am in a situation in which I need
to use a program to generate a header file using a template file
before I can compile the program. Has anyone encountered a similiar
situation? What is the best way to accomplish this? Suggestions.
"John W. Eaton" wrote:
On 31-Oct-2000, Bruce Korb [EMAIL PROTECTED] wrote:
| It is ugly. Especially...
Isn't that what the move-if-change script is for?
Its a nice try at the problem, but it doesn't work, for
the reason you noted.
The move-if-change saves the timestamp
Earnie Boyd wrote:
--- Bruce Korb [EMAIL PROTECTED] wrote:
I made an archive file named "configure" that contains
a shar archive of the generated files. It runs, recreating
the generated files, deletes itself and then runs autoconf.
^^ NO
Allan Clark wrote:
Perhaps the tack to sail on this component is not "make rpm" but "make
package", where a number of files is converted to a ~.spec,
prototype/pkginfo, ~.cmpnt/~.pkg/~.prod, or whatever:
1) list of files (source - target)
2) inittab mods
3) rc.d mods
4) copywrite (with
101 - 174 of 174 matches
Mail list logo
