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

[Arne Vajhøj]

On 10/15/2024 3: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.
> 
> 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.

$ define package_name [package_name.INCLUDE]

should work.

$ cc/include will not work with this weird setup. If you changed the
includes to be:
     #include "include_file.h"
or:
     #include "package_name/include/include_file.h" or
then it would work.

Writing some DCL that does an edit/edt/comm with a substitute on
all .c files in a directory tree is not that hard to write. Doing it
in Macro-32 may take a little longer even for you.

:-)

Arne