[jamming] Majam - keeping jam up-to-date

David Turner dturner at nds.com
Thu Aug 10 01:02:59 PDT 2006


Regarding MacOS, Jam was never used to drive the build anyway, all it did
was output a list of commands that had to be run with another tool
(CodeWarrior or MPW ?). I'm pretty certain that very few users of this
feature exist, so dropping MacOS support shouldn't be a problem.

Regarding VMS, maybe there is a way to still specify paths in the Jamfiles
with the 'standard' ".", ".." and "/" separators, and translating them 
on the go
into the corresponding VMS-ims (kind of like when you translate "/" into 
"\"
for Windows paths)

this would allow for simpler Jamfiles while still supporting the platform.

However, devil is in the details. Anyone has a good web pages explaining
the delicacies of VMS file systems without too much head scratching ?
Is there any specific reason why this wouldn't be practical for VMS users ?

Regards,

- David Turner
- The FreeType Project  (www.freetype.org)

Alen Ladavac a écrit :
>> I see the `needed _host_` problem a little different. If jam can be
>> ported on a platform,
>> port it. I dont see how that would greatly influence other files than
>> the builtin-Jambase, which has around 1200 lines.
>>     
>
> The biggest problem I see is for example old MacOS using ":" both as
> SLASH and as DOT, and "::" as a DOTDOT. Also, VMS using "." as SLASH
> and "[]"/"[-]" as DOT/DOTDOT. The potential problem here is that I see
> a lot of mumbo-jumbo going on in path parsing and in the default
> Jambase in order to work with these strange setups. In my
> modifications, I simply allowed the paths to be specified directly
> with "/", and only eventually is that converted to "\" on NT when
> needed. I have completely removed the notions of SLASH, DOT and
> DOTDOT, what simplified the scripts a lot, and simplified the code
> itself somewhat.
>
> Now, I don't have any experience in those systems whatsoever, so I
> don't claim I know whether it might still be possible to use the
> "/"-only paths and convert when needed. But if it is not, the first
> thing I'd do would be to drop support for those OSs. I simply don't
> expect to need it ever. Perhaps I'm a bit selfish, but I like to
> simplify things for me. :)
>
>   
>> But this can be overriden using a splited Jambase, for each supported platform,
>> that retains only the rules/actions needed for _host_.
>>     
>
> I hope we are all into the same distinction between host and target
> systems? (Jam originally doesn't make this distinction so what is the
> best thing to do about it? Or should anything be done at all, or just
> let everyone come up with individual solutions?)
>
> Cheers,
> Alen
>
>
> _______________________________________________
> jamming mailing list  -  jamming at perforce.com
> http://maillist.perforce.com/mailman/listinfo/jamming
>
>   


***********************************************************************************
Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the postmaster at nds.com and destroy the original message.
*********************************************************************************** 


More information about the jamming mailing list