[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