autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Multi-Line Definitions


From: Eric Lemings
Subject: RE: Multi-Line Definitions
Date: Tue, 18 Sep 2007 15:17:16 -0600

 

> -----Original Message-----
> From: Ralf Wildenhues [mailto:address@hidden 
> Sent: Tuesday, September 18, 2007 1:32 PM
> To: Eric Lemings; address@hidden
> Cc: address@hidden
> Subject: Re: Multi-Line Definitions
> 
> Hello Eric,
> 
> * Eric Lemings wrote on Mon, Sep 17, 2007 at 11:53:23PM CEST:
> > 
> > I have a Autoconf M4 macro that defines a multi-line preprocessor
> > symbol.
> [...]
> > How hard would it be to handle such macro definitions?  Is it even
> > possible?
> 
> Multi-line AC_DEFINEs are not supported currently.  Recently (in
> Autoconf 2.60), support for multi-line AC_SUBSTs has been implemented.
> 
> Why do you need them?  This is an serious question: The preprocessor
> will turn your multi-line define into a single-line one anyway.

Well, I'm working on converting Apache Standard C++ Library
(http://incubator.apache.org/stdcxx/) from a hand-written Makefile
config/build system to a GNU Autoconf-based config/build system.  This
particular request is needed, well, for readability more than anything
I suppose.  As you say, the whole macro could be defined on one long
line and it wouldn't matter at all to the compiler and other tools.
It just doesn't look very pleasing to the eye.  :)

> If we implement them, what should be the semantics: newlines are
> interpreted as backslash-newline, or only backslash-newline 
> is accepted?

I'd say only backslash-newline combinations should be accepted as this
is
what the compiler...er preprocessor expects in preprocessing directives.

> Here it is useful to consider that users may generate output 
> files that
> will not be input to a C preprocessor, but some other, 
> similar language.

True.  In that case, perhaps the behavior should be language-dependent?

...
> several weeks.  @DEFS@ would be another step ('make' implementations
> have ugly length limits too), but I would not see that as a priority,
> as it can be worked around using AC_CONFIG_HEADERS.

Thanks for the speedy turnaround.  :)

Eric.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]