[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments in make variable definition
From: |
Pippijn van Steenhoven |
Subject: |
Re: comments in make variable definition |
Date: |
Sun, 26 Dec 2010 08:09:31 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Wed, Dec 22, 2010 at 06:17:47PM +0100, Stefano Lattarini wrote:
> On Tuesday 21 December 2010, Ralf Wildenhues wrote:
> > * Stefano Lattarini wrote on Tue, Dec 21, 2010 at 01:55:39PM CET:
> > > On Sunday 19 December 2010, Ralf Wildenhues wrote:
> > > > * Stefano Lattarini wrote on Fri, Dec 17, 2010 at 12:19:40PM CET:
> > > > > xmandir = $(mandir) # we want info files installed in $(mandir)
> > > > > because ...
> > > > > xman_TEXINFOS = foo.texi
> > > >
> > > > (And the inline comment is of course not ok ;-)
> > >
> > > (Maybe it's time to deprecate them too in the manual ...)
> >
> > I don't see how they were ever not problematic. Well, at least given
> > the autoconf.texi general warnings about comments in makefiles.
> >
> Ah, but AFAIK, make comments are problematic only in makefile *rules*,
> not in variable definitions:
> VAR = foo bar # a probably portable comment
> tgt:; touch $@ # a bad unportable commen
>
> Try also to search:
> ^[^\t#].*=.*\s# file:^Makefile\.am$
> with google code search (not many entries, luckily, but still).
>
> Regards,
> Stefano
Actually it is not always ok. FreeBSD's make chokes on it in some
instances:
VAR = foo # this comment is ok
VAR = foo \
# this is also ok
VAR = foo \
# this is ok \
# <- Unassociated shell command
Also, it will break $(am__append*) variables, but that is not relevant in
this case.
--
Pippijn van Steenhoven
signature.asc
Description: Digital signature