Re: [jamboost] Re: Re: Problem building bjam using build.jam (VMS)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-09-17 06:45:27

Johan Nilsson wrote:

> > Could you please try applying the attached patch?
>
> You did read the part about "voodoo logic", "black magic" and "woe be to
> people who mess with this code" in pathvms.c, right? :-)

Yep. That comment is applicable to the entire jam, to a certain extent. But, 
of course, it easy for me to say ;-)

> Anyway, the patch worked insofar as to producing the desired result, e.g.
> $("[.binvms]":P) == ""). However the semantics doesn't seem to be identical
> under windows where $("./binvms":P) => ".". Haven't tried under unix. Would
> [.binvms] => [] => "" be a better choice? 

I think you are right -- seems this way on unix too.

> Maybe consulting the perforce
> jamming list would be a good idea?

I almost given up with the idea to get any feedback on jamming list, 
unfortunately. Maintainers usually keep silence.

> It was also possible to run 'jam -fbuild.jam", but the next problem was
> that the ".rm" action isn't defined for VMS (which is straightforward to
> fix). 

Strange, I see

if $(VMS) { actions piecemeal together existing .rm. {
DELETE $(>[--2]:J=";*, ") $(>[-1]);*
} }

in build.jam. Do you have an older copy?

> When I started looking through the build.jam file, however it looks
> like it isn't terribly platform independent (only Windows and unices
> supported?). Did any Mac users try "jam -fbuild.jam"?

I don't know the answer, alas. I see some cconditionals for NT, Unix and VMS,
but don't know about Mac.

> One very important thing from my point of view is that multiple definitions
> (e.g. include paths and defines) cannot be specified using multiple
> identical switches with the compilers I'm using (DEC C and DEC C++). If you
> try to execute "cc /DEFINE=X /DEFINE=DEBUG=1" only one of them will be
> applied - same goes for "/INCLUDE". I guess the rationale for this is
> simply that it is the "VMS way". The VMS way to pass "multivalued"
> definitions is to use "/<switch>=(value1,value[=1],...,value_n)", e.g.
> "/INCLUDE=(disk$user1:[common.boost.boost], disk$user2:[mystuff.hdr])
> /DEFINES=(X=Y,NDEBUG)".
>
> Is the above also the case when running Boost.Build (I hope not, but I
> haven't come that far yet).

I think that the problem is that Boost.Build does not support DEC C/C++ at the 
moment. However, when/if that support is implemented (which should not be 
very hard), it easy to create syntax that compiler wants.

> In perforce jam this was handled by some indirection using "DEFINES" and
> "HDRS" (IIRC) with some help from FDefines, FIncludes et al. BTW - what
> happened to compatibility mode - the distributed Jambase doesn't contain
> that stuff anymore.

I'm afraid the compatibility can no longer be guaranteed. For one thing, bjam 
and perforce jam codebases are moving further and further apart. Some of the 
changes are global, which makes merging hard. Some features are not 
compatible. And there's little we can do --- keeping is sync will take time 
and IMO not much benefit. As for Jambase -- this beast was not merged for a 
really long time.

> I'll give you as much help as I can to resolve this (or perhaps the other
> way around :-)

Either way, I hope we'll get bjam/Boost.Build up and running on VMS.

Thanks,
Volodya