Conference turris::c_plus_plus

        .-1 reminds me of topics 3138 and 3139 in this conference.
        
        Dan

Well, this becomes stranger, with no logical rw defined at all, look at this :

$ type testje.cxx
#include <rw/file1.h>
#include <rw/sub/file2.h>
void main(void)
{
}
$ cc/version nl:
DEC C++ V5.5-017 on OpenVMS Alpha V7.1
$ cxx/include=tp_im$users:[dekeyser.rw] testje !ok
$ show log tp_im$users /full
"TP_IM$USERS" [exec] = "DBC022$DKA300:[USERS.TP_IM.]" [concealed] (LNM$SYSTEM_
TABLE)
$  cxx/include=DBC022$DKA300:[USERS.TP_IM.dekeyser.rw] testje

#include <rw/file1.h>
.^
%CXX-F-NOINCLFILE, Cannot find file <rw/file1.h> specified in #include directive
.
at line number 1 in file TP_IM$USERS:[DEKEYSER]TESTJE.CXX;1

#include <rw/file1.h>
.^
%CXX-E-NOOBJ, Object file deleted.
at line number 1 in file TP_IM$USERS:[DEKEYSER]TESTJE.CXX;1

$ cxx/version nl:
DEC C++ V5.5-017 on OpenVMS Alpha V6.1-1H2
$ cxx/include=$RDK:[CUSTOMERS.SIDMAR.CXX.rw] testje !ok 
$ show log $rdk/full
 "$RDK" [exec] = "$1$DUA1000:[TP_IM.DEKEYSER.]" [concealed,terminal] (LNM$SYSTEM
_TABLE)
$ cxx/include=$1$DUA1000:[TP_IM.DEKEYSER.CUSTOMERS.SIDMAR.CXX.RW] testje

#include <rw/file1.h>
.^
%CXX-F-NOINCLFILE, Cannot find file <rw/file1.h> specified in #include directive
.
at line number 1 in file $RDK:[CUSTOMERS.SIDMAR.CXX]TESTJE.CXX;1

#include <rw/file1.h>
.^
%CXX-E-NOOBJ, Object file deleted.
at line number 1 in file $RDK:[CUSTOMERS.SIDMAR.CXX]TESTJE.CXX;1

RE .0:

> def rw dsa1:[project1.rw],dsa1:[project1.rw.]

The thought here, I guess, is that by making a search list with
a translation to a directory spec for rw, and to a rooted spec
for directories rooted at rw, that it should work correctly for both

    RW:FILE1.H
      and
    RW:[SUB]FILE2.H

I agree that seems quite logical and nice, but as far as I know it
never has worked that way in RMS.  If you're seeing it work on
OpenVMS V7.1, then I'll guess the change is in RMS services like
SYS$PARSE rather than the DEC C RTL - unless somebody has really
hacked on decc$to_vms to analyze search lists and such.

The problem here is trying to use a VMS search list to simulate the
simple pathname-concatenation processing of NT and UNIX compilers.
You should just use the same mechanism on VMS.  On nt you had:

        c:\rw\file1.h
	c:\rw\sub\file2.h

So you made the include path be the common part preceding the rw in your
#include directives, "c:\".

On VMS, you have:

        dsa1:[project1.rw]file1.h
        dsa1:[project1.rw.sub]file2.h

So you want to do the same thing, and use the include path dsa1:[project1.
The problem is that the VMS syntax rigidly distinguishes directory
names from file names, and you can't just append one or the other
to the same prefix.  Instead of using a VMS logical name containing a
mixture of directory names and root names, just specify the path
using pathname syntax:  /include="/dsa1/project1".


RE .2:

This isn't really a complete reproducer, but I suspect that what's
going on is related either to the current default device/directory,
or something else with RMS defaulting the "device" to include the
directory spec within the concealed rooted logical.  You should
be able to duplicate the behavior using f$parse lexical functions
in DCL.  For a /include qualifier that is not UNIXy and a #include
directive that is UNIXy, the compiler translates the UNIXy name
using decc$to_vms, and then calls $PARSE with the translated name
as the primary filespec and the /include qualifier value as the
default filespec.

  Rudy being out this week,I've take the problem over.

  About .2, this effectively works because the test was performed from the 
  directory above [.rw]

  Note that, given the description, their is a syntax that should work and 
  doesn't in every cases:

     For the angle-bracketed form, the search order is as follows:

     1. Search the file location indicated by a slash (/). 
	This is a UNIX-style name that can combine only
	with UNIX names specified explicitly in the #include
	directive. It causes a specification like <sys/types.h>
	to be considered first as /sys/types.h, which will be
	translated to SYS:TYPES.H.

  So by defining a logical name RW to be the upper directory of inclusion (i.e. 
  tp_im$users:[dekeyser.rw] in case .2), the compiler should find the included 
  files. It does in V7.1 but doesn't in V6.2. Probably some changes in VMS or C 
  RTLs.

  I've proposed the customer to specify the /INCLUDE_DIRECTORY in a UNIXy way: 
  this work in all cases: cxx/include="/tp_im$users/dekeyser". And is logic. 
  And if they use Unix style, they're better to continue, and...

  Best,
  Mich�le.

>     1. Search the file location indicated by a slash (/). 
>	This is a UNIX-style name that can combine only
>	with UNIX names specified explicitly in the #include
>	directive. It causes a specification like <sys/types.h>
>	to be considered first as /sys/types.h, which will be
>	translated to SYS:TYPES.H.
>
>  So by defining a logical name RW to be the upper directory of inclusion (i.e. 
>  tp_im$users:[dekeyser.rw] in case .2), the compiler should find the included 
>  files. It does in V7.1 but doesn't in V6.2. Probably some changes in VMS or C 
>  RTLs.

If the logical name RW is defined as tp_im$users:[dekeyser.rw], then when
<rw/file1.h> gets translated by step 1 above to rw:file1.h, the file is
found.  But then <rw/sub/file2.h> gets translated to rw:[sub]file2.h,
and with the specified definition for rw this is not a valid filespec;
in order to get this one to work, the definition of rw needs to be a
"rooted" directory spec: tp_im$users:[dekeyser.rw.].  The base note did
not say that the simple definition of rw worked on V7.1, it used a
search list using a combination of simple directory spec and rooted spec:

> $ def rw dsa1:[project1.rw],dsa1:[project1.rw.]

On a V6.2 system using this kind of search list, the $parse service says
that rw:[sub] has an error in the directory name.  I'll guess that V7.1
fixed $parse to be more reasonable.  Even on a V6.2 system, you can notice
a peculiar behavior difference depending on the order of the rooted
and simple directory specs in the translation:

$! Put rooted spec last, top-level ok, subdir absolutely fails
$
$ def rw NT$:[REPETE.CXX3468.RW],NT$:[REPETE.CXX3468.RW.]
$ dir rw:file1.h

Directory NT$:[REPETE.CXX3468.RW]

FILE1.H;1

Total of 1 file.
$ dir rw:[sub]file2.h
%DIRECT-E-OPENIN, error opening RW:[SUB]FILE2.H as input
-RMS-F-DIR, error in directory name
$
$! Put rooted spec first, top-level ok, subdir complains but file still found!
$
$ def rw NT$:[REPETE.CXX3468.RW.],NT$:[REPETE.CXX3468.RW]
$ dir rw:file1.h

Directory NT$:[REPETE.CXX3468.RW]

FILE1.H;1

Total of 1 file.
$ dir rw:[sub]file2.h

Directory NT$:[REPETE.CXX3468.RW.][SUB]

%DIRECT-E-OPENIN, error opening RW:[SUB]FILE2.H as input
-RMS-F-DIR, error in directory name
FILE2.H;1

Total of 1 file.
$

But as suggested both in .3 and .4, since they're trying to duplicate an
NT environment where pathnames concatenate essentially the same as on UNIX,
they're better of using the concatenable UNIXy style of name in the
/include qualifier.