Hello again Tom, On 7 Sep 2010, at 19:58, Tom Browder wrote:
> On Tue, Sep 7, 2010 at 07:25, Tom Browder <[email protected]> wrote: >> On Tue, Sep 7, 2010 at 05:49, Tom Browder <[email protected]> wrote: >>> On Tue, Sep 7, 2010 at 01:58, Gary V. Vaughan <[email protected]> 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 ([email protected])
PGP.sig
Description: This is a digitally signed message part
