When I check out and build the latest VM on FreeBSD, disabledPlugins.c contains some duplicated definitions (reported in an earlier mail).
I tried to find what generates that file in VMMaker, and failed. I've tried grepping the contents of the mcz, and can't find any mention of "disabled".
(But as long as I say --without-npsqueak, and remove the offending duplications from disabledPlugins.c, the Cog VM compiled on FreeBSD!)
frank
platforms/unix/config/mktargets
e.g. find platforms -name .svn -print -o ( -type f ) -exec grep -H disabledPlugins {} ; | fgrep -v .svn
which is useful enough to wrap up in a script (which I link to $HOME/bin/findsvn $HOME/bin/findgit & $HOME/bin/findcvs, etc.
#!/bin/sh #IFS=<tab><nl> IFS=' ' DIR=.svn case $0 in *git) DIR=.git;; *cvs) DIR=CVS;; esac DIRS= while [ -n "$1" -a -d "$1" ]; do DIRS="$DIRS $1" shift done find ${DIRS:-.} -name $DIR -prune -o ( "$@" ) | grep -v /$DIR
On Tue, Jul 20, 2010 at 1:29 AM, Frank Shearar <frank.shearar@angband.za.org
wrote:
When I check out and build the latest VM on FreeBSD, disabledPlugins.c contains some duplicated definitions (reported in an earlier mail).
I tried to find what generates that file in VMMaker, and failed. I've tried grepping the contents of the mcz, and can't find any mention of "disabled".
(But as long as I say --without-npsqueak, and remove the offending duplications from disabledPlugins.c, the Cog VM compiled on FreeBSD!)
frank
Ah, that leads me right to the problem. Thanks, Eliot!
OK, so first, the standard warning that I'm a clueless newbie, so please forgive any silly questions.
It looks like this is what happens: when you run configure, lines 27296 - 27362 check to see if you're building vm-sound-OSS. If not, that plugin's added to the variable disabled_plugins.
But later, lines 28696 - 28708 do the same thing. (Checkpoint 1)
Later on, that variable's turned into a file plugins.exc (for "except", I guess).
mktarget then builds a disabledPlugins.c with duplicate entries for those two plugins.
Going back to Checkpoint 1 above, configure itself looks like it's generated by something (autoconf?) from configure.ac, which has special cases for the Problem Plugins:
AC_ARG_WITH(vm-sound-OSS, [ --without-vm-sound-OSS disable OSS vm sound support default=enabled]], [with_vm_sound_OSS="$withval"], [with_vm_sound_OSS="yes"]) if test "$with_vm_sound_OSS"="no"; then AC_PLUGIN_DISABLE_PLUGIN(vm-sound-OSS); fi
So this and the corresponding chunk for vm-display-fbdev must be commented out, and configure regenerated, and then presumably disabledPlugins.c won't have duplications.
Now I'm happy to do the legwork here, but I've never touched autoconf or m4 stuff in my life. Any hints would be greatly appreciated!
frank
On 2010/07/20 19:37, Eliot Miranda wrote:
platforms/unix/config/mktargets
e.g. find platforms -name .svn -print -o ( -type f ) -exec grep -H disabledPlugins {} ; | fgrep -v .svn
which is useful enough to wrap up in a script (which I link to $HOME/bin/findsvn $HOME/bin/findgit & $HOME/bin/findcvs, etc.
#!/bin/sh #IFS=<tab><nl> IFS=' ' DIR=.svn case $0 in *git) DIR=.git;; *cvs) DIR=CVS;; esac DIRS= while [ -n "$1" -a -d "$1" ]; do DIRS="$DIRS $1" shift done find ${DIRS:-.} -name $DIR -prune -o ( "$@" ) | grep -v /$DIR
On Tue, Jul 20, 2010 at 1:29 AM, Frank Shearar <frank.shearar@angband.za.org mailto:frank.shearar@angband.za.org> wrote:
When I check out and build the latest VM on FreeBSD, disabledPlugins.c contains some duplicated definitions (reported in an earlier mail). I tried to find what generates that file in VMMaker, and failed. I've tried grepping the contents of the mcz, and can't find any mention of "disabled". (But as long as I say --without-npsqueak, and remove the offending duplications from disabledPlugins.c, the Cog VM compiled on FreeBSD!) frank
Hi Frank,
On Wed, Jul 21, 2010 at 11:41 AM, Frank Shearar < frank.shearar@angband.za.org> wrote:
Ah, that leads me right to the problem. Thanks, Eliot!
OK, so first, the standard warning that I'm a clueless newbie, so please forgive any silly questions.
It looks like this is what happens: when you run configure, lines 27296 - 27362 check to see if you're building vm-sound-OSS. If not, that plugin's added to the variable disabled_plugins.
But later, lines 28696 - 28708 do the same thing. (Checkpoint 1)
Later on, that variable's turned into a file plugins.exc (for "except", I guess).
mktarget then builds a disabledPlugins.c with duplicate entries for those two plugins.
Going back to Checkpoint 1 above, configure itself looks like it's generated by something (autoconf?) from configure.ac, which has special cases for the Problem Plugins:
AC_ARG_WITH(vm-sound-OSS, [ --without-vm-sound-OSS disable OSS vm sound support default=enabled]], [with_vm_sound_OSS="$withval"], [with_vm_sound_OSS="yes"]) if test "$with_vm_sound_OSS"="no"; then AC_PLUGIN_DISABLE_PLUGIN(vm-sound-OSS); fi
So this and the corresponding chunk for vm-display-fbdev must be commented out, and configure regenerated, and then presumably disabledPlugins.c won't have duplications.
I think the fix here is to make the disabledPlugins list unique, done in configure.ac via echo ${disabled_plugins} | tr ' ' '\012' | sort -u > plugins.exc
I'll check this in.
But the more serious issue is that the configure in VMMaker is only suitable for linux. I guess that the right thing to do for FreeBSD is to run make in platforms/unix/config to generate a FreeBSD-specific configure. But I'm out of my depth when it comes to autoconf.
Now I'm happy to do the legwork here, but I've never touched autoconf or m4 stuff in my life. Any hints would be greatly appreciated!
I've hacked until I could get Cog to compile but that's a long way from understanding what the right thing to do here is.
frank
On 2010/07/20 19:37, Eliot Miranda wrote:
platforms/unix/config/mktargets
e.g. find platforms -name .svn -print -o ( -type f ) -exec grep -H disabledPlugins {} ; | fgrep -v .svn
which is useful enough to wrap up in a script (which I link to $HOME/bin/findsvn $HOME/bin/findgit & $HOME/bin/findcvs, etc.
#!/bin/sh #IFS=<tab><nl> IFS=' ' DIR=.svn case $0 in *git) DIR=.git;; *cvs) DIR=CVS;; esac DIRS= while [ -n "$1" -a -d "$1" ]; do DIRS="$DIRS $1" shift done find ${DIRS:-.} -name $DIR -prune -o ( "$@" ) | grep -v /$DIR
On Tue, Jul 20, 2010 at 1:29 AM, Frank Shearar <frank.shearar@angband.za.org mailto:frank.shearar@angband.za.org> wrote:
When I check out and build the latest VM on FreeBSD, disabledPlugins.c contains some duplicated definitions (reported in an earlier mail).
I tried to find what generates that file in VMMaker, and failed. I've tried grepping the contents of the mcz, and can't find any mention of "disabled".
(But as long as I say --without-npsqueak, and remove the offending duplications from disabledPlugins.c, the Cog VM compiled on FreeBSD!)
frank
On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:
But the more serious issue is that the configure in VMMaker is only suitable for linux. I guess that the right thing to do for FreeBSD is to run make in platforms/unix/config to generate a FreeBSD-specific configure. But I'm out of my depth when it comes to autoconf.
Note that Ian moved to CMake for the unix builds, so autoconf is no longer used for building from the SVN trunk. In addition, Geoffroy Couprie has developed this further such that the VM can be built for both unix and Windows targets, see thread here:
http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html
It's up to Ian and Andreas to say if they want to pursue this direction, but if you need the Cog build process to be more platform independent this would be a good thing to consider.
Dave
On 7/22/2010 4:55 AM, David T. Lewis wrote:
On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:
But the more serious issue is that the configure in VMMaker is only suitable for linux. I guess that the right thing to do for FreeBSD is to run make in platforms/unix/config to generate a FreeBSD-specific configure. But I'm out of my depth when it comes to autoconf.
Note that Ian moved to CMake for the unix builds, so autoconf is no longer used for building from the SVN trunk. In addition, Geoffroy Couprie has developed this further such that the VM can be built for both unix and Windows targets, see thread here:
http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html
It's up to Ian and Andreas to say if they want to pursue this direction, but if you need the Cog build process to be more platform independent this would be a good thing to consider.
Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now: * Availability of the tool chain: There have been free versions of MSVC for years now, so this is no longer an issue. * Performance of the VM: With the JIT, the performance difference between the compilers no longer matters. * Size of difficulty of the install: New versions of MingW are no easier to install than Cygwin or other monsters.
On the other hand, there are some exceptionally good reasons to use MSVC: * Debugging: Did you know that MSVC now has seemless in-place editing? When I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked! * Up-to-date headers and libraries: SqueakSSL wouldn't compile on *any* version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old. * Consistent use of runtime libraries: For some external linkage, having the latest MSVC platform libraries available is important.
At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.
Cheers, - Andreas
Andreas Raab wrote:
On 7/22/2010 4:55 AM, David T. Lewis wrote:
On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:
But the more serious issue is that the configure in VMMaker is only suitable for linux. I guess that the right thing to do for FreeBSD is to run make in platforms/unix/config to generate a FreeBSD-specific configure. But I'm out of my depth when it comes to autoconf.
Note that Ian moved to CMake for the unix builds, so autoconf is no longer used for building from the SVN trunk. In addition, Geoffroy Couprie has developed this further such that the VM can be built for both unix and Windows targets, see thread here:
http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html
It's up to Ian and Andreas to say if they want to pursue this direction, but if you need the Cog build process to be more platform independent this would be a good thing to consider.
Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now:
- Availability of the tool chain: There have been free versions of
MSVC for years now, so this is no longer an issue.
- Performance of the VM: With the JIT, the performance difference
between the compilers no longer matters.
- Size of difficulty of the install: New versions of MingW are no
easier to install than Cygwin or other monsters.
On the other hand, there are some exceptionally good reasons to use MSVC:
- Debugging: Did you know that MSVC now has seemless in-place editing?
When I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked!
- Up-to-date headers and libraries: SqueakSSL wouldn't compile on
*any* version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old.
- Consistent use of runtime libraries: For some external linkage,
having the latest MSVC platform libraries available is important.
At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.
Cheers,
- Andreas
Hi Andreas,
A few possible issues:
I heard that the MS tools can't reasonably be used with less than 2Gb of ram and a fast processor. I've been regularly using the Win VM building setup suggested by you for years on a P3 with 1Gb of memory. And my current Win environment is a 1Gb VirtualBox inside a 2.5Gb Mac. I know, I could dual boot to Win, to have the full 2.5Gb for it...
Besides, Cog does not generate native code for every CompiledMethod in the system, so I wonder if there would be a visible performance loss leaving GCC.
Cheers, Juan Vuletich
On 7/22/2010 9:00 AM, Juan Vuletich wrote:
I heard that the MS tools can't reasonably be used with less than 2Gb of ram and a fast processor. I've been regularly using the Win VM building setup suggested by you for years on a P3 with 1Gb of memory. And my current Win environment is a 1Gb VirtualBox inside a 2.5Gb Mac. I know, I could dual boot to Win, to have the full 2.5Gb for it...
That's the tools. You don't need to use much of the tools if you only want to recompile (in fact, hopefully none). In other words, even if this is true you should be no worse off than today.
Besides, Cog does not generate native code for every CompiledMethod in the system, so I wonder if there would be a visible performance loss leaving GCC.
That remains to be seen, but I don't think this is going to be an issue. The performance differences have been historically high in micro benchmarks (2x) but much less pointed in macro benchmarks (10%). In fact, when measuring performance without the core interpreter loop (i.e., just the primitives) the MS compiler historically fared better than GCC (noticable for example for complex BitBlt rules). The big gain of GCC was static register assignments for interpret() which has been severely broken in GCC 3 and 4 (which is the reason I'm sticking with 2.95.2). And since the core interpreter loop is precisely what Cog optimizes I would actually expect a net benefit but we'll have to run the benchmarks to be sure.
Cheers, - Andreas
Andreas Raab wrote:
On 7/22/2010 9:00 AM, Juan Vuletich wrote:
I heard that the MS tools can't reasonably be used with less than 2Gb of ram and a fast processor. I've been regularly using the Win VM building setup suggested by you for years on a P3 with 1Gb of memory. And my current Win environment is a 1Gb VirtualBox inside a 2.5Gb Mac. I know, I could dual boot to Win, to have the full 2.5Gb for it...
That's the tools. You don't need to use much of the tools if you only want to recompile (in fact, hopefully none). In other words, even if this is true you should be no worse off than today.
Great!
Besides, Cog does not generate native code for every CompiledMethod in the system, so I wonder if there would be a visible performance loss leaving GCC.
That remains to be seen, but I don't think this is going to be an issue. The performance differences have been historically high in micro benchmarks (2x) but much less pointed in macro benchmarks (10%). In fact, when measuring performance without the core interpreter loop (i.e., just the primitives) the MS compiler historically fared better than GCC (noticable for example for complex BitBlt rules). The big gain of GCC was static register assignments for interpret() which has been severely broken in GCC 3 and 4 (which is the reason I'm sticking with 2.95.2). And since the core interpreter loop is precisely what Cog optimizes I would actually expect a net benefit but we'll have to run the benchmarks to be sure.
Cheers,
- Andreas
I see. So maybe this even brings an actual performance improvement! Thanks for your answer, and for your constant and continued effort on the Windows VM.
Cheers, Juan Vuletich
Hello,
On Thu, Jul 22, 2010 at 5:20 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 7/22/2010 4:55 AM, David T. Lewis wrote:
On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:
But the more serious issue is that the configure in VMMaker is only suitable for linux. I guess that the right thing to do for FreeBSD is to run make in platforms/unix/config to generate a FreeBSD-specific configure. But I'm out of my depth when it comes to autoconf.
Note that Ian moved to CMake for the unix builds, so autoconf is no longer used for building from the SVN trunk. In addition, Geoffroy Couprie has developed this further such that the VM can be built for both unix and Windows targets, see thread here:
http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html
It's up to Ian and Andreas to say if they want to pursue this direction, but if you need the Cog build process to be more platform independent this would be a good thing to consider.
Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now:
- Availability of the tool chain: There have been free versions of MSVC for
years now, so this is no longer an issue.
* Performance of the VM: With the JIT, the performance difference between
the compilers no longer matters.
- Size of difficulty of the install: New versions of MingW are no easier to
install than Cygwin or other monsters.
MSYS is not that hard to install. And GCC can be use to cross compile, which is really useful for tests, continuous integration, etc.
On the other hand, there are some exceptionally good reasons to use MSVC:
- Debugging: Did you know that MSVC now has seemless in-place editing? When
I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked!
- Up-to-date headers and libraries: SqueakSSL wouldn't compile on *any*
version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old.
Did you check the recent headers? Most of the recent API (XP/Vista) are in the actual MinGW headers. The DirectX headers are a bit old, but considering you're using DirectX 7, I don't think that's an issue. What specific headers/libraries/functions are you talking about?
- Consistent use of runtime libraries: For some external linkage, having
the latest MSVC platform libraries available is important.
At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.
Well, here goes my shameless advertisement: CMake could be used to generate Makefiles for MSVC :) I think it would still need to be fixed though, but that's less work to do.
Anyway, do you think you could keep the code compatible with GCC? I could take care of the header fixes.
Best regards,
Geoffroy
Hi Geoffroy,
On Thu, Jul 22, 2010 at 10:34 AM, Geoffroy Couprie geo.couprie@gmail.comwrote:
Hello,
On Thu, Jul 22, 2010 at 5:20 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 7/22/2010 4:55 AM, David T. Lewis wrote:
On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:
But the more serious issue is that the configure in VMMaker is only suitable for linux. I guess that the right thing to do for FreeBSD is to run make in platforms/unix/config to generate a FreeBSD-specific configure. But I'm out of my depth when it comes to autoconf.
Note that Ian moved to CMake for the unix builds, so autoconf is no longer used for building from the SVN trunk. In addition, Geoffroy Couprie has developed this further such that the VM can be built for both unix and Windows targets, see thread here:
http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html
It's up to Ian and Andreas to say if they want to pursue this direction, but if you need the Cog build process to be more platform independent this would be a good thing to consider.
Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now:
- Availability of the tool chain: There have been free versions of MSVC
for years now, so this is no longer an issue.
- Performance of the VM: With the JIT, the performance difference between
the compilers no longer matters.
- Size of difficulty of the install: New versions of MingW are no easier
to install than Cygwin or other monsters.
MSYS is not that hard to install. And GCC can be use to cross compile, which is really useful for tests, continuous integration, etc.
What about C++ compilation?
On the other hand, there are some exceptionally good reasons to use MSVC:
- Debugging: Did you know that MSVC now has seemless in-place editing?
When I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked!
- Up-to-date headers and libraries: SqueakSSL wouldn't compile on *any*
version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old.
Did you check the recent headers? Most of the recent API (XP/Vista) are in the actual MinGW headers. The DirectX headers are a bit old, but considering you're using DirectX 7, I don't think that's an issue. What specific headers/libraries/functions are you talking about?
The thread info block TIB isn't provided, a hack is required to get multi-monitor stuff to compile against directx7, CommandLineToArgvW doesn't appear to compile correctly. WS_ACTIVECAPTION is not defined. STACK_SIZE_PARAM_IS_A_RESERVATION is not defined. Some socket constants are not defined, etc, etc. Look for references to __MINGW32__, !defined & ifndef in platforms/win32 in the Cog tree. Not a lot current;y because we moved to cygwin and gcc 3.4.4, but when we were with the old 2.95 there was a lot more. As far as we're aware gcc 2.95 still produces better code for the interpreter than either gcc 3.x or 4.x (although I suspect that one needs to declare global registers differently, i,e. prefix them with static, and things will be copacetic again).
- Consistent use of runtime libraries: For some external linkage, having
the latest MSVC platform libraries available is important.
At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.
Well, here goes my shameless advertisement: CMake could be used to generate Makefiles for MSVC :) I think it would still need to be fixed though, but that's less work to do.
Anyway, do you think you could keep the code compatible with GCC? I could take care of the header fixes.
Yes. Its just a matter of ifdeffing, and the differences can be localized. There are differences anyway. Since MingW uses the MS libraries a few choice MS incompatibilities surface such as printf format specifiers for 64-bit values, in C99 %llx %lld et al are used, but in MS it's %I64x %I64d etc. Hence
#if _MSC_VER # define LLFMT "I64d" #else # define LLFMT "lld" #endif
Grr...
best, Eliot
Best regards,
Geoffroy
On Thu, Jul 22, 2010 at 8:06 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
Hi Geoffroy,
On Thu, Jul 22, 2010 at 10:34 AM, Geoffroy Couprie geo.couprie@gmail.comwrote:
Hello,
On Thu, Jul 22, 2010 at 5:20 PM, Andreas Raab andreas.raab@gmx.dewrote:
On 7/22/2010 4:55 AM, David T. Lewis wrote:
On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:
But the more serious issue is that the configure in VMMaker is only suitable for linux. I guess that the right thing to do for FreeBSD is to run make in platforms/unix/config to generate a FreeBSD-specific configure. But I'm out of my depth when it comes to autoconf.
Note that Ian moved to CMake for the unix builds, so autoconf is no longer used for building from the SVN trunk. In addition, Geoffroy Couprie has developed this further such that the VM can be built for both unix and Windows targets, see thread here:
http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html
It's up to Ian and Andreas to say if they want to pursue this direction, but if you need the Cog build process to be more platform independent this would be a good thing to consider.
Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now:
- Availability of the tool chain: There have been free versions of MSVC
for years now, so this is no longer an issue.
- Performance of the VM: With the JIT, the performance difference between
the compilers no longer matters.
- Size of difficulty of the install: New versions of MingW are no easier
to install than Cygwin or other monsters.
MSYS is not that hard to install. And GCC can be use to cross compile, which is really useful for tests, continuous integration, etc.
What about C++ compilation?
I don't know what issues you encountered, but 3.4.5 was fine, 4.2 had broken exception handling, and 4.4 works well.
On the other hand, there are some exceptionally good reasons to use MSVC:
- Debugging: Did you know that MSVC now has seemless in-place editing?
When I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked!
- Up-to-date headers and libraries: SqueakSSL wouldn't compile on *any*
version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old.
Did you check the recent headers? Most of the recent API (XP/Vista) are in the actual MinGW headers. The DirectX headers are a bit old, but considering you're using DirectX 7, I don't think that's an issue. What specific headers/libraries/functions are you talking about?
The thread info block TIB isn't provided, a hack is required to get multi-monitor stuff to compile against directx7, CommandLineToArgvW doesn't appear to compile correctly. WS_ACTIVECAPTION is not defined. STACK_SIZE_PARAM_IS_A_RESERVATION is not defined. Some socket constants are not defined, etc, etc. Look for references to __MINGW32__, !defined & ifndef in platforms/win32 in the Cog tree. Not a lot current;y because we moved to cygwin and gcc 3.4.4, but when we were with the old 2.95 there was a lot more. As far as we're aware gcc 2.95 still produces better code for the interpreter than either gcc 3.x or 4.x (although I suspect that one needs to declare global registers differently, i,e. prefix them with static, and things will be copacetic again).
Would it be hard to update the code to more recent directx versions? (do you have to maintain the code for old Windows versions?)
A lot of headers were fixed in recent MinGW versions (and as far as I know, squeak builds fine with gcc 4). I don't know gcc 2.95 (the version used when I learned C was 3.4.5 :p), and I can't judge the performance differences, but I think requiring gcc 4.4 would allow a lot of code cleaning.
- Consistent use of runtime libraries: For some external linkage, having
the latest MSVC platform libraries available is important.
At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.
Well, here goes my shameless advertisement: CMake could be used to generate Makefiles for MSVC :) I think it would still need to be fixed though, but that's less work to do.
Anyway, do you think you could keep the code compatible with GCC? I could take care of the header fixes.
Yes. Its just a matter of ifdeffing, and the differences can be localized. There are differences anyway. Since MingW uses the MS libraries a few choice MS incompatibilities surface such as printf format specifiers for 64-bit values, in C99 %llx %lld et al are used, but in MS it's %I64x %I64d etc. Hence
#if _MSC_VER # define LLFMT "I64d" #else # define LLFMT "lld" #endif
Yes, THAT is really annoying. We encountered a lot of problems with 32/64
code and format specifiers in vlc, but switching to gcc 4.4 fixed them.
On Thu, Jul 22, 2010 at 11:55 AM, Geoffroy Couprie geo.couprie@gmail.comwrote:
On Thu, Jul 22, 2010 at 8:06 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
Hi Geoffroy,
On Thu, Jul 22, 2010 at 10:34 AM, Geoffroy Couprie <geo.couprie@gmail.com
wrote:
Hello,
On Thu, Jul 22, 2010 at 5:20 PM, Andreas Raab andreas.raab@gmx.dewrote:
On 7/22/2010 4:55 AM, David T. Lewis wrote:
On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:
But the more serious issue is that the configure in VMMaker is only suitable for linux. I guess that the right thing to do for FreeBSD is to run make in platforms/unix/config to generate a FreeBSD-specific configure. But I'm out of my depth when it comes to autoconf.
Note that Ian moved to CMake for the unix builds, so autoconf is no longer used for building from the SVN trunk. In addition, Geoffroy Couprie has developed this further such that the VM can be built for both unix and Windows targets, see thread here:
http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html
It's up to Ian and Andreas to say if they want to pursue this direction, but if you need the Cog build process to be more platform independent this would be a good thing to consider.
Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now:
- Availability of the tool chain: There have been free versions of MSVC
for years now, so this is no longer an issue.
- Performance of the VM: With the JIT, the performance difference between
the compilers no longer matters.
- Size of difficulty of the install: New versions of MingW are no easier
to install than Cygwin or other monsters.
MSYS is not that hard to install. And GCC can be use to cross compile, which is really useful for tests, continuous integration, etc.
What about C++ compilation?
I don't know what issues you encountered, but 3.4.5 was fine, 4.2 had broken exception handling, and 4.4 works well.
The issue is that binaries produced with g++ -mno-cygwin -mwindows will not work because there is no support for them in the MS run-time.
On the other hand, there are some exceptionally good reasons to use MSVC:
- Debugging: Did you know that MSVC now has seemless in-place editing?
When I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked!
- Up-to-date headers and libraries: SqueakSSL wouldn't compile on *any*
version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old.
Did you check the recent headers? Most of the recent API (XP/Vista) are in the actual MinGW headers. The DirectX headers are a bit old, but considering you're using DirectX 7, I don't think that's an issue. What specific headers/libraries/functions are you talking about?
The thread info block TIB isn't provided, a hack is required to get multi-monitor stuff to compile against directx7, CommandLineToArgvW doesn't appear to compile correctly. WS_ACTIVECAPTION is not defined. STACK_SIZE_PARAM_IS_A_RESERVATION is not defined. Some socket constants are not defined, etc, etc. Look for references to __MINGW32__, !defined & ifndef in platforms/win32 in the Cog tree. Not a lot current;y because we moved to cygwin and gcc 3.4.4, but when we were with the old 2.95 there was a lot more. As far as we're aware gcc 2.95 still produces better code for the interpreter than either gcc 3.x or 4.x (although I suspect that one needs to declare global registers differently, i,e. prefix them with static, and things will be copacetic again).
Would it be hard to update the code to more recent directx versions? (do you have to maintain the code for old Windows versions?)
A lot of headers were fixed in recent MinGW versions (and as far as I know, squeak builds fine with gcc 4). I don't know gcc 2.95 (the version used when I learned C was 3.4.5 :p), and I can't judge the performance differences, but I think requiring gcc 4.4 would allow a lot of code cleaning.
- Consistent use of runtime libraries: For some external linkage, having
the latest MSVC platform libraries available is important.
At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.
Well, here goes my shameless advertisement: CMake could be used to generate Makefiles for MSVC :) I think it would still need to be fixed though, but that's less work to do.
Anyway, do you think you could keep the code compatible with GCC? I could take care of the header fixes.
Yes. Its just a matter of ifdeffing, and the differences can be localized. There are differences anyway. Since MingW uses the MS libraries a few choice MS incompatibilities surface such as printf format specifiers for 64-bit values, in C99 %llx %lld et al are used, but in MS it's %I64x %I64d etc. Hence
#if _MSC_VER # define LLFMT "I64d" #else # define LLFMT "lld" #endif
Yes, THAT is really annoying. We encountered a lot of problems with 32/64
code and format specifiers in vlc, but switching to gcc 4.4 fixed them.
How does 4.4 fix the issue? Remember we're talking about -mno-cygwin -mwindows because under that environment there's no GPL issue.
best Eliot
On Thu, Jul 22, 2010 at 9:59 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
On Thu, Jul 22, 2010 at 11:55 AM, Geoffroy Couprie geo.couprie@gmail.comwrote:
On Thu, Jul 22, 2010 at 8:06 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
Hi Geoffroy,
On Thu, Jul 22, 2010 at 10:34 AM, Geoffroy Couprie < geo.couprie@gmail.com> wrote:
Hello,
On Thu, Jul 22, 2010 at 5:20 PM, Andreas Raab andreas.raab@gmx.dewrote:
On 7/22/2010 4:55 AM, David T. Lewis wrote:
On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:
> But the more serious issue is that the configure in VMMaker is only > suitable > for linux. I guess that the right thing to do for FreeBSD is to run > make in > platforms/unix/config to generate a FreeBSD-specific configure. But > I'm out > of my depth when it comes to autoconf. >
Note that Ian moved to CMake for the unix builds, so autoconf is no longer used for building from the SVN trunk. In addition, Geoffroy Couprie has developed this further such that the VM can be built for both unix and Windows targets, see thread here:
http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html
It's up to Ian and Andreas to say if they want to pursue this direction, but if you need the Cog build process to be more platform independent this would be a good thing to consider.
Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now:
- Availability of the tool chain: There have been free versions of MSVC
for years now, so this is no longer an issue.
- Performance of the VM: With the JIT, the performance difference
between the compilers no longer matters.
- Size of difficulty of the install: New versions of MingW are no
easier to install than Cygwin or other monsters.
MSYS is not that hard to install. And GCC can be use to cross compile, which is really useful for tests, continuous integration, etc.
What about C++ compilation?
I don't know what issues you encountered, but 3.4.5 was fine, 4.2 had broken exception handling, and 4.4 works well.
The issue is that binaries produced with g++ -mno-cygwin -mwindows will not work because there is no support for them in the MS run-time.
Well, now, g++ produces working binaries.
- Consistent use of runtime libraries: For some external linkage,
having the latest MSVC platform libraries available is important.
At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.
Well, here goes my shameless advertisement: CMake could be used to generate Makefiles for MSVC :) I think it would still need to be fixed though, but that's less work to do.
Anyway, do you think you could keep the code compatible with GCC? I could take care of the header fixes.
Yes. Its just a matter of ifdeffing, and the differences can be localized. There are differences anyway. Since MingW uses the MS libraries a few choice MS incompatibilities surface such as printf format specifiers for 64-bit values, in C99 %llx %lld et al are used, but in MS it's %I64x %I64d etc. Hence
#if _MSC_VER # define LLFMT "I64d" #else # define LLFMT "lld" #endif
Yes, THAT is really annoying. We encountered a lot of problems with 32/64
code and format specifiers in vlc, but switching to gcc 4.4 fixed them.
How does 4.4 fix the issue? Remember we're talking about -mno-cygwin -mwindows because under that environment there's no GPL issue.
Sorry, I was confusing with something else. We redefined the symbols too.
On 7/22/2010 10:34 AM, Geoffroy Couprie wrote:
* Performance of the VM: With the JIT, the performance difference between the compilers no longer matters. * Size of difficulty of the install: New versions of MingW are no easier to install than Cygwin or other monsters.MSYS is not that hard to install. And GCC can be use to cross compile, which is really useful for tests, continuous integration, etc.
You can do all of this on Windows, we use Ant and Staf for such purposes.
On the other hand, there are some exceptionally good reasons to use MSVC: * Debugging: Did you know that MSVC now has seemless in-place editing? When I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked! * Up-to-date headers and libraries: SqueakSSL wouldn't compile on *any* version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old.Did you check the recent headers? Most of the recent API (XP/Vista) are in the actual MinGW headers. The DirectX headers are a bit old, but considering you're using DirectX 7, I don't think that's an issue. What specific headers/libraries/functions are you talking about?
Try compiling SqueakSSL and see how far you get. But really, I'm just *tired* of hunting this stuff; I have lost all patience.
* Consistent use of runtime libraries: For some external linkage, having the latest MSVC platform libraries available is important. At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.Well, here goes my shameless advertisement: CMake could be used to generate Makefiles for MSVC :)
I'm not sure I understand. What point is there in "generating" Makefiles? I've never generated any Makefiles for my builds, why would an extra indirection be advantageous?
Anyway, do you think you could keep the code compatible with GCC? I could take care of the header fixes.
I'm not planning on breaking anything that compiles today but I'll no longer go out of my way to provide compatibility with ancient headers and libraries. In other words, no more code like this:
#if _WIN32_WINNT < 0x0500 /* i.e., an old mingw */
static HRESULT (__stdcall *SHGetFolderPathW)(HWND, int, HANDLE, DWORD, WCHAR*);
#define CSIDL_APPDATA 0x001A #define CSIDL_PROGRAM_FILES 0x0026 #define CSIDL_MYMUSIC 0x000D #define CSIDL_MYPICTURES 0x0027 #define CSIDL_MYVIDEO 0x000E #define CSIDL_PROFILE 40
#endif
/* ... */
#if _WIN32_WINNT < 0x0500 /* i.e. on old mingw */ hShell = LoadLibrary("SHFolder.dll"); SHGetFolderPathW = (void*)GetProcAddress(hShell, "SHGetFolderPathW"); #endif
Cheers, - Andreas
On Thu, Jul 22, 2010 at 8:24 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 7/22/2010 10:34 AM, Geoffroy Couprie wrote:
- Performance of the VM: With the JIT, the performance difference
between the compilers no longer matters.
- Size of difficulty of the install: New versions of MingW are no
easier to install than Cygwin or other monsters.
MSYS is not that hard to install. And GCC can be use to cross compile, which is really useful for tests, continuous integration, etc.
You can do all of this on Windows, we use Ant and Staf for such purposes.
Sure. That was mostly for convenience, because cross compiling means that I don't need two different machines to build the Windows and Linux versions.
On the other hand, there are some exceptionally good reasons to useMSVC:
- Debugging: Did you know that MSVC now has seemless in-place
editing? When I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked!
- Up-to-date headers and libraries: SqueakSSL wouldn't compile on
*any* version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old.
Did you check the recent headers? Most of the recent API (XP/Vista) are in the actual MinGW headers. The DirectX headers are a bit old, but considering you're using DirectX 7, I don't think that's an issue. What specific headers/libraries/functions are you talking about?
Try compiling SqueakSSL and see how far you get. But really, I'm just *tired* of hunting this stuff; I have lost all patience.
I will try. I know how annoying it can be to fix headers, but it got a lot better with recent versions.
* Consistent use of runtime libraries: For some external linkage,having the latest MSVC platform libraries available is important.
At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.
Well, here goes my shameless advertisement: CMake could be used to generate Makefiles for MSVC :)
I'm not sure I understand. What point is there in "generating" Makefiles? I've never generated any Makefiles for my builds, why would an extra indirection be advantageous?
Again, for convenience: you can detect if all the required libraries are present, add user specified paths (instead of hard-coded paths in the actual Makefile), and if you add files to the cross directory, you only have to modify one file to enable compilation on Windows and Linux. I can understand if you prefer writing Makefiles by hand, instead of using autotools, but CMake is really easy to use, and can create Makefiles for Linux, MSVC and MinGW, with no extra effort. Maintaining two build chains is more work.
Anyway, do you think you could keep the code compatible with GCC? I
could take care of the header fixes.
I'm not planning on breaking anything that compiles today but I'll no longer go out of my way to provide compatibility with ancient headers and libraries. In other words, no more code like this:
#if _WIN32_WINNT < 0x0500 /* i.e., an old mingw */
static HRESULT (__stdcall *SHGetFolderPathW)(HWND, int, HANDLE, DWORD, WCHAR*);
#define CSIDL_APPDATA 0x001A #define CSIDL_PROGRAM_FILES 0x0026 #define CSIDL_MYMUSIC 0x000D #define CSIDL_MYPICTURES 0x0027 #define CSIDL_MYVIDEO 0x000E #define CSIDL_PROFILE 40
#endif
/* ... */
#if _WIN32_WINNT < 0x0500 /* i.e. on old mingw */ hShell = LoadLibrary("SHFolder.dll"); SHGetFolderPathW = (void*)GetProcAddress(hShell, "SHGetFolderPathW"); #endif
SHGetFolderPathW is provided by MinGW now. With a recent version, I could clean a lot of those #ifdef. And if the code produced by MSVC is faster than gcc 2.95, then performance is no longer a reason to keep using 2.95.
Best regards,
Geoffroy
On 7/22/2010 12:07 PM, Geoffroy Couprie wrote:
I'm not sure I understand. What point is there in "generating" Makefiles? I've never generated any Makefiles for my builds, why would an extra indirection be advantageous?Again, for convenience: you can detect if all the required libraries are present, add user specified paths (instead of hard-coded paths in the actual Makefile), and if you add files to the cross directory, you only have to modify one file to enable compilation on Windows and Linux. I can understand if you prefer writing Makefiles by hand, instead of using autotools, but CMake is really easy to use, and can create Makefiles for Linux, MSVC and MinGW, with no extra effort.
Seriously? You mean that if I drop the stuff from http://eleves.ec-lille.fr/~couprieg/divers/patches.zip into my build tree cmake will magically generate MSVC build files and it'll just work? If that's actually true, I'm sold :-)
I'll try it tonight.
Cheers, - Andreas
On Thu, Jul 22, 2010 at 02:15:01PM -0700, Andreas Raab wrote:
On 7/22/2010 12:07 PM, Geoffroy Couprie wrote:
I'm not sure I understand. What point is there in "generating" Makefiles? I've never generated any Makefiles for my builds, why would an extra indirection be advantageous?
Again, for convenience: you can detect if all the required libraries are present, add user specified paths (instead of hard-coded paths in the actual Makefile), and if you add files to the cross directory, you only have to modify one file to enable compilation on Windows and Linux. I can understand if you prefer writing Makefiles by hand, instead of using autotools, but CMake is really easy to use, and can create Makefiles for Linux, MSVC and MinGW, with no extra effort.
Seriously? You mean that if I drop the stuff from http://eleves.ec-lille.fr/~couprieg/divers/patches.zip into my build tree cmake will magically generate MSVC build files and it'll just work? If that's actually true, I'm sold :-)
I'll try it tonight.
It's possible that it actually *is* true. This is exactly what CMake was designed to do (hence the name, "Cross-platform Make"). Whether it works as advertised I can't say. Frankly I'm not entirely sure why Ian went to the considerable effort of moving to CMake just for the sake of the unix source tree, but I suspect it was mainly a matter of running out of patience with the autoconf mess. Given that he did go to all that effort, and given that Geoffroy went to the extra effort of getting it to work on Windows also, well... who knows, maybe it will turn out to be worth the trip.
Note, IIUC Geoffroy's work is focused on building unix and Windows targets from a unix host, so it might not be what you would have in mind for a native Windows build process (Geoffroy, please correct me if I misunderstand).
Dave
p.s. Personally, I'm with Eliot - I can't stand any of these things, and I think it's great if somebody else wants to work on it ;-)
On 7/22/2010 5:24 PM, David T. Lewis wrote:
On Thu, Jul 22, 2010 at 02:15:01PM -0700, Andreas Raab wrote:
Seriously? You mean that if I drop the stuff from http://eleves.ec-lille.fr/~couprieg/divers/patches.zip into my build tree cmake will magically generate MSVC build files and it'll just work? If that's actually true, I'm sold :-)
I'll try it tonight.
It's possible that it actually *is* true. This is exactly what CMake was designed to do (hence the name, "Cross-platform Make").
Not much success. I tried running CMake naively and was instantly greeted with the recommendation to run cmake/configure. Which of course is a shell script so needs to be run from Cygwin. When I do that (after some fiddling with --src and --generator) it complains that the win32 directory doesn't have a CMakeLists.txt:
$ ../platforms/win32/cmake/configure --src=./src/ --generator="Visual Studio 10" -- Configuring squeak for i686-pc-cygwin -- Using source directory /cygdrive/c/SqueakVM/cmake-test/winbuild/src -- Using generator Visual Studio 10 ../platforms/win32 -DVM_HOST=i686-pc-cygwin -DPLATFORM_SOURCE_VERSION= -DVM_VERSION= -DOPT--src=/cygdrive/c/SqueakVM/cmake-test/winbuild/src CMake Error: The source directory "C:/SqueakVM/cmake-test/platforms/win32" does not appear to contain CMakeLists.txt. Specify --help for usage, or press the help button on the CMake GUI.
Which is correct, but I don't see a CMakeLists.txt in the patches. So I'm at a loss at this point. Geoffrey, any instructions?
Frankly I'm not entirely sure why Ian went to the considerable effort of moving to CMake just for the sake of the unix source tree, but I suspect it was mainly a matter of running out of patience with the autoconf mess. Given that he did go to all that effort, and given that Geoffroy went to the extra effort of getting it to work on Windows also, well... who knows, maybe it will turn out to be worth the trip.
I think the benefit for me would be elsewhere, namely in being able to just gen Makefiles for various compiler versions. It is quite a pain in the rear to try to load a Visual Studio X build file into a Visual Studio X-1; if cmake could make address this it might be worthwhile for that reason alone.
Note, IIUC Geoffroy's work is focused on building unix and Windows targets from a unix host, so it might not be what you would have in mind for a native Windows build process (Geoffroy, please correct me if I misunderstand).
That's okay, I'm just trying to see what cmake actually spits out. Unfortunately I'm a complete noob in this area so I'm stuck with the above.
Cheers, - Andreas
On Fri, Jul 23, 2010 at 5:36 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 7/22/2010 5:24 PM, David T. Lewis wrote:
On Thu, Jul 22, 2010 at 02:15:01PM -0700, Andreas Raab wrote:
Seriously? You mean that if I drop the stuff from http://eleves.ec-lille.fr/~couprieg/divers/patches.ziphttp://eleves.ec-lille.fr/%7Ecouprieg/divers/patches.zipinto my build tree cmake will magically generate MSVC build files and it'll just work? If that's actually true, I'm sold :-)
I'll try it tonight.
It's possible that it actually *is* true. This is exactly what CMake was designed to do (hence the name, "Cross-platform Make").
Not much success. I tried running CMake naively and was instantly greeted with the recommendation to run cmake/configure. Which of course is a shell script so needs to be run from Cygwin.
Sorry about that. When I wrote my patches, I was using MinGW on Linux or on Windows with MSYS, so a shell was easier to use. I didn't consider MSVC at that time. I can fix it and not require a shell.
When I do that (after some fiddling with --src and --generator) it complains that the win32 directory doesn't have a CMakeLists.txt:
$ ../platforms/win32/cmake/configure --src=./src/ --generator="Visual Studio 10" -- Configuring squeak for i686-pc-cygwin -- Using source directory /cygdrive/c/SqueakVM/cmake-test/winbuild/src -- Using generator Visual Studio 10 ../platforms/win32 -DVM_HOST=i686-pc-cygwin -DPLATFORM_SOURCE_VERSION= -DVM_VERSION= -DOPT--src=/cygdrive/c/SqueakVM/cmake-test/winbuild/src CMake Error: The source directory "C:/SqueakVM/cmake-test/platforms/win32" does not appear to contain CMakeLists.txt. Specify --help for usage, or press the help button on the CMake GUI.
Which is correct, but I don't see a CMakeLists.txt in the patches. So I'm at a loss at this point. Geoffrey, any instructions?
That's weird. IIRC, the file platforms/CMakeLists.txt file exists, and it shouldn't look for that file in platforms/win32. I'll fix the configure script this evening.
2c.
One of good things switching to MSVC is debugging. The gdb is cool, when today is 70's. i found debugging VM built by GNU tools under windows is real pain.
But the downside of it, i think will be loss of performance - AFAIK MSVC does not supports jump tables (which is used by gnuification step), which gives roughly 30% increase in interpreter performance.
I had build the VM under Win32 with the compiler from MS VS 2005 in the past. It was a sort of fun to debug BitBlt-code under the really good studio debugger. The speed was the same as under gcc 2.?? coming with the standard build tools for win32. But I have no hard facts at hand anymore.
Using the studio as build environment had the only problem of missing solution files. I manually configured the solutions at these time. But today I'm using CMake for other projects. And I generate my Makefiles, my XCode project, Eclipse-workspaces and VS-Solutions from a single project description on at the moment four platforms. This is very effective (for me) an we have at least a working cmake-infrastructure under Linux/Unix.
Marco
2010/7/24 Igor Stasenko siguctua@gmail.com:
2c.
One of good things switching to MSVC is debugging. The gdb is cool, when today is 70's. i found debugging VM built by GNU tools under windows is real pain.
But the downside of it, i think will be loss of performance - AFAIK MSVC does not supports jump tables (which is used by gnuification step), which gives roughly 30% increase in interpreter performance.
-- Best regards, Igor Stasenko AKA sig.
On Thu, Jul 22, 2010 at 8:20 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 7/22/2010 4:55 AM, David T. Lewis wrote:
On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:
But the more serious issue is that the configure in VMMaker is only suitable for linux. I guess that the right thing to do for FreeBSD is to run make in platforms/unix/config to generate a FreeBSD-specific configure. But I'm out of my depth when it comes to autoconf.
Note that Ian moved to CMake for the unix builds, so autoconf is no longer used for building from the SVN trunk. In addition, Geoffroy Couprie has developed this further such that the VM can be built for both unix and Windows targets, see thread here:
http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html
It's up to Ian and Andreas to say if they want to pursue this direction, but if you need the Cog build process to be more platform independent this would be a good thing to consider.
Personally, I'll be moving the Windows build back into MS land. All the reasons for using the MingW/GCC tool chain are gone by now:
- Availability of the tool chain: There have been free versions of MSVC for
years now, so this is no longer an issue.
- Performance of the VM: With the JIT, the performance difference between
the compilers no longer matters.
- Size of difficulty of the install: New versions of MingW are no easier to
install than Cygwin or other monsters.
and one /very/ important reason, MingW does not support C++ which is increasingly problematic; e.g. the Bochs plugin for the Cog simulator is C++. At Teleplace we have media plugins in C++ which have to be built separately.
The downside for me is that I've drunk the gcc extended asm statement coolaid in platforms/Cross/vm/sqAtomicOps.h and am not looking forward to porting these.
On the other hand, there are some exceptionally good reasons to use MSVC:
- Debugging: Did you know that MSVC now has seemless in-place editing? When
I worked on SqueakSSL, I was shocked to find that an access violation was simply presented as a break point and after fixing it the compiler patched the code in place without restarting Squeak, and it worked!
- Up-to-date headers and libraries: SqueakSSL wouldn't compile on *any*
version of MingW or Cygwin due to the absence / lack of correctness of the headers and missing libraries even though the APIs are 5+ years old.
- Consistent use of runtime libraries: For some external linkage, having
the latest MSVC platform libraries available is important.
and support for C++ compilation.
At this point the advantage is clearly with the MS tool chain and the only hurdle is that I'll have to update all the makefiles etc.
and the asm statements :(
cheers Eliot
Cheers,
- Andreas
On Thu, Jul 22, 2010 at 4:55 AM, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:
But the more serious issue is that the configure in VMMaker is only
suitable
for linux. I guess that the right thing to do for FreeBSD is to run make
in
platforms/unix/config to generate a FreeBSD-specific configure. But I'm
out
of my depth when it comes to autoconf.
Note that Ian moved to CMake for the unix builds, so autoconf is no longer used for building from the SVN trunk. In addition, Geoffroy Couprie has developed this further such that the VM can be built for both unix and Windows targets, see thread here:
http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html
It's up to Ian and Andreas to say if they want to pursue this direction, but if you need the Cog build process to be more platform independent this would be a good thing to consider.
Personally I hate both autoconf and CMake with a passion. They are very confusing. It was considerable effort to modify the autoconf setup to compile Cog and I'm not motivated to put in the effort to convert the CMake setup to also compile Cog. But I'm not against it. If some kind soul out there who understands CMake wants to merge Ian's CMake into the Cog branch and verify it can be used to build Cog then I'll look kindly on junking autoconf and moving to CMake. I'll happily integrate; just don't expect me to do the hard work :)
cheers Eliot
Dave
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
David T. Lewis -
Eliot Miranda -
Frank Shearar -
Geoffroy Couprie -
Igor Stasenko -
Juan Vuletich -
Marco Schmidt