On 2021-02-17, Leo Butler wrote:
> I cannot find DIST_COMMON documented in the automake manual[*]. Is this
> intended or an oversight?
Most likely intentional, this looks pretty internal to the "make dist"
machinery and not meant to be used directly by package authors.
> Look
Hello,
I cannot find DIST_COMMON documented in the automake manual[*]. Is this
intended or an oversight?
Looking at the automake perl script doesn't really enlighten me,
either.
I would like to know:
-what does DIST_COMMON contain by default?
-is it possible to set it or otherwise over-ri
ticular for MacOS X.
* Fixed handling of nobase_ targets.
* Fixed support of implicit rules leading to .lo objects.
+* Fixed late inclusion of --add-missing files (e.g. depcomp) in DIST_COMMON
New in 1.5:
* Support for `configure.ac'.
Index: automake.in
===
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> 2001-09-22 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
adl>Fix for distcommon2.test: * automake.in
adl> (automake_needs_to_reprocess_all_files): New variable. ("main"):
adl> Process all Makefiles a second time if
adl> $automa
Hello,
I've discovered some problem with depcomp file. If I haven't it in my
root and run automake --foreign -a, it will be created, but it will not
be listed in DIST_COMMON files of Makefile.in. As a result, it is
missing in distribution package and it cannot be successfully b
- Original Message -
From: "Raja R Harinath" <[EMAIL PROTECTED]>
>
> This doesn't look like it'll work with, say
>
> automake --add-missing src/Makefile
>
> This won't add 'depcomp' to DIST_COMMON in the top Makefile.in.
xist");
> + }
> + else
> + {
> + &generate_makefile ($output_files{$am_file}, $am_file);
> + }
> }
> +++$automake_has_run;
> }
> +while ($automake_needs_to_reprocess_all_files);
This doesn't look like it'll work
fix releases until (almost) everybody is happy.
Pavel> The problem is that Automake doesn't add depcomp to DIST_COMMON if
Pavel> 1) the sources are in the subdirectory and
Pavel> 2) depcomp doesn't already exist in the top-level directory.
depcomp should appear in the D
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>> Yeah, I still have a few of your patches sitting in my mailbox.
Derek> Well, when you get around to it, this one should take the place
Derek> of my last depcomp patch. I fixed tests/depcomp, tidied the
Derek> ChangeLog based on the s
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
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
"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
>> 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
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
--
De
> "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
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
, 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
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
>> 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
> 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
> "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 ont
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
> Der
> "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 understa
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
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
> > > > DI
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 i
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
"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 t
"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 Soluti
29 matches
Mail list logo
