[Vm-dev] updating configure.ac

Ben Coman btc at openinworld.com
Mon Oct 17 15:39:06 UTC 2016


Just an interesting article I wanted to hang somewhere I could find it again...
http://voices.canonical.com/jussi.pakkanen/2013/03/26/a-list-of-common-cmake-antipatterns/

cheers -ben

On Mon, Oct 17, 2016 at 11:30 PM, Ben Coman <btc at openinworld.com> wrote:
> 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