|
Boost-Build : |
From: Johan Nilsson (gclbb-jamboost_at_[hidden])
Date: 2003-07-02 02:54:17
Hi,
although this is a question on basic Jam (2.5rc3) and not on boost.build, I
figured it's closely related to this group.
The problem is related to the use of relative paths in include statements
under OpenVMS (yes), e.g. "#include <boost/bind.hpp>" and the header
dependency scanning. For those of you not familiar with the operating system
(and I imagine not so many are) a fictional path for bind.hpp would look
like this:
DISK$USER:[COMMON.BOOST.BOOST]BIND.HPP (earlier versions of the file system
wasn't neither case preserving nor case sensitive).
To make the C++ compiler I'm using (DEC C++ 6.5-0004) work with relative
directories I have to use what's called a concealed rooted logical
definition of the base directory, e.g.:
DEFINE/LOGICAL/TRANSLATION=CONCEALED DISK$USER:[COMMON.BOOST.] BOOST_ROOT
after that I'm able to pass that path to the compiler using UNIX-style(sic)
as follows:
cxx /include=("/boost_root", ...) whatever.cpp
---- in whatever.cpp ---
#include <boost/bind.hpp>
-------------------------
Now, the problem is that Jam isn't able to locate the header due to the
mismatch between path specifications in the operating system and the
compiler. I'm setting up the path for Jam by using HDRS += "\"/boost_root\""
; and the build is ok this way, but the file isn't automatically rebuilt if
the header changes.
I've been reading through the source for Jam, but am having problems finding
the interactions between path_build, path_parse, file_dirscan and all other
stuff. I had a vague idea of intercepting the paths/filenames passed to
these functions, checking if they were UNIX-style and, if so - do some kind
of preprocessing to VMS-ify them (e.g. translate "/boost_root" to
DISK$USER:[COMMON.BOOST]) but I'm having problems making it work. I also
tried duplicating the include directory definitions passed to the compiler
and Jam. e.g. /include=("/boost_root", DISK$USER:[COMMON.BOOST, ...) to make
both Jam and cxx happy but that didn't work out either - perhaps due to some
problem in Jam (path_build?) combining DISK$USER:[COMMON.BOOST] with
"boost/bind.hpp").
I'd like to make this work out and am willing to put some effort into it,
and I imagine boost.build could benefit as well, so my real question is:
Could someone more familiar give me a more thorough explanation of what's
going on during the build, and give me some hints on _what_ needs to be done
(and, even better, also where).
Thanks // Johan
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk