Re: Patch 2 of 4: mkinstalldirs
> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes: >> Nope, afraid not. Where did you get this mkinstalldirs? Tim> Hmm - then I don't really know where I got it. Some GNU package, Tim> I guess. Without knowing where it came from I can't check it in. That's true even if you have paperwork signed, since you didn't write it. Tom
Re: Testsuite fails
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
>> Ideally we'd have some way to tell autoconf, "if this package can
>> be cross-compiled, then check for a cross `strip' as well". Maybe
>> there's an ugly way to do this.
Akim> But I think your request is precisely AC_CHECK_TOOL. What
Akim> exactly do you mean?
Suppose I have AM_INIT_AUTOMAKE call AC_CHECK_TOOL. Then every
package needs config.{guess,sub}. (Or at least that was true in the
past.)
The idea is something like:
* the user declares a package suitable for cross compilation:
AC_CAN_CROSS_COMPILE
* AM_INIT_AUTOMAKE conditionalizes on this:
AC_IF_CROSS([AC_CHECK_TOOL([STRIP],[strip])])
Akim> Also, my number one grief against the test suite is that it is
Akim> classified by alphabetical order, which looks cute, but is a
Akim> stupid an order as the random order. We need to order them from
Akim> the ``innermost tests'' to the outermost, so that it gives us
Akim> some good intuition of *where* it fails, and what failures are
Akim> actually the same only one.
That would be nice, but the automake tests are really just a bunch of
regression tests. Mostly they test for fairly specific bugs. This
isn't a great quality to have in a test suite.
If someone wants to reorder them, that's fine, I guess. I don't want
to do it since it seems like a lot of work for no particular reason.
One problem with reordering is deciding where to put a new test.
Tom
Manual additions (DOS issues)
> > > suggest that your patch makes them uniform. And of course, the same > > > as promoted by autoconf.texi :) > > How do you mean, Akim? autoconf.texi doesn't say anything > > about this... Or do you want me to add such an entry? > > Arg, sorry, I really thought there was some text about this issue in > there. So yes, your proposal is gladly accepted :) OK - here goes. I've listed '[\\/]* | ?:[\\/]*' as the canonical absolute path test; I'll submit patches to use this throughout autoconf later. 2001-02-20 Tim Van Holder <[EMAIL PROTECTED]> * doc/autoconf.texi: Add new node discussing issues related to file systems (DOS, specifically). Document DJGPP's bash's special handling of $PATH_SEPARATOR. manual-additions.diff
Re: 43-conditionals-as-hashes.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Ideally I'd say we need objects for variables, and have a
Akim> uniformized handling of conditionalized/unconditinal variables.
This patch needed a lot less defense than you posted -- the only
reason conditionals were implemented in that ugly way was Perl 4
compatibility.
I agree the new setup is much better. For one thing it will
eventually let us fix the problems involving variables which are both
conditionally and unconditionally defined (including conditional use
of `+=').
Akim> * automake.in (&conditional_dump): New.
Akim> (&check_ambiguous_conditional, &variable_defined)
Akim> (&variable_conditions_sub, &variable_value_as_list_worker)
Akim> (&define_variable, read_am_file, &read_main_am_file): Be sure to
Akim> handle `$conditional{$vars}' as a hash instead of a plain string.
Ok.
Tom
Re: 44-conditionals-cleanup.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&check_ambiguous_conditional, &read_main_am_file):
Akim> Use a uniform naming scheme.
Akim> ("e_cond_val, &unquote_cond_val): Delete, dead code.
Akim> (&read_am_file): Fix conditioned definition of backslash continued
Akim> items.
Ok.
Tom
Re: 45-confh4-test.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * dist-vars.am: Remove, merge into... Akim> * distdir.am: this. Akim> * automake.in (dirname, basename, backname): Move at the top of Akim> the file so that prototypes are checked, Akim> Use them without `&'. Akim> (&handle_dist): Adjust. This is ok, but annoying. I prefer to have stupid functions like basename at the end of the file so I can just forget about them. Tom
automake/54
I think the line at 1260 from automake-1.4d in the function handle_single_transform_list: 1260 &require_file ($FOREIGN, 'compile') 1261 if $lang eq 'c'; should instead read: 1260 &require_config_file ($FOREIGN, 'compile') 1261 if $lang eq 'c'; This makes the error about not finding './compile' go away. I now have it in config subdirectory. Or perhaps, one of the *with_line functions? It also appears at line 4752, but is qualified with a if $relative_dir eq '.', so don't think this change is needed. Paul
Re: 37-unify-handle-dist.patch
On Tue, Feb 20, 2001 at 01:02:50PM -0700, Tom Tromey wrote: > BTW it is hard to read big rearrangement patches. It is made worse rearrangements are done better by a script than a patch. -- Thomas E. Dickey <[EMAIL PROTECTED]> http://dickey.his.com ftp://dickey.his.com
Re: 41-header-vars-canonical.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in ($top_builddir): Remove, used in one place. Akim> (&define_standard_variables): Adjust. Akim> Move the definition of triplet variables into... Akim> * header-vars.am: here. Ok. If I don't get to the rest of the patches today please fix the top_builddir problem when you check this in. Tom
Re: 42-conditionals-true-when.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (&conditional_true_when): Modernize, simplify. Akim> Warning: `$comp' is now private (my), while it used to be Akim> `inherited' from a `local' elsewhere in the code. AFAICT it was Akim> wrong, but some dirty side effect might show up. Akim> (&conditionals_true_when): New. Akim> (&variable_conditions_sub, &variable_conditions_reduce): Use it. Ok. Tom
Re: 39-dejagnu.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (&handle_tests_dejagnu): Move the definition of a Akim> default `site.exp' into... Akim> * dejagnu.am (site.exp): here. Akim> Use DOS compliant file names. Ok. Tom
Re: 40-formatting.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (&initialize_global_constants): Don't define $USAGE. Akim> (&usage): Handle the former content of $USAGE. Akim> Don't pretend autoconf cares about Makefile.in. Akim> Classify the options. Akim> (&handle_tests): Formatting and mying changes. Ok. Tom
Re: 33-dist-flavors.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> This patch includes all the diffs of Makefile.ins, i.e., subdirs' Akim> Makefile have not changed. The big change in the top Makefile.in Akim> comes from the fact that the so called `find complex command' is Akim> attached to distdir (where it belongs IMHO), rather than to each Akim> dist-like target. A "top level" Makefile.in might actually be called from a higher directory. Suppose I take a complete auto*-using package and make it a subdir of another package. This might affect this code. I don't remember. But we have to be sure that this change doesn't cause problems in this scenario. If it does cause problems (I haven't looked) then one solution would be to introduce an intermediate target: dist: _am-dist-intermediate _am-dist-intermediate: distdir find ... Could you look at this first? If there are no problems then go ahead and commit it. Tom
Re: 35-dist-targets.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * distdir.am (distdir): Handle the DIST-TARGETS. Akim> * automake.in (&handle_dist_worker): Don't. This is ok if patch 34 goes in. Tom
Re: 36-uniq.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> It is on purpose my uses of uniq have no &: it disables Akim> prototype checking. Do we really want prototypes? I seem to remember Perl experts telling me that they are confusing and weird. Akim> * distdir.am (GZIP_ENV): Define. Akim> * automake.in (&handle_dist): Don't. Akim> (&uniq): New. Akim> (&handle_dist_worker, &am_install_var): Use it. Ok. Tom
Re: 37-unify-handle-dist.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * dist.am: Remove, merge into... Akim> * distdir.am: here. Use the neat sed snippet for banners. Akim> BTW, distcheck is phony. Akim> * automake.in (&handle_dist_worker): Remove, merge into... Akim> (&handle_dist): this. Akim> (&file_contents): Strip leading new lines. Akim> Be sure to end comments with new lines. Ok. BTW it is hard to read big rearrangement patches. It is made worse because sometimes they include actual code changes as well. For instance this patch wasn't just a rearrangement, it included semantic differences in file_contents. I'd prefer to see rearrangements separate from semantic changes. Then hopefully I can approve rearrangements without trying to read them in detail. Tom
Re: 38-clean-dist.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (&dist_cmp): New. Akim> (&handle_dist): Use it. Akim> Promote `my' over `local'. Ok. Beware: I believe there is one place in automake where local() is required. I know that sucks. I think it is in the variable expansion code, but I'm afraid I don't remember for certain. Tom
Re: 34-transform-global-options.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (&file_contents): Transform the global options (such Akim> as CYGNUS). Akim> (&handle_texinfo, &handle_dist_worker, &handle_tests_dejagnu): Don't. Ok. Tom
Re: Makefile.am and other directories...
Well, I do this already, but what that does is remake my entire project, when all I really want to do is cd into ONLY the part1/ directory and ONLY remake the portions that it depends on. In other words, I want it to "cd ../part2 ; make" in order to make the stuff in part1/ On Tue, Feb 20, 2001 at 11:00:00AM -0700, Tom Tromey wrote: > > "Jiva" == Jiva DeVoe <[EMAIL PROTECTED]> writes: > > Jiva> I have a project with the following structure: > Jiva> src/ > Jiva> part1/ > Jiva> part2/ > > Jiva> The code in part1/ depends on .o files created in part2/. What > Jiva> sort of macros should I put in my part1/ Makefile.am to cause it > Jiva> to make sure the files in part2/ are made before it tries to > Jiva> make the stuff in part1/? > > Use the ordering of directories in src/Makefile.am to do this: > > SUBDIRS = part2 part1 > > Tom -- Jiva DeVoe VP Of Software Development Opnix, Inc. - Simply cool bandwidth. GPG Fingerprint: 0A17 DF84 516A 1DC4 B837 FE6D 3128 41CD 97CB 4AA7
Re: Makefile.am and other directories...
> "Jiva" == Jiva DeVoe <[EMAIL PROTECTED]> writes: Jiva> Well, I do this already, but what that does is remake my entire Jiva> project, when all I really want to do is cd into ONLY the part1/ Jiva> directory and ONLY remake the portions that it depends on. In Jiva> other words, I want it to "cd ../part2 ; make" in order to make Jiva> the stuff in part1/ There's no automatic way to do that with the current automake. Tom
Re: AM_CFLAGS
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> ifdef([m4_pattern_allow], Akim> [m4_pattern_allow([^AM_CFLAGS$])])dnl Feel free to check in this change if you get to it before I do. Tom
Re: automake -vs- BSD make
> "Lars" == Lars Hecking <[EMAIL PROTECTED]> writes: >> I'm surprised Make doesn't speak here. Reading the test files, GNU >> Make is required, and GNU Make is usually verbose. In my case I have: Lars> I'm using BSD make here. That's the whole point of the exercise. Lars> Requiring GNU make doesn't make much sense IMHO. Maybe we should make a copy of the test that does the build in srcdir. If we do the build in a separate directory then we can't rely on a non-GNU make working. Tom
Makefile.am and other directories...
I have a project with the following structure: src/ part1/ part2/ The code in part1/ depends on .o files created in part2/. What sort of macros should I put in my part1/ Makefile.am to cause it to make sure the files in part2/ are made before it tries to make the stuff in part1/? -- Jiva DeVoe VP Of Software Development Opnix, Inc. - Simply screaming bandwidth. GPG Fingerprint: 0A17 DF84 516A 1DC4 B837 FE6D 3128 41CD 97CB 4AA7
Re: $ in source file names
> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: >> If Automake doesn't support $ in source file names, then I would >> suggest that it isn't an important requirement for Libtool. Alexandre> I disagree. libtool can be used independently from Alexandre> automake. And, in fact, until libtool supports correctly Alexandre> file names containing `$' and line-feeds, I won't be Alexandre> convinced we do the right thing regarding single-evaluation Alexandre> of arguments. And as Alexandre knows, we've already run into problems regarding `$' in names when testing libgcj. Java tends to end up with file names like this due to how inner classes are implemented. Tom
Re: Makefile.am and other directories...
> "Jiva" == Jiva DeVoe <[EMAIL PROTECTED]> writes: Jiva> I have a project with the following structure: Jiva> src/ Jiva> part1/ Jiva> part2/ Jiva> The code in part1/ depends on .o files created in part2/. What Jiva> sort of macros should I put in my part1/ Makefile.am to cause it Jiva> to make sure the files in part2/ are made before it tries to Jiva> make the stuff in part1/? Use the ordering of directories in src/Makefile.am to do this: SUBDIRS = part2 part1 Tom
Re: $ in source file names
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes: Robert> The problem is that even though Robert> progname_SOURCES = 'm$in.cpp' Robert> is in Makefile.am, am_progname_OBJECTS is empty. Robert> Is this not supported by Automake, or is it a bug? It is both. Supporting it is difficult, but given the existence and implementation of Java, it also is no longer an unreasonable thing for a developer to do. In fact they might not have a choice. Tom
Re: Fail: install2.test
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> As a specific advice, please, never test again any of the Akim> Autotools as root, as they are not meant for it, and this Akim> produces false alarms. Maybe we could modify `defs' to `exit 77' when the user is root. I'm not too concerned about it though. This is the first such report in automake history. Tom
Re: BUILT_SOURCES
> "Florent" == Florent Devin <[EMAIL PROTECTED]> writes: Florent> I have seen a var which is BUILT_SOURCES. Florent> Affecting this variable causes the make process build the var before Florent> anything. (If I am wrong please tell me). Florent> But is it necessary to build this var if the cmd is make clean ??? This only happens with earlier versions of automake. The current prerelease has (slightly) different, better semantics for BUILT_SOURCES. For instance, a built source is no longer built when invoking a clean target. Tom
BUILT_SOURCES
Hi, I have seen a var which is BUILT_SOURCES. Affecting this variable causes the make process build the var before anything. (If I am wrong please tell me). But is it necessary to build this var if the cmd is make clean ??? -- Florent DEVIN
Re: Fail: install2.test
Stephen Torri <[EMAIL PROTECTED]> writes: > No problem. I will move the code into a user directory and work as my > normal user. In regards to install the "questionable" tarball, how do you > handle it? There is nothing but trust here. If someone wants to hurt you, given that `install' is very likely to be run by root, there is nothing to do but completely check what's going to be done. Have fun! :) But for the other targets, the environment of root being usually so different, it's a bad idea to be root when running them. > If my /usr/local/bin is owned by root then I cannot install it as a > normal user. That's why I wrote `but for make install'.
Re: Fail: install2.test
No problem. I will move the code into a user directory and work as my normal user. In regards to install the "questionable" tarball, how do you handle it? If my /usr/local/bin is owned by root then I cannot install it as a normal user. Stephen On 20 Feb 2001, Akim Demaille wrote: > Stephen Torri <[EMAIL PROTECTED]> writes: > > > > cp: cannot open `foo' for reading: Permission non accordée > > > > Worked fine. I was able to create "bar". (logged in as root) > > This test is precisely trying to check that automake does not perform > invalid operations, but the user is not expected to be root. > > As a general advice, you should not be root when playing with foreign > (thanks for your trust :) tarballs but when `make install'. > > As a specific advice, please, never test again any of the Autotools as > root, as they are not meant for it, and this produces false alarms. > > The conclusion is that Automake is fine on your machine :) > --- Buyer's Guide for a Operating System: Don't care to know: Mac Don't mind knowing but not too much: Windows Hit me! I can take it!: Linux
Re: Fail: install2.test
Stephen Torri <[EMAIL PROTECTED]> writes: > > cp: cannot open `foo' for reading: Permission non accordée > > Worked fine. I was able to create "bar". (logged in as root) This test is precisely trying to check that automake does not perform invalid operations, but the user is not expected to be root. As a general advice, you should not be root when playing with foreign (thanks for your trust :) tarballs but when `make install'. As a specific advice, please, never test again any of the Autotools as root, as they are not meant for it, and this produces false alarms. The conclusion is that Automake is fine on your machine :)
Re: Fail: install2.test
On 20 Feb 2001, Akim Demaille wrote: > > How frustrating not to see what failed... > > Could you try this: > > /tmp % touch foo nostromo 16:38 > /tmp % chmod 000 foo nostromo 16:38 > /tmp % cp -pR foo barnostromo 16:38 > cp: cannot open `foo' for reading: Permission non accordée Worked fine. I was able to create "bar". (logged in as root) > and this: > > src/am/tests % make check TESTS=install2.testnostromo 16:39 > make check-TESTS > make[1]: Entering directory `/mnt/nostromo/home/lrde/prof/akim/src/am/tests' > PASS: install2.test > == > All 1 tests passed > == > make[1]: Leaving directory `/mnt/nostromo/home/lrde/prof/akim/src/am/tests' > src/am/tests % ls testSubDir/foo-0.1 nostromo 16:39 > src/am/tests % nostromo 16:39 Okay my setup for directories is: /usr/src/automake So the testSbuDir is at /usr/src/automake/tests/testSubDir Here is the output of "ls testSubDir/foo-0.1: Makefile.am Makefile.in aclocal.m4 configure configure.in depcomp install-sh missing mkinstalldirs Stephen --- Buyer's Guide for a Operating System: Don't care to know: Mac Don't mind knowing but not too much: Windows Hit me! I can take it!: Linux
Re: Fail: install2.test
How frustrating not to see what failed... Could you try this: /tmp % touch foo nostromo 16:38 /tmp % chmod 000 foo nostromo 16:38 /tmp % cp -pR foo barnostromo 16:38 cp: cannot open `foo' for reading: Permission non accordée and this: src/am/tests % make check TESTS=install2.testnostromo 16:39 make check-TESTS make[1]: Entering directory `/mnt/nostromo/home/lrde/prof/akim/src/am/tests' PASS: install2.test == All 1 tests passed == make[1]: Leaving directory `/mnt/nostromo/home/lrde/prof/akim/src/am/tests' src/am/tests % ls testSubDir/foo-0.1 nostromo 16:39 src/am/tests % nostromo 16:39
Fail: install2.test
Problem with install2.test
Here is the output from "make check TESTS='install2.test' VERBOSE=yes
---
Making check in .
make[1]: Entering directory `/usr/src/automake'
make[1]: Nothing to be done for `check-am'.
make[1]: Leaving directory `/usr/src/automake'
Making check in m4
make[1]: Entering directory `/usr/src/automake/m4'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/usr/src/automake/m4'
Making check in tests
make[1]: Entering directory `/usr/src/automake/tests'
make check-TESTS
make[2]: Entering directory `/usr/src/automake/tests'
=== Running test ./install2.test
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
configure: creating ./config.status
config.status: creating Makefile
make[3]: Entering directory `/usr/src/automake/tests/testSubDir'
chmod -R a+w foo-0.1 > /dev/null 2>&1; rm -rf foo-0.1
mkdir foo-0.1
for subdir in .; do \
if test "$subdir" = .; then :; else \
test -d foo-0.1/$subdir \
|| mkdir foo-0.1/$subdir \
|| exit 1; \
(cd $subdir && \
make top_distdir=../foo-0.1 distdir=../foo-0.1/$subdir distdir) \
|| exit 1; \
fi; \
done
find foo-0.1 -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec /bin/sh ./install-sh -c -m a+r {} {} \; \
|| chmod -R a+r foo-0.1
/bin/sh /usr/src/automake/tests/testSubDir/missing --run tar chof - foo-0.1 |
GZIP=--best gzip -c > foo-0.1.tar.gz
chmod -R a+w foo-0.1 > /dev/null 2>&1; rm -rf foo-0.1
make[3]: Leaving directory `/usr/src/automake/tests/testSubDir'
FAIL: install2.test
===
1 of 1 tests failed
===
make[2]: Leaving directory `/usr/src/automake/tests'
make[1]: Leaving directory `/usr/src/automake/tests'
Stephen
---
Buyer's Guide for a Operating System:
Don't care to know: Mac
Don't mind knowing but not too much: Windows
Hit me! I can take it!: Linux
Re: ansi3.test
On 20 Feb 2001, Akim Demaille wrote: > Stephen Torri <[EMAIL PROTECTED]> writes: > > > On 20 Feb 2001, Akim Demaille wrote: > > > > > Huh??? What version of autoconf are you using? Could you try this? > > > > autoconf 2.94d > > You missed the second part of my request methinks, with the grep. > > Update your cvs copy of Autoconf, and I bet it will work. > Recompile the latest CVS and then ran the checks again. It past ansi3.test so I will assume we got it right. Thanks. Stephen --- Buyer's Guide for a Operating System: Don't care to know: Mac Don't mind knowing but not too much: Windows Hit me! I can take it!: Linux
Re: automake -vs- BSD make
> > I'm using BSD make here. That's the whole point of the exercise. > > Requiring GNU make doesn't make much sense IMHO. > > OK, sorry. So actually you skip the GNU Make test, right? Is it > possible to have some verbose output from BSD Make? There are two related options: -d and -V. See http://www.openbsd.org/cgi-bin/man.cgi?query=make&apropos=0&sektion=1&manpath=OpenBSD+Current&arch=i386&format=html
Re: ansi3.test
On 20 Feb 2001, Akim Demaille wrote:
> Huh??? What version of autoconf are you using? Could you try this?
autoconf 2.94d
> src/am/tests % make check TESTS=ansi3.test nostromo 15:45
---
Output of make check TESTS=ansi3.test VERBOSE=yes
---
Making check in .
make[1]: Entering directory `/usr/src/automake'
make[1]: Nothing to be done for `check-am'.
make[1]: Leaving directory `/usr/src/automake'
Making check in m4
make[1]: Entering directory `/usr/src/automake/m4'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/usr/src/automake/m4'
Making check in tests
make[1]: Entering directory `/usr/src/automake/tests'
make check-TESTS
make[2]: Entering directory `/usr/src/automake/tests'
=== Running test ./ansi3.test
Makefile.am:1: installing `./ansi2knr.c'
Makefile.am:1: installing `./ansi2knr.1'
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking for gcc... gcc
checking for object suffix... o
checking for executable suffix...
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for style of include used by make... #
checking dependency style of gcc... gcc
checking for gcc option to accept ANSI C... none needed
checking for function prototypes... yes
checking for ANSI C header files... yes
checking for string.h... yes
configure: creating ./config.status
config.status: creating Makefile
make[3]: Entering directory `/usr/src/automake/tests/testSubDir'
gcc -DPACKAGE=\"hello\" -DVERSION=\"0.23\" -DPROTOTYPES=1 -DSTDC_HEADERS=1
-DHAVE_STRING_H=1 -I. -I. -g -O2 -c ansi2knr.c
gcc -g -O2 @LDFLAGS@ -o ansi2knr ansi2knr.o
gcc: @LDFLAGS@: No such file or directory
make[3]: *** [ansi2knr] Error 1
make[3]: Leaving directory `/usr/src/automake/tests/testSubDir'
FAIL: ansi3.test
===
1 of 1 tests failed
===
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory `/usr/src/automake/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/usr/src/automake/tests'
make: *** [check-recursive] Error 1
Stephen
---
Buyer's Guide for a Operating System:
Don't care to know: Mac
Don't mind knowing but not too much: Windows
Hit me! I can take it!: Linux
Re: ansi3.test
Stephen Torri <[EMAIL PROTECTED]> writes: > On 20 Feb 2001, Akim Demaille wrote: > > > Huh??? What version of autoconf are you using? Could you try this? > > autoconf 2.94d You missed the second part of my request methinks, with the grep. Update your cvs copy of Autoconf, and I bet it will work.
Re: automake -vs- BSD make
Lars Hecking <[EMAIL PROTECTED]> writes: > > I'm surprised Make doesn't speak here. Reading the test files, GNU > > Make is required, and GNU Make is usually verbose. In my case I have: > > I'm using BSD make here. That's the whole point of the exercise. > Requiring GNU make doesn't make much sense IMHO. OK, sorry. So actually you skip the GNU Make test, right? Is it possible to have some verbose output from BSD Make?
Re: ansi3.test
Stephen Torri <[EMAIL PROTECTED]> writes:
> === Running test ./ansi3.test
> Makefile.am:1: installing `./ansi2knr.c'
> Makefile.am:1: installing `./ansi2knr.1'
> checking for a BSD compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for mawk... no
> checking for gawk... gawk
> checking whether make sets ${MAKE}... yes
> checking for gcc... gcc
> checking for object suffix... o
> checking for executable suffix...
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking how to run the C preprocessor... gcc -E
> checking for style of include used by make... #
> checking dependency style of gcc... gcc
> checking for gcc option to accept ANSI C... none needed
> checking for function prototypes... yes
> checking for ANSI C header files... yes
> checking for string.h... yes
> configure: creating ./config.status
> config.status: creating Makefile
> make[3]: Entering directory `/usr/src/automake/tests/testSubDir'
>
> gcc -DPACKAGE=\"hello\" -DVERSION=\"0.23\" -DPROTOTYPES=1 -DSTDC_HEADERS=1
> -DHAVE_STRING_H=1 -I. -I. -g -O2 -c ansi2knr.c
>
> gcc -g -O2 @LDFLAGS@ -o ansi2knr ansi2knr.o
> gcc: @LDFLAGS@: No such file or directory
Huh??? What version of autoconf are you using? Could you try this?
src/am/tests % make check TESTS=ansi3.test nostromo 15:45
make check-TESTS
make[1]: Entering directory `/mnt/nostromo/home/lrde/prof/akim/src/am/tests'
PASS: ansi3.test
==
All 1 tests passed
==
make[1]: Leaving directory `/mnt/nostromo/home/lrde/prof/akim/src/am/tests'
src/am/tests % grep LDFLAGS testSubDir/Makefile testSubDir/config.status
testSubDir/Makefile:LDFLAGS =
testSubDir/Makefile:hello_LDFLAGS =
testSubDir/Makefile:LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o
$@
testSubDir/Makefile:$(LINK) $(hello_LDFLAGS) $(hello_OBJECTS) $(hello_LDADD)
$(LIBS)
testSubDir/config.status:s%@LDFLAGS@%%g
> make[3]: *** [ansi2knr] Error 1
> make[3]: Leaving directory `/usr/src/automake/tests/testSubDir'
> FAIL: ansi3.test
Re: Errors compiling "make checks" on CVS automake.
Stephen Torri <[EMAIL PROTECTED]> writes: > gcc -g -O2 @LDFLAGS@ -o foo foo.o > gcc: @LDFLAGS@: No such file or directory You are most probably using a version of Autoconf before this patch: 2001-01-26 Akim Demaille <[EMAIL PROTECTED]> * aclang.m4: dnl AC_ARG_VAR's newline. (AC_PROG_CC, AC_PROG_F77, AC_PROG_CXX): AC_ARG_VAR(LDFLAGS). * acgeneral.m4 (AC_CHECK_LIB): Don't do it. and after this one: 2001-01-24 Akim Demaille <[EMAIL PROTECTED]> Don't AC_SUBST too much, as it makes Automake include those variables in Makefiles, and drives autoscan to require unneeded programs. * acgeneral.m4 (_AC_INIT_PREPARE): Don't AC_SUBST CFLAGS, CPPFLAGS, CXXFLAGS and LDFLAGS. (AC_ARG_VAR): AC_SUBST the var. Document it only once, even if there are several different docs. * aclang.m4 (AC_PROG_CPP): Declare CPP and CPPFLAGS to AC_ARG_VAR. (AC_PROG_CXXCPP): Declare CXXCPP and CPPFLAGS. While inter CVS version checks are definitely useful, please then be sure to use up to date version of all the tools. And state clearly your environment.
Re: automake -vs- BSD make
> I'm surprised Make doesn't speak here. Reading the test files, GNU > Make is required, and GNU Make is usually verbose. In my case I have: I'm using BSD make here. That's the whole point of the exercise. Requiring GNU make doesn't make much sense IMHO. > Could you > > srcdir=. VERBOSE=yes sh -x ./target-cflags.test > > ? Will do.
Re: Errors compiling "make checks" on CVS automake.
On 20 Feb 2001, Akim Demaille wrote:
> Stephen Torri <[EMAIL PROTECTED]> writes:
>
> I personally observe no failure. Please, post the result of
>
> make check TESTS='ansi3.test install2.test pr87.test subobj3.test
> target-cfalgs.test' VERBOSE=yes
Here is the result: (long)
---
Making check in .
make[1]: Entering directory `/usr/src/automake'
make[1]: Nothing to be done for `check-am'.
make[1]: Leaving directory `/usr/src/automake'
Making check in m4
make[1]: Entering directory `/usr/src/automake/m4'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/usr/src/automake/m4'
Making check in tests
make[1]: Entering directory `/usr/src/automake/tests'
make check-TESTS
make[2]: Entering directory `/usr/src/automake/tests'
=== Running test ./ansi3.test
Makefile.am:1: installing `./ansi2knr.c'
Makefile.am:1: installing `./ansi2knr.1'
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking for gcc... gcc
checking for object suffix... o
checking for executable suffix...
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for style of include used by make... #
checking dependency style of gcc... gcc
checking for gcc option to accept ANSI C... none needed
checking for function prototypes... yes
checking for ANSI C header files... yes
checking for string.h... yes
configure: creating ./config.status
config.status: creating Makefile
make[3]: Entering directory `/usr/src/automake/tests/testSubDir'
gcc -DPACKAGE=\"hello\" -DVERSION=\"0.23\" -DPROTOTYPES=1 -DSTDC_HEADERS=1
-DHAVE_STRING_H=1 -I. -I. -g -O2 -c ansi2knr.c
gcc -g -O2 @LDFLAGS@ -o ansi2knr ansi2knr.o
gcc: @LDFLAGS@: No such file or directory
make[3]: *** [ansi2knr] Error 1
make[3]: Leaving directory `/usr/src/automake/tests/testSubDir'
FAIL: ansi3.test
=== Running test ./install2.test
automake: configure.in: installing `./install-sh'
automake: configure.in: installing `./mkinstalldirs'
automake: configure.in: installing `./missing'
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
configure: creating ./config.status
config.status: creating Makefile
make[3]: Entering directory `/usr/src/automake/tests/testSubDir'
chmod -R a+w foo-0.1 > /dev/null 2>&1; rm -rf foo-0.1
mkdir foo-0.1
for subdir in .; do \
if test "$subdir" = .; then :; else \
test -d foo-0.1/$subdir \
|| mkdir foo-0.1/$subdir \
|| exit 1; \
(cd $subdir && \
make top_distdir=../foo-0.1 distdir=../foo-0.1/$subdir distdir) \
|| exit 1; \
fi; \
done
find foo-0.1 -type d ! -perm -777 -exec chmod a+rwx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec /bin/sh ./install-sh -c -m a+r {} {} \; \
|| chmod -R a+r foo-0.1
/bin/sh /usr/src/automake/tests/testSubDir/missing --run tar chof -
foo-0.1 | GZIP=--best gzip -c > foo-0.1.tar.gz
chmod -R a+w foo-0.1 > /dev/null 2>&1; rm -rf foo-0.1
make[3]: Leaving directory `/usr/src/automake/tests/testSubDir'
FAIL: install2.test
=== Running test ./pr87.test
automake: configure.in: installing `./install-sh'
automake: configure.in: installing `./mkinstalldirs'
automake: configure.in: installing `./missing'
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking for gcc... gcc
checking for object suffix... o
checking for executable suffix...
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for style of include used by make... #
checking dependency style of gcc... gcc
configure: creating ./config.status
config.status: creating Makefile
config.status: creating foo/Makefile
config.status: creating bar/Makefile
make[3]: Entering directory `/usr/src/automake/tests/testSubDir/build'
chmod -R a+w test_am-1.0 > /dev/null 2>&1; rm -rf test_am-1.0
mkdir test_am-1.0
for subdir in foo bar; do \
if test "$subdir" = .; then :; else \
test -d test_am-1.0/$subdir \
|| mkdir test_am-1.0/$subdir \
|| exit 1; \
(cd $subdir && \
make top_distdir=../test_am-1.0 distdir=../test_am-1.0/$subdir distdir) \
|| exit 1; \
fi; \
done
make[4]: Entering directory `/usr/src/automake/tests/testSubDir/build/foo'
make[4]: Leaving directory `/usr/src/
Re: automake -vs- BSD make
Lars Hecking <[EMAIL PROTECTED]> writes:
> === Running test ./target-cflags.test
> automake: Makefile.am: installing `./compile'
> creating cache ./config.cache
[...]
> creating ./config.status
> creating Makefile
> gcc -DPACKAGE=\"target-cflags\" -DVERSION=\"0.0\" -I. -I..-DFOO -g -O2 -c -o
>foo-foo.o `test -f foo.c || echo '../'`foo.c
> gcc -g -O2 -o foo foo-foo.o
> gcc -DPACKAGE=\"target-cflags\" -DVERSION=\"0.0\" -I. -I.. -g -O2 -c ../bar.c
> gcc -g -O2 -o bar bar.o
I'm surprised Make doesn't speak here. Reading the test files, GNU
Make is required, and GNU Make is usually verbose. In my case I have:
config.status: creating Makefile
make[3]: Entering directory
`/mnt/nostromo/home/lrde/prof/akim/src/am/tests/testSubDir/obj'
gcc -DPACKAGE=\"target-cflags\" -DVERSION=\"0.0\" -I. -I..-DFOO -g -O2 -c -o
foo-foo.o `test -f foo.c || echo '../'`foo.c
gcc -g -O2 -o foo foo-foo.o
gcc -DPACKAGE=\"target-cflags\" -DVERSION=\"0.0\" -I. -I.. -g -O2 -c ../bar.c
gcc -g -O2 -o bar bar.o
make[3]: Leaving directory
`/mnt/nostromo/home/lrde/prof/akim/src/am/tests/testSubDir/obj'
Could you
srcdir=. VERBOSE=yes sh -x ./target-cflags.test
?
> creating cache ./config.cache
[...]
> creating Makefile
> ./target-cflags.test[51]: ./foo: not found
Hm, in my case something is rebuilt.
Maybe this version of the file would make it easier to track
#! /bin/sh
# Test to make sure target specific CFLAGS work
# Assar Westerlund <[EMAIL PROTECTED]>
. $srcdir/defs || exit 1
cat > configure.in << 'END'
AC_INIT(foo.c)
AM_INIT_AUTOMAKE(target-cflags,0.0)
AC_PROG_CC
AC_OUTPUT(Makefile)
END
cat > Makefile.am << 'END'
AUTOMAKE_OPTIONS = foreign no-dependencies
bin_PROGRAMS = foo bar
foo_CFLAGS = -DFOO
END
cat > foo.c << 'END'
#include
#ifdef FOO
int main(void) {
return 0;
}
#endif
END
cat > bar.c << 'END'
#ifndef FOO
int main(void)
{
return 0;
}
#endif
END
# Fail gracefully if no autoconf.
$needs_autoconf
# Likewise for gcc.
(gcc -v) > /dev/null 2>&1 || exit 77
# Likewise for GNU make.
($MAKE --version) > /dev/null 2>&1 || exit 77
set -e
$ACLOCAL
$AUTOCONF
$AUTOMAKE -a
mkdir obj
(
cd obj
../configure
$MAKE
/foo
./bar
)
./configure
$MAKE
./foo
./bar
Re: automake -vs- BSD make
[Sorry, should've posted this to the list sooner. The system is OpenBSD 2.8
m68k (amiga). If necessary, I can try the same on i386.
This was automake-1.4c, but 1.4e has the same problems.]
Tom Tromey writes:
> Could you run this and send me the output?
>
> make TESTS='pr19.test target-cflags.test' VERBOSE=t check
Sure. But I must say that I find the output rather inconclusive :-/
$ make check TESTS='pr19.test target-cflags.test' VERBOSE=t
Making check in .
Making check in m4
Making check in tests
make check-TESTS
=== Running test ./pr19.test
automake: configure.in: installing `./install-sh'
automake: configure.in: installing `./mkinstalldirs'
automake: configure.in: installing `./missing'
automake: configure.in: installing `./depcomp'
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... no
checking for nawk... nawk
checking whether make sets ${MAKE}... yes
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
ing dependency style of gcc... gcc
checking for flex... flex
checking for flex... (cached) flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... yes
checking for bison... no
checking for byacc... no
updating cache ./config.cache
creating ./config.status
creating Makefile
flex foo.l && mv lex.yy.c foo.c
source='foo.c' object='foo.o' libtool=no depfile='.deps/foo.Po'
tmpdepfile='.deps/foo.TPo' depmode=gcc /bin/sh ./depcomp gcc
-DPACKAGE=\"am_lex_bug\" -DVERSION=\"0.1.1\" -DYYTEXT_POINTER=1 -I. -I. -g -O2 -c
-o foo.o `test -f foo.c || echo './'`foo.c
gcc -g -O2 -o foo foo.o -lfl
chmod -R a+w am_lex_bug-0.1.1 > /dev/null 2>&1; rm -rf am_lex_bug-0.1.1
mkdir am_lex_bug-0.1.1
find am_lex_bug-0.1.1 -type d ! -perm -777 -exec chmod a+rwx {} \; -o ! -type d !
-perm -444 -links 1 -exec chmod a+r {} \; -o ! -type d ! -perm -400 -exec chmod a+r
{} \; -o ! -type d ! -perm -444 -exec /bin/sh ./install-sh -c -m a+r {} {} \; ||
chmod -R a+r am_lex_bug-0.1.1
/bin/sh /tmp/automake-1.4c/tests/testSubDir/missing --run tar chof - am_lex_bug-0.1.1
| GZIP=--best gzip -c > am_lex_bug-0.1.1.tar.gz
chmod -R a+w am_lex_bug-0.1.1 > /dev/null 2>&1; rm -rf am_lex_bug-0.1.1
chmod -R a+w am_lex_bug-0.1.1 > /dev/null 2>&1; rm -rf am_lex_bug-0.1.1
GZIP=--best gunzip -c am_lex_bug-0.1.1.tar.gz | /bin/sh
/tmp/automake-1.4c/tests/testSubDir/missing --run tar xf -
chmod -R a-w am_lex_bug-0.1.1; chmod a+w am_lex_bug-0.1.1
mkdir am_lex_bug-0.1.1/=build
mkdir am_lex_bug-0.1.1/=inst
chmod a-w am_lex_bug-0.1.1
dc_install_base=`CDPATH=: && cd am_lex_bug-0.1.1/=inst && pwd` && cd
am_lex_bug-0.1.1/=build && ../configure --srcdir=.. --prefix=$dc_install_base &&
make && make dvi && make check && make install && make installcheck && make
uninstall && test `find $dc_install_base -type f -print | wc -l` -le 1 && make dist
&& make distclean && rm -f am_lex_bug-0.1.1.tar.gz && test `find . -type f -print
| wc -l` -eq 0
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... no
checking for nawk... nawk
checking whether make sets ${MAKE}... yes
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for style of include used by make... include
checking dependency style of gcc... gcc
checking for flex... flex
checking for flex... (cached) flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... yes
checking for bison... no
checking for byacc... no
updating cache ./config.cache
creating ./config.status
creating Makefile
flex ../foo.l && mv lex.yy.c foo.c
source='foo.c' object='foo.o' libtool=no depfile='.deps/foo.Po'
tmpdepfile='.deps/foo.TPo' depmode=gcc /bin/sh ../depcomp gcc
-DPACKAGE=\"am_lex_bug\" -DVERSION=\"0.1.1\" -DYYTEXT_POINTER=1 -I. -I.. -g -O2
-c -o foo.o `test -f foo.c || echo '../'`foo.c
gcc -g -O2 -o foo foo.o -lfl
chmod -R a+w am_lex_bug-0.1.1 > /dev/null 2>&1; rm -rf am_lex_bug-0.1.1
mkdir am_lex_bug-0.1.1
find am_lex_bug-0.1.1 -type d ! -perm -777 -exec chmod a+rwx {} \; -o ! -type d !
-perm -444 -links 1 -exec chmod a+r {} \; -o ! -type d ! -perm -400 -exec chmod a+r
{} \; -o ! -type d ! -perm -444 -exec /bin/sh .././install-sh -c -m a+r {} {} \; ||
chmod -R a+r am_lex_bug-0.1.1
/bin/sh /tmp/automake-1.4c/tests/testSubDi
Re: Errors compiling "make checks" on CVS automake.
Lars Hecking <[EMAIL PROTECTED]> writes: > target-cflags (note spelling) fails for me on OpenBSD as well. I > have already sent verbose output to Tom. I've found the related thread, but not your answer.
Re: Errors compiling "make checks" on CVS automake.
> I personally observe no failure. Please, post the result of > > make check TESTS='ansi3.test install2.test pr87.test subobj3.test >target-cfalgs.test' VERBOSE=yes target-cflags (note spelling) fails for me on OpenBSD as well. I have already sent verbose output to Tom.
Re: Errors compiling "make checks" on CVS automake.
Stephen Torri <[EMAIL PROTECTED]> writes: > Downloaded the latest automake from CVS. Running "make" went fine. Ran > "make check" and got five errors: > > ansi3.test > install2.test > pr87.test > subobj3.test > target-cfalgs.test > > New to automake so I cannot point out the exact problem. Willing to assist > any way I can. I personally observe no failure. Please, post the result of make check TESTS='ansi3.test install2.test pr87.test subobj3.test target-cfalgs.test' VERBOSE=yes Do you have a good compiler on your machine?
Errors compiling "make checks" on CVS automake.
Downloaded the latest automake from CVS. Running "make" went fine. Ran "make check" and got five errors: ansi3.test install2.test pr87.test subobj3.test target-cfalgs.test New to automake so I cannot point out the exact problem. Willing to assist any way I can. Stephen --- Buyer's Guide for a Operating System: Don't care to know: Mac Don't mind knowing but not too much: Windows Hit me! I can take it!: Linux
Re: Patch 1 of 4: Better DOS path support
"Tim Van Holder" <[EMAIL PROTECTED]> writes: > > suggest that your patch makes them uniform. And of course, the same > > as promoted by autoconf.texi :) > How do you mean, Akim? autoconf.texi doesn't say anything > about this... Or do you want me to add such an entry? Arg, sorry, I really thought there was some text about this issue in there. So yes, your proposal is gladly accepted :)
Re: Making a single library from multiple source directories
On Feb 19, 2001, Paul Martinolich <[EMAIL PROTECTED]> wrote:
> But now I have a situation in which, the library contains many
> different parts and contains a lot of source. What is the best
> way using automake to accomplish this?
CVS automake should support it just fine.
> Can libtool handle such a situation?
It's supposed to, yes.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: $ in source file names
On Feb 19, 2001, Robert Boehne <[EMAIL PROTECTED]> wrote:
> I attempted to build a test case which uses a file with a $ in
> the name.
> Is this not supported by Automake, or is it a bug?
The former, I think.
> If Automake doesn't support $ in source file names, then
> I would suggest that it isn't an important requirement for Libtool.
I disagree. libtool can be used independently from automake. And, in
fact, until libtool supports correctly file names containing `$' and
line-feeds, I won't be convinced we do the right thing regarding
single-evaluation of arguments.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
