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

[Gary V. Vaughan]

Hi Tom,

On 7 Sep 2010, at 22:00, Tom Browder wrote:
> On Tue, Sep 7, 2010 at 09:03, Gary V. Vaughan <address@hidden> wrote:
>> Hello again Tom,
> 
> Hey, Gary, sorry to keep bugging you, but this m4 and its potential
> for me is intriguing.

No problem.  I'll stop replying if I feel bugged ;)

Hmm, I think you are considering using m4 *instead* of cpp, right?
I'm sure that's possible too, though you would need to teach m4 to
understand *all* of the directives supported by cpp, otherwise it
will fall over when it encounters a system header.  M4-2.0 might
need a little work in the syntax parser to allow hooking in a bit
of C code to make it seamless... otherwise you'll need to massage
the files before m4 sees them; maybe a job for an `m4pp' script:

  #!/bin/sh

  while test $# -gt 0; do
     case $1 in
        # this won't work as is, because some options take args!
        -*) options="${options+$options }$1 ;;
        *)  files="${files+$files }$1 ;;
     esac
     shift
  done

  cat $files \
    | awk '/* massage cpp into m4 digestable format */ \
    | m4 $options

  exit $?

However, I was talking about using m4 as an *additional* pre-processor,
which would leave well alone any #include <sys/header.h> lines for
cpp proper to deal with.

My rationale is this: If you're happy with the facilities offered by
cpp when it comes to any particular file in your project, then why
tack on another preprocessor stage for the sake of it?  But, there
are definitely cases (converting a table of values into a class with
accessor functions and some private data members to support them)
where m4 can make meta-programming *much* easier and less error-prone.
In those cases, let m4 expand any macros it knows about so that you
get to write the fun parts of the code rather than the boring repetitive
stuff.

This makes migrating your project into `m4pp' a breeze: everything
stays exactly as it was before, until you want to use the added
power of m4 somewhere.  At that point you rename the file from
`.c/.cc' to `.m4c/.m4cc' and add a make rule that generates `.c/.cc'
files for the compiler to eat by feeding the `.m4c/.m4cc' files
through m4.  As long as you remember not to edit those output files
(by adding a DO NOT EDIT notice and turning of write permission in
the make rule that does the generation is a good way to achieve that),
everything is more or less the same as it always was.

Since you have the generated `.c/.cc' files around anyway, you can
ship those when you distribute your package, so that users don't
need to have `m4pp' or GNU M4-2.x or anything else that you used
to turn the `.m4c/.m4cc' meta program into a standard C/C++ file.

Thinking about it, my old article could have made this clearer, but I
was so carried away with excitement about all the whiz-bang new
possibilities of M4-2.0 it passed me by at the time :)

Another thing I got wrong is that it's important to be able to tell
whether or not the C/C++ compiler is going to choke on your headers,
so I would continue to put cpp headers in `.h' files (maybe `.hh' or
something if only the C++ compiler will grok them), and keep the
shared m4 headers in plain `.m4' suffixed files.  If you need to
generate a cpp parsable header from an `.m4' header, then you would
do the same as with source code: a `.m4h' meta-program and a make
rule to feed that through m4 to create a `.h' file that is shipped
with the package to save users from installing an m4 development
environment just to compile your code.

So, with the system I was envisioning where you use m4 as an
additional preprocessor on just those files that need the extra
power of m4, there's no need to move back and forth between the
two styles.  Just slowly migrate files into m4 as you find the
need.  The syncfiles output, and multiple-inclusion protection are
useful too, but are more to help m4 play nicely with cpp than do
away with cpp altogether.

>> Niceville?  How come I never found that in my months of biking the
>> length and breadth of the sunshine state?
> 
> Did you get to the Panhandle (sometimes called Lower Alabama:
> Pensacola, Fort Walton Beach, Destin, Panama City)?  Niceville is on
> Florida Highway 20 on the north side of Choctawhatchee Bay across from
> Destin.  If you came this way I'll bet you came via US Highway 98
> along the gulf--much more scenic and well-known route.

No further than Talahassee to break up the miles of interstate on
a trip from Lynchburg, TN to Miami, FL (3 days hard riding!).  The
geography of Choctawhatchee Bay looks interesting... should I pencil
in a visit for my next FL road trip?

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

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