Re: [Boost-users] OpenVMS 8.2 port?

From: Boris Gubenko (Boris.Gubenko_at_[hidden])
Date: 2005-11-28 13:58:43

Rene Rivera wrote:

>
> Many compilers support changing the way user includes (#include "")
> are
> handled. They let you specify if the paths should be interpreted
> relative to the source point or relative to the include path, for
> example. Does VMS have such an option? Does it understand relative
> include paths at all? Barring that those includes could be changed
> to
> plain '#include "native.h"' and adding the appropriate include path.
> What is the option for adding an include path? The other solution
> is to
> move the files themselves out of the modules dir, and that's a
> painful
> alternative.
>

The compilers on VMS understand relative include paths and there is
an option telling the compiler how to interpret a relative path:
/NESTED_INCLUDE_DIRECTORY=[INCLUDE_FILE,PRIMARY_FILE]. This is what I
tried first, but, to my surprise, it did not work in this case. It may
be a bug in the compiler, or it may be a "feature" :-). I've asked our
include file processing expert to look into this. I also asked if there
is some other compiler option we can apply in this case and I'm waiting
for the reply (there are tons of include file processing options on
VMS).

However, if it turns out to be a compiler bug which will be fixed in
some future release of the compiler, it makes sense to implement a
solution which would work with the current released compilers. If
changing directory is not an option (it was convenient enough to do
in the .com script), changing includes to plain '#include "native.h"'
(probably, under the '#ifdef __vms' condition) and adding include path
pointing to current working directory (via /INCLUDE=[] switch) is an
obvious workaround.

>
> If I remember correctly, I would have to search the boost.build list
> archives to be sure, if it's not in the VAXC mode it would not just
> generate warnings but errors. Don't remember what or why though.
>

On VMS, there are informational messages, warnings and errors. What I'm
talking about is disabling informational messages or just one
particular informational message which was generated when compiling
the sources in relaxed ANSI mode (the default).

On VMS, warnings are bad because the compiler marks the .obj file as
having compilation warnings and it has ramifications for linking and
dlopen'ing. Although the warnings can be disabled, if the source
generates warnings in relaxed ANSI mode, perhaps, the source should
be fixed. But, again, all I saw in relaxed ANSI mode was: "the
identifier ... is implicitly declared as a function".

>
> OK. Thanks. Hopefully Philip will post his version of the script so
> I
> can compare and merge.
>

Sure.

>
> You really don't need to quote my entire message with the
> attachment ;-)
>

I know. I realized that after I hit "send" :-)

Boris

----- Original Message ----- 
From: "Rene Rivera" <grafik.list_at_[hidden]>
To: <boost-users_at_[hidden]>
Sent: Sunday, November 27, 2005 11:58 PM
Subject: Re: [Boost-users] OpenVMS 8.2 port?

> Boris Gubenko wrote:
>> Tried it -- see attached. "don't know how to make [.modules]order.c"
>> is because there is no order.c module in 1.31.0.
> 
> Makes sense.
> 
>> The real problem though is the one I've fixed in build_vms.com : on
>> VMS, you cannot compile sources in modules subdirectory unless you cd
>> into this subdirectory. This is because these sources include header
>> files from the parent directory using '#include "../native.h"'
>> directive. This is what I did in build_vms.com:
>> 
>> $ set def [.modules]
>> $ cc 'CC_FLAGS -
>>      path.c, -
>>      property-set.c, -
>>      regex.c, -
>>      sequence.c, -
>>      set.c
>> $ set def [-]
>> 
>> btw, it would be the same if the sources used a VMS-style notation:
>> '#include "[-]native.h"'. In both cases, when compiled from *parent*
>> directory, the compiler would not find include file.
> 
> Many compilers support changing the way user includes (#include "") are 
> handled. They let you specify if the paths should be interpreted 
> relative to the source point or relative to the include path, for 
> example. Does VMS have such an option? Does it understand relative 
> include paths at all? Barring that those includes could be changed to 
> plain '#include "native.h"' and adding the appropriate include path. 
> What is the option for adding an include path? The other solution is to 
> move the files themselves out of the modules dir, and that's a painful 
> alternative.
> 
>> A couple of comments:
>> 
>> Instead of /STANDARD=VAXC I suggest /WARN=NOINFO which would silence
>> all informational messages or /WARN=DISABLE=IMPLICITFUNC  As far as I
>> can tell, the only compiler diagnostics for jam sources was
>> "%CC-I-IMPLICITFUNC the identifier ... is implicitly declared as a
>> function". You don't really need to place compiler in the VAXC mode
>> to compile modern sources :-) This is not a bug, of course.
> 
> If I remember correctly, I would have to search the boost.build list 
> archives to be sure, if it's not in the VAXC mode it would not just 
> generate warnings but errors. Don't remember what or why though.
> 
>> A bug which you cannot see before the link phase is multiply defined
>> symbol for glob. On modern VMS systems, there is a glob function in
>> libc (CRTL in VMS terms). If you want to continue to use your own
>> implementation of glob (which, I think, is a good idea), you need to
>> specify /PREFIX_LIBRARY_ENTRIES=(ALL,EXCEPT=GLOB) instead of
>> /PREFIX_LIBRARY_ENTRIES=ALL_ENTRIES (there is no symbol preemption on
>> VMS). I stumble across this bug when linking bootstrap jam. It is
>> fixed in build_vms.com I sent you.
> 
> OK. Thanks. Hopefully Philip will post his version of the script so I 
> can compare and merge.
> 
> [...]
> 
>>>#~ Copyright 2002-2005 Rene Rivera.
> 
> [...]
> 
> You really don't need to quote my entire message with the attachment ;-)
> 
> 
> -- 
> -- Grafik - Don't Assume Anything
> -- Redshift Software, Inc. - http://redshift-software.com
> -- rrivera/acm.org - grafik/redshift-software.com
> -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
> 
>