Re: Can C #includes like this be made to work onVMS?

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@dont-email.me>, mail@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