🚀 go-pugleaf

Hi,

after receiving helpful responses on my posting from Tue, 21 Oct 
1997 I now  want to comment on some points of the follow ups and 
tell about the problems solution that fits best for my needs (and 
may be others as well).


Out of my original posting:
>using the **VMS** C++-Compiler CXX v5.5 I have a problem with 
>#include directives that contain relative pathes:
>
>Assume I need these 2 files
>   [proj.main]main.cpp   and   [proj.incl]incl.h
>and  [proj.main]main.cpp  contains the following include directive:
>  #include "../incl/incl.h"
>
>When compiling  main.cpp  with [proj.main]  as default directory, i.e.
> $  set def [proj.main]
> $  cc main.cpp
>everything works fine !
>
>But when I try to do the same with another default directory, like
> $ set def [whatever]
> $ cxx [proj.main]main.cpp
>then the compiler aborts and tells 
>> %CXX-F-NOINCLFILE, Cannot find file "../incl/incl.h" specified in 
>> #include directive.
>
>Setting the qualifier  /include_directory=([proj.incl]) doesn't
>help either.


Shane Smith wrote:
>If I read your problem correctly, you're telling the compiler to look
>for files in locations specified relative to your default directory, and
>wondering why it can't find them when you're in a different default directory.
No, I expected that the compiler searches the include file relative to
the directory which keeps the main file.
Other compilers (like Watcom C++) on other operating systems have
absolutly no problems with this !

Shane continued:
>"../incl/incl.h" means "In the directory called INCL below my current
>one". If you're not in the directory above INCL, of course it can't find
>it.
No, UNIX shells interpret this as "in the directory called INCL 
*next to* the current one". 
The only question now is, how does the *compiler* interpret this ?
Relative to the directory from which the compiler was called, i.e. the
default directory, OR (and that's what I expected) relative to the
directory in which the file is stored that is presently beeing
compiled. 


David Mathog wrote:
>I don't know what the C++ standard (sic) says, but relative paths are a
>violation of the ANSI C standard.  The best solution is to remove all
>relative paths from all includes, make sure that each header file has a
>unique name, and then use the /include= command line qualifier to pick up
>the ones you need. 

The "Working Paper f. Draft Proposed Intern. Standard f. Information
Systems -- C++" (from Jan '96, chapter 16.2, see
http://gateway.dtseng.com/sig/rsm/cxx/jan96/ ) writes about this topic
that "the named source file is searched for in an implementation-
defined manner."

And for example the Watcom-C++-Manual allows all kind of file
specifications (including drive and path) in the #include directive
explicitly !
Unfortunatly I can't find such information in the VMS CXX Online
Information.

But is there any rational reason for a compiler working in an
operating system that uses a hierarchical file system not to allow
relative file specifications ???


Finally our solution:
With our system managers help I now know what the technical problem
was and how to solve it in manner that doesn't require to reorganize
my existing source files or to use additional logicals:

However, to ensure that the compiler (called from an arbitrary default
directory, and currently compiling the file DISK:[proj.main]main.cxx)
finds the include file  DISK:[proj.incl]incl.h which is relatively(!)
specified in a UNIX typical way like  
     #include "../incl/incl.h",
one has to write the specification of the /INCLUDE_PATH qualifier
**in a UNIX typical** form, too.

Here this means that
        /INCLUDE_PATH="/disk/proj/main"  (and 
        /INCLUDE_PATH="/disk/proj/incl"   as well, of course) 
work fine, whereas 
	/INCLUDE_PATH="DISK:[proj.main]"
fails.


I hope this can help others, too, and
many thanks for the fast suggestions of help to 
Shane Smith, David Mathog and mr.sargon !

With kind regards,
Christian.