> Why not provide both mechanisms, and let people use what they
> want?
`package-framework' (ftp.regexps.com) actually does this, by the way.
I emphasize the globbing option because it's what I use most often,
and what I think is usually best.
-t
Re: glob v. list
Why not provide both mechanisms, and let people use what they want?
Personally, I've been bitten far more often with globs and would tend to
explicitly list files. But that's my "policy" decision and this is really a
"mechanism" question.
H
From: IETF Mail Server <>
Subject: Your request
IETF Directory and Database Mail Server 1.0 [optimus]
Request arrived - Thu Oct 24 23:34:14 EST
Request processed -
Processing mail headers ...
Processing message contents...
Command: --LMQ23Q57wb26T3s8s9Rpe460Xfu6f1pz
ERROR> Command --LMQ23Q57W
Long-time automake readers already know I'm strongly against
this sort of structuring. This yields Makefiles which are
fragile and undependable. For instance, if you create a
temporary file with a "source-like" name in the source tree,
then the build fails.
On Thu, 2002-10-24 at 18:02, Tom Tromey wrote:
> > "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:
>
> >> JAVAC = gcj -C
>
> Braden> I thought of that, but thought there might be something less
> Braden> subtle. Perhaps this should be done by the AM_PROG_GCJ macro?
>
> This is actua
Olaf Weber <[EMAIL PROTECTED]> writes:
>
> Shouldn't that be ARFLAGS, just as we have CFLAGS not C_FLAGS. That
> seems to be the "canonical" name.
Libtool uses AR_FLAGS currently. Whichever is adopted it'd be nice
for them to be the same.
%% Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> If you do things right, your Makefiles don't need to contain
Tom> specific filenames at all, and you don't need to edit any
Tom> Makefiles as you add, delete, or rename files
tom> Long-time automake readers already know I'm strongly against t
[ back to automake for this one ]
> "Tom" == Tom Lord <[EMAIL PROTECTED]> writes:
Tom> Also in defence of the `sh + make' approach:
Tom> GNU make can do lots of useful globbing and set manipulation of file
Tom> lists.
Tom> If you do things right, your Makefiles don't need to contain
Tom> sp
> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes:
>> JAVAC = gcj -C
Braden> I thought of that, but thought there might be something less
Braden> subtle. Perhaps this should be done by the AM_PROG_GCJ macro?
This is actually sort of a standard approach.
AC_PROG_CC looks at the CC env
> "Eric" == Eric Anderson <[EMAIL PROTECTED]> writes:
Eric> Makefile:225: *** missing separator. Stop.
Eric> and line 225 of the Makefile is:
Eric> @SET_MAKE@
This means that whatever configure is building this Makefile doesn't
invoke AC_PROG_MAKE_SET. AM_INIT_AUTOMAKE invokes this, so it
i
>> AC_CONFIG_SUBDIRS(libghttp-1.0.9-mod)
Eric> Where does this go in the configure.in file? Above the AC_OUTPUT
Eric> command? From what I have read there has to be an order to the script,
Eric> so I want to make sure I put it in the right place
Anyplace before AC_OUTPUT is fine.
>> SUBDIRS = l
A suggestion to conditionals in Makefiles. Conditionals inside Makefiles
could be changed to replace the not-included lines with empty lines
instead of commenting them with '#'. If it would just replace them with
empty lines it would allow configuration like this:
FILES = \
hi akim,
first, thank you for responding!
i finally did find out what was wrong: autoconf 2.5x and 2.13 debian
packages were both installed on my system. the *packages* don't
conflict but the programs do. inadvertantly, some of what i did used
the 2.5 tools and some used the 2.13 tools.
i made
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
Paul Thomas writes:
> source path: lib/am/libs.am
> installed path: share/automake-1.x/ams/libs.am
> 25c25,26
> < AR = ar
> ---
>> AR = @AR@
>> AR_FLAGS = @AR_FLAGS@
Shouldn't that be ARFLAGS, just as we have CFLAGS not C_FLAGS. That
seems to be the "canonical" name.
> I strongly recommend that
| hi all,
| i'm trying to learn autoconf by converting one of my programs to use
| autoconf. i'm having difficulty; here's what i tried:
|
|% cp Makefile Makefile.orig
|% mv Makefile Makefile.in
|% autoscan
|% mv configure.scan configure.in
|% autoheader
|% autoconf
|
[EMAIL PROTECTED] wrote:
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
17 matches
Mail list logo
