tags 18440 notabug
close 18440
thanks
On 09/10/2014 10:49 AM, Ralf Corsepius wrote:
On 09/10/2014 03:24 AM, Dan Nicolaescu wrote:
Trying to add a target with
libexec_LIBRARIES
results in an error:
error: 'libexecdir' is not a legitimate directory for 'LIBRARIES'
But it looks like having
It had likely stopped being deterministic due to the new perl behavior
of having non-deterministic order of numerating hash keys:
http://search.cpan.org/dist/perl-5.18.0/pod/perldelta.pod#Hash_randomization
http://onionstand.blogspot.ie/2012/12/are-you-relying-on-hash-keys-being.html
See also
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
Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18286
On 08/18/2014 02:30 AM, Peter Johansson wrote:
Hi,
I have this snippet in my 'Makefile.am'
include am/test_data.am
$(srcdir)/am/test_data.am: $(srcdir)/test/data.txt $(srcdir)/am/test_data.am.in
cd $(srcdir) $(SHELL)
On Fri, 2014-12-19 at 22:01 +0100, Stefano Lattarini wrote:
Hi, thanks for the patch, and sorry for the delay.
On 12/02/2014 02:22 PM, Yanko Kaneti wrote:
The current am__cd right before invoking valac invalidates
any relative flags setup done before that.
On 12/22/2014 11:32 AM, Yanko Kaneti wrote:
On Fri, 2014-12-19 at 22:01 +0100, Stefano Lattarini wrote:
Hi, thanks for the patch, and sorry for the delay.
On 12/02/2014 02:22 PM, Yanko Kaneti wrote:
The current am__cd right before invoking valac invalidates
any relative flags setup done
It had likely stopped being deterministic due to the new perl behavior
of having non-deterministic order of numerating hash keys:
http://search.cpan.org/dist/perl-5.18.0/pod/perldelta.pod#Hash_randomization
http://onionstand.blogspot.ie/2012/12/are-you-relying-on-hash-keys-being.html
See also
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
On Mon, 2014-12-22 at 12:05 +0100, Stefano Lattarini wrote:
On 12/22/2014 11:32 AM, Yanko Kaneti wrote:
On Fri, 2014-12-19 at 22:01 +0100, Stefano Lattarini wrote:
Hi, thanks for the patch, and sorry for the delay.
On 12/02/2014 02:22 PM, Yanko Kaneti wrote:
The current am__cd
So that diffs displayed by the 'compare-autodiffs' target are
less spurious and more useful.
* gen-testsuite-part: Sort keys of %deps_extractor, %wrapper_setups
and %depmodes before iterating on them.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
gen-testsuite-part | 8
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
So that they prefer checking the semantics of the generated Makefiles,
rather than grepping their content. This will be useful in an upcoming
refactoring.
* t/distcom-subdir.sh: Adjust this test.
* t/distcom2.sh: And this.
* t/distcom3.sh: And this.
* t/distcom4.sh: And this.
* t/distcom5.sh:
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 of
Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18286
On 08/18/2014 02:30 AM, Peter Johansson wrote:
Hi,
I have this snippet in my 'Makefile.am'
include am/test_data.am
$(srcdir)/am/test_data.am: $(srcdir)/test/data.txt $(srcdir)/am/test_data.am.in
cd $(srcdir) $(SHELL)
On 12/19/2014 11:58 PM, Kip Warner wrote:
Hey list,
I am attempting to set a variable in my Makefile.am that contains a
normalized absolute path. I am doing this because another application
invoked through one of my rules breaks when fed a relative path and it
needs it.
On Mon, 2014-12-22 at 11:09 +0100, Stefano Lattarini wrote:
I guess Automake is just complaining about GNU make specific
constructs ('$(replapth ...)' in this case) that would cause
other make implementations to choke. You might need to add
AUTOMAKE_OPTIONS = -Wno-portability to the
On Mon, 2014-12-22 at 17:24 +0100, Stefano Lattarini wrote:
You might be able to use:
PATH_WORKAROUND = `relpath $(abs_top_builddir)/Tests/some_file.foo`
But then you must be aware that $(PATH_WORKAROUND) cannot be used
as a file at make level (i.e., can't be a prerequisite, or a target,
17 matches
Mail list logo
