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-ride
- if (grep (/$lastflag/, ('-H', '-h', '--header', '--internal-header',
- '--vapi', '--internal-vapi', '--gir')))
+ if (grep (/^$lastflag$/, ('-H', '-h', '--header', '--internal-header',
+ '--vapi', '--internal-vapi',
Hi Colomban - back on your automake bug report from six years ago (sorry!):
Date: Wed, 15 Oct 2014 17:17:00 +0200
From: Colomban Wendling
[...]
The problem is that parsing of valac flags uses a non-anchored pattern
and so any argument happening to be a subset of a parsed
similar commit v1.14-19-g52e6404.
Fixes automake bug http://debbugs.gnu.org/17908
* bin/automake.in (handle_dist): Sort @dist_common.
(print_autodist_files): Swap invocations of 'sort' and 'uniq', for
consistency with the new code in 'handle_dist' and to get rid of a
minor hack.
* NEWS: Update
diff --git a/NEWS b/NEWS
index bdc9bb9..5d14c5e 100644
--- a/NEWS
+++ b/NEWS
@@ -116,6 +116,10 @@ New in 1.14.2:
risks causing Arg list too long for projects using automatic
dependency tracking and having a ton of source files (bug#18744).
+ - Automake tries to offer a more
similar commit v1.14-19-g52e6404.
Fixes automake bug http://debbugs.gnu.org/17908
* bin/automake.in (handle_dist): Sort @dist_common.
(print_autodist_files): Swap invocations of 'sort' and 'uniq', for
consistency with the new code in 'handle_dist' and to get rid of a
minor hack.
* NEWS: Update
diff --git a/NEWS b/NEWS
index bdc9bb9..5d14c5e 100644
--- a/NEWS
+++ b/NEWS
@@ -116,6 +116,10 @@ New in 1.14.2:
risks causing Arg list too long for projects using automatic
dependency tracking and having a ton of source files (bug#18744).
+ - Automake tries to offer a more
Hi Peter.
On 12/22/2014 01:30 PM, Peter Rosin wrote:
diff --git a/NEWS b/NEWS
index bdc9bb9..5d14c5e 100644
--- a/NEWS
+++ b/NEWS
@@ -116,6 +116,10 @@ New in 1.14.2:
risks causing Arg list too long for projects using automatic
dependency tracking and having a ton of source files
:
+ echo ' ' $(DIST_COMMON) ' ' | $(FGREP) ' $(top_srcdir)/depcomp '
+END
$ACLOCAL
$AUTOCONF
$AUTOMAKE
test ! -e depcomp
-cat subdir/Makefile.am 'END'
+cat subdir/Makefile.am 'END'
bin_PROGRAMS = foo
+.PHONY: test-distcom
+test-distcom:
+ echo ' ' $(DIST_COMMON) ' ' | $(FGREP
There is not need to make that an Automake variable early,
only to later get and munge its contents, and use the new
content to redefine the variable.
* bin/automake.in (@dist_common): New global variable.
(push_dist_common, handle_dist): Use it.
(handle_dist): Define am__DIST_COMMON instead
Hi,
The parsing of valac flags is too permissive and incorrectly matches
some input, possibly leading to garbage in DIST_COMMON -- and then,
build failures.
The problem is that parsing of valac flags uses a non-anchored pattern
and so any argument happening to be a subset of a parsed argument
Comments on some of our automake-time pre-processing of $(DIST_COMMON)
said that it was done in order to put README first because it then
becomes easier to make a Usenet-compliant shar file. But such a
format is hardly relevant anymore, and not worth the (albeit small)
added complexity
This change simplifies the automake internals dealing with the
checking, copying and distributing of required auxiliary files.
With this change, a required auxiliary file is *unconditionally*
added to the contents of the DIST_COMMON variable in the generated
Makefile.in, before checking whether
adl == Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
adl 2001-09-22 Alexandre Duret-Lutz [EMAIL PROTECTED]
adlFix for distcommon2.test: * automake.in
adl (automake_needs_to_reprocess_all_files): New variable. (main):
adl Process all Makefiles a second time if
adl
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
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision
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 built. If
I
.
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 DIST_COMMON variable from the
toplevel, unfortunately its existence starts
);
+ }
}
+++$automake_has_run;
}
+while ($automake_needs_to_reprocess_all_files);
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.
- Hari
--
Raja R Harinath -- [EMAIL
- 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.
You cannot use automake --add-missing src/Makefile until a straight
"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.
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
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.
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
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
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
/\\$/{N;s/\\.//g;}' testSubDir/Makefile.in \
|grep '^DIST_COMMON.*subdir/bar.in' Makefile.in || exit 1
exit 0
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
"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
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
"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
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
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
33 matches
Mail list logo
