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

[Arne Vajhøj]

On 10/15/2024 3:54 PM, Arne Vajhøj wrote:
> 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.

Or move the include files to [package_name.INCLUDE.package_name].

Any setup where the include path and file system path match
are OK.

Arne