[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: double assignment is an error in automake 1.5?
From: |
Richard Boulton |
Subject: |
Re: double assignment is an error in automake 1.5? |
Date: |
29 Aug 2001 00:10:51 +0100 |
On 28 Aug 2001 01:35:33 +0200, Assar Westerlund wrote:
> I would like to check if it's the case that this is supposed to be an
> error or not. Being able to set a variable multiple times is a rather
> common thing to do in Makefiles, so I was kind of assuming that would
> be carried over to automake.
I'm not able to say whether this is supposed to be an error.
However, a couple of points:
1) I've been trying to compile various gnome applications. Many of these
have variables which are set multiple times: and in the vast majority of
cases this is due to a mistake. Causes of these look to be such things
as:
i) copying errors (copying a block of code and forgetting to change
a bit of it)
ii) in large Makefile.am's, defining something such as noinst_DATA twice
due to not realising that it's already defined elsewhere
Many of these mistakes don't actually cause problems at present, on most
systems, but are well worth correcting in any case.
2) It is, however, sometimes desirable to override a definition,
especially when a standardised makefile fragment is being "include"ed. If
multiple assignment is forbidden, there is no way to do this.
I would suggest that the ideal solution is to add a flag to automake's
command line to say "assume that multiple definition of variables means
use the last definition as an override", for backwards compatability.
(But give a warning that this is deprecated behaviour)
Perhaps this flag should be "--backwards-compatible", and also allow
other significant incompatabilities to pass (such as using += on a
variable which isn't yet defined.)
Also, add some method of _explicitly_ overriding any previous definitions
of a variable. eg, "A o= B", though probably with some symbol other
than "o". Or possibly "override A=B", though that is a bit of a radical
departure from the existing syntax.
I would say that the extra command line flag would be of some considerable
value on branch-real-1.5, since compiling many applications is very
difficult with automake 1.5 due to this problem, but the new syntax for
overrides would be destined for HEAD only.
Comments? Patches? Or shall I add making a patch for this to my list
of things to do?
--
Richard