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"
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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users