[Vm-dev] Ian's cmake design (was: svn git bridge?)

[gettimothy]

Hi all,

The CMakeVMakerSqueak is getting close enough that it is worth considering for going to Ian's design (its what I have in mind)

My time is very limited so I cannot get this done ASAP.


However, the design seems solid to me and there is no reason why the tool cannot be used to generate what Ian's approach.(Imho, it does this now)


I am currently focusing (at most, one day a week) on writing Help documentation as I create a configuration.

I am very willing to provide feedback via email (every day after my day job) for anybody who wants to get this done.

Steps remaining (excluding refactoring) are:

1. Document workflows.
2. Complete all configurations to generate what Eliot currently supports.
3. Decouple from the pharo CMakeVMMaker 
4. Automate the creation of CMake Templates/Components by parsing CMake help output and creating Squeak CMake objects (the idea is similar to Seaside Components for CMake)

I think the design is loosely coupled and makes sense.

I too think Ian's CMake work is awesome. I currently use his approach for generating CMakeLists.txt output for the plugins.

The mantra for the project is "CMAKE drives the development decisions" .

thank you for your time.

tty







---- On Sat, 23 Apr 2016 23:08:04 -0400 Eliot Miranda<eliot.miranda at gmail.com> wrote ---- 

 
Dave, 
 
> On Apr 23, 2016, at 7:56 PM, David T. Lewis <lewis at mail.msen.com> wrote: 
> 
> 
>> On Sat, Apr 23, 2016 at 05:10:37PM -0700, Eliot Miranda wrote: 
>> 
>> David, 
>> 
>>> On Apr 23, 2016, at 3:13 PM, David T. Lewis <lewis at mail.msen.com> wrote: 
>>> 
>>> 
>>>>> On Sat, Apr 23, 2016 at 10:44:02AM -0700, Eliot Miranda wrote: 
>>>>> 
>>>>> On Apr 23, 2016, at 10:30 AM, Tobias Pape <Das.Linux at gmx.de> wrote: 
>>>>> 
>>>>> PS: Personally (i.e. IMHO), I think that IF we go with cmake, we should follo Ians way with 
>>>>> probably some mix of the self vm stuff. It can really work. And it can also help us 
>>>>> getting things compiled on MS compilers, btw. 
>>>> 
>>>> What do you mean by "Ian's way" exactly? Please describe it. 
>>>> 
>>>> Things I know: 
>>>> - Ian's autoconf code (platforms/unix/conf, the various additional snippets that get included when one builds the autoconf support, rather than things that get computed at build time) is extremely difficult to work with 
>>>> - gmake files work with MS compilers too 
>>> 
>>> My experience is different. I find it a bit obscure in the sense that it 
>>> would benefit from some better documentation and comments in the cmake files. 
>>> 
>>> Aside from that, Ian got the design dead right. Cmake handles the overall 
>>> build. The VM build procedures are in a small number of files. Configurations 
>>> that are specific to some part of the build tree are located with the source, 
>>> and versioned with the source files to which they apply. 
>> 
>> And how is that significantly different from the gmake files? Gnu make ha goes the overall build, the VM build procedures are in a small number of files. Configurations that are specific to some part of the build tree are located with the source, and versioned with the source files to which they apply. None of this is specific to cmake. 
>> 
>> What is specific to both cmake and autoconf is their being Makefile compilers, with all the difficulties that implies (learning a specialized language, waiting for compiles, interpreting compile-time and run-time errors and mapping them back to the source. 
> 
> I don't know. 
> 
> My point is that Ian's design is well considered, and works very well in my experience. 
> 
> 
>>> Looking back at the last seven years or so, I would say: 
>>> 
>>> - The number of changes to the cmake procedures has been minimal. 
>>> - Building a VM with Ian's procedure is still remarkably easy. 
>>> - The total amount of code (cmake files) required to make this work is small. 
>>> - In the few cases where I needed to change something, I have been able to 
>>> figure out what to do. 
>>> - Despite years of upgrades (sic) to my operating systems and compilers, 
>>> it still works. 
>> 
>> Looking back at the past 9 years I would say that Andreas' gnu makefiles for Windows never stopped working, were much easier to extend to Cog and Newspeak and the building of platform-specific Newspeak installers was straight-forward. 
> 
> I have no problem believing that :-) 
> 
>>> 
>>> I have very little patience for fiddling around with build systems, and 
>>> no patience whatsoever for autotools. But I have had no trouble using 
>>> and occasionally modifying Ian's cmake build procedures. 
>> 
>> Have you used the gnu makefiles? Have you extended them? 
> 
> If you are referring to e.g. the acinclude.m4 and Makefile.inc files, then 
> yes I have used and extended them. 
 
No, I'm referring to the gnu makefiles used to build win32 and Mac OS X cog. I posted their svn urls in my point by point comparison of them with cmake. 
 
> Dave 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160425/4826a4c5/attachment.htm