Re: symlinked files break dist-target
Alexandre Oliva [EMAIL PROTECTED] writes: On May 2, 2001, Felix Natter [EMAIL PROTECTED] wrote: I have some source-files which are shared between some autoconf/automake- projects. So I use symlinks in my projects. But using automake, this breaks the dist-target (make dist). I can't see why symlinks would break `make dist'. What is the symptom? I created a minimal hello-world-package for this: http://www.ndh.net/home/natter/hello-1.0.tar.gz the problem does not occur if the symlink simply points to a directory one level up: hello.c - ../hello.c works, but hello.c - ../util/hello.c does not. untar this, move hello.c to ../util and create a symlink for it: $ cd /tmp $ tar -xzf hello-1.0.tar.gz $ cd hello-1.0 $ mkdir /tmp/util $ mv hello.c ../util $ ln -s ../util/hello.c $ ./configure $ make dist Furthermore, the dist-target usually uses gtar, although I only have /bin/tar. Is there a way to detect $(TAR) ? thanks, -- Felix Natter
Re: @_am_quote@ not replaced by 'configure'
Robert == Robert Boehne [EMAIL PROTECTED] writes: Robert On a related note, I wonder if it would be reasonable to add a Robert test case to Automake similar to the style that Libtool uses. Robert A test that actually compiles code and attempted to use Robert dependencies, invoke libtool, etc. would help find these Robert problems before they get checked in. The test could simply be Robert skipped if there is no C/C++/F77/? compiler found. I would Robert be more than happy to contribute the test as well. Any Robert thoughts? Sounds good to me. We already have some tests along these lines, though maybe none explicitly test dependency tracking. Robert The way I look at this is that a real-world test case will Robert help catch more bugs before they make it into the cvs Robert repository, but I also understand that keeping the testsuite Robert short and simple is a concern too. So where do the Robert maintainers draw this line? The test suite really exists to try to help us release a non-buggy automake. While it sucks if it takes a long time to run, my first concern is for its usefulness. So in general I never draw this line: I just add a test whenever it would help. Tom
Re: Bad dependencies generation
Paul == Paul F Kunz [EMAIL PROTECTED] writes: Paul To answer my own question about bad dependency generation with Paul the combination of Red Hat 7.1beta, gcc 2.96, and Paul autoconf/automake released version. It is gcc 2.96 causing the Paul problem, as it went away after installing gcc 2.95.3. I'm still running Red Hat 6.2, not 7.x. Could you tell me exactly what went wrong? Red Hat 7 will be around for a while still. I'd like to make sure that depcomp can support the gcc it includes. Tom
Re: patch: missing uninstall-am target breaks non-gnu make
Robert == Robert Collins [EMAIL PROTECTED] writes: Robert This is just a patch for the fix suggested to me. Robert + 'uninstall-am' =3D 1,=0A= I checked this in. Thanks. Tom
Re: More CVS head errors
Robert == Robert Collins [EMAIL PROTECTED] writes: Robert I'm currently having to distribute two patches for automake to Robert achieve the pass on make distcheck - the openbsd install-am Robert target, and the workaround I put together for subobj5.test. If Robert you guys have some idea of the timeframe for a formal fix to Robert both of those I'd appreciate knowing it. (Not to keep you to Robert it, but for planning purposes). I just checked in your fix for the first. I don't remember the subobj5 bug or fix. I'm sure it is still here in my automake mailbox somewhere. I'm afraid I'm the bottleneck right now, and I'm unpredictable :-( Tom
Re: register_language() ?
Pavel == Pavel Roskin [EMAIL PROTECTED] writes: Pavel Applied after a short fight with CVS. The version you are using Pavel on sourceware.cygnus.com tends to commit only some of the files Pavel in a single run (either only those from the current directory Pavel or all files except those from the current directory). I've never seen this. Pavel The CVS on sourceware.cygnus.com must be very old since it has Pavel another bug that I fixed almost 2 years ago: It is. Upgrading it is hard since it has a largish custom performance patch in it. (This is the file attributes patch Ian Taylor wrote.) Our experience has been that this patch really does help performance, but unfortunately no one has ever tried to get it incorporated into the main line of cvs :-(. Tom
Re: PATCH: subdirs and conditionals
Richard == Richard Boulton [EMAIL PROTECTED] writes: Richard The gstreamer project, however, has a Makefile.am with Richard conditionals for each of a set of conditions dictating which Richard SUBDIRS are to be built. The file currently has 16 separate Richard conditionally defined variables (and will have more soon), Richard used only in the SUBDIRS variable. How do you define SUBDIRS? Richard The attached patch avoids computing the list of conditionals Richard for the SUBDIRS variable, where it is not actually needed, if Richard the DIST_SUBDIRS variable is defined. Thanks, I'm checking this in. Please send a ChangeLog entry with patches. Tom
Re: Warning fix for automake on CVS Libtool
Pavel == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel * automake.in (scan_texinfo_file): Don't push undefined values
Pavel to @clean_suffixes.
Pavel -push @clean_suffixes, $predefined_index{$1};
Pavel +push @clean_suffixes, $predefined_index{$1}
Pavel + if (defined $predefined_index{$1});
I think any possible value here is already defined.
So the `if' is not required.
Maybe this was fixed after you sent your patch? I don't see anything
in the ChangeLog though.
Pavel -push @clean_suffixes, $hidden_index{$1};
Pavel +push @clean_suffixes, $hidden_index{$1}
Pavel + if (defined $hidden_index{$1});
I think this is actually ok.
Akim, I notice that while @defcodeindex is handled, @defindex is not.
Is that intentional, or just an oversight?
Tom
Re: $MAKE and ansi.test
Patrick == Patrick Welche [EMAIL PROTECTED] writes:
Patrick From configure:
Patrick checking whether make sets ${MAKE}... (cached) yes
This means that make sets the make variable `MAKE'...
Patrick From defs:
Patrick # User can set MAKE to choose which make to use. Must use GNU make.
Patrick test -z $MAKE MAKE=make
Patrick Ah - maybe its because defs is a shell script.. and make
Patrick doesn't necessarily export ${MAKE}?
Yeah. make might not necessarily set the environment variable MAKE.
Tom
Re: symlinked files break dist-target
Felix == Felix Natter [EMAIL PROTECTED] writes: Felix I created a minimal hello-world-package for this: Felix http://www.ndh.net/home/natter/hello-1.0.tar.gz Congratulations -- you found a `make dist' oddity that we never considered. The problem is that by default we use `ln' to make the dist tree. But `ln' isn't exactly like `cp' (or `ln -s' -- which we used to use but got rid of due to other problems, as I recall) when working on symlinks. If there was a portable way to test for the presence of a symlink we could use that in the distdir rule. But right now I think we have two choices: 1. Always use `cp' 2. Disallow what you are trying to do. I'm inclined to #2. Good performance in `distdir' seems to be a popular choice. Also relative symlinks that point outside the package don't seem to be an important thing to support. However, as always, I'm open to arguments for #1, or other solutions I haven't considered. Felix Furthermore, the dist-target usually uses gtar, although I only Felix have /bin/tar. Is there a way to detect $(TAR) ? AM_INIT_AUTOMAKE should be doing that already. Why does it detect gtar when you don't have it? Tom
Re: --add-missing broken
Akim == Akim Demaille [EMAIL PROTECTED] writes: Ralf == Ralf Corsepius [EMAIL PROTECTED] writes: Ralf Related question: Which directory is am_dir/--am-dir supposed to Ralf point to, now? ../automake/ or ../automake/am? Akim Good question. No idea what Tom will prefer. AFAIC, a single Akim option is enough, and therefore /automake seems the right Akim answer. Maybe --libdir would sound better? I agree it should point to /automake. We can rename it if you really want to. It doesn't matter to me. This option is only for the test suite. Tom
Re: 97.5-merge-finish-languages-dependencies.patch (Was: 98-no-depend2.patch)
Akim == Akim Demaille [EMAIL PROTECTED] writes: Akim * automake.in (finish_languages): Rename as... Akim (handle_languages): this. Akim Include the body of... Akim (handle_dependency): this. Akim Remove. Ok. Tom
Re: 103-handle-languages-morphing-4.patch
Akim == Akim Demaille [EMAIL PROTECTED] writes: Akim * automake.in (handle_languages): Don't use $comp. Ok. Tom
Re: 104-handle-languages-morphing-5.patch
Akim == Akim Demaille [EMAIL PROTECTED] writes: Akim * automake.in (handle_languages): Compute `$ltoutarg' and Akim `$outarg' independently from dependency code. Akim There is no use looping on a language's possible extensions since Akim we loop over used extensions. Akim Therefore, there is no use for a local `%transform'. It has been hard for me to figure out what the patches preceding this one did. I'm guessing that we still include depend2 multiple times, but that the loop is not visible in this patch? I think this is ok. The important thing is that we understand that a given language can have multiple extensions in a single package, so we might have to emit rules more than once per language. Tom
Re: 107-handle-languages-morphing-7.patch
Akim == Akim Demaille [EMAIL PROTECTED] writes: Akim * automake.in (handle_languages): Don't transform %COMPILER%. Akim Use `$lang-compiler' instead of `$pfx' to transform generic Akim %COMPILE% and %LTCOMPILE%. Akim * ext-compile.am: Use %COMPILE%, %COMPILER% and %SOURCE% instead Akim of %COMPILER% and $. The last comment here is wrong -- it should mention LTCOMPILE and not COMPILER. This patch is ok. Tom
Re: 108-handle-languages-morphing-8.patch
Akim == Akim Demaille [EMAIL PROTECTED] writes: Akim * automake.in (Language): Replace the attribute `output_arg' with Akim `compile_flag' and `output_flag'. Akim (Automake): Adjust language registrations. Akim (handle_languages): Transform `-c' and `-o' for both suffix and Akim per object rules, instead of `OUTARG' and `LTOUTARG' only for Akim generic rules. Akim (handle_single_transform_list): Adjust to `compile_flag' and Akim `output_flag'. Akim * depend2.am, ext-compile.am: Use `%-c%' and `%-o%'. Ok. Tom
Re: 109-handle-languages-morphing-9.patch
Akim == Akim Demaille [EMAIL PROTECTED] writes: Akim * automake.in (handle_languages): `ext-compile.am' and Akim `depend2.am' are now equivalent for generic rules: output only the Akim latter. Akim * ext-compile.am: Remove. Ok. Tom
Re: 111-if-bang.patch
Akim == Akim Demaille [EMAIL PROTECTED] writes: Akim Support `if !COND', `else COND', `end COND'. Akim * automake.texi (Conditionals): Document it. Akim * automake.in ($WHITE_PATTERN, $MACRO_PATTERN, $BOGUS_MACRO_PATTERN) Akim ($GNITS_VERSION_PATTERN, $INCLUDE_PATTERN): Use `\d' and `\s'. Akim ($IF_PATTERN, $ELSE_PATTERN, $ENDIF_PATTERN): Likewise, and accept Akim a leading `!' before the condition. Akim (handle_options): Use `\d'. Akim (cond_stack_if, cond_stack_else, cond_stack_endif): New. Akim (read_am_file, file_contents_internal): Use them. Akim (transform): No longer substitute `%!COND%', forcing the use of Akim `! %?COND%'. Akim * ansi2knr.am, lex.am, tags.am, texinfos.am, yacc.am: Adjust. Ok. Could you update automake.texi to reflect this change? Tom
Re: 115-define-compiler-var.patch
Akim == Akim Demaille [EMAIL PROTECTED] writes: Akim * automake.in (define_compiler_variables): Use only $LANG as Akim argument. Akim (handle_languages): Adjust. Ok. Tom
Re: 116-language-link.patch
Akim == Akim Demaille [EMAIL PROTECTED] writes: Akim The goal is to handle LINK and the like just the way we handle Akim COMPILE and the like. First I have to understand completely Akim what's so special wrt C, but I'm confident we can reach Akim something generic and shorter (many lang_*_finish are likely to Akim be useless). I'm not sure what you mean by C being special. If you mean the `pure' stuff, then what has happened in the past is that people do weird things and still want the C support to appear. That is, C is special first because it has been convenient for it to be special. I don't have a particularly good example at hand. Akim * automake.in (Language): Add attribute `link'. Akim (register_language): Specify for cxx, objc, f77, gcj. Akim (lang_cxx_finish, lang_f77_finish, lang_objc_finish) Akim (lang_java_finish): Adjust. Ok. Tom
Re: 120-language-Name.patch
Akim == Akim Demaille [EMAIL PROTECTED] writes: Akim * automake.in (Language): Add attributes `Name' and `config_vars'. Akim (finish): Work properly if there is no _finish. Akim (Automake): Register language Names and AC_SUBST dependencies. Akim Register Fortran 77 variables upon which ratfor and ppf77 depend. Akim (handle_languages): Once per language, invoke Akim `define_linker_variables', and check its config_vars. Akim (lang_cxx_finish, lang_f77_finish, lang_objc_finish) Akim (lang_java_finish): Remove. Akim (lang_ppf77_finish, lang_ratfor_finish): Adjust. Ok. Tom I dislike this. This is a move away from encapsulation. The Tom objects, not the callers, ought to know what they are up to. Akim I don't understand too well. This is implemented in the Akim classes, not by the callers themselves. I.e., this code is in Akim Language, not Automake. Ok. I think I just meant that when languages are actual objects, the base language should have an empty finish method so that we don't have to conditionalize on the nonexistence of the method. Tom
Re: 123-file-contents-is-am.patch
Akim == Akim Demaille [EMAIL PROTECTED] writes: Akim * automake.in (file_contents_internal): Accept $IS_AM. Akim (handle_compile, define_standard_variables, file_contents): Akim Adjust. Ok. Tom
Re: 125-better-file-contents.patch
Akim == Akim Demaille [EMAIL PROTECTED] writes:
Akim Still getting closer to what Tom doesn't want: the read_am_file
Akim removal. I would be lying if I pretended that this removal was
Akim easy: pretty many weaknesses in file_contents weaknesses are
Akim uncovered by the test suite when you replace read_am_file with
Akim file_contents.
Akim But I'm very confident.
I'm still not. That's why I'm reluctant to look at 124- and 125-.
Akim More precisely, I have problems with keeping line numbers
Akim sync'ed in error messages. I understand fairly well this is a
Akim good service to provide to the user, but it's somewhat in
Akim opposition with the most (in my own definition of the word)
Akim natural implementation of file_contents.
I think it is crucial to give good line numbers in errors. People
find automake cryptic enough already. Giving incorrect line numbers
in errors will make this problem worse.
Akim ifeq (${APACHE_DIR_IS_SRC},yes)
Akim SUBDIRS = java
Akim else
Akim SUBDIRS = c java
Akim endif
I like your reasoning about this. However, does your plan of using
make_paragraphs work even if the user inserts whitespace? Suppose I
add a newline between each pair of lines in your example. Does the
paragraph separation still work? If not then it can't really be
considered reliable...
Akim verbatim
Akim ifeq (${APACHE_DIR_IS_SRC},yes)
Akim SUBDIRS = java
Akim else
Akim SUBDIRS = c java
Akim endif
Akim end verbatim
This is interesting. I wonder if users would expect automake not to
look at the contents of verbatim at all? E.g., in the above SUBDIRS
would be considered as not defined? That is easy from an
implementation point of view. But from the user's point of view it
might be painful.
Tom
Re: dist-all.patch
Akim == Akim Demaille [EMAIL PROTECTED] writes: Akim Quite straightforward (oh, how I love *.am only patches :). The Akim only question is whether we want to factor tar too or not. It's up to you. It doesn't matter to me. Akim * distdir.am (dist-all): Build all the flavors using a single Akim distdir. Ok. Tom
Re: automake debug output
Lars == Lars J Aas [EMAIL PROTECTED] writes: Lars When I run automake in certain projects, I get the below Lars attached output. It's been like this for a while (figured it Lars was a known issue that would soon get fixed), but now I suspect Lars that I'm the only one who gets them (they only come when I run Lars automake in the projects where I have multi- level entries in Lars $(SUBDIRS), and I might be the only one using that). Does Lars anyone know what the below messages are all about? Are you still seeing this problem? The code in automake.in looks different now. I assume the problem got fixed. Tom
Re: libtool 1.4: make uninstall broken?
Peter == Peter Eisentraut [EMAIL PROTECTED] writes: Peter The reason is that install-info is often installed under /sbin, Peter so it's not in the ordinary user's path. The install targets Peter work around this by not calling install-info in that case, Peter but uninstall does not. The rules in texinfos.am look like they both do the same thing regarding install-info. Peter Tom Tromey said to me something along the lines that uninstall Peter is of too little use to bother. It is true that I think uninstall is nearly useless. Peter A correct fix, in my mind, would be to add Autoconf checks for Peter install-info, possibly combined with missing support. At the Peter same time, vendors should be flamed not to install install-info Peter into sbin. Ordinary users can make perfectly good use of it. I'm not extremely interested in adding another check to every configure just to see if install-info is in /sbin. Traditionally you have to make sure your PATH is set correctly when building GNU packages. `missing' support would be doable, though what would it do other than ignore the call? Tom
Re: Warning fix for automake on CVS Libtool
Hi, Tom!
Pavel -push @clean_suffixes, $predefined_index{$1};
Pavel +push @clean_suffixes, $predefined_index{$1}
Pavel +if (defined $predefined_index{$1});
I think any possible value here is already defined.
So the `if' is not required.
The warnings were only from %hidden_index, but I was under impression that
some protection is needed here as well. I missed the [cfkvtp] part in
the regular expression. Sorry.
Pavel -push @clean_suffixes, $hidden_index{$1};
Pavel +push @clean_suffixes, $hidden_index{$1}
Pavel +if (defined $hidden_index{$1});
I think this is actually ok.
I tend to agree. Automake is not required to check texinfo files and warn
about their contents - other tools exist for that. Not cleaning few files
is not a big deal since correctness of make dist doesn't rely on
correctness of make distclean and the later is ensured by make
distcheck.
Akim, I notice that while @defcodeindex is handled, @defindex is not.
Is that intentional, or just an oversight?
From reading the documenation for texinfo it seems to be an oversight. The
difference between @defcodeindex and @defindex is purely cosmetical. The
save applies to @syncodeindex vs. @synindex.
Almost untested patch (in produces no warnings, that's all I know):
ChangeLog:
* automake.in (scan_texinfo_file): Consider @defindex and
@synindex in the same way as @defcodeindex and @syncodeindex
respectively.
___
--- automake.in
+++ automake.in
@@ -2601,9 +2601,9 @@
# Try to find what are the indexes which are used.
# Creating a new category of index.
- elsif (/^\@defcodeindex (\w+)/)
+ elsif (/^\@def(code)?index (\w+)/)
{
-push @clean_suffixes, $1;
+push @clean_suffixes, $2;
}
# Storing in a predefined index.
@@ -2618,9 +2618,9 @@
}
# Merging an index into an another.
- elsif (/^\@syncodeindex (\w+) \w+/)
+ elsif (/^\@syn(code)?index (\w+) \w+/)
{
- push @syncodeindexes, $1s;
+ push @syncodeindexes, $2s;
}
}
___
By the way, I discovered a terrible bug in CVS Automake while testing it -
make dvi doesn't propagate to the subdirectories.
--
Regards,
Pavel Roskin
Re: target dependency bug
Robert == Robert Collins [EMAIL PROTECTED] writes: Robert I understand. However Robert cf_gen.$(OBJEXT): cf_gen_defines.h Robert is somewhat ugly for an automake file :] I agree. Perhaps it would make sense to add a dependency like this in the dependency tracking allowed but disabled by the end user case? Tom
Re: crosscompiling dll linux-mingw32
On Saturday 05 May 2001 11:34 pm, Tom Tromey wrote: Gary == Gary V Vaughan [EMAIL PROTECTED] writes: Gary A short while before the libtool-1.4 release, Edward M. Lee Gary posted a joint patch to libtool and automake which takes care of Gary the worst of this sort of thing. I applied the libtool parts Gary before the release but the automake parts need some work first Gary IIRC. Hi Gary. Do you have a pointer to this patch? Hey Tom. Sure thing: http://mail.gnu.org/pipermail/automake/2001-March/007909.html Cheers, Gary. -- ___ _ ___ __ _mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
