<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, 1 Dec 2018 at 07:46, Ronie Salgado <<a href="mailto:roniesalg@gmail.com">roniesalg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr">
Hello,<div><br></div><div>When I started making the minheadless version I
 wanted to nuke all of the platform specific code, and unify it as much 
as possible. For building I adapted the hand written CMake scripts that I
 normally use for my projects. One of my motivation for CMake is on using MSVC for building on Windows, which is also a requirement in order to support the UWP for running the VM in a retail Xbox One.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div>Before folding back into opensmalltalk, Pharo actually had a CMake helper to build the VM with options etc.</div><div>This was deemed too complicated and people steered towards a vanilla makefile.</div></div></blockquote><div>Pharo was NOT using CMake.  Pharo was generating cmake scripts from the image, which then they were being used for compiling the VM. That is definitely a complicated and not a proper way of cmake.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div>Now, yes, build times are long. But because there are a lot of dependencies being built as part of the whole.</div><div>There are some optimisations yes, like not rebuilding, say, FreeType on every build.</div></div></blockquote><div>And also plugins. Many plugins do not make sense as being part of the VM. There are not properly maintained or used. In Pharo at least there is the tendency of moving as much functionality as out of the plugins, and replacing them with libraries that called via the FFI.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<div>Is is a pendulum swing in action?</div>

</div></blockquote><div>Well, with Esteban we decided one year ago that in order to reduce friction with the community, to use cmake only for configuration purpose (i.e replace autoconf to generate a config.h), and to keep using the existent makefiles. We already adapted the makefiles from Linux and Mac for Pharo. Handling dependencies during the build process is also another motivation for keeping the makefiles.</div><div><br></div><div>As for me, I prefer to just use cmake for the whole build process. In my opinion, I think that we are suffering from the lack of proper separation between the core VM, and user specific features (e.g: freetype, cairo, midi, mp3 player, etc) that should be isolated as much as possible from the vm. The VM itself should be a virtual processor and memory manager, it should not be a full operating system with 3D graphics, joystick support, midi controller plugin interface. Those other features are not the responsibility of the VM.<br></div><div><br></div><div>I just submitted a pull request that fixes the build with cygwin for win32 ( <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/311" target="_blank">https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/311</a> ). </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>During the weekend I will write proper documentation on how these cmake scripts are supposed to work. Normally it should just be a matter of issuing the following commands on the top-level directory:</div><div><br></div><div>mkdir build</div><div>cd build</div><div>cmake ..</div><div>make</div><div><br></div><div>and then for development just use make, and some occasional make clean. The scripts in build.minheadless.cmake are in place to automate this process and for building all of the variants of the vm. Cygwin is a bit trickier because it is treated as an Unix instead of Windows. Cygwin requires some additional command line options because it requires settings cmake in cross compilation mode by passing a toolchain file to cmake. The scripts in 
build.minheadless.cmake/x86|x64/<vm variant>/ already take care of detecting the usage of Cygwin, and passing the proper command line options to cmake.</div></div></div></blockquote><div><br></div><div>I fetched it down. The build worked...</div><div>$ cd pharo.cog.spur<br></div><div>$ ./mvm</div><div><div>[100%] Built target pharo</div></div><div>$ cd release/dist</div><div>$ ls</div><div><div>libpharo.dll.a  libPharoVMCore.a  libpharow.dll.a  pharo.exe  pharow.exe</div></div><div><br></div><div><div>But then...  </div></div><div>$ ./pharo.exe<br></div><div><div>produces error... "while loading shared libraries: libwinpthread-1.dll: cannot open shared object file: No such file or directory"</div></div><div><br></div><div>And from CMD.EXE side running "pharo.exe" produces two system error pop-ups...<br>"The code execution cannot proceed because libfreetyupe-6.dll was not found."</div><div><div>"The code execution cannot proceed because libwinpthread-1.dll was not found."</div><div><br></div><div>I'll start hunting around, but anyone have some ideas?</div><div><br></div><div>cheers -ben</div><br class="gmail-Apple-interchange-newline"></div><div><br></div></div></div></div></div></div>