n rules are concerned).
For the worst cases (package building html documentation from
info files with random tools) your patch provides recursion over
the `html' targets, and user can override the `html-am' target
(or whatever they are called) with custom rules. That still
looks like a win over existing setups.
[...]
--
Alexandre Duret-Lutz
served this problem, too; and, yes, I'm configuring with CC set.
Braden> However, I'm using autoconf 2.53/automake 1.6.3.
I think this should work with Automake 1.7.3.
--
Alexandre Duret-Lutz
he rebuild rules in `Makefile'.
See also http://sources.redhat.com/ml/automake/2003-02/msg00112.html
[...]
--
Alexandre Duret-Lutz
lean does not remove the files listed in
Rafael> AC_CONFIG_FILES.
Thank you. The documentation is wrong.
--
Alexandre Duret-Lutz
-I option and dirlist),
so that needs to be documented too.
- aclocal is run throughout the test suite, so you should make
sure setting this envvar will never lead to spurious failures.
- All the above will be large enough to require you sign
a copyright disclaimer before it can be installed.
See http://sources.redhat.com/automake/contribute.html for other details.
--
Alexandre Duret-Lutz
x27;, or both.
David> However, how do I do this when the examples are possibly scattered
David> over two directories - $top_srcdir/examples and $top_builddir/examples
David> ???
Just like you did.
Did you tried this? If it didn't work, please send a bug report.
--
Alexandre Duret-Lutz
m to best effect?
in yourprog_LDADD or yourlib_LIBADD.
[...]
Simon> Alas "hello" always builds it's own getopt, which is looking
Simon> appeallingly simple at the moment.
Many "serious" packages do that to, so perhaps it's not worth the trouble.
--
Alexandre Duret-Lutz
Giuseppe> makefile, Automake doesn't set these variables...
Hi Giuseppe,
What do you mean by "doesn't set"? Could you explain what you got,
how you got it, and what you expected?
[...]
--
Alexandre Duret-Lutz
s, just upgrade to a recent Automake version. Dependencies
are no longer distributed, they are computed at build time and
can be disabled with a configure option.
--
Alexandre Duret-Lutz
am.fdpl
fdpl -g -o $@ -main ownmain.c program.fdpl
--
Alexandre Duret-Lutz
;t
Markus> rebuilt when files change.
I can't reproduce this. Which dependency mode are you using?
I'm attaching the test-case I've been using. Could you modify
it to exhibit your problem?
--
Alexandre Duret-Lutz
#! /bin/sh
# Copyright (C) 2003 Free Software Foundation, In
ile.am is
distributed. So this file should be *inside* your source tree,
or you will have surprises when you run `make dist'.
In short, copy automake.mk into your source tree, and include
it with
include automake.mk
or
include $(top_srcdir)/makefiles/automake.mk
[...]
--
Alexandre Duret-Lutz
or %option prefix will not break the automake
Richard> rule. But how portable is 'lex -t'?
lex -t, if portable, seems attractive to me because it would
allow us to drop ylwrap from the lex rules.
--
Alexandre Duret-Lutz
27; variable, either in your top-level
| `Makefile.am', or on the command line when invoking `make'.
--
Alexandre Duret-Lutz
tp://sources.redhat.com/automake/automake.html#FAQ
David> I'm not 100% sure what a VPATH build is
A build performed out of the source code directory. This
requires a make feature called VPATH to work (see `Compiling For
Multiple Architectures' in file INSTALL), hence the name.
[...]
--
Alexandre Duret-Lutz
ly necessary to print the if/else/fi blocks?
They won't be output in Automake 1.8
(you can try that from CVS if you want).
Thanks
--
Alexandre Duret-Lutz
>>> "Bill" == Bill Moseley <[EMAIL PROTECTED]> writes:
[...]
Bill> BTW -- automake 1.4-p4 autoconf 2.57.
[...]
Bill> I tried that before, and fell back to AM_CPPFLAGS.
Bill> Perhaps I'm missing the point:
My answer applies to Automake 1.7.x.
[...]
--
Alexandre Duret-Lutz
IBXML2_OBJS should be set to libswishindex_la-parser.lo, not parser.lo.
parser.lo is compiled with the default flags; libswishindex_la-parser.lo is
compiled with libswishindex.la's flags.
[...]
--
Alexandre Duret-Lutz
SDL_CFLAGS and SDL_LIBS, and use them where appropriate
in your Makefile.am (be it AM_CFLAGS or prog_CFLAGS).
--
Alexandre Duret-Lutz
On Mon, Jun 02, 2003 at 09:09:23AM +0200, Akim Demaille wrote:
>
> I discovered a nice property of AC_CONFIG_AUX_DIR and (CVS) Automake:
> you can use the Autoconf macro, and not provide a Makefile.am for this
> directory. The content is properly shipped, everything works fine,
> and you saved one
k.
Hi!
Sorry for doing such a late follow-up. I found your mail while
googling for a way to import a non-installed libtool library.
Is your libtool importer available somewhere? I'd have a use
for it :)
Thanks,
--
Alexandre Duret-Lutz
> Did anyone ever make a test release with a version number like 4.5.1?
Coreutils.
[...]
--
Alexandre Duret-Lutz
do what I want and people
Ryan> like the idea presented, I don't mind hacking it in.)
Here is where to start:
http://sources.redhat.com/automake/contribute.html
--
Alexandre Duret-Lutz
n_SOURCES = exec/main.c
exec_main_LDADD = libfoo.a
--
Alexandre Duret-Lutz
ntroduces a bug in the case the library already exists. Your
program will be linked to the old library, and then the library
will be rebuilt when make enter the subdirectory as part of the
SUBDIRS recursion.
--
Alexandre Duret-Lutz
ists ).
spam is filtered globally on all gnu.org lists since last
summer[*]. There is nothing we can do here about this. You
should discuss this matter on the [EMAIL PROTECTED] mailing
list.
[*] You can get the feeling here:
http://sources.redhat.com/ml/bug-automake/2002/
--
Alexandre Duret-Lutz
EXTRA_DISTing subdirectories is
the use of wildcards: there is a entry about this in the
Automake FAQ (in recent manuals).
--
Alexandre Duret-Lutz
in EXTRA_DIST.
Could you show an example of such a setup? I don't understand
why you EXTRA_DIST a directory you don't want to distribute.
It's important that we copy symlinked files and I tend to think
we should not handle directory differently.
--
Alexandre Duret-Lutz
On Tue, Jun 24, 2003 at 02:02:25PM +0200, Akim Demaille wrote:
>
> Why wouldn't nodist_ stuff be automatically included into CLEANFILES?
I think it would make sense.
http://www.cygwin.com/ml/bug-automake/2002/msg01693.html
On Thu, Jun 26, 2003 at 11:23:04AM +0200, Ralf Wildenhues wrote:
> Intel compiler icc version 7.1 handles the -MF option inconsistently.
> Documentation states that it has to be used together with -M or -MM.
> If used with -MD, for example, it will replace the file ending with .d:
[...]
> Subsequen
On Thu, Jun 26, 2003 at 02:47:24PM +0200, Akim Demaille wrote:
>
> > On Thu, Jun 26, 2003 at 11:23:04AM +0200, Ralf Wildenhues wrote:
> >> Intel compiler icc version 7.1 handles the -MF option inconsistently.
> >> Documentation states that it has to be used together with -M or -MM.
> >> If used
.h /usr/include/features.h \
[...]
What happens with `icc -MD -c -o foo/bar.o foo/bar.c' ?
Does that create foo/bar.d or bar.d? For Automake the
ideal would be foo/bar.d.
You mentioned that the depcomp configure test fails to
chose the icc mode. What mode does it select presently?
[...]
--
Alexandre Duret-Lutz
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
[...]
adl> You mentioned that the depcomp configure test fails to
adl> chose the icc mode. What mode does it select presently?
Update: I've got the occasion to try ICC 7.1 (Build 20030617Z)
with
ported in some diagnostics related to AUTOMAKE_OPTIONS.
* Remove Latin-1 characters from elisp-comp.
* Update the manual's @dircategory to match the Free Software Directory.
--
Alexandre Duret-Lutz
.gnu.org/archive/html/autotools-announce/2003-07/msg0.html
--
Alexandre Duret-Lutz
foo
: > Makefile.am
autoreconf -vfi
./configure
make distcheck
rm -Rf foo
./configure
make distcheck
works for me with Automake 1.7.4, 1.7.5b, and 1.7a. (Autoconf 2.57a)
[...]
--
Alexandre Duret-Lutz
to match the Free Software Directory.
--
Alexandre Duret-Lutz
pgp0.pgp
Description: PGP signature
SCRIPTS.)
Because the default mode for install is 755. On which platform
do you see this?
Adding -m 755 to INSTALL_SCRIPTS seems harmless, but if some
install does not default to 755 somewhere, shouldn't we do
something similar for programs?
[...]
--
Alexandre Duret-Lutz
[http://mail.gnu.org/archive/html/bug-coreutils/2003-07/msg00052.html]
Sorry for the delay.
>>> "Jim" == Jim Meyering <[EMAIL PROTECTED]> writes:
Jim> Alexandre Duret-Lutz <[EMAIL PROTECTED]> wrote:
>> On Wed, Jul 16, 2003 at 08:46:26AM +0200, Jim M
ing thing - I see in section 9.4 of the automake
Steven> manual the example program is called maude... Well my program is
Steven> really called maude and has been for many years:
Steven> http://maude.cs.uiuc.edu
No idea how old is this maude.
http://mail.gnu.org/archive/html/automake-patches/2002-01/msg00055.html
--
Alexandre Duret-Lutz
ory ? -> Note that my makefiles reside in the
Giannis> module1, module2, module3, module4, program1 and program2
Giannis> subdirectories.
See the subdir-objects options.
--
Alexandre Duret-Lutz
RCES = ...
[src/sub2/Makefile.am] (with nested packages)
SUBDIRS = sub2.1 sub2.2 ...
noinst_LTLIBRARIES = libsub2.la
libsub2_la_SOURCES =
libsub2_la_LIBADD = \
sub2.1/libsub1.2.la \
sub2.2/libsub2.2.la \
...
etc.
--
Alexandre Duret-Lutz
o the CC: list of the PR.
Changing the cleaning order will not work: the symmetric problem
also exists (see the comments in lib/am/subdirs.am before the
definition of distclean-recursive).
--
Alexandre Duret-Lutz
u have defined
it. That's why distclean-local exists: so you don't have to override
Automake's distclean rule.
In other words, keep only the distclean-local definition.
--
Alexandre Duret-Lutz
ctory, is the put a Makefile.am in that directory and build
everything from there. POSE, the PalmOS Emulator, use such a
setup (at least that was the case two years ago when I last
built it).
--
Alexandre Duret-Lutz
ear to be a couple of "@&t@" strings
Norman> astray in that section. Is this fallout from some not-quite-working
Norman> escaping, or is it something more arcane than I recognise!? ]
This is a trick to prevent Autoconf from complaining about the
direct assignment to LIBOBJS.
[...]
--
Alexandre Duret-Lutz
bash script, I can call it and inside it call make, that is i
Fernando> do now, but how can i do this using automake?
This is not supported.
--
Alexandre Duret-Lutz
extension, does
anybody knows of another implementation where it works? (Do not
misread this as an objection, I'm just curious to know where it
can work.)
--
Alexandre Duret-Lutz
>>> "gd" == Guido Draheim <[EMAIL PROTECTED]> writes:
gd> Alexandre Duret-Lutz wrote:
>>>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> Hi,
Ralf> Simple question: Does automake support filenames containing bl
>>> "Hari" == Raja R Harinath <[EMAIL PROTECTED]> writes:
[...]
Hari> I think it's worthwhile to consider Ralf's patch after he
Hari> addresses some of my comments.
I completely agree.
--
Alexandre Duret-Lutz
On Mon, Jul 28, 2003 at 01:09:21PM +0200, Markus Werle wrote:
> Hi!
>
> Though I appreciate the automatic dependency tracking mechanism,
> I sometimes encounter problems with this approach using Intel's C++
> compiler. For reasons I do not understand prefixed objects get rebuilt,
> so either depcom
executable, recheck and regenerate
Andrew> test -x config.status && ./config.status --recheck
Andrew> test -x config.status && ./config.status
Andrew> # Exit true if we got this far
Andrew> exit 0
This whole script (including its last part) can be replaced by
autoreconf -im
(I'd use -vfim, though.)
--
Alexandre Duret-Lutz
the Automake manual.
http://sources.redhat.com/automake/automake.html#FAQ
--
Alexandre Duret-Lutz
On Tue, Jul 29, 2003 at 09:19:19AM +0200, Mattias Br?ndstr?m wrote:
>
> fooincludedir = ${prefix}/include/project/foo
> fooinclude_HEADERS = headerA.h headerB.h headerX.h
>
> I wonder if this is the conventional way to do this?
Yes. That, or the nobase_ setting you mention.
However hardcoding $(
On Tue, Jul 29, 2003 at 10:45:18AM +0200, Mattias Br?ndstr?m wrote:
> lib_LTLIBRARIES = libproject.la
> librkcone_la_LIBADD = foo/libfoo.a
>
> When I do it like these I get a warning during the build process saying:
>
> *** Warning: Linking the shared library libproject.la against the
> *** static
On Tue, Jul 29, 2003 at 01:16:53PM +0200, Mattias Br?ndstr?m wrote:
[...]
> automake: src/rkcone/common/Makefile.am: object `Exception.lo' created
> both with libtool and without
[...]
> I suspect there is an obvious solution to this that I am missing. Can
> someone set a library building newbie on
s
you use per-target flags such as libfoo_a_CFLAGS, so you don't
even need to put -fPIC in that variable. All you need is to use
it.
--
Alexandre Duret-Lutz
A work around to this issue is to ensure that these two objects get
different basenames. As explained in *note renamed objects::, this
happens automatically when per-targets flags are used.
bin_PROGRAMS = prog
prog_SOURCES = prog.c foo.c ...
prog_CFLAGS = $(AM_CFLAGS)
lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = foo.c ...
Adding `prog_CFLAGS = $(AM_CFLAGS)' is almost a no-op, because when the
`prog_CFLAGS' is defined, it is used instead of `AM_CFLAGS'. However
as a side effect it will cause `prog.c' and `foo.c' to be compiled as
`prog-prog.$(OBJEXT)' and `prog-foo.$(OBJEXT)' which solves the issue.
--
Alexandre Duret-Lutz
ES+= hello-linux.c
Harlan> else
Harlan> libhello_la_SOURCES+= hello-generic.c
Harlan> endif
Yes, thanks. I'll use this instead.
Harlan> As I recall, there *used* to be a problem with this. I
Harlan> don't know if it has been fixed or not.
I think it was fixed in Automake 1.7.
--
Alexandre Duret-Lutz
hat foo.$(OBJEXT) is created in both cases?
Tim> The program never builds foo.lo, but it does build foo.$(OBJEXT)
Indeed. I'm installing the following on HEAD and branch-1-7.
2003-07-30 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* automake.in (handle_single_transform_list): C
need to mention it and risk a confusion.
>From the Automake point of view it doesn't matters what a *.la
file consists of: it's just a realization of the libtool library
concept.
Similarly I'm not sure we should go so deep as mentioning the
.libs/_libs directories: this is an implementation detail of
Libtool.
--
Alexandre Duret-Lutz
is situation it will complain
with a message such as
object `foo.$(OBJEXT)' created both with libtool and without
A workaround for this issue is to ensure that these two objects get
different basenames. As explained in *Note renamed objects::, this
happens automatically when per-targets flags are used.
bin_PROGRAMS = prog
prog_SOURCES = prog.c foo.c ...
prog_CFLAGS = $(AM_CFLAGS)
lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = foo.c ...
Adding `prog_CFLAGS = $(AM_CFLAGS)' is almost a no-op, because when the
`prog_CFLAGS' is defined, it is used instead of `AM_CFLAGS'. However
as a side effect it will cause `prog.c' and `foo.c' to be compiled as
`prog-prog.$(OBJEXT)' and `prog-foo.$(OBJEXT)' which solves the issue.
--
Alexandre Duret-Lutz
>>> "Norman" == Norman Gray <[EMAIL PROTECTED]> writes:
Norman> Alexandre, greetings,
Norman> On Wednesday, July 30, 2003, at 06:40 PM, Alexandre Duret-Lutz wrote:
>> Here is a second version of this section, so that we have
Norman> This looks
files get placed in the same direcotry
Corn> where their makefile.am is in.
Not really, their are built in the same directory as their Makefiles.
That makes a difference since you can choose where Makefiles go.
http://sources.redhat.com/ml/automake/2003-07/msg00069.html
[...]
--
Alexandre Duret-Lutz
>>> "juman" == juman <[EMAIL PROTECTED]> writes:
[...]
juman> Any tips of how I easiest disable the compilation from
juman> using the -O2 flag temporary?
Run
./configure CFLAGS=-g
--
Alexandre Duret-Lutz
is behaviour changed.
Are you sure?? AFAICT --disable-static correctly disables the
building of static libraries for the whole package (I'm using it
every day). The libtool thread is discussing is a way to
disable static libraries on a per-target basis.
--
Alexandre Duret-Lutz
e top-level, like
./configure{,.ac}, aclocal.m4 and Makefile.{in,am}, but I'm
afraid you'll have to live with them. Uniformity matters most
than personal taste.
[...]
--
Alexandre Duret-Lutz
projects, which I guess is not always true. Yet if anyone
has some experience to share on this topic I'm interested.
--
Alexandre Duret-Lutz
like you are not looking at the manual that comes with
your version. (The first paragraph of the manual should tell
you which version it documents.)
make ps is new is 1.7.x
--
Alexandre Duret-Lutz
>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> I expected TEXINFO_TEX to override AC_CONFIG_AUX_DIR, but it doesn't:
Thanks. I'm installing this on HEAD and branch-1-7.
2003-08-05 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* au
On Wed, Aug 06, 2003 at 03:28:51PM -0600, Tom Tromey wrote:
> I haven't looked at this yet.
>
> Take a look at the appended `make' output. Why are we building in
> `tests' twice?
There are two different tests/ directories on HEAD...
be build as follows (dependency):
FAU> foobar: bar.c common/foo.c
[src/Makefile.am]
bin_PROGRAMS = foobar
foobar_SOURCES = bar.c common/foo.c
--
Alexandre Duret-Lutz
reached any please-all solution.
--
Alexandre Duret-Lutz
>>> "Erik" == Erik Hofman <[EMAIL PROTECTED]> writes:
Erik> Alexandre Duret-Lutz wrote:
>> ARFLAGS is supported in current CVS Automake.
Erik> Are you kidding me?
No.
Erik> It's not supported in the latest stable release.
Correct.
--
Alexandre Duret-Lutz
ARFLAGS is supported in current CVS Automake.
--
Alexandre Duret-Lutz
>>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
[...]
Harlan> Is there a way to pass configure options to distcheck's
Harlan> "configure" run?
See DISTCHECK_CONFIGURE_FLAGS.
--
Alexandre Duret-Lutz
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> [http://mail.gnu.org/archive/html/bug-coreutils/2003-07/msg00052.html]
adl> Sorry for the delay.
[...]
Jim> What do you think about dropping that warning altogether,
adl> Someo
; is now in DIST_SUBDIRS twice.
[...]
Harlan> I think the rule for running *clean-recursive needs to
Harlan> "uniq" DIST_SUBDIRS.
I don't see how this can be done because the ordering in
DIST_SUBDIRS matters. It's easier to fix your definition of
DIST_SUBDIRS so that sntp appears only once, or (better) to
avoid DIST_SUBDIRS by using conditionals.
--
Alexandre Duret-Lutz
ake" is any flavor of BSD
make. 1.7.7 will include a fix for this.
[...]
--
Alexandre Duret-Lutz
On Tue, Aug 19, 2003 at 11:09:21AM +0200, Benjamin Sailer wrote:
> Or do i just have to upgrade the
> autotools?
I would try this first. Automake 1.6.3 is more than one year old,
and 1.7.x has a few NEWS entries in this area.
eate
the missing Makefile.in
At least you shouldn't have to play a symlink game this way.
[...]
--
Alexandre Duret-Lutz
is
created at all. It seems to me it should only exists when TeX
has been run without any file argument.
--
Alexandre Duret-Lutz
value" or
"make -e" because environment dependent builds are harder to
debug when you have no clue they are environment dependent.
I guess everybody has already been bitten by a hidden
environment variable.
Still, I'm not a DejaGNU user, so maybe none of this makes sense
and RUNTESTFLAGS must be handled differently from other
variables.
--
Alexandre Duret-Lutz
guages, but at the current pace
you shouldn't expect this anytime soon.
--
Alexandre Duret-Lutz
ee them.
Libtool builds such libraries in a secret place. You should
only refer to libj.la in your Makefile and let libtool do the
magic.
--
Alexandre Duret-Lutz
* ...
If I recall correctly, the Swig manual explains how to do that.
(The Swig mailing lists are probably a better place to discuss
this.)
It would be a lot different if you were actually trying to use
Swig + Automake + Libtool. Let me know if this is your case.
[...]
--
Alexandre Duret-Lutz
the
install rules. If your `Makefile.am' uses a local install rule (e.g.,
`install-exec-local') or an install hook, then you must write that code
to respect `DESTDIR'.
--
Alexandre Duret-Lutz
>>> "Tom" == Tom Howard <[EMAIL PROTECTED]> writes:
[...]
Tom> While I'm at it, if I have a target 'dist-foobar' is there
Tom> a way to have the 'dist' target call the 'dist-foobar'
Tom> target as well?
[...]
See dist-hook in the manual.
--
Alexandre Duret-Lutz
ist-gzip, dist-bzip2, etc)
Tom> Any other ideas?
I'm afraid I have no idea what else you are expecting.
--
Alexandre Duret-Lutz
Patrick Welche:
| On Thu, Aug 21, 2003 at 01:25:29AM +0200, Alexandre Duret-Lutz wrote:
| > >>> "Patrick" == Patrick Welche <[EMAIL PROTECTED]> writes:
| >
| > Patrick> txinfo3.test txinfo13.test txinfo16.test txinfo18.test txinfo22.test
| > Patrick>
VS
versions of these files manually. I'm considering updating the
automatic rules to take these files from CVS instead of ftp,
since I don't think it makes any difference.
--
Alexandre Duret-Lutz
>>> "Dale" == Dale E Martin <[EMAIL PROTECTED]> writes:
[...]
Dale> AC_CONFIG_HEADERS([FooConfig.h:FooConfig.h.in])
Dale> AC_OUTPUT(Makefile)
AC_CONFIG_FILES([
FooConfig.h:FooConfig.h.in
Makefile
])
AC_OUTPUT
[...]
--
Alexandre Duret-Lutz
null`])
AC_SUBST([PYTHONINC], [$adl_cv_python_inc])])
--
Alexandre Duret-Lutz
eturn0throw runs it prints "cought: hello" in
this second run, while it did not during "make check" above.
Too me, this indicates that the exception was not caught during
the first run. Perhaps it's not the same code which is being
executed? I'm sorry I don't have any other idea.
--
Alexandre Duret-Lutz
m. The real error is in aclocal.m4 line 473.
Could you show that to us? Something is probably underquoted.
--
Alexandre Duret-Lutz
rograms that are installed
with a custom rule or a separate script.
--
Alexandre Duret-Lutz
files.)
* Resurrect multilib support.
* Noteworthy manual updates:
- Extending aclocal: how to write m4 macros that won't trigger warnings
with Automake 1.8.
- A Shared Library: Rewrite and split into subsections.
--
Alexandre Duret-Lutz
pgp0.pgp
Description: PGP signature
On Mon, Sep 22, 2003 at 06:12:50PM +0100, Gary V. Vaughan wrote:
[...]
> I was hoping to remove acinclude.m4 and use m4_include in aclocal.m4 by
> switching to CVS automake, but currently the contents are still copied to
> aclocal.m4 if they are not in the same directory as configure.ac. Wherever
> > Do not use aclocal.m4 in these subdirectories. Simply add
> > m4_include([../aclocal.m4]) and maybe m4_include([../ltdl.m4])
> > at the top of all these configure.ac.
>
> Not an option since all of the automake macros need to be copied in for
> configure.ac to be expandable to a working con
On Wed, Sep 24, 2003 at 02:19:06PM +0200, Akim Demaille wrote:
> At the origin I was considering that AC_CONFIG_M4_DIR was
> automatically passed to m4 as a -I, so instead of
> m4_include([config/init.m4]) etc. you'd have m4_include([init.m4]).
Isn't there a chicken'n'egg problem? How can you tra
101 - 200 of 920 matches
Mail list logo
