On Mon, Oct 17, 2016 at 3:31 PM, phil@highoctane.be phil@highoctane.be wrote:
On Mon, Oct 17, 2016 at 8:59 AM, Esteban Lorenzano estebanlm@gmail.com wrote:
On 17 Oct 2016, at 02:07, Ben Coman btc@openInWorld.com wrote:
Phil, Could you outline the steps. Are you doing something other than this... https://github.com/pharo-project/pharo-vm
I think he is talking “in general”, not about the VM in particular.
In general. But also about the VM since I wanted to build it for OSX/Win/Linux and CMake + the image code supporting it, while initially a royal PITA (version had to be correct etc) proved to be very useful for a lot of things because it was all logical, variables could be set nicely etc. The CMake UI also allows to detect for a number of crappy mistakes, so, a godsend.
It can also generate XCode project files, which is very useful.
autoconf and makefiles, no thanks.
The image side CMake support looks great to me, better than the VMMaker green UI, which well, let's keep it at that.
It also working nice with a CI server, so why use stoneage tooling when you have a more modern one available?
Learn the damn CMake and profit. We want a great VM, let's use great tools.
A lot of the stuff I read make CMake seem much better, but actually it seems slow - particularly "rebuild leaf" for the 4-level 1112 files ... http://www.kaizou.org/2016/09/build-benchmark-large-c-project.html
I see... $ cd opensmalltalk-vm $ find . -name "*.c" | wc -l #==> 2128 $ find . -name "*.h" | wc -l #==> 1769 but I guess typically we're not building everything, more like... $ find platforms/unix -name "*.c" | wc -l #==> 71 $ find platforms/unix -name "*.h" | wc -l #==> 39 $ find spursrc -name "*.c" | wc -l #==> 6 $ find spursrc -name "*.h" | wc -l #==> 6 which is more in the ballpark of 3-level 100 files.
I found "Recursive Make Considered Harmful" an interesting read... http://aegis.sourceforge.net/auug97.pdf
and why CMake generates recursive Makefiles... https://cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles...
and how automake can generate non-recursive makefiles... https://www.murrayc.com/permalink/2009/07/24/non-recursive-automake-is-the-b... http://karelzak.blogspot.com.au/2013/02/non-recursive-automake.html
with some annecdotal reports on the benefits on non-recursive makefiles http://stackoverflow.com/questions/559216/what-is-your-experience-with-non-r...
and some tips for handmade Makefiles... http://david.rothlis.net/large-gnu-make/
I bumped into an interesting discussion from a project considering to move from autoconf to Cmake. I was particularly surprised to read that cross-compilation was apparently easier with autoconf than Cmake, since after all CMake is "Cross Platform Make" https://github.com/libjpeg-turbo/libjpeg-turbo/issues/56 and if/when I get back to looking porting to at Xen Rump kernel, cross compilation will be important. Although I remember when doing the tiny Rump tutorial for each of autoconf and Cmake, the latter felt more natural.
Also btw, it seems there is future potential to cross-compile native Windows binaries from Linux with Microsoft donating their debugging Codegen to LLVM, https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-code... http://lists.llvm.org/pipermail/llvm-dev/2015-October/091847.html and some people have previously used the MSVC command-line cl.exe over Wine https://oxygene.sk/2010/09/cross-compiling-with-cmake-and-autotools/ http://www.kegel.com/wine/cl-howto-win7sdk.html http://nullprogram.com/blog/2016/06/13/
CMake's ability to generate different build systems is certainly attractive, but having a common set of make files across all platforms might be just as useful from a support perspective.
I don't really know which way to jump, and sorry I guess none of this discussion helps Gerardo's original query about where best to direct his energy.
cheers -ben