<br><br><div class="gmail_quote">On Thu, Jul 22, 2010 at 8:20 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
On 7/22/2010 4:55 AM, David T. Lewis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Jul 21, 2010 at 08:49:19PM -0700, Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But the more serious issue is that the configure in VMMaker is only suitable<br>
for linux. I guess that the right thing to do for FreeBSD is to run make in<br>
platforms/unix/config to generate a FreeBSD-specific configure. But I'm out<br>
of my depth when it comes to autoconf.<br>
</blockquote>
<br>
Note that Ian moved to CMake for the unix builds, so autoconf is no longer<br>
used for building from the SVN trunk. In addition, Geoffroy Couprie has<br>
developed this further such that the VM can be built for both unix and<br>
Windows targets, see thread here:<br>
<br>
<a href="http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html" target="_blank">http://lists.squeakfoundation.org/pipermail/vm-dev/2010-May/004574.html</a><br>
<br>
It's up to Ian and Andreas to say if they want to pursue this direction,<br>
but if you need the Cog build process to be more platform independent<br>
this would be a good thing to consider.<br>
</blockquote>
<br>
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:<br>
* Availability of the tool chain: There have been free versions of MSVC for years now, so this is no longer an issue.<br>
* Performance of the VM: With the JIT, the performance difference between the compilers no longer matters.<br>
* Size of difficulty of the install: New versions of MingW are no easier to install than Cygwin or other monsters.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
On the other hand, there are some exceptionally good reasons to use MSVC:<br>
* 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!<br>
* 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.<br>
* Consistent use of runtime libraries: For some external linkage, having the latest MSVC platform libraries available is important.<br></blockquote><div><br></div><div>and support for C++ compilation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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.<br></blockquote><div><br></div><div>and the asm statements :(</div><div><br></div><div>
cheers</div><div>Eliot</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
</font></blockquote></div><br>