<div dir="ltr">Tobias,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 17, 2016 at 10:49 PM, Tobias Pape <span dir="ltr"><<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 18.10.2016, at 02:57, Ben Coman <<a href="mailto:btc@openinworld.com">btc@openinworld.com</a>> wrote:<br>
<br>
><br>
> On Tue, Oct 18, 2016 at 5:31 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
>><br>
>> Hi Phil,<br>
>><br>
>> On Mon, Oct 17, 2016 at 12:31 AM, <a href="mailto:phil@highoctane.be">phil@highoctane.be</a> <<a href="mailto:phil@highoctane.be">phil@highoctane.be</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Mon, Oct 17, 2016 at 8:59 AM, Esteban Lorenzano <<a href="mailto:estebanlm@gmail.com">estebanlm@gmail.com</a>> wrote:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On 17 Oct 2016, at 02:07, Ben Coman <btc@openInWorld.com> wrote:<br>
>>>><br>
>>>> Phil, Could you outline the steps. Are you doing something other than this...<br>
>>>> <a href="https://github.com/pharo-project/pharo-vm" rel="noreferrer" target="_blank">https://github.com/pharo-<wbr>project/pharo-vm</a><br>
>>>><br>
>>>><br>
>>>> I think he is talking “in general”, not about the VM in particular.<br>
>>>><br>
>>> 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.<br>
>>> The CMake UI also allows to detect for a number of crappy mistakes, so, a godsend.<br>
>>><br>
>>> It can also generate XCode project files, which is very useful.<br>
>>><br>
>>> autoconf and makefiles, no thanks.<br>
>>><br>
>>> The image side CMake support looks great to me, better than the VMMaker green UI, which well, let's keep it at that.<br>
>><br>
>><br>
>> That tool is not used to generate VM source.<br>
>><br>
>>><br>
>>><br>
>>> It also working nice with a CI server, so why use stoneage tooling when you have a more modern one available?<br>
>>><br>
>>> Learn the damn CMake and profit. We want a great VM, let's use great tools.<br>
>><br>
>><br>
>> There is agreement amongst the CogVM builders that<br>
>> - we will use cake or autoconf to generate a cogConfig.h that describes the build target platform's capabilities<br>
>> - we will /not/ use either autoconf or cake to generate VM makefiles<br>
><br>
> Most of my reading indicates the main virtue of CMake over autoconf is<br>
> the generation of makefiles for different build systems.<br>
<br>
</span>ACK.<br>
it can generate Xcode, VisualStudio, Eclipse… project files, which _tremendously_ eases<br>
debugging.<br></blockquote><div><br></div><div>With respect, only in limited genres. Firstly VM debugging is much easier in the simulator than in C. No ammount of navigation through the C code can compensate for the fact that the C is an output language, and not the language of implementation for the key parts of the VM. Second, in debugging the core VM, the support functions that print stack frames and backtraces, objects, references to objects, free lists, etc, etc. It is these that make i possible to debug the VM (as an execution engine, not the support C code), and make project files an inadequate solution. VM state is /not/ the C stack, the locus of attention in a traditional C debugger.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Dear CogVM builders, what is the IDE you use for development and debugging that works<br>
with the "only for config.h" scheme? I'm really interested.<br>
(And no, editor+gdb does not count)<br></blockquote><div><br></div><div>The simulator, primarily, i.e. Squeak or Pharo. Next, indeed gdb or lldb plus the significant number of debugging functions included in the VM. And it /does/ count.</div><div><br></div><div>That said, I have no objection if someone builds a CMake scheme to generate project files for those debugging support C code. I will still council that this effort is wasted when trying to debug the VM as an execution engine; for that one really has to learn the architecture and become familiar with the debug functions (and yes, good documentation would help here, and a lot more than a project file).</div><div><br></div><div>What I *do* object to is the use of these project files for a build system. For the last time, I *will not* support such a move. Experience has shown (already 8 yard on Cog) that these get in the way of an efficient build system; they are inflexible and slow. The lean mean gmake files are much much better. So _please_ desist from pushing project build makefiles via CMake. I find this direction antagonising; I have expressed myself clearly on the point, and I have not seen any convincing counterarguments. So can we please settle on the fact that we have agreed to use gmake makefiles for builds. Enough said?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best regards<br>
<span class="HOEnZb"><font color="#888888"> -Tobias<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> If we are not<br>
> doing that, there seems little imperative to move from autoconf to<br>
> cmake. Autoconf reportedly has slightly better coverage of feature<br>
> determination.<br>
><br>
> btw, I found this an interesting insight...<br>
> <a href="http://stackoverflow.com/questions/4071880/autotools-vs-cmake-vs-scons" rel="noreferrer" target="_blank">http://stackoverflow.com/<wbr>questions/4071880/autotools-<wbr>vs-cmake-vs-scons</a><br>
><br>
> "An important distinction must be made between who uses the tools.<br>
> Cmake is a tool that must be used by the user when building the<br>
> software. The autotools are used to generate a distribution tarball<br>
> that can be used to build the software using only the standard tools<br>
> available on any SuS compliant system. In other words, if you are<br>
> installing software from a tarball that was built using the autotools,<br>
> you are not using the autotools. On the other hand, if you are<br>
> installing software that uses Cmake, then you are using Cmake and must<br>
> have it installed to build the software.<br>
><br>
> The great majority of users do not need to have the autotools<br>
> installed on their box. Historically, much confusion has been caused<br>
> because many developers distribute malformed tarballs that force the<br>
> user to run autoconf to regenerate the configure script, and this is a<br>
> packaging error. More confusion has been caused by the fact that most<br>
> major linux distributions install multiple versions of the autotools,<br>
> when they should not be installing any of them by default. Even more<br>
> confusion is caused by developers attempting to use a version control<br>
> system (eg cvs, git, svn) to distribute their software rather than<br>
> building tarballs."<br>
><br>
> cheers -ben<br>
><br>
><br>
>> - we will write linux makefiles in the style of the windows and mac makefiles, all using gmake<br>
>><br>
>> We are not using bad tools; cake and autoconf are all useful in their place, but experience has shown that they are not good tools for generating the makefiles we use to build the VM, primarily because they are slow, being painful to run on each make, and because they are higher-order, so figuring out what input to change to achieve a changed output is indirect, and may require a build step (running autoconf/cmake). The makefiles we have for windows and mac are much better; they are fast, running immediately, and direct, their configuration options never depend on rebuilding the make system, only in their configuration files (<a href="http://plugins.int" rel="noreferrer" target="_blank">plugins.int</a>,plugins.ext and attendant platforms/foo/plugins/Makefile files).<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>