Xref: utzoo comp.unix.sysv386:4543 comp.unix.misc:908
Path: utzoo!utgpu!cunews!micor!latour!ecicrl!clewis
From: clewis@ferret.ocunix.on.ca (Chris Lewis)
Newsgroups: comp.unix.sysv386,comp.unix.misc
Subject: Re: M4 macro processor
Message-ID: <1261@ecicrl.ocunix.on.ca>
Date: 3 Feb 91 19:56:23 GMT
References: <873@fnx.UUCP> <1080@mwtech.UUCP>
Followup-To: comp.unix.sysv386
Organization: Elegant Communications Inc., Ottawa, Canada
Lines: 29

In article <1080@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
>In article <873@fnx.UUCP> del@fnx.UUCP (Dag Erik Lindberg) writes:
>>I have an application that is just screaming for something like a 
>>macro-processor.  The C pre-processor is no good because the files
>>I need to deal with are Motorola assembly sources which use '#'
>>to signify a constant value as opposed to a memory reference.

>The C-Preprocessor is a C-Preprocessor is a C-Preprocessor ....
>and NOT a general macro processor. I support your view so far.

Weeelll, I agree with the sentiment, but it shouldn't neccessarily
stop people from trying new things with it.  Back when U of Toronto
got its first 68000 evaluation board (long before Sun et. al.) some
poor soul cobbled up a 68000 assembler out of CPP.  (well, actually,
I believe it was used to substitute ".text" numeric constants for
mnemonics and run thru the PDP 11 assembler to produce a binary, but
you get what I mean).  Dag may very well be able to use CPP on his
assembler provided that he runs sed on it first and afterwards to change
the '#' to something else and back.  Sed may even be enough to
do what he needs all by itself.

Another source for reasonably close documentation on m4 (or, indeed
source for a replacement) is in Kernighan's Software Tools book
(or, Software Tools in Pascal).
-- 
Chris Lewis, Phone: (613) 832-0541, Internet: clewis@ferret.ocunix.on.ca
UUCP: uunet!mitel!cunews!latour!ecicrl!clewis
Moderator of the Ferret Mailing List (ferret-request@eci386)
Psroff enquiries: psroff-request@eci386, current patchlevel is *7*.