[Vm-dev] updating configure.ac

Ben Coman btc at openinworld.com
Mon Oct 17 15:30:32 UTC 2016


On Mon, Oct 17, 2016 at 3:31 PM, phil at highoctane.be <phil at highoctane.be> wrote:
>
> On Mon, Oct 17, 2016 at 8:59 AM, Esteban Lorenzano <estebanlm at gmail.com> wrote:
>>
>> On 17 Oct 2016, at 02:07, Ben Coman <btc at 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.3F

and how automake can generate non-recursive makefiles...
  https://www.murrayc.com/permalink/2009/07/24/non-recursive-automake-is-the-best-alternative-to-automake/
  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-recursive-make

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-codegen-in-vs-2015-update-1/
  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


More information about the Vm-dev mailing list