m4-discuss
[Top][All Lists]
Advanced

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

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


From: Tom Browder
Subject: Re: Having Trouble with m4 Input (m4 version 1.4.13)
Date: Tue, 7 Sep 2010 10:00:03 -0500

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.

> 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:

>> 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.

What I'm thinking about here is incrementalism.  In trying to do over
a big project I would want a way to go back and forth between cpp and
m4-cpp until everything works and everyone is comfortable.  With the
right tools, that duality could work forever.

>>   + would autogen be the best tool for that?

I'm thinking here maintain the cpp headers in cpp format and automate
the translation to the m4 version when needed using make and a
suitable rule.

I'm also thinking that I wouldn't have to drastically change a c/cc
file except for my example (if it would work), so that c/cc files
wouldn't need transforming (but I probably misread the process--I'll
comment later).  See below:

>> 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.m4h)
>> #else
>> include "sample.h"
>> #endif

Would anything else have to be modified in a c/cc source file?

> 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

Yes, that could work, but my method could still work during my
back-and-forth era (maybe forever).  I frankly wasn't thinking about
distributing in such a manner.

> 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.

And that would work since I guess the m4-cpp would be shipped, too.

>> 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 :)

Yes, but the distro package in my world would have the cpp header, not
the built version.  It would be built on site.

Okay, given the m4-cpp process as I understand it, is something like
this right/workable? =>

1. Convert a cpp header to m4-cpp format (by a suitable filter).  Now we

   # have a make rule to do it
   <transform> sample.h sample.m4h

2. Convert a c/cc file to m4-cpp include format (both forms in the
same file) but rename it:

 #  do this once and the new file becomes dual-capable with
 #  either a translation or a simple name change
 mv  sample.cc sample.m4cc.

Then all source files would be *.h and *.m4cc

So, if I want to use m4-cpp:

  <transform> sample.h sample.hm4
  m4 m4-cpp.m4 sample.m4cc > sample.cc
  #... compile sample.cc

And if I want to use cpp

  cp sample.m4cc sample.cc
  #... compile sample.cc

> 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.

Cheers,

-Tom



reply via email to

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