Re: [boost] Re: Open Watcom jam files [was: Re: Open watcom]

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.

J

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:
> > [1] provides an environment setup file at [ow]/setvars.bat (whereas for
> > MS it is [vc]/bin/vcvars.bat.
> > [2] 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
> directly?
>     setup = "call \""$(setup)"\" > nul " ;
>
>     if [ os.name ] = NT
>     {
>         setup = $(setup)"
> " ;
>     }
>     else
>     {
>         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