Emacs byte compilation now respects silent build rules (e.g. make V=0).
i.e. use AM_V_GEN to show this instead
GEN bar.elc
Thanks. I applied the patch.
s .elc byte compilation now respects silent rules
* lib/am/lisp.am: Use $(AM_V_GEN) in .el.elc rule.
As the build output now respects silent rules the $(make V=0) output
is clearer and now shows...
GEN bar.elc
GEN foo.elc
---
lib/am/lisp.am | 2 +-
1 file changed, 1 insertion
Your bug report
#32868: Check if make supports nested variables is done twice when using silent
rules
which was filed against the automake package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 32
On 28 Feb 2022 15:58, Karl Berry wrote:
> Fixes automake bug https://bugs.gnu.org/32868.
>
> Looks fine to me.
>
> +./configure -C
> +grep '^AM_DEFAULT_VERBOSITY = 1' Makefile
>
> Good :).
>
> I remain steadfastly opposed to (ever) changing th
Fixes automake bug https://bugs.gnu.org/32868.
Looks fine to me.
+./configure -C
+grep '^AM_DEFAULT_VERBOSITY = 1' Makefile
Good :).
I remain steadfastly opposed to (ever) changing the default to be silent
rules, as we've already discussed ad nauseam :). --thanks, karl.
Fixes automake bug https://bugs.gnu.org/32868.
The AM_SILENT_RULES macro defines all the silent-rules related setup.
It's also called by users to change the default verbosity level. This
leads to a quirk where automake calls it, expands the full context,
and then users call it, and it's fully
SILENT_RULES([DEFAULT])
> -# --
> -# Enable less verbose build rules; with the default set to DEFAULT
> -# ("yes" being less verbose, "no" or empty being verbose).
> -AC_DEFUN([AM_SILENT_RULES],
> -[AC_ARG_ENABLE([silent-rules], [dnl
> +# _AM_SILENT_RULES
On 20 Feb 2022 16:27, Zack Weinberg wrote:
> > i'm inclined to bring this back as the way to opt-in to silent-rules
> > by default.
>
> And I’m still absolutely opposed to making it even *possible* to have silent
> rules be on by default. In fact I’d like to see —enable
Fixes automake bug https://bugs.gnu.org/32868.
The AM_SILENT_RULES macro defines all the silent-rules related setup.
It's also called by users to change the default verbosity level. This
leads to a quirk where automake calls it, expands the full context,
and then users call it, and it's fully
On 20.02.22 19:52, Mike Frysinger wrote:
i don't think changing AM_V_P semantics is feasible. it's documented in the
manual as having this behavior and has since automake-1.13 (for ~10 years).
Well, that might be the case by now. When I filed that 7 years ago it
wasn't, though.
> this
> i'm inclined to bring this back as the way to opt-in to silent-rules
> by default.
And I’m still absolutely opposed to making it even *possible* to have silent
rules be on by default. In fact I’d like to see —enable-silent-rules removed,
with make V=0 the *only* way to switch to silent mode.
.
>
> If I remove AM_SILENT_RULES, the test is only done once.
>
> Is this intended behaviour ?
it's because of how silent rules are integrated. AM_INIT_AUTOMAKE has:
AC_REQUIRE([AM_SILENT_RULES])
which makes the silent rules framework always available.
but if you want to opt-in
On Fri, 27 Mar 2015 17:45:30 +0100, Pavel Raiskup wrote:
> On Wednesday 11 of March 2015 02:06:40 Mirko Vogt wrote:
> > I just stumbled across an issue where a project fails to compile using
> > automake and silent-rules with $V being set to sth. else other tha
On 9/28/18 1:47 PM, Jacob Kroon wrote:
Hi,
If I use AM_SILENT_RULES([yes]) in my configure.ac, when I run the
configure scripts I see this:
...
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
...
If I remove
Thank you for filing a new bug report with debbugs.gnu.org.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.
Your
Hi all,
In order to make automake builds quieter when building with the
silent-rules option, I made some patches that do this. Before spending
the time figuring out how to write tests for these I would like to see if
there was any interest in doing this.
The patches are up on my github account
On Wednesday 11 of March 2015 02:06:40 Mirko Vogt wrote:
I just stumbled across an issue where a project fails to compile using
automake and silent-rules with $V being set to sth. else other than '1'
or '0'.
This is because of the following resulting Makefile code when using
silent rules
Hi all,
I've been trying to make a large automake-generated project I work on build
quieter. While there is some support for silent-rules, there are several
places where automake templates* don't silence themselves, which I'd like
to rectify.
I have made several changes locally which helps a lot
On Fri, Jun 7, 2013 at 2:55 PM, Darren Garvey darren.gar...@gmail.com wrote:
Hi all,
I've been trying to make a large automake-generated project I work on build
quieter. While there is some support for silent-rules, there are several
places where automake templates* don't silence themselves
On 7 June 2013 23:10, Gavin Smith gavinsmith0...@gmail.com wrote:
On Fri, Jun 7, 2013 at 2:55 PM, Darren Garvey darren.gar...@gmail.com
wrote:
Hi all,
I've been trying to make a large automake-generated project I work on
build
quieter. While there is some support for silent-rules
%SILENT% doesn't work in any of the places I tried. I'm speculating that
this is because it's substituted too early. I see it being used in a few
places (eg. lib/am/library.am), but those rules are full of other %NAME%
strings.
Different files will use different substitutions. For SILENT to
* Makefile.am ($(srcdir)/doc/amhello-1.0.tar.gz): Here.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
Makefile.am | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index b6a5bbd..030c2eb 100644
---
We used to have several couples of tests named like 'silent-foo-gcc.sh'
and 'silent-foo-generic.sh'. Differently from what the names suggest,
the first test in such a couple (that is, silent-foo-gcc.sh) was not
meant to check specific GCC-related features, but rather to check how
the silent rules
tags 12501 + moreinfo
severity 12501 wishlist
thanks
On 09/24/2012 09:35 AM, Hib Eris wrote:
Hi all,
I think Automake generated makefiles can be a little less verbose when
building with silent rules.
Please consider attached patch.
Thanks,
Hib Eris
From
Hi all,
I think Automake generated makefiles can be a little less verbose when
building with silent rules.
Please consider attached patch.
Thanks,
Hib Eris
0001-Do-not-echo-targets-when-building-with-silent-rules.patch
Description: Binary data
: accept a third optional argument
refactor: silent rules handling (a little)
silent: new $(AM_V_P) variable, tell if we're running in silent mode
NEWS |6 +++
automake.in | 46 -
doc/automake.texi | 18
| 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/automake.in b/automake.in
index 5d777c1..722a202 100644
--- a/automake.in
+++ b/automake.in
@@ -1206,7 +1206,6 @@ sub define_verbose_tagvar ($)
if (option 'silent-rules')
{
define_verbose_var ($name
to determine whether make is being run in verbose mode
(as with make V=1) or quiet mode (as with make V=0).
I will push by tomorrow if there is no objection.
Regards,
Stefano
Stefano Lattarini (3):
refactor: define_verbose_var: accept a third optional argument
refactor: silent rules handling
| 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/automake.in b/automake.in
index 5d777c1..722a202 100644
--- a/automake.in
+++ b/automake.in
@@ -1206,7 +1206,6 @@ sub define_verbose_tagvar ($)
if (option 'silent-rules')
{
define_verbose_var ($name
)
TestLowLatencyData3_LDADD = $(PTHREAD_LIBS) $(LDADD)
TestLowLatencyData3_CFLAGS = $(PTHREAD_CFLAGS) $(AM_CFLAGS)
endif
then when building with silent rules, the codes that are linked
against libpthread are displayed as follows:
CC TestLowLatencyData1-TestLowLatencyData1.o
CCLD
)
TestLowLatencyData2_CFLAGS = $(PTHREAD_CFLAGS) $(AM_CFLAGS)
TestLowLatencyData3_LDADD = $(PTHREAD_LIBS) $(LDADD)
TestLowLatencyData3_CFLAGS = $(PTHREAD_CFLAGS) $(AM_CFLAGS)
endif
then when building with silent rules, the codes that are linked
against libpthread are displayed as follows:
CC
On Wed, May 9, 2012 at 12:09 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
This is expected, since the use of per-target compilation flags causes
the generated object files to be renamed; see:
http://www.gnu.org/software/automake/manual/automake.html#Renamed-Objects
Good, I was
On 05/01/2012 04:05 PM, Stefano Lattarini wrote:
Before this change, support for silent rules was optional and activated
only if the 'silent-rules' option was specified.
The rationale behind that behaviour was that the silent-rules machinery
originally only worked with make implementations
Before this change, support for silent rules was optional and activated
only if the 'silent-rules' option was specified.
The rationale behind that behaviour was that the silent-rules machinery
originally only worked with make implementations supporting nested
variables expansions, which isn't
On 05/01/2012 04:05 PM, Stefano Lattarini wrote:
[FYI] {maint} silent rules: support for them is always active now
Oops, wrong, this was *not* an FYI: I haven't pushed the patch yet, and
I'd love a review before I do so.
Sorry for the noise,
Stefabi
The AM_SILENT_RULES macro needs an argument to be enabled.
Currently, if the silent-rules option is set in AM_INIT_AUTOMAKE, the
action is an AC_REQUIRE on the macro, which runs it without any arg,
resulting in an useless action.
The only way for now to enable silent-rules is to call
On 04/28/2012 11:25 AM, Marc-Antoine Perennou wrote:
The AM_SILENT_RULES macro needs an argument to be enabled.
Currently, if the silent-rules option is set in AM_INIT_AUTOMAKE, the
action is an AC_REQUIRE on the macro, which runs it without any arg,
resulting in an useless action.
The only
tags 11371 wontfix
thanks
Hi Eric, Marc-Antoine.
On 04/28/2012 07:48 PM, Eric Blake wrote:
On 04/28/2012 11:25 AM, Marc-Antoine Perennou wrote:
The AM_SILENT_RULES macro needs an argument to be enabled.
Currently, if the silent-rules option is set in AM_INIT_AUTOMAKE, the
action
Reviving and oldish bug report (and CC:ing the Automake list now).
Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8665
I wrote:
A relevant excerpt [from the manual]:
You can add your own variables, so strings of your own choice are shown.
The following snippet shows how you would
Reviving and oldish bug report (and CC:ing the Automake list now).
Reference: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8665
I wrote:
A relevant excerpt [from the manual]:
You can add your own variables, so strings of your own choice are shown.
The following snippet shows how you would
Hi Dave, thanks for the patch.
It turns out we have already in place a workaround for a situation
similar to the one you're facing (that situation being the Sun C++
compiler being named 'CC'). So the best fix IMO is to extend this
workaround to deal also with you case. The attached patch should
Your patch does not work for me. Attached is a fixed version of your patch
that matches the offending $CXX value correctly, handles spaces in compiler
wrapper arguments, and fixes a typo.
If you have a better alternative to the conservative case statement that I
used, please use it. Between
Otherwise non-silent output such as pgCC or sunCC could
unintentionally match.
---
tests/silent-many-generic.test |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/tests/silent-many-generic.test b/tests/silent-many-generic.test
index a7a0487..4d254ee 100755
---
...@gmail.com
+ silent-rules tests: fix spurious failures with Sun Studio C++
+ * tests/silentcxx.test: The C++ compiler from Sun Studio is named
+ `CC'. Account for this in our grepping checks on the make output.
+ Since we are at it, throw in a couple of improvements
relevant file snippets:
configure.ac:
AM_SILENT_RULES([yes])
Makefile.am:
check_JAVA = Hello.java
Now with make check you get output:
CLASSPATH=.:./.:$CLASSPATH javac -d . Hello.java
echo timestamp classcheck.stamp
As all sources are compiled with one command a silent javac output could
be
; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) $(AUTOMAKE) --gnu Makefile'; \
$(am__cd) $(top_srcdir) $(AUTOMAKE) --gnu Makefile
The problem with such rules is that, when the 'silent-rules' option is
used, they do not respect the default or enforced verbosity; worse of all,
they have
an automake limitation, rather than an intrinsic bug.
Also note that your report prompted me to think about a more general
incompleteness of the current APIs for the 'silent-rules' support;
for more info (in case you are interested), see:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8665
Thanks
' should be `echo' when silent rules are in effect, and `:'
when they are not; viceversa for `AM_Q_ECHO'.
To give a simplified example of what I'm proposing:
$ cat Makefile.am 'END'
headers:
@... [commands defining a shell variable `$headers']; \
$(AM_V_ECHO) cd somedir generate
at this point), to be merged into 'master'?
With above issue and nits below addressed.
Subject: [PATCH] tests: more coverage on yacc/lex silent-rules, plus minor
cleanups
* tests/silent-yacc-gcc.test: Add sanity checks verifying that the
generated Makefile.in files really contains
' Makefile.in
--- /dev/null
+++ b/tests/silent-yacc-headers.test
+# Check silent-rules mode for Yacc, when yacc-generated headers are
+# involved (i.e., the `-d' option is in *YFLAGS).
+
+required=yacc
+. ./defs || Exit 1
+
+set -e
+
+mkdir sub
+
+cat configure.in 'EOF'
+AM_SILENT_RULES
On Saturday 22 January 2011, Ralf Wildenhues wrote:
* Stefano Lattarini wrote on Sat, Jan 22, 2011 at 12:28:58PM CET:
Well, not really, but I've become more suspicious since I realised
that, after my recent commit v1.11-268-g3544a43 yacc: support variable
expansions in *YFLAGS definition,
* Stefano Lattarini wrote on Sat, Jan 22, 2011 at 02:38:55PM CET:
or add an XFAILing test that exposes this change?
Well, to make amend, I can add a bunch of tests verifying that the
idiom holds for the whole lot of *FLAGS variables. Attached is my
attempt for YFLAGS. Should I add the
Hi Ralf.
I've (basically) addressed all your nits, and pushed to yacc-work.
Just one nit on my part ...
+# Check that the expected non-generic rules has been truly generated.
truly have been generated.
+# Otherwise, the coverage offered by this test will be weaker then
+# expected
* Stefano Lattarini wrote on Sat, Jan 22, 2011 at 06:38:29PM CET:
I've (basically) addressed all your nits, and pushed to yacc-work.
Thanks!
Just one nit on my part ...
+# Check that the expected non-generic rules has been truly generated.
truly have been generated.
+#
: Fri Jan 21 12:49:32 2011 +0100
Subject: [PATCH] tests: more coverage on yacc/lex silent-rules, plus minor cleanups
* tests/silent-yacc-gcc.test: Add sanity checks verifying that the
generated Makefile.in files really contains the non-generic rules
we expect. Do not redundantly remove by hand files
patch should fix these shortcomings.
OK for the 'yacc-work' branch (branch which, BTW, might as well
be made public at this point), to be merged into 'master'?
With above issue and nits below addressed.
Subject: [PATCH] tests: more coverage on yacc/lex silent-rules, plus minor
cleanups
* stefano.lattar...@gmail.com wrote on Thu, Dec 23, 2010 at 12:27:38PM CET:
* tests/silent-rules-nowarn.test: New test.
* tests/Makefile.am (TESTS): Update.
How about silent-nowarn.test for consistency with the other names?
OK with or without that change.
Thanks,
Ralf
Hello,
I noticed on NixOS GNU/Linux that silent*.test would randomly fail (see
http://hydra.nixos.org/build/477516.) The reason is that these tests
would fail if “mv” is found in the standard output of ‘make’, but the
random build directory names used by Nix could very well contain this
string.
Oops, here’s the right patch:
Make these tests more robust. Previously, they would fail if the name
of the build directory contains `mv', which can very well happen with Nix.
--- automake-1.11.1/tests/silent.test 2009-12-08 19:02:32.0 +0100
+++ automake-1.11.1/tests/silent.test
At Monday 05 July 2010, Ludovic Courtès wrote:
I noticed on NixOS GNU/Linux that silent*.test would randomly fail (see
http://hydra.nixos.org/build/477516.) The reason is that these tests
would fail if “mv” is found in the standard output of ‘make’, but the
random build directory names used
Hi,
Stefano Lattarini stefano.lattar...@gmail.com writes:
At Monday 05 July 2010, Ludovic Courtès wrote:
I noticed on NixOS GNU/Linux that silent*.test would randomly fail (see
http://hydra.nixos.org/build/477516.) The reason is that these tests
would fail if “mv” is found in the standard
At Monday 26 April 2010, Ralf Wildenhues ralf.wildenh...@gmx.de
wrote:
* Stefano Lattarini wrote on Mon, Apr 26, 2010 at 12:15:33AM CEST:
--- a/tests/silent6.test
+++ b/tests/silent6.test
@@ -99,5 +99,3 @@ $AUTOMAKE
grep 'AM_V_GEN' Makefile.in
$AUTOMAKE --force -Wno-all
* Stefano Lattarini wrote on Mon, Apr 26, 2010 at 10:59:50AM CEST:
By the way, I didn't understand if you're going to amend the patches
yourself, or if I should do that instead...
I can do that, but it's likely going to not be before the weekend.
Cheers,
Ralf
At Monday 26 April 2010, Ralf Wildenhues ralf.wildenh...@gmx.de
wrote:
* Stefano Lattarini wrote on Mon, Apr 26, 2010 at 10:59:50AM CEST:
By the way, I didn't understand if you're going to amend the
patches yourself, or if I should do that instead...
I can do that, but it's likely going
Patch updated.
From 416e668a12cec7aa0119fa2ca958e2a22413c522 Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Tue, 27 Apr 2010 02:00:14 +0200
Subject: [PATCH 1/9] Relax tests on silent-rules to cater for overly verbose makes.
* tests/silent.test: When testing
Patch updated (with a tiny improvement w.r.t. stricter make output
grepping)
From 84e67683c982c7fe2a0e05880edc0612953af7ce Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Tue, 27 Apr 2010 02:06:05 +0200
Subject: [PATCH 8/9] Tests on extensibility of silent-rules
copyright years.
* tests/silent2.test: Likewise.
* tests/silent3.test: Likewise.
From 3d7b25b09b22324806a2ef805cf004cea3ba1b65 Mon Sep 17 00:00:00 2001
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Sun, 25 Apr 2010 22:20:57 +0200
Subject: [PATCH 1/9] Relax silent-rules tests to cater
* Stefano Lattarini wrote on Mon, Apr 26, 2010 at 12:15:33AM CEST:
--- a/tests/silent6.test
+++ b/tests/silent6.test
@@ -99,5 +99,3 @@ $AUTOMAKE
grep 'AM_V_GEN' Makefile.in
$AUTOMAKE --force -Wno-all -Wportability
grep 'AM_V_GEN' Makefile.in
-
-:
Please don't remove trailing ':' or
* Dmitry V. Levin wrote on Sun, Jan 17, 2010 at 02:37:10AM CET:
There seems to be a bug in automake: silent-rules support is not
compatible with --disable-dependency-tracking yet. Passing this option to
configure results to garbage both in silent and verbose output.
Here is a reproducer
Hi,
There seems to be a bug in automake: silent-rules support is not
compatible with --disable-dependency-tracking yet. Passing this option to
configure results to garbage both in silent and verbose output.
Here is a reproducer on GNU/Linux:
$ automake --version |head -1
automake (GNU automake
On Wed, 2009-10-14 at 03:17 +0200, Ralf Corsepius wrote:
But YOU can still disable it by default, by writing your packaging
automation tools to supply --disable-silent-rules as part of calling
./configure, and/or writing an appropriate config.site. In other words,
the person running
On 10/14/2009 06:55 PM, Bob Friesenhahn wrote:
On Wed, 14 Oct 2009, Ralf Wildenhues wrote:
Actually, complaining can indeed change the situation.
Exactly.
To put it bluntly, I find the situation automake as shifted itself to be
similar to this ole' joke:
Look Ma, I can ride my bike with
bitten when there were incompatible changes
(gnustep-make 1.x - 2.x) a few years ago that were *hidden* by the
silent output.
So, what's the problem for you to pass --disable-silent-rules,
--disable-shave, messages=yes, etc? I do it for all my packages that
have silent rules by default
On Thu, 15 Oct 2009, Ralf Corsepius wrote:
Look Ma, I can ride my bike with the hands off the handlebar ... some hours
later, the same kid will tell: Look Ma, I can ride my bike without teeth.
In other words, I am expecting the same users who find AM_SILENT cool, to
be loosing their teeth
On Wed, 14 Oct 2009, Ralf Wildenhues wrote:
What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?
Exactly this is the problem.
I still fail to understand. What problem do you have with either
echo export V=1 ~/.bashrc
or
echo
* Ralf Corsepius wrote on Wed, Oct 14, 2009 at 09:23:10AM CEST:
On 10/14/2009 07:05 AM, Ralf Wildenhues wrote:
I still fail to understand. What problem do you have with either
echo export V=1 ~/.bashrc
or
echo enable_silent_rules=no ${CONFIG_SITE-/usr/local/share/config.site}
correctly.)
What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?
Exactly this is the problem.
The problem isn't the support for silent rules. The problem is that
some packages are enabling it by default because it looks like Linux
and Linux
without warning doesn't mean it is
being built correctly.)
What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?
Exactly this is the problem.
The problem isn't the support for silent rules. The problem is that
some packages are enabling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Corsepius on 10/13/2009 9:20 AM:
What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?
Exactly this is the problem.
The problem isn't the support for silent rules. The problem
On 10/14/2009 02:58 AM, Eric Blake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Corsepius on 10/13/2009 9:20 AM:
What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?
Exactly this is the problem.
The problem isn't
, LDFLAGS etc. in
compiler calls etc. for correctness
(NB: A package, which compiles without warning doesn't mean it
is being built correctly.)
What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?
Exactly this is the problem.
I still fail
(NB: A package, which compiles without warning doesn't mean it is being
built correctly.)
What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?
Exactly this is the problem.
It means automake is pushing around package maintainers to modify
expand on this nuisance a bit more?
What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time? This is an honest question;
I'd like to avoid extra work for distributors.
Thanks,
Ralf
* Jan Engelhardt wrote on Wed, May 27, 2009 at 09:12:44PM CEST:
On Sunday 2009-05-24 15:24, Thomas Dickey wrote:
all :
echo $(XY_V)
XY_V = $(XY_$(V))
XY_0 = silent
XY_1 = verbose
XY_ = unknown
I think this is supported by POSIX. POSIX [1] says: Macros can appear
anywhere in
On Sat, 30 May 2009, Ralf Wildenhues wrote:
POSIX says that; however different implementations of 'make' treat
forward-references differently.
Well that's when you would put XY_V last, just to be sure:
XY_ = unknown
XY_0 = silent
XY_1 = verbose
XY_V = $(XY_$(V))
then there is no forward
On Sunday 2009-05-24 15:24, Thomas Dickey wrote:
On Sun, 24 May 2009, Bruno Haible wrote:
- The `silent-rules' option enables Linux kernel-style silent build output.
This option requires the widely supported but non-POSIX `make' feature
of recursive variable expansion,
We are talking
- The `silent-rules' option enables Linux kernel-style silent build output.
This option requires the widely supported but non-POSIX `make' feature
of recursive variable expansion,
We are talking about constructs like this:
== Makefile ==
all :
echo $(XY_V)
XY_V = $(XY_
sorry, hit the send key too early.
* Ralf Wildenhues wrote on Sun, May 24, 2009 at 03:20:04PM CEST:
IRIX make barfs if the inner macro expansion is used without $() or ${}
even for one-character macros. IOW, IRIX make barfs over $(foo$V) but
copes with $(foo$(V)).
There are also some make
On Sun, 24 May 2009, Bruno Haible wrote:
- The `silent-rules' option enables Linux kernel-style silent build output.
This option requires the widely supported but non-POSIX `make' feature
of recursive variable expansion,
We are talking about constructs like this:
== Makefile
Hello Bruno, Bob,
* Bruno Haible wrote on Sun, May 24, 2009 at 01:12:02PM CEST:
- The `silent-rules' option enables Linux kernel-style silent build output.
This option requires the widely supported but non-POSIX `make' feature
of recursive variable expansion,
We are talking about
Hi Bob, all,
* Bob Friesenhahn wrote on Sun, May 17, 2009 at 10:43:51PM CEST:
P.S. I am pretty pissed that almost all recent discussion of automake
major features and direction has apparently taken place on the
automake-patches list rather than the automake list where it belongs.
Not
to permanently silence warnings from your code,
you should probably just use appropriate pragmas or command-line options
to disable those warnings.
One of the primary reasons (IMHO) for Automake silent rules is so that I
CAN see the warnings in my code (without resorting to redirecting make's
stdout
Is anyone aware of specific vendor make programs which fail with
automake 1.11's new `silent-rules' option?
- The `silent-rules' option enables Linux kernel-style silent build output.
This option requires the widely supported but non-POSIX `make' feature
of recursive variable
I see that the only way to request the new `silent-rules' feature is
by using the new form of AM_INIT_AUTOMAKE to pass the option. Since
my package can not use the new form of AM_INIT_AUTOMAKE, then it can
not request `silent-rules'.
The reason for this limitation is that using the new form
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes:
The reason why my package can not use AC_INIT is that the package
version information is (often) computed by shell script code based on
the last entry in the project ChangeLog or other information. It is
(apparently) not possible for
On Sun, 2009-05-17 at 15:43 -0500, Bob Friesenhahn wrote:
The reason why my package can not use AC_INIT is that the package
version information is (often) computed by shell script code based on
the last entry in the project ChangeLog or other information. It is
(apparently) not possible
On Sun, May 17, 2009 at 4:43 PM, Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
I see that the only way to request the new `silent-rules' feature is by
using the new form of AM_INIT_AUTOMAKE to pass the option. Since my package
can not use the new form of AM_INIT_AUTOMAKE, then it can
Bob Friesenhahn wrote:
It does not make sense to manually edit configure.ac each time a new
package needs to be produced.
Is there a way that some of my own script code can be executed prior to
AC_INIT and a way to pass this information in a shell variable to
AC_INIT? If so, then I can
On Sun, 17 May 2009, NightStrike wrote:
On Sun, May 17, 2009 at 4:43 PM, Bob Friesenhahn
bfrie...@simple.dallas.tx.us wrote:
I see that the only way to request the new `silent-rules' feature is by
using the new form of AM_INIT_AUTOMAKE to pass the option. Since my package
can not use the new
On Sun, 17 May 2009, Peter O'Gorman wrote:
Hi Bob,
You can use m4_easycmd to run your scripts at autoconf time. E.g. (from
autoconf itself):
AC_INIT([GNU Autoconf],
m4_esyscmd([build-aux/git-version-gen .tarball-version]),
[bug-autoc...@gnu.org])
I still owe you large quantities
1 - 100 of 130 matches
Mail list logo
