[Info-vax] Native compilers

[Dave Froble]

On 2/24/2022 6:04 AM, Johnny Billquist wrote:
> On 2022-02-23 21:02, VAXman- at SendSpamHere.ORG wrote:
>> In article <sv5ias$ute$1 at news.misty.com>, Johnny Billquist <bqt at softjar.se>
>> writes:
>>> On 2022-02-22 16:06, VAXman- at SendSpamHere.ORG wrote:
>>>> There is no .INCLUDE directive in Macro-32!  It is not referenced in the
>>>> VAX Macro LRM either.  Adding a ".INCLUDE /whatever/" elicits the error:
>>>>
>>>>     .INCLUDE    /whatever/
>>>> ^
>>>> %AMAC-E-UNRECSTMT, unrecognized statement
>>>> at line number 173 in file SYS$SYSROOT:[SYSMGR]X.MAR;3
>>>>
>>>>
>>>>> Or at least this is what I *know* is true in Macro-11, and while it's
>>>>> been quite a while since I played with Macro-32, I'm fairly certain it's
>>>>> the same there.
>>>>
>>>> 'Tis not!
>>>
>>> Ok. This time I'm really surprised. Makes one wonder why this was
>>> removed in Macro-32, which certainly otherwise feels like a spiritual
>>> successor to Macro-11.
>>>
>>> And I certainly believed I had used it in the dim past when I played
>>> more on VAXen. Brains develop bit rot...
>>
>> Personally, I prefer the macro library mechanism.  If you need to ".INCLUDE"
>> put it in a macro library, reference the library (.LIBRARY) and then callout
>> the module.  The idea is reusable macros.  One time Macro-32 should simply be
>> put into the source.
>
> They have different uses, and are not interchangeable.
> I certainly like the macro libraries, but they cannot be used for things like
> some prefix file you want to add to the compilation. Which is why .include is
> also good. Of course, you can also do this on the command line, which is what I
> believe John Reagan was hinting at.
>
> But I find it a bit annoying to have to remember to throw those things in on the
> command line, so when possible, I use .include instead.

Well, yes, it would be annoying.  But if it was easy ...

My practice, for many years, is to include build procedures with every 
application, perhaps for a single program, or for many programs.  A command file 
contains the procedure for compiling and linking the program.  Thus, one doesn't 
need to remember, and the thing is self documenting.

With the build procedure as part of the application, re-building one, or many, 
programs is rather trivial.

An example of several lines from the command file for building my database product:

$ !     Now compile the DAS modules
$
$ MACRO/OBJECT=DASL:CLOSE/NOLIST        DASS:DASPRE+DASS:CLOSE+SYS$LIBRARY:LIB/LIB
$ MACRO/OBJECT=DASL:DATA/NOLIST         DASS:DASPRE+DASS:DATA+SYS$LIBRARY:LIB/LIB
$ MACRO/OBJECT=DASL:DEFUPD/NOLIST       DASS:DASPRE+DASS:DEFUPD+SYS$LIBRARY:LIB/LIB

Yeah, the lines wrapped ...

For a Basic app:

$ DBASIC/NOLIST/OBJECT=OEL: OES:OE7104
$ DLINK OEL:OE7104/EXE=OEE:/NOMAP
$ PURGE OES:OE7104.*
$ PURGE OEL:OE7104.*
$ PURGE OEE:OE7104.*
$ DELETE OEL:OE7104.OBJ;*

Note, for the "Order Entry" apps the logicals:

$ sho log oe*

   "OEE" = "DISK1:[SOFTWARE.OE.EXECUTE]"
   "OEL" = "DISK1:[SOFTWARE.OE.LIBRARY]"
   "OES" = "DISK1:[SOFTWARE.OE.SOURCE]"

And the simple "master ring" to control them all:

$ t disk1:[software]cp.com
$ M = F$EXTRACT(0,2,P1)
$ SPAWN/NOWAIT/NOTIFY/INPUT='M'L:'P1'.COM/OUTPUT='M'L:'P1'.LOG

Invoked by: CP OE7104

This ain't rocket science.  Implement a reasonable method of building apps, and 
regardless of the steps, things become easy to manage.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486