We want AUTOMAKE_OPTIONS in Makefile.in to be the combination of
configure.ac and Makefile.am options. Define a new variable owner
for this, because we need to override the Makefile.am value
unconditionally and never emit warnings.
* lib/Automake/VarDef.pm (VAR_COMPUTED): New.
(dump): Print it.
On 08/22/2012 11:41 AM, Paolo Bonzini wrote:
Hi Stefano,
Hi Paolo, and thanks for the patches.
these patches add back support for obsolete dist-* options, by parsing
the AUTOMAKE_OPTIONS variable and distilling AM_DIST_FORMATS out of it.
The first two patches are required for this. They
Il 22/08/2012 13:47, Stefano Lattarini ha scritto:
Hi Paolo.
Since I still have some gripes with the preparatory [PATCH 1/2], I'm
thinking about reworking this patch to make is independent from that.
Find my ideas below. Do you think they would be a good move? If
yes, would you mind
On 08/22/2012 01:53 PM, Paolo Bonzini wrote:
Il 22/08/2012 13:47, Stefano Lattarini ha scritto:
Hi Paolo.
Since I still have some gripes with the preparatory [PATCH 1/2], I'm
thinking about reworking this patch to make is independent from that.
Find my ideas below. Do you think they would
Hi Paolo.
After reading this patch carefully, I realize the issue is more complicated
and tricky than it appeared at first. To avoid getting stuck here, I think
we should re-work your other patch to be independent from this one (it can
be done quite easily, see my reply to that patch). Once
On 08/22/2012 02:07 PM, Paolo Bonzini wrote:
Il 22/08/2012 14:03, Stefano Lattarini ha scritto:
I'm a bit confused as to where to draw the line between Automake and GNU
make...
It depends. A rule of thumb is that, when Automake *must* process something
at automake runtime (as is certainly
On 08/22/2012 02:32 PM, Paolo Bonzini wrote:
Il 22/08/2012 14:23, Stefano Lattarini ha scritto:
True, but in the make dist case, automake has otherwise no business in
parsing the dist-format options.
But IMHO it makes sense to keep the need/ability to recognize those options
segregated in
On 08/22/2012 02:43 PM, Paolo Bonzini wrote:
Il 22/08/2012 14:41, Stefano Lattarini ha scritto:
It is a bit ugly that _process_option_list has to know about the
no-dist-gzip option in order to give a warning. This way, I can give a
superior error message if somebody specifies no-dist-xz.
On 08/21/2012 06:03 PM, Paolo Bonzini wrote:
Looking at GNU Smalltalk, I see:
* warn for INCLUDES (vs. AM_CPPFLAGS)
Turns out this has already been done for ages (at least since 2003).
I'll just remove support for it in Automake 1.13. See the patch
below.
OK?
Regards,
Stefano
On Wed, Aug 22, 2012 at 5:12 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
On 08/21/2012 06:03 PM, Paolo Bonzini wrote:
Looking at GNU Smalltalk, I see:
* warn for INCLUDES (vs. AM_CPPFLAGS)
Turns out this has already been done for ages (at least since 2003).
I'll just remove
On Wed, Aug 22, 2012 at 10:12 PM, Paolo Bonzini bonz...@gnu.org wrote:
On Wed, Aug 22, 2012 at 5:12 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
On 08/21/2012 06:03 PM, Paolo Bonzini wrote:
Looking at GNU Smalltalk, I see:
* warn for INCLUDES (vs. AM_CPPFLAGS)
Turns out this
Il 22/08/2012 23:52, Stefano Lattarini ha scritto:
I'd much rather a mandatory noisy warning period before a feature is
completely removed.
This would require a new category of warnings that are are unconditionally
show, regardless of strictness or any -Wnone option. As usual, patches
On 08/22/2012 03:52 PM, Stefano Lattarini wrote:
OTOH, I believe developers working on older systems should be ready to
install more recent developer tools once in a while. You can't truly
expect not to update your Automake installation for 3, 4 years!
Oh, _I_ fully wish that RHEL 5 would at
On Tue, Aug 21, 2012 at 12:55 AM, Peter Johansson troj...@gmail.com wrote:
On 08/21/2012 02:46 PM, Jason Eisner wrote:
Better idea:
Have default 644 for files and 755 for directories, but let the user
override this by explicitly specifying any of
* the desired file permissions
* the
On 08/22/2012 02:51 PM, daniel.ja...@t-online.de wrote:
Hi Stefano,
Hi Daniel. Note that I'm re-adding the mailing list in CC:, so that
our discussion will be registered in the Automake bug tracker.
here are the files you asked for.
Thanks!
So I took a closer look at the whitelisting problem that was reported
in GNU Smalltalk.
The piece of code that was removed in Automake-NG is:
foreach my $primary ('SOURCES', 'LIBADD', 'LDADD', 'LDFLAGS', 'DEPENDENCIES')
{
foreach my $var (variables $primary)
{
my
On 08/21/2012 07:14 PM, Stefano Lattarini wrote:
On 08/21/2012 06:01 PM, Paolo Bonzini wrote:
* Alternatively, could Automake-NG suggest converting suffix
rules to pattern rules
Yep, I will amend NG-NEWS to suggest that.
Done with the patch below. I will push shortly.
On 08/21/2012 06:03 PM, Paolo Bonzini wrote:
Looking at GNU Smalltalk, I see:
* warn for INCLUDES (vs. AM_CPPFLAGS)
Turns out this has already been done for ages (at least since 2003).
I'll just remove support for it in Automake 1.13. See the patch
below.
OK?
Regards,
Stefano
On 08/15/2012 04:46 PM, Diego Elio Pettenò wrote:
On 15/08/2012 12:49, Del Merritt wrote:
All good questions; mostly because I am not completely sure yet that a)
I won't want to be able to install the sub-libraries later, b) my
hand-built makefiles do it this way already, so I was minimizing
On Wed, Aug 22, 2012 at 5:12 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
On 08/21/2012 06:03 PM, Paolo Bonzini wrote:
Looking at GNU Smalltalk, I see:
* warn for INCLUDES (vs. AM_CPPFLAGS)
Turns out this has already been done for ages (at least since 2003).
I'll just remove
On 22/08/2012 12:12, Paolo Bonzini wrote:
What about first making the warning visible always, not just with
-Wobsolete? And add to the message that support will be removed in
1.14.
+1
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
On Wed, Aug 22, 2012 at 10:12 PM, Paolo Bonzini bonz...@gnu.org wrote:
On Wed, Aug 22, 2012 at 5:12 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
On 08/21/2012 06:03 PM, Paolo Bonzini wrote:
Looking at GNU Smalltalk, I see:
* warn for INCLUDES (vs. AM_CPPFLAGS)
Turns out this
On 08/22/2012 09:12 AM, Stefano Lattarini wrote:
From 54a49542d417850e646fefe7bad56546a2362449 Mon Sep 17 00:00:00 2001
Message-Id:
54a49542d417850e646fefe7bad56546a2362449.1345648257.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@gmail.com
Date: Wed, 22 Aug 2012
On 08/22/2012 10:28 PM, Eric Blake wrote:
On 08/22/2012 09:12 AM, Stefano Lattarini wrote:
From 54a49542d417850e646fefe7bad56546a2362449 Mon Sep 17 00:00:00 2001
Message-Id:
54a49542d417850e646fefe7bad56546a2362449.1345648257.git.stefano.lattar...@gmail.com
From: Stefano Lattarini
Il 22/08/2012 23:52, Stefano Lattarini ha scritto:
I'd much rather a mandatory noisy warning period before a feature is
completely removed.
This would require a new category of warnings that are are unconditionally
show, regardless of strictness or any -Wnone option. As usual, patches
On 08/22/2012 03:52 PM, Stefano Lattarini wrote:
OTOH, I believe developers working on older systems should be ready to
install more recent developer tools once in a while. You can't truly
expect not to update your Automake installation for 3, 4 years!
Oh, _I_ fully wish that RHEL 5 would at
On Wed, 22 Aug 2012, Del Merritt wrote:
[Reponding on-list to what was Diego's private response to me; I hope he
doesn't mind.]
I just finished an experiment with a single libfoo.a and all many-thousands
of sources for libfoo_a_SOURCES. The compilation worked, but I got the
dreaded
27 matches
Mail list logo
