Re: Having Trouble with m4 Input (m4 version 1.4.13)

[Gary V. Vaughan]

Hello again Tom,

On 7 Sep 2010, at 19:58, Tom Browder wrote:

> On Tue, Sep 7, 2010 at 07:25, Tom Browder <address@hidden> wrote:
>> On Tue, Sep 7, 2010 at 05:49, Tom Browder <address@hidden> wrote:
>>> On Tue, Sep 7, 2010 at 01:58, Gary V. Vaughan <address@hidden> wrote:
>> ...
>>>> Here is an ealy draft for an article I wrote for `Linux User & Developer'
> 
> Oops, after looking closer it looks like modifying code for m4-cpp
> would be at least partly a one-way street.

Of course.  It would make no sense for it to be any other way, otherwise
you couldn't use the extra power of m4 to pay back for the effort of
switching away from cpp.  Once you've made any substantial use of m4
to help generate repetitive parts of your code, you'll always have to
redo that part by hand if you want to go back to cpp.  So there's no
need to worry that the syntax for m4 #include(foo.h) is a little
different than what cpp provides.

I seem to remember that at one point I had some ideas for putting the
right hooks into the M4-2.0 syntax parser that it would be possible
to teach m4 to grok the gamut of cpp syntax - but I'm afraid that is
lost in the mists of time.  I'm sure after a little time poking around
the innards of M4 it would come back to me though.

> As I see it. to get users to go change legacy code in that direction
> one would have to
> 
> 1. provide a filter to change conventional cpp headers into an m4 version

However, there's no need to feel as though you have to convert the
entire installed header tree to m4 style – in the article I think I
said that a good point to draw the dividing line might be between
system headers (#include <unistd.h>) which would be left untouched
by m4 for cpp to slurp; and project headers ("#include(localheader.h)"),
which would allow you to set up a library of m4 code for you project
in shared header files.

>   + would autogen be the best tool for that?

I think that is unnecessary.  Make is just fine (from memory, so the
syntax is probably not quite right):

.SUFFIXES: .m4c

.m4c.c:
        $(M4) $^ > $@

> 2. make some kind of way for the c/cc files to work with conventional
> cpp processing as well as m4-cpp processing
> 
> Would this work for 2?
> 
> // sample.cc
> #if defined(USE_M4CPP)
> include(sample.h.m4)
> #else
> include "sample.h"
> #endif

Again, I would ship the generated files after m4 has done it's work so
that the end-user has no worries about finding just the right version
of GNU m4 to regenerate everything from scratch - just like we already
do with configure: we don't expect users to find and install copies of
autoconf/automake/libtool and locate the correct versions of all the
macros that were used to generate the configure script, we just ship
the configure script as is.

> If something like [2] would work then the user wouldn't have to do too
> much if [1] were provided by the m4 or gcc project.  And the autotools
> could be modified to allow for automatic processing for cpp or m4-cpp
> depending on an option or environment variable...

Well, the user wouldn't even know the difference until they tried to
edit a sample.h and spotted a big notice at the top reminding them:
"DO NOT EDIT THIS FILE - IT WAS GENERATED FROM SAMPLE.M4H" or similar :)

> Niceville, Florida

Niceville?  How come I never found that in my months of biking the
length and breadth of the sunshine state?

Cheers,
-- 
Gary V. Vaughan (address@hidden)

PGP.sig
Description: This is a digitally signed message part