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.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.
* 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