Re: [revised patch 1/1] support AC_SUBST'able automake rules
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: Lars> Anyways, are the people that count looking into this patch? I'd Lars> prefer it if it was applied or rejected as soon as possible Lars> instead of waiting in the dark... What, and break the long automake tradition of getting email about your patch 8 months later? I assume you don't have automake paperwork filed. Do you? If not tell me and I will send you the form you have to fill out. Usually I'm less enthused about reading a patch unless I know the paperwork is in process. Sometimes it turns out that paperwork can't be filled out due to restrictive employers. Tom
Re: amtraces
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: >> > Ok, thanks. >> > This is definitely an automake bug. >> > Your proposed fix sounds ok to me. >> >> Patch included. Derek> Whoops. Here's the patch for real. This patch is still big enough that we need paperwork. Derek> Akim, what is the naming scheme you are using for patches. Derek> Should I be trying to use something similar? Akim usually uses a number and then a short description. You can do this if you like but there's no requirement. Tom
Re: unneeded spaces in automake rules?
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: Lars> Any point in these spaces? Nope. I checked this in. Please send a ChangeLog entry with your patches. Tom
Re: a bug, i guess ...
> "Oswald" == Oswald Buddenhagen <[EMAIL PROTECTED]> writes:
Oswald> { echo "configure: error: source directory already configured; run "make
distclean" there first" 1>&2; exit 1; }
Oswald> (note the " around "make distclean" - they should be \")
Thanks. Weirdly, nobody ever noticed this before.
I've checked in a fix.
Tom
Re: AM_INCLUDE is a bad name.
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: Pavel> I believe that names beginning with am_ are Pavel> private. I.e. AM_INCLUDE should become am_include. I believe Pavel> that user code should not do anything with the names beginning Pavel> with ac_ and am_. I chose `_am_' instead to make it even more obvious. Tom
Re: AM_INCLUDE is a bad name.
>> I'd like to also work out a naming scheme for internally generated >> targets. That way eventually it will be clear what people can rely >> on and what they cannot. Suggestions here are welcome. Alexandre> How 'bout `_am-target-name'? (note the leading underscore) Sounds good. I've updated HACKING. Tom
Re: automake (cvs 2001 Feb 6) incorrectly sees .o rule collision
> "Adam" == Adam J Richter <[EMAIL PROTECTED]> writes: Adam> EXTRA_PROGRAMS = typedefs Adam> EXTRA_typedefs_SOURCES = typedefs.l Adam> It produced the following error: Adam> automake: Makefile.am: object `typedefs.$(OBJEXT)' created by Adam> `typedefs.c' and ` This is intentional. You only specified EXTRA_typedefs_SOURCES for `typedefs'. But this means that the default .c file rule is invoked. Instead try adding `typedefs_SOURCES =' to Makefile.am. Then the warning goes away. Tom
Re: 27-fixsubdirs-am.patch
Tom> Note that the clean-am rules are run from the clean-recursive
Tom> rules in subdirs.am. That happens so that we can force the
Tom> ordering, and it is important. This is true for the ordinary
Tom> (all, install, etc) -recursive rules in subdirs.am as well.
Akim> !!!
Akim> Do we have specific tests? Are the rules written down
Akim> somewhere? Can't we imagine having some higher level construct
Akim> specifying the constraints over the ordering instead of relying
Akim> on the order in which things are processed?
I'm not sure I understand.
There are two problems here. One is that we tell users that they can
force the ordering by rearranging SUBDIRS. So this is a feature, and
we can't really just ditch it. The other problem is that arranging
the ordering any other way is complicated to implement, I think.
I don't see anything hugely wrong with the current approach here. It
took us a long time to get it to this point. Changes with subdir
processing should be approached with caution.
Akim> I have a question: sometimes I see `&defined_variable
Akim> ('SUBDIRS')', and sometimes $recursive_install, and I couldn't
Akim> determine the relationship between the two. Aren't they the
Akim> same?
I don't really remember $recursive_install :-(. Anyway it is set in
&handle_subdirs, which is called fairly late. We should probably
either ditch it, or rename it and set it very early in
&generate_makefile.
In the very long term I'd like to see automake move to a single
Makefile model. The idea is we'd have Makefile.am in each
subdirectory, as now, but we'd generate a single large Makefile.in
with complete cross-directory dependency information.
This would be a step towards my ideal build system, which,
unfortunately, cannot be implemented using `make'. My very very long
term goal is to eliminate make and automake and replace them with
something sensible.
Tom
Re: 25-clean-targets.patch
>> What you don't want to do is inline the actual rules. Akim> That's indeed what I was referring to. Well, I think. What Akim> were you thinking about? I did not think about parallel Akim> builds... The transformation above is what is now implemented. Akim> In fact, what I presented in the previous, both are implemented, Akim> it just depends on the input you give it. I don't understand. How are both of them implemented? I think we should transform this: clean: foo clean: bar into clean: foo bar ... and not inline the rules from `foo' and `bar' under `clean'. That way we preserve parallel builds (I admit that these are unlikely for `clean' -- but I imagine we're planning to use this same machinery elsewhere) as well as `make -k'. Akim> local $_ = "sub3\n"; Akim> so how about using $_ with caution? Just tell me your preference. My rule has been to try to use $_ only when it is obviously safe. I try not to assume it is preserved across function calls. So I think it is fine in something like &basename or &flatten, but not in a big loop in some function that isn't a `leaf'. Tom
Re: DIST_COMMON broke
Tom Tromey wrote: > > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > Derek> Also, looking at this area of the code reminds me that I sent > Derek> a, unfortunately largish, patch in something over a month ago > Derek> that hasn't been reviewed to my knowledge. The patch was > Derek> intended to fix a misplaced depcomp file (a bug which is still > Derek> present in the current CVS Automake, I might add), but I had > Derek> also ended up removing all the "special case '.'" bugs the code > Derek> is littered with FIXME comments about (especially around the > Derek> &require_file_* functions). > > Yeah, I still have a few of your patches sitting in my mailbox. Well, when you get around to it, this one should take the place of my last depcomp patch. I fixed tests/depcomp, tidied the ChangeLog based on the standards and practices Raja & Akim made me aware of, and merged the rest with the current CVS Autoconf. ChangeLog entry: * automake.in (require_file_with_conf_line, require_file_with_line, require_file): Pass a @require_file_path of $relative_dir instead of '.' to require_file_internal so that all the special casing of '.' can be removed elsewhere. (require_config_file, require_conf_file_with_line, require_conf_file_with_conf_line): Remove special casing for '.' and make sure $config_aux_dir is maintained properly. (require_file_internal): Remove special casing of '.' and set @require_file_path when missing files are added. (maybe_push_required_file): Remove special casing of '.' (handle_dependencies): Remove a workaround for a bug now fixed and remove $config_aux_dir special casing. (handle_configure): Remove special casing for $config_aux_dir (handle_python): Ditto. (yacc_lex_finish_helper): Change $config_aux_dir switch to switch on the value of $config_aux_dir_set_in_configure_in. (handle_texinfo): Ditto. (scan_one_configure_file): Set $config_aux_dir and $config_aux_dir_set_in_configure_in properly so special casing on the value of $config_aux_dir can be removed elsewhere. * tests/depcomp.test: New file. * tests/confsub.test: Look for depcomp in $(top_srcdir) instead of the first subdir containing a C file. * tests/libobj2.test: Ditto. * tests/Makefile.am (TESTS): Added 'depcomp.test'. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not aim for the head. I will not aim for the head. I will not aim for the head... - Bart Simpson on chalkboard, _The Simpsons_ Index: ChangeLog === RCS file: /cvs/automake/automake/ChangeLog,v retrieving revision 1.1001 diff -u -r1.1001 ChangeLog --- ChangeLog 2001/02/07 21:51:39 1.1001 +++ ChangeLog 2001/02/07 23:27:58 @@ -522,6 +522,35 @@ * automake.in (handle_ltlibraries): Allow _LDFLAGS to be conditionally defined. Fixes PR automake/77 and ldflags.test. +2000-12-05 Derek Price <[EMAIL PROTECTED]> + + * automake.in (require_file_with_conf_line, + require_file_with_line, require_file): Pass a @require_file_path + of $relative_dir instead of '.' to require_file_internal so that + all the special casing of '.' can be removed elsewhere. + (require_config_file, require_conf_file_with_line, + require_conf_file_with_conf_line): Remove special casing for '.' + and make sure $config_aux_dir is maintained properly. + (require_file_internal): Remove special casing of '.' and set + @require_file_path when missing files are added. + (maybe_push_required_file): Remove special casing of '.' + (handle_dependencies): Remove a workaround for a bug now fixed + and remove $config_aux_dir special casing. + (handle_configure): Remove special casing for $config_aux_dir + (handle_python): Ditto. + (yacc_lex_finish_helper): Change $config_aux_dir switch to + switch on the value of $config_aux_dir_set_in_configure_in. + (handle_texinfo): Ditto. + (scan_one_configure_file): Set $config_aux_dir and + $config_aux_dir_set_in_configure_in properly so special casing + on the value of $config_aux_dir can be removed elsewhere. + + * tests/depcomp.test: New file. + * tests/confsub.test: Look for depcomp in $(top_srcdir) instead of the + first subdir containing a C file. + * tests/libobj2.test: Ditto. + * tests/Makefile.am (TESTS): Added 'depcomp.test'. + 2000-11-25 Tom Tromey <[EMAIL PROTECTED]> * automake.in (file_contents_with_transform): Added file name and Index: automake.in === RCS file: /cvs/automake/automake/automake.in,v retrieving revi
Re: DIST_COMMON broke
Tom Tromey wrote: > > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > Derek> Also, looking at this area of the code reminds me that I sent > Derek> a, unfortunately largish, patch in something over a month ago > Derek> that hasn't been reviewed to my knowledge. The patch was > Derek> intended to fix a misplaced depcomp file (a bug which is still > Derek> present in the current CVS Automake, I might add), but I had > Derek> also ended up removing all the "special case '.'" bugs the code > Derek> is littered with FIXME comments about (especially around the > Derek> &require_file_* functions). > > Yeah, I still have a few of your patches sitting in my mailbox. > > We have to get the assignment stuff worked out. > I've been putting that off since I hate dealing with it. I got some preliminary email in that direction from Brian Youmans @gnu.org the other day. I filled out the email form and returned it. The original mail said that would get me the next set of forms, but I haven't seen them yet, nor, in fact, received any reply at all. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- For sale: One parachute. Never opened. Small stain.
Re: tests/ChangeLog
Pavel Roskin wrote: > On 7 Feb 2001, Tom Tromey wrote: > > > I've long considered it a mistake that tests/ChangeLog exists. I > > think it should be merged with the main ChangeLog. > > > > How about I rename tests/ChangeLog and we start putting entries into > > the toplevel ChangeLog? Any objections? > > No objections. > > In fact, by having two ChangeLogs GNU Automake "endorses" its users to use > this style. This should be fixed. Looks like you need to regenerate the Makefile.in - you broke make dist: [dprice@empress automake-clean]$ make dist chmod -R a+w automake-1.4c > /dev/null 2>&1; rm -rf automake-1.4c mkdir automake-1.4c /bin/sh ./mkinstalldirs automake-1.4c/. . for subdir in . m4 tests; do \ if test "$subdir" = .; then :; else \ test -d automake-1.4c/$subdir \ || mkdir automake-1.4c/$subdir \ || exit 1; \ (cd $subdir && \ make top_distdir=../automake-1.4c distdir=../automake-1.4c/$subdir distdir) \ || exit 1; \ fi; \ done make[1]: Entering directory `/home/dprice/work/automake-clean/m4' make[1]: Leaving directory `/home/dprice/work/automake-clean/m4' make[1]: Entering directory `/home/dprice/work/automake-clean/tests' make[1]: *** No rule to make target `ChangeLog', needed by `distdir'. Stop. make[1]: Leaving directory `/home/dprice/work/automake-clean/tests' make: *** [distdir] Error 1 Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not bring sheep to class. I will not bring sheep to class. I will not bring sheep to class... - Bart Simpson on chalkboard, _The Simpsons_
Re: DIST_COMMON broke
"Derek R. Price" wrote: > Tom Tromey wrote: > > > Derek> Checked in? Fixes? I'm not pulling any changes... > > > > I can't explain that. I've seen the commit message and everything. > > > > You aren't using the subversions automake are you? > > That is a mirror that doesn't update. > > Yeah, I am. Where is the other one? Nevermind. Found it from the Automake home page. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- 89. A day without sunshine is like, you know, night.
Re: DIST_COMMON broke
>> You aren't using the subversions automake are you? >> That is a mirror that doesn't update. Derek> Yeah, I am. Where is the other one? All the info is available via the home page. http://sources.redhat.com/automake/ Tom
Re: DIST_COMMON broke
Tom Tromey wrote: > Derek> Checked in? Fixes? I'm not pulling any changes... > > I can't explain that. I've seen the commit message and everything. > > You aren't using the subversions automake are you? > That is a mirror that doesn't update. Yeah, I am. Where is the other one? Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- 89. A day without sunshine is like, you know, night.
Re: DIST_COMMON broke
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: Derek> Also, looking at this area of the code reminds me that I sent Derek> a, unfortunately largish, patch in something over a month ago Derek> that hasn't been reviewed to my knowledge. The patch was Derek> intended to fix a misplaced depcomp file (a bug which is still Derek> present in the current CVS Automake, I might add), but I had Derek> also ended up removing all the "special case '.'" bugs the code Derek> is littered with FIXME comments about (especially around the Derek> &require_file_* functions). Yeah, I still have a few of your patches sitting in my mailbox. We have to get the assignment stuff worked out. I've been putting that off since I hate dealing with it. Tom
Re: DIST_COMMON broke
Derek> Checked in? Fixes? I'm not pulling any changes... I can't explain that. I've seen the commit message and everything. You aren't using the subversions automake are you? That is a mirror that doesn't update. Tom
Re: DIST_COMMON broke
Tom Tromey wrote:
> > "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
>
> >> I'm checking this in.
>
> Pavel> I'm sorry, but the bug seems to be yours. The new test fails
> Pavel> after automake.in changes from revision 1.848 to 1.849.
>
> Oh, I know it is mine..
>
> Pavel> In fact it says directly: "Don't push @inputs onto the dist list."
> Pavel> Not good. Many programs rely on that.
>
> It is more complicated than that. The &require_file_with_conf_line
> call sometimes pushes onto the dist list.
>
> This area still requires more work. I think I know another case where
> it can fail: suppose you do `AC_OUTPUT(subdir/foo)' where there is no
> Makefile.am in subdir? Then I think no rule to rebuild subdir/foo
> will be generated.
You're right. Here's a test for that too. Well, if you still want it, re
Pavel's recent email.
Just a note, some of the logic you just mentioned seems to be in
&maybe_push_required_file, but I haven't studied &require_file_internal long
enough to know what it's supposed to be doing.
Also, looking at this area of the code reminds me that I sent a,
unfortunately largish, patch in something over a month ago that hasn't been
reviewed to my knowledge. The patch was intended to fix a misplaced depcomp
file (a bug which is still present in the current CVS Automake, I might
add), but I had also ended up removing all the "special case '.'" bugs the
code is littered with FIXME comments about (especially around the
&require_file_* functions). I have only had to alter the patch once (well,
okay, so the test was also broken and I fixed that too), so far, to keep it
in sync with the CVS Automake, but with all the work going on lately this
might get worse. If somebody could review it and maybe check it in it would
be greatly appreciated. It cleans up a bunch of code. I'll include the new
patch in a subsequent email.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
If that plane leaves the ground and you're not with him, you'll regret it.
Maybe not today and maybe not tomorrow, but soon and for the rest of your life.
- Humphrey Bogart as Rick, _Casablanca_
#! /bin/sh
# A test for failure to include files and targets provided in AC_OUTPUT
# when the subdir doesn't contain a Makefile.am
. $srcdir/defs || exit 1
cat > configure.in << EOF
AM_INIT_AUTOMAKE(nonesuch, nonesuch)
AC_OUTPUT(subdir/bar \
Makefile)
EOF
: > Makefile.am
mkdir subdir
: > subdir/bar.in
$AUTOMAKE || exit 1
# verify bar.in
grep '^subdir/bar.in:' Makefile.in || exit 1
# yeah, so it eats _all_ the backslashes...
sed '/\\$/{N;s/\\.//g;}' testSubDir/Makefile.in \
|grep '^DIST_COMMON.*subdir/bar.in' Makefile.in || exit 1
exit 0
Re: DIST_COMMON broke
Tom Tromey wrote: > Anyway I wrote a test for the weird case and checked it in. > > I also checked in a fix for both the recent bugs in that area. I'm > afraid I'm not entirely sure why my fix fixes distcommon.test :-(. Checked in? Fixes? I'm not pulling any changes... Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- Travel advisories - Alaska: Tourists are warned to wear tiny bells on their clothing when hiking in bear country. The bells warn away MOST bears. Tourists are also cautioned to watch the ground on the trail, paying particular attention to bear droppings, to be alert for the presence of Grizzly Bears. One can tell Grizzly droppings by the tiny bells in them.
Re: DIST_COMMON broke
>> This area still requires more work. I think I know another case where >> it can fail: suppose you do `AC_OUTPUT(subdir/foo)' where there is no >> Makefile.am in subdir? Then I think no rule to rebuild subdir/foo >> will be generated. Pavel> I would not call it a "failure" - if Automake doesn't control that Pavel> directory then it shouldn't care. We already handle this scenario for AC_CONFIG_HEADER. I'm sure it is much more common there. Pavel> I don't like rules that rebuild something in a directory other Pavel> than "." and (in limited situations) $srcdir. Why not? Anyway I wrote a test for the weird case and checked it in. I also checked in a fix for both the recent bugs in that area. I'm afraid I'm not entirely sure why my fix fixes distcommon.test :-(. Tom
Re: tests/ChangeLog
On 7 Feb 2001, Tom Tromey wrote: > I've long considered it a mistake that tests/ChangeLog exists. I > think it should be merged with the main ChangeLog. > > How about I rename tests/ChangeLog and we start putting entries into > the toplevel ChangeLog? Any objections? No objections. In fact, by having two ChangeLogs GNU Automake "endorses" its users to use this style. This should be fixed. Regards, Pavel Roskin
Re: DIST_COMMON broke
> This area still requires more work. I think I know another case where > it can fail: suppose you do `AC_OUTPUT(subdir/foo)' where there is no > Makefile.am in subdir? Then I think no rule to rebuild subdir/foo > will be generated. I would not call it a "failure" - if Automake doesn't control that directory then it shouldn't care. I don't like rules that rebuild something in a directory other than "." and (in limited situations) $srcdir. Maybe my understanding is too primitive, I don't know. Regards, Pavel Roskin
tests/ChangeLog
I've long considered it a mistake that tests/ChangeLog exists. I think it should be merged with the main ChangeLog. How about I rename tests/ChangeLog and we start putting entries into the toplevel ChangeLog? Any objections? Tom
Re: DIST_COMMON broke
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes: >> I'm checking this in. Pavel> I'm sorry, but the bug seems to be yours. The new test fails Pavel> after automake.in changes from revision 1.848 to 1.849. Oh, I know it is mine.. Pavel> In fact it says directly: "Don't push @inputs onto the dist list." Pavel> Not good. Many programs rely on that. It is more complicated than that. The &require_file_with_conf_line call sometimes pushes onto the dist list. This area still requires more work. I think I know another case where it can fail: suppose you do `AC_OUTPUT(subdir/foo)' where there is no Makefile.am in subdir? Then I think no rule to rebuild subdir/foo will be generated. Tom
Re: DIST_COMMON broke
Hello, Tom! > Derek> I've attached a slightly more succinct test for the original > Derek> problem I pointed out (distcommon.test). It's nice as a > Derek> perquisite at least, as it doesn't require autoconf or make... > Derek> I'm not quite sure I understand the second problem you pointed > Derek> out. > > I'm checking this in. I'm sorry, but the bug seems to be yours. The new test fails after automake.in changes from revision 1.848 to 1.849. revision 1.849 date: 2001/02/04 03:27:52; author: tromey; state: Exp; lines: +27 -11 * automake.in (handle_configure): Don't modify variable which aliases list element. Don't push @inputs onto the dist list. Fixes colon7.test. (initialize_per_input) [dist_dirs]: New variable. (handle_dist_worker): Use global dist_dirs. (handle_configure): Set dist_dirs entries at toplevel. In fact it says directly: "Don't push @inputs onto the dist list." Not good. Many programs rely on that. Regards, Pavel Roskin
Re: DIST_COMMON broke
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: Derek> I've attached a slightly more succinct test for the original Derek> problem I pointed out (distcommon.test). It's nice as a Derek> perquisite at least, as it doesn't require autoconf or make... Derek> I'm not quite sure I understand the second problem you pointed Derek> out. I'm checking this in. Tom
Re: DIST_COMMON broke
Pavel Roskin wrote: > The new test fails exactly how it should. I'm going to apply it unless you > come with something better. Well, you should have seen my slightly more succinct version by now. I'd say check them both in, as there is some logic that says it'd be nice to be able to notice the failure without Autoconf & Make installed and some which says it's nice to have a test with a full follow through that might catch other related errors in the future. Maybe combing them makes the most sense? As long as the `exit 77` due to missing tools comes after the grep that terminates my test... Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- If a man speaks in the forest, and there is no woman around to hear him, is he still wrong?
Re: DIST_COMMON broke
Pavel Roskin wrote: > Hello, Derek! > > > > > Looks like someone broke the 'make dist' target in the last few days. > > I also noticed that. > > > > > Specifically, input files from AC_OUTPUT are no longer being added to > > > > DIST_COMMON... > > Exactly the same problem. > > > > Here's the patch. > > > > This doesn't appear to be the correct fix. I'll write the test case > > Tom just requested and see if I can't figure out anymore. > > How about this test (distdir2.test): I've attached a slightly more succinct test for the original problem I pointed out (distcommon.test). It's nice as a perquisite at least, as it doesn't require autoconf or make... I'm not quite sure I understand the second problem you pointed out. It turns out that the first fix I sent in actually works, but I think it is not the correct fix. It looks to me like require_file_with_conf_line is supposed to be calling maybe_push_required_file for these files but isn't for some reason. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I saw nothing unusual in the teacher's lounge. I saw nothing unusual in the teacher's lounge. I saw nothing unusual in the teacher's lounge... - Bart Simpson on chalkboard, _The Simpsons_ #! /bin/sh # A test for failure to include files provided in AC_OUTPUT into DIST_COMMON . $srcdir/defs || exit 1 cat > configure.in << EOF AM_INIT_AUTOMAKE(nonesuch, nonesuch) AC_OUTPUT(subdir/bar \ Makefile \ subdir/Makefile) EOF : > Makefile.am mkdir subdir : > subdir/Makefile.am : > subdir/bar.in $AUTOMAKE || exit 1 # verify bar.in grep 'DIST_COMMON.*bar.in' subdir/Makefile.in || exit 1 exit 0
Re: DIST_COMMON broke
Hello, Derek! > How about this test (distdir2.test): Oops, posted to early. Some sanity checks were missing. > It fails even earlier when it creates an empty archive on "make dist". > This seems to be another bug. Never mind. I just forgot to remove "missing". The new test fails exactly how it should. I'm going to apply it unless you come with something better. Regards, Pavel Roskin Index: tests/ChangeLog --- tests/ChangeLog +++ tests/ChangeLog @@ -1 +1,6 @@ +2001-02-07 Pavel Roskin <[EMAIL PROTECTED]> + + * distdir2.test: New test. + * Makefile.am (XFAIL_TESTS): Add distdir2.test. + 2001-02-04 Tom Tromey <[EMAIL PROTECTED]> Index: tests/Makefile.am --- tests/Makefile.am +++ tests/Makefile.am @@ -2,7 +2,7 @@ AUTOMAKE_OPTIONS = gnits -XFAIL_TESTS = +XFAIL_TESTS = distdir2.test TESTS =\ acinclude.test \ aclocal.test \ Index: tests/distdir2.test --- /dev/null +++ tests/distdir2.test @@ -0,0 +1,44 @@ +#! /bin/sh + +# Make sure that the templates of files that appear in configure.in +# are distributed. + +. $srcdir/defs || exit 1 + +cat > configure.in << 'END' +AC_INIT(foo) +AC_CONFIG_AUX_DIR(.) +AM_INIT_AUTOMAKE(distdir2, 0) +AC_OUTPUT([Makefile foo/Makefile foo/bar]) +END + +cat > Makefile.am <<'END' +SUBDIRS = foo +END + +mkdir foo + +cat > foo/Makefile.am <<'END' +noinst_SCRIPTS = bar +END + +touch foo/bar.in + +# Fail gracefully if no autoconf. +$needs_autoconf + +# Likewise for gcc. +(gcc -v) > /dev/null 2>&1 || exit 0 + +touch README NEWS AUTHORS ChangeLog + +# Remove some files installed by defs. These will be reinstalled by +# automake. +rm -f install-sh missing mkinstalldirs depcomp + +$ACLOCAL || exit 1 +$AUTOCONF || exit 1 +$AUTOMAKE -a || exit 1 +CC=gcc ./configure || exit 1 +$MAKE || exit 1 +$MAKE distcheck || exit 1
Re: DIST_COMMON broke
Hello, Derek! > > > Looks like someone broke the 'make dist' target in the last few days. I also noticed that. > > > Specifically, input files from AC_OUTPUT are no longer being added to > > > DIST_COMMON... Exactly the same problem. > > Here's the patch. > > This doesn't appear to be the correct fix. I'll write the test case > Tom just requested and see if I can't figure out anymore. How about this test (distdir2.test): __ #! /bin/sh # Make sure that the templates of files that appear in configure.in # are distributed. . $srcdir/defs || exit 1 cat > configure.in << 'END' AC_INIT(foo) AC_CONFIG_AUX_DIR(.) AM_INIT_AUTOMAKE(distdir2, 0) AC_OUTPUT([Makefile foo/Makefile foo/bar]) END cat > Makefile.am <<'END' SUBDIRS = foo END mkdir foo cat > foo/Makefile.am <<'END' noinst_SCRIPTS = bar END touch foo/bar.in $ACLOCAL || exit 1 $AUTOCONF || exit 1 $AUTOMAKE -a || exit 1 CC=gcc ./configure || exit 1 $MAKE || exit 1 $MAKE distcheck || exit 1 __ It fails even earlier when it creates an empty archive on "make dist". This seems to be another bug. Regards, Pavel Roskin
Re: DIST_COMMON broke
"Derek R. Price" wrote: > "Derek R. Price" wrote: > > > Looks like someone broke the 'make dist' target in the last few days. > > Specifically, input files from AC_OUTPUT are no longer being added to > > DIST_COMMON... > > Here's the patch. This doesn't appear to be the correct fix. I'll write the test case Tom just requested and see if I can't figure out anymore. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- 77. (D)inner not ready: (A)bort, (R)etry, (P)izza?
Re: 30-transform-cond.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> A very stupid and mechanic patch, indeed, but it helps me seeing what Akim> happens. In this patch I took the freedom of introducing a new Akim> syntax: @FOO@ means `to be substituted', while `?FOO?' means to be Akim> removed if positive, or to kill the line if negative, and conversely Akim> for `?!FOO?'. Akim> This patch includes the Makefile.ins' diffs, i.e., no changes. Umm, there are plenty of Makefile.in changes here. Some are whitespace changes, which I'd prefer not to change: Akim> - d=$(srcdir); \ Akim> + d=$(srcdir); \ Others are semantic changes: Akim> - f="`echo $$p | sed -e 's|^.*/||'`"; \ Akim> + f="$$p"; \ I do like the patch. But I'd like these things to be fixed before you check it in. Thanks, Tom
Re: 29-backname.patch
Akim> * automake.in: Various formatting changes, and modernization of Akim> Perl constructs. Akim> (&backname): New. Akim> (&handle_configure, define_standard_variables): Use it. Ok. Akim> - print "Copyright 2000 Free Software Foundation, Inc.\n"; Akim> + print "Copyright 2000, 2001 Free Software Foundation, Inc.\n"; Hmm... shouldn't we print all the copyright years here? And in aclocal? Tom
Re: include only in cvs-automake?
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes: Per> The Autotools book, the automake-1.4 manual, and the Per> automake-1.4/NEWS all imply that "include" is part of automake Per> 1.4. So how come it doesn't work, but when I try automake from Per> cvs it does work? Maybe it is a bug in the book. It's hard to remember 1.4 :-( Per> So what is it that is holding back a release of automake 1.5? Per> Are people in the middle of some major-write? Are there major Per> bugs in the cvs version that are not in 1.4? Mostly the delay is due to lack of confidence in the prereleases. Try 1.4b. It seems to work pretty well. I hope to release 1.4d fairly soon. I do want to get 1.5 out. Tom
Re: Q: Distributing config.h
> "David" == David Petrou <[EMAIL PROTECTED]> writes: David> include_HEADERS = pdl_config.h David> This seems to imply that config.h should _not_ be distributed, David> like I'm doing above. What's wrong with what I'm doing? If David> it's really so bad, how do I get around the problem that users David> of my library need things defined by configure? `includedir' is for system-independent headers. See the GNU coding standards. These days most people write a little `*-config' script (see, eg, gnome-config) which prints info required by a package. Or you could try to find a system-dependent place to install the header. Or you could just ignore the problem, but I advise against that. David> So, question #2: what's a good way to set the name and version David> of my software if I can't do it through AM_INIT_AUTOMAKE? How David> much will life suck if I make up new defines called David> PDL_VERSION, PDL_PACKAGE and not update the package and version David> information in AM_INIT_AUTOMAKE? If you do this then `make dist' won't work. Instead put this in configure.in: AM_INIT_AUTOMAKE(..., no-define) AC_DEFINE_UNQUOTED(PDL_VERSION, "$VERSION") AC_DEFINE_UNQUOTED(PDL_PACKAGE, "$PACKAGE") Then you still only have to update in one place. Tom
Re: DIST_COMMON broke
"Derek R. Price" wrote:
> Looks like someone broke the 'make dist' target in the last few days.
> Specifically, input files from AC_OUTPUT are no longer being added to
> DIST_COMMON...
Here's the patch.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
I am not a 32 year old woman.
I am not a 32 year old woman.
I am not a 32 year old woman...
- Bart Simpson on chalkboard, _The Simpsons_
Index: ChangeLog
===
RCS file: /cvs/automake/ChangeLog,v
retrieving revision 1.999
diff -u -r1.999 ChangeLog
--- ChangeLog 2001/02/06 15:10:35 1.999
+++ ChangeLog 2001/02/07 18:07:01
@@ -1,3 +1,8 @@
+2001-02-07 Derek Price <[EMAIL PROTECTED]>
+
+ * automake.in (handle_configure): make sure AC_CONFIG_FILES input files
+ get distributed
+
2001-02-06 Pavel Roskin <[EMAIL PROTECTED]>
* automake.in (handle_dependencies): Rename AM_INCLUDE to
Index: automake.in
===
RCS file: /cvs/automake/automake.in,v
retrieving revision 1.865
diff -u -r1.865 automake.in
--- automake.in 2001/02/06 15:03:58 1.865
+++ automake.in 2001/02/07 18:07:05
@@ -3514,6 +3514,12 @@
# Require all input files.
&require_file_with_conf_line ($ac_output_line, $FOREIGN,
&rewrite_inputs_into_dependencies (0, @inputs));
+
+ # input files also need to be distributed
+ foreach (@inputs)
+ {
+ &maybe_push_required_file(&dirname($_), &basename($_), $_);
+ }
}
# These files get removed by "make clean".
Re: AM_INCLUDE is a bad name.
Hello, Akim! > Under this condition, I will definitely quit the group. I'm OK with > providing reasonable backward compatibility, but I'm tired (to remain > somewhat polite) of wasting my time in details of the past. You are missing the point completely. Nobody is asking _you_ to care about backward compatibility. I know, it's really hard if you want to make radical changes. The point is that we should allow other people (be it maintainers of Libtool or GTK+ or NCurses) to provide macros compatible with more that one version of Autoconf if: 1) They are under pressure to do it. 2) They manage to do it correctly (which may be impossible, but _we_ shouldn't care too much). The alternatives are: 1) ifdef - may be obsoleted in the future by m4_ifdef 2) Providing different macro files for different versions of autoconf - really ugly. 3) Switching everybody to the next version of Autoconf. This is a major headache for the projects as big as GNOME. > I am *not* interested in helping obsolescent users, I'm interested in It is not about you helping obsolescent users. It is about allowing other people help them. I don't want to force any changes against your will. If you don't change you mind I don't want to push this idea. "ifdef" works for me. Regards, Pavel Roskin
Re: AM_INCLUDE is a bad name.
Alexandre Oliva <[EMAIL PROTECTED]> writes: > On Feb 7, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote: > > > I am referring to other applications depending upon Autoconf such as > > Automake, for which it is perfectly reasonable to require a version of > > Autoconf which is released. > > But I disagree it's perfectly reasonable to require the latest > released version of autoconf just because we can. For a long time, > automake was still tested with Perl 4, just because it could support > Perl 4, without forcing its users to upgrade. However, as soon as > autoconf 2.50 is available (or even earlier), automake may want to use > its new features. AC_VERSION_CASE would be a good thing in this case. > Ditto for libtool. And for any other tool that wants to impose as > little as possible onto its users. Sorry, but I strongly disagree, and I think there is just no point in discussing about it, we will never agree. Given your point of view, I see no interest at all in implementing trace support in Automake if it is still to deal with users who don't want to upgrade. Under this condition, I will definitely quit the group. I'm OK with providing reasonable backward compatibility, but I'm tired (to remain somewhat polite) of wasting my time in details of the past. I am *not* interested in helping obsolescent users, I'm interested in providing better, simpler tools. If that's not the deal here, then fine, I quit. And you know this not a threat, this is just my point of view. If my conditions are not accepted, then it's simple, I have nothing to do here.
unneeded spaces in automake rules?
Any point in these spaces? Lars J Index: data.am === RCS file: /cvs/automake/automake/data.am,v retrieving revision 1.26 diff -u -r1.26 data.am --- data.am 2000/10/16 09:01:36 1.26 +++ data.am 2001/02/07 16:23:17 @@ -21,7 +21,7 @@ ## Funny invocation because Makefile variable can be empty, leading to ## a syntax error in sh. @list='$(@DIR@_DATA)'; for p in $$list; do \ - if test -f "$$p"; then d= ; else d="$(srcdir)/"; fi; \ + if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ ## If the _DATA variable has an entry like foo/bar, install it as ## $(destdir)/bar, not $(destdir)/foo/bar. The user can always make a ## new dir variable for the latter case. Index: header.am === RCS file: /cvs/automake/automake/header.am,v retrieving revision 1.26 diff -u -r1.26 header.am --- header.am 2001/02/04 04:43:11 1.26 +++ header.am 2001/02/07 16:23:17 @@ -22,7 +22,7 @@ ## a syntax error in sh. @list='$(@DIR@_HEADERS)'; for p in $$list; do \ ## A header file can be in the source directory or the build directory. - if test -f "$$p"; then d= ; else d="$(srcdir)/"; fi; \ + if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ BASE f="`echo $$p | sed -e 's|^.*/||'`"; \ NOBASE f="$$p"; \ echo " $(INSTALL_HEADER) $$d$$p $(DESTDIR)$(@NDIR@dir)/$$f"; \ Index: lisp.am === RCS file: /cvs/automake/automake/lisp.am,v retrieving revision 1.17 diff -u -r1.17 lisp.am --- lisp.am 2000/10/16 09:01:36 1.17 +++ lisp.am 2001/02/07 16:23:17 @@ -22,7 +22,7 @@ ## a syntax error in sh. @list='$(@DIR@_LISP)'; for p in $$list; do \ ## A lisp file can be in the source directory or the build directory. - if test -f "$$p"; then d= ; else d="$(srcdir)/"; fi; \ + if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ BASE f="`echo $$p | sed -e 's|^.*/||'`"; \ NOBASE f="$$p"; \ echo " $(INSTALL_DATA) $$d$$p $(DESTDIR)$(@NDIR@dir)/$$f"; \
Re: AM_INCLUDE is a bad name.
On Feb 7, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote:
> I am referring to other applications depending upon Autoconf such as
> Automake, for which it is perfectly reasonable to require a version of
> Autoconf which is released.
But I disagree it's perfectly reasonable to require the latest
released version of autoconf just because we can. For a long time,
automake was still tested with Perl 4, just because it could support
Perl 4, without forcing its users to upgrade. However, as soon as
autoconf 2.50 is available (or even earlier), automake may want to use
its new features. AC_VERSION_CASE would be a good thing in this case.
Ditto for libtool. And for any other tool that wants to impose as
little as possible onto its users.
--
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: AM_INCLUDE is a bad name.
Alexandre Oliva <[EMAIL PROTECTED]> writes: > On Feb 6, 2001, Akim Demaille <[EMAIL PROTECTED]> wrote: > > > Don't go that way! AC_PREREQ. > > It won't let you define fallbacks for older releases, which is exactly > the point. ifdef, as you proposed, is the way to go. I think there is some confusion on what we are discussing about. I am referring to other applications depending upon Autoconf such as Automake, for which it is perfectly reasonable to require a version of Autoconf which is released. In this case AC_PREREQ is just what we want, and we don't want to play with tests on the version numbers. You require a version, and if nonetheless you need some specific macro of the bleeding edge Autoconf, then ifdef is good. That's why I'm referring to the pair AC_PREREQ/ifdef. As far as individual tools are concerned, they just have to provide backward compatibility, that's for sure.
Re: autotools + MSVC
On Feb 7, 2001, Geoffrey Wossum <[EMAIL PROTECTED]> wrote:
> Command line error D2021 : invalid numeric argument '/Wp,-MD,.deps/applicationpr
> I'm using automake 1.4
automake 1.4's ``development'' Makefiles (i.e., those you get before
`make dist' or `automake -i') require GNU make and GCC. CVS
automake's don't.
--
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
