[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