On 5/5/22 6:13 PM, Jake Hamby wrote:

> CC /FLOAT=IEEE_FLOAT/IEEE=DENORM/NAMES=(AS_IS,SHORTENED)/ACCEPT=NOVAXC_KEYWORDS/REENTRANCY=MULTITHREAD/ARCH=EV56/OPT=(TU
> NE=EV67)/ASSUME=NOHEADER_TYPE_DEFAULT/WARNINGS=(WARNINGS=ALL, DISABLE=(EXTRASEMI,MAYLOSEDATA3))/DEBUG/NOOPTIMIZE/LIST=[.
> OUT.DEBUG.OBJ.Objects]bytearrayobject/SHOW=ALL/DEFINE=("Py_BUILD_CORE",_USE_STD_STAT, _POSIX_EXIT, __STDC_FORMAT_MACROS,
> _LARGEFILE, _SOCKADDR_LEN, __SIGNED_INT_TIME_T, USE_ZLIB_CRC32, _OSF_SOURCE, HAVE_EXPAT_CONFIG_H, XML_POOR_ENTROPY, USE
> _PYEXPAT_CAPI, CONFIG_32, ANSI, SOABI="""cpython-310-alpha-openvms""", SHLIB_EXT=""".EXE""", ABIFLAGS="""""", MULTIARCH=
> """cpython-310-alpha-openvms""", PLATFORM="""OpenVMS""", USE_SSL,_DEBUG)/INCLUDE_DIRECTORY=([], [.Include], [.Include.in

If you want those include directories to work with relative paths in
#include directives having relatvie paths and Unix syntax, you'd
probably need to replace:

/INCLUDE=([])

with

/INCLUDE=("./")

> ternal], [.Modules.expat], [.Modules._decimal.libmpdec], [.Modules._multiprocessing], [.Modules._io], [.vms], oss$root:[
> include], dtr$library, SSL111$ROOT:[INCLUDE]) /OBJECT=[.OUT.DEBUG.OBJ.Objects]bytearrayobject.obc [.Objects]bytearrayobj
> ect.c
>
> #include "clinic/bytearrayobject.c.h"
> .^
> %CC-F-NOINCLFILEF, Cannot find file "clinic/bytearrayobject.c.h" specified in #include directive.
> at line number 75 in file USERS:[JHAMBY.Projects.vms-cpython.Objects]bytearrayobject.c;1
> %MMS-F-ABORT, For target [.OUT.DEBUG.OBJ.Objects]bytearrayobject.obc, CLI returned abort status: %X10B91264.
>
> No matter what I do, I can't figure out how to get it to locate the "clinic" subdirectory inside "[.Objects]bytearrayobject.c".

Do you have DECC$EFS_CHARSET defined in the environment? Nothing
involving Unix syntax and two dots in a filename is going to work on VMS
without that.

On Thursday, May 5, 2022 at 9:12:08 PM UTC-4, Steven Schweda wrote:
> > Resurrecting this thread: did anyone ever find a resolution to the
> > problem of the C compiler not being able to find headers when they're
> > referenced in quotes with UNIX-style paths? [...]
>
> Looks to me like a different problem.
>
> > [...] I can't figure out how to get it to locate the "clinic"
> > subdirectory [...]
>
> That's not the actual problem.
>
> Many "UNIX-style paths" work just fine. Simple paths with multiple
> dots also seem to work. _Your_ case fails:
>
> its $ type jh.c;
> #include "a.d.g"
> #include "sd/b.h"
> #include "sd/b.c.h"
>
> its $ cc /noobj jh.c
>
> #include "sd/b.c.h"
> .^
> %CC-F-NOINCLFILEF, Cannot find file "sd/b.c.h" specified in #include directive.
> at line number 3 in file ITS$DKA0:[SMS.itrc.hamby]jh.c;7
>
> The first two directives work. A simple explanation of why the third
> one would fail did not leap to my mind.

My first guess of the "problem" is perhaps the part of the specification ".c". Is this being interpreted as a file extension for a source file rather than parsed as part of the entire file spec? Try changing the .c to .x and try again. If the new extension works, I would suspect the .c

Dan

> [...] you'd probably need to replace:
>
> /INCLUDE=([])
>
> with
>
> /INCLUDE=("./")

Did you ever try that?

> [...] Nothing involving Unix syntax and two dots in a filename is
> going to work on VMS without that.

Do you mean as in the demonstration above, where the following worked
properly?:

#include "a.d.g"

> My first guess [...]

Guess again?

its $ type jh2.c
#include "a.d.g"
#include "sd/b.g"
#include "sd/a.d.g"

its $ cc /noobj jh2.c

#include "sd/a.d.g"
..^
%CC-F-NOINCLFILEF, Cannot find file "sd/a.d.g" specified in #include directive.
at line number 3 in file ITS$DKA0:[SMS.itrc.hamby]jh2.c;2

its $ dire [.sd]

Directory ITS$DKA0:[SMS.itrc.hamby.sd]

a^.d.g;1 b^.c.h;1 b.g;1 b.h;1

_Not_ guessing in a case like this is almost as easy as guessing.

On Thursday, May 5, 2022 at 10:26:26 PM UTC-4, abrsvc wrote:
> My first guess of the "problem" is perhaps the part of the specification ".c". Is this being interpreted as a file extension for a source file rather than parsed as part of the entire file spec? Try changing the .c to .x and try again. If the new extension works, I would suspect the .c
>
> Dan

It's not the ".c", it's the general quirkiness how the CRTL (which the compiler uses)
converts unix-style paths to VMS specifications. Trying defining the logical name
DECC$POSIX_COMPLIANT_PATHS to the value 2, which makes it work on my
system.