[Info-vax] Can C #includes like this be made to work onVMS?

[Mark Berryman]

On 10/15/24 1:21 PM, Brian Schenkenberger wrote:
> On 2024-10-15 19:15:00 +0000, John Dallman said:
> 
>> In article <vemd23$1qdt1$1 at dont-email.me>, mail at SendSpamHere.ORG (Brian
>> Schenkenberger) wrote:
>>
>>> I want to port a freeware package. It's C code is littered with
>>> includes like:
>>>
>>> #include "package_name/include_file.h"
>>>
>>> I've tried the DECC$***_INCLUDE logicals, the CC command quilifier
>>> /INCLUDE_DIRECTORY and logicals, rooted and otherwise, defining
>>> "package_name". Can't get the C compiler to find include_file.h.
>>
>> Don't try to define "package name". General C practice is to regard that
>> as a directory name that the compiler should look for, used to collect
>> specific headers together.
>>
>> Instead, try using the various ways of specifying where you want include
>> files to be read from to indicate the directory that holds the
>> "package_name" directory.
>>
>> The compiler should look for the directory called "package_nane" and the
>> "include_file.h" within it.
>>
>> John
> 
> In the distribution, the includes are in a directory:
> 
> [package_name.INCLUDE]
> 
> and the source is in [package_name.SRC]
> 
> I am hoping not to have to edit all of the sources to change the 
> #include "..."s.


Given what you have described, there are at least two ways to address this.

1. By far the easiest is to $define package_name [package_name.include] 
which will use the normal C RTL rules for finding files.

2. As an alternative, the following will also work.

a. create/dir [package_name.include.package_name]
    and move all of the include files into that directory
b. create first.h
   #pragma include_directory "./package_name/include"
   ^Z
c. Do your compiles from the top_level directory
    CC/FIRST=first.h [.src]file.c

I find it easiest to create a descrip.mms file to do this and let mms do 
the work.

Mark Berryman