From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2005-03-30 11:50:21
Volodya, your mails are shown to me as having a
delivery date very distant in the past (dec 2004).
I doubt it's a local problem here, I guess your computer
clock is not adjusted.
Vladimir Prus ha escrito:
> Reece Dunn wrote:
> >> I've installed it and am trying to figure out how to write the base .jam
> >> for the compiler (need to read how to use it from the command line 1st,
> >> I guess) then I'll add it to my regression collection.
> > I am looking at an installation on v1.3 and from the quick scan I have
> > done it seems that it should be possible to adapt the MS VC++ toolset
> > (both BBv1 and BBv2) since Open Watcom:
> >  provides an environment setup file at [ow]/setvars.bat (whereas for
> > MS it is [vc]/bin/vcvars.bat.
> >  provides an implementation of cl.exe at [ow]/binnt/cl.exe -- it
> > should be easy to adapt to open watcom.
> > As far as I can tell, this should be fairly trivial for BBv1. The
> > question is: how do we deal with BBv2.
> > Looking at this in general, the Digital Mars compiler provides a CL
> > adapter, so it should be possible to do:
> > using msvc : 7.0 : "c:/.../vc/bin/cl.exe" ;
> > using ow : 1.3 : "c:/watcom/binnt/cl.exe" ;
> > using dm : 8.4 : "c:/dm/bin/cl.exe" ;
> > where ow and dm are defined something like (pseudocode):
> > # ow.jam
> > import msvc ; # bring in the msvc toolset
> > msvc.adapter : ow : 6.0 ; # treat the ow toolset as a msvc-6.0 clone.
> > # tell msvc where the environment configuration is relative to cl.exe
> > msvc.setup : ow : "../setvars.bat" ;
> > # --end ow.jam
> > I don't know how easy this would be to implement. The alternative would
> > be to duplicate the msvc.jam configuration and adapt it for OpenWatcom
> > and DigitalMars compilers.
> I think the right solution would work like this:
> # ow.jam
> toolset.inherit ow : msvc ;
> rule init ( version : command * )
> # The following is needed for all toolsets anyway.
> local condition = [ common.check-init-parameters cw :
> version $(version) ] ;
> # If version is specified, we try to search first in default paths,
> # and only then in PATH.
> command = [ common.get-invocation-command msvc : cl.exe : $(command)
> : [ default-paths $(version) ] : $(version) ] ;
> common.handle-options msvc : $(condition) : $(command) : $(options) ;
> # The following is a msvc-specific logic for detecting setup script
> if $(command)
> command = [ common.get-absolute-tool-path $(command[-1]) ] ;
> local root = $(command:D) ;
> setup = $(root)\\bin\\$(setup) ;
> # CONSIDER: What's the point of 'call'. Can we invoke the script
> setup = "call \""$(setup)"\" > nul " ;
> if [ os.name ] = NT
> setup = $(setup)"
> " ;
> setup = "cmd /S /C "$(setup)" \"&&\" " ;
> # prefix with setup, or quoted path if any
> local prefix = $(setup) ;
> flags ow.compile .CC $(condition) : $(prefix)$(compiler) ;
> flags ow.compile .RC $(condition) : $(prefix)$(resource-compiler) ;
> flags ow.link .LD $(condition) : $(prefix)$(linker) ;
> flags ow.archive .LD $(condition) : $(prefix)$(linker) ;
> Now, the part of locate script is just a copy paste, so it would be
> reasonable to factor it out into some function in the msvc module, and just
> call it from ow.jam.
> - Volodya
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk