[Info-vax] Native compilers

Johnny Billquist bqt at softjar.se
Thu Feb 24 06:04:07 EST 2022


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.

Typical things are stuff like you have some configuration step that 
based on your choices creates a prefix file with various symbols 
defined. Which is then included in with the compilation, and the source 
have various conditional parts that are included or not (or modified) 
based on what's in the prefix file.

You could, of course, create a macro out of the whole thing, and put 
that in a library, and then the source refers to that created library, 
invokes the known macro that defines all the choices made, and then you 
are good. But that seems like a very complicated way of doing things here...

(There is so much conditional code in RSX it's almost ridiculous. 
Without such prefix files selecting which way to build things, it would 
become horrible. Hello LB:[11,10]RSXMC.MAC)

   Johnny



More information about the Info-vax mailing list