"L. D. Marks" <[EMAIL PROTECTED]> writes:
>
> 2) Duplicate, and inconsistent gcc/g++/g77 compilers
The c++ compiler for some reason always seems a good candidate for
breakage on systems I see. I think bad installations are outside the
scope of autoconf, but you can always have configure che
Martin Frydl <[EMAIL PROTECTED]> writes:
>
> - config.guess does not use CFLAGS when making compilation checks but
> this can be "fixed" by providing necessary flags directly in CC
> variable
I think the cpu type guessed is supposed to depend only on the system,
not on an intended compiler mode.
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.
Marc Waeckerlin <[EMAIL PROTECTED]> writes:
>
> Is there a check or macros for invoking m4 in autoconf, automake?
We use a couple in GMP, just searching for an m4 with enough features
(eval, $#), and checking for a gremlin in m4wrap that afflicts a few
systems.
[EMAIL PROTECTED] (Bob Proulx) writes:
>
> I will verify that that bug exists at least up through 10.20. Between
> 10.20 and 11.0 HP changed their make program somewhat.
For what it's worth we got a bug report today about it happening on a
"HP-UX null B.10.20 A 9000/898". But another hpux 10.20
Tom Tromey <[EMAIL PROTECTED]> writes:
>
> Thanks. I don't think we generate code like this, and we seem to
> already reject inputs like this. So I think we're safe.
I had managed to bring it on myself,
my_objects = one$U.lo two$U.lo \
@THREE@
where @THREE@ could be empty, d
Tom Tromey <[EMAIL PROTECTED]> writes:
>
> I think we'd need some autoconf support to make this really work. For
> instance you'd probably want to be able to run tests on both
> compilers, generate two different config.h's, etc.
Yes. I've been setting up some stuff like that for GMP to run a
co
"Paul F. Kunz" <[EMAIL PROTECTED]> writes:
>
> /bin/sh: -c: line 1: syntax error near unexpected token `;'
> /bin/sh: ... for tst in ; ...
bash doesn't like an empty list like that. Is $(TESTS) empty for some
reason? In any case, I think newer automake avoids the problem.
Martin Frydl <[EMAIL PROTECTED]> writes:
>
> lib_LTLIBRARIES = libmylib.la
> libmylib_la_SOURCES = file.cpp subdir/file.cpp
>
> Is there any possibility how to use multiple files with the same name
> as sources for one library (program)?
GMP does that sort of thing with a conv
I think it'd be good if automake checked its support files like
"missing" and "ansi2knr.c" are up-to-date, not just that they exist.
A warning if they differ from the /usr/share/automake versions would
probably be enough, since there's at least a chance of intentional
local modifications. I guess
In 1.4f files given as
EXTRA_HEADERS = foo.h
don't get into a "make dist". Is this meant to work? It did in
recent cvs versions but I guess noinst_HEADERS might be the right way
to do it. A bit of a test below if it is meant to work.
EXTRA_HEADERS also don't seem to get into $(HEADER
Tom Tromey <[EMAIL PROTECTED]> writes:
>
> >>>>> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
>
> Kevin> I think it should create and distribute the info files
> Kevin> unconditionally, but only install (or uninstall) them under
&g
Would it be easy to let info_TEXINFOS be conditionally defined?
if WANT_FOO
info_TEXINFOS = foo.texi
endif
I think it should create and distribute the info files unconditionally,
but only install (or uninstall) them under WANT_FOO. Perhaps it'd
just be a case of splittin
Raja R Harinath <[EMAIL PROTECTED]> writes:
>
> I've attached a patch only to revert the CONFIG_COMMANDS case. I
> think the CONFIG_LINKS= part in the above is harmless.
Oops, yep. It was the links that had been annoying me.
Tom Tromey <[EMAIL PROTECTED]> writes:
>
> I don't know when I'll fix the bug but it will definitely be before
> the next release.
The bandaid I'm using is below. It seems to work, but it'd be a
mistake to assume I know what I'm doing.
--- automake.in.old Fri Feb 2 06:29:06 2001
+++ automake
When config.status is invoked to regenerate a Makefile, I think it
might be possible to give an empty CONFIG_LINKS and CONFIG_COMMANDS as
well as the current empty CONFIG_HEADERS, to speed up regeneration
when there's a bunch of links.
* automake.in (handle_configure): Call config.status
I wanted to use
AC_CONFIG_FILES(foo/bar.h:foo/bar.in)
but found automake generates rules based on bar.h.in, not bar.in.
I think the following might be modifying @other_input_files, changing
"foo/bar.h:foo/bar.in" to just "foo/bar.h" by the time it gets to
process the foo subdirectory.
I tried to use
check_LTLIBRARIES = libfoo.la
but found it added "-rpath $(checkdir)" to the libtool link, which
didn't work since $(checkdir) doesn't exist.
I thought to use this as a convenience library built only under a
"make check". If this is how it's meant to be used then I think
Tom Tromey <[EMAIL PROTECTED]> writes:
>
> >>>>> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
>
> Kevin> I find though that I got it wrong for the case where automake
> Kevin> isn't automatically generating any suffixes, but
Tom Tromey <[EMAIL PROTECTED]> writes:
>
> Thanks, I finally checked this in.
Excellent.
I find though that I got it wrong for the case where automake isn't
automatically generating any suffixes, but rather there's only
user-supplied ones with $(SUFFIXES). This comes up in autoconf I
think.
Th
I'd like to propose the patch below to put any $(SUFFIXES) from
Makefile.am at the head of the .SUFFIXES list in Makefile.in.
This would help a certain situation in GMP where either a foo.c or
foo.s is used, according to the configured target. With the whole
.SUFFIXES list sorted, .c is before .
Alex Hornby <[EMAIL PROTECTED]> writes:
>
> # Makefile.am fragment
> FOO = foo bar
> BAR = ${FOO:%=%.c}
> ...
>
> What do people think?
It'd be nice to be able to embed little fragments of perl to do things
like that, for the "static" case that is. But perhaps that idea has
come up before. Or
I've struck a bit of a problem using a combination of ansi2knr,
libtool and .s assembler files which I think is related to automake
sorting the .SUFFIXES list.
I want a certain foo.lo to be provided either by foo.c or foo.s (and
some other possibilities) depending on the configured target, and if
Using a recent cvs automake, I tried "make TAGS" in a separate object
directory, but the etags command got config.in without a $(srcdir)
path. Perhaps the @CONFIG@ in tags.am should be in the list that gets
uniquified and checked for needing $(srcdir). The same might apply to
$(LISP) there too,
> I don't remember if this breaks anything. It probably doesn't,
> though. Can you write a patch? Or, if not, could you submit a PR?
I think it's enough to move the test for EXTRA to after the bit that
adds $(EXEEXT), per below. It does the right thing for me on some
gnu-ish makefiles.
On a recent cvs snapshot I noticed $(EXEEXT) is automatically added to
check_PROGRAMS, bin_PROGRAMS etc, but not to EXTRA_PROGRAMS. I think
adding it there might be useful for consistency and to let something
like the following work in a demos directory.
EXTRA_PROGRAMS = foo bar
Using a CVS automake I recently had a directory where I wanted to run
some tests only if a certain configuration option is selected.
if SOME_OPTION
check_PROGRAMS = foo bar
TESTS = $(check_PROGRAMS)
endif
This has the desired effect, except when using bash (2.04)
27 matches
Mail list logo
