I saw his old reply to my message two times this evening. These message has proper time but they're old. Apparently, they're sent automatically by some program, not by Volodya. Joaqu?n M? L?pez Mu?oz wrote:
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Alexander Nasonov