Does anyone know of the status of Watcom (http://www.openwatcom.org/) w.r.t. boost compilation? Are there plans to test against this compiler in the future?
Charles Schwartz wrote:
Does anyone know of the status of Watcom (http://www.openwatcom.org/) w.r.t. boost compilation?
I don't.
Are there plans to test against this compiler in the future?
That's not the way testing works. At least, the organization doesn't plan to test on a platform or compiler. Some individual volunteers to set up the process that periodically runs the tests and upload them. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Charles Schwartz wrote:
Does anyone know of the status of Watcom (http://www.openwatcom.org/) w.r.t. boost compilation?
I don't.
Are there plans to test against this compiler in the future?
That's not the way testing works. At least, the organization doesn't plan to test on a platform or compiler. Some individual volunteers to set up the process that periodically runs the tests and upload them.
(hint, hint: if you'd like to volunteer...) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
David Abrahams wrote:
Charles Schwartz wrote:
Does anyone know of the status of Watcom (http://www.openwatcom.org/) w.r.t. boost compilation?
I don't.
Are there plans to test against this compiler in the future?
That's not the way testing works. At least, the organization doesn't plan to test on a platform or compiler. Some individual volunteers to set up the process that periodically runs the tests and upload them.
(hint, hint: if you'd like to volunteer...)
It's now on the to-do list, how's that.
Charles Schwartz wrote:
(hint, hint: if you'd like to volunteer...)
It's now on the to-do list, how's that.
You're very suggestible; I like that ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
At Wednesday 2004-12-01 06:51, you wrote:
David Abrahams wrote:
David Abrahams wrote:
Charles Schwartz wrote:
Does anyone know of the status of Watcom (http://www.openwatcom.org/) w.r.t. boost compilation?
I don't.
Are there plans to test against this compiler in the future?
That's not the way testing works. At least, the organization doesn't plan to test on a platform or compiler. Some individual volunteers to set up the process that periodically runs the tests and upload them.
(hint, hint: if you'd like to volunteer...) It's now on the to-do list, how's that.
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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
At Wednesday 2004-12-01 14:24, you wrote:
At Wednesday 2004-12-01 06:51, you wrote:
David Abrahams wrote:
David Abrahams wrote:
Charles Schwartz wrote:
Does anyone know of the status of Watcom (http://www.openwatcom.org/) w.r.t. boost compilation?
I don't.
Are there plans to test against this compiler in the future?
That's not the way testing works. At least, the organization doesn't plan to test on a platform or compiler. Some individual volunteers to set up the process that periodically runs the tests and upload them.
(hint, hint: if you'd like to volunteer...) It's now on the to-do list, how's that.
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.
well, I found the docs, and went to compile a small source of my own... no STL files are included: Extensions.cpp(8): Error! E059: col(14) unable to open 'set' given how many parts of the STL are used in boost, which STL is recommended for use with Watcom?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law" _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
well, I found the docs, and went to compile a small source of my own... no STL files are included: Extensions.cpp(8): Error! E059: col(14) unable to open 'set'
given how many parts of the STL are used in boost, which STL is recommended for use with Watcom?
I know for sure that STLPort worked with the commercial watcom releases (that was long long ago...). Stefan
At Thursday 2004-12-02 12:46, you wrote:
Victor A. Wagner Jr. wrote:
well, I found the docs, and went to compile a small source of my own... no STL files are included: Extensions.cpp(8): Error! E059: col(14) unable to open 'set' given how many parts of the STL are used in boost, which STL is recommended for use with Watcom?
I know for sure that STLPort worked with the commercial watcom releases (that was long long ago...).
yes, I'm trying that now and bumping into difficulties.... namespace I think I'm rebuilding all of Watcom right now and will give it a go later today
Stefan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
At Wednesday 2004-12-01 06:51, you wrote:
David Abrahams wrote:
David Abrahams wrote:
Charles Schwartz wrote:
Does anyone know of the status of Watcom (http://www.openwatcom.org/) w.r.t. boost compilation?
I don't.
Are there plans to test against this compiler in the future?
That's not the way testing works. At least, the organization doesn't plan to test on a platform or compiler. Some individual volunteers to set up the process that periodically runs the tests and upload them.
(hint, hint: if you'd like to volunteer...)
It's now on the to-do list, how's that.
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. Regards, Reece
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
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
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
participants (3)
-
Alexander Nasonov -
Charles Schwartz -
David Abrahams -
Joaquín Mª López Muñoz -
Reece Dunn -
Stefan Slapeta -
Victor A. Wagner Jr. -
Vladimir Prus