<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 8 November 2013 16:49, 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">Hi Igor,<br>
hi list,<br>
<br>
sorry for replying late,…<br>
<br>
My reply was intended to stir the conversation a litte,<br>
to keep it going, which, I assume, it did. I really like<br>
your opinion, Igor :)<br>
<div><div class="h5"><br>
<br>
On 07.11.2013, at 14:28, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br>
<br>
>><br>
>><br>
>><br>
>> On 7 November 2013 08:58, Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br>
>> Hey Tim and all,<br>
>> On 07.11.2013, at 05:00, Ron Teitelbaum <<a href="mailto:ron@usmedrec.com">ron@usmedrec.com</a>> wrote:<br>
>><br>
>> > Hey Tim,<br>
>> ><br>
>> > Göran and Eliot have been discussing this. I just talked to Eliot about it<br>
>> > yesterday. He said he was happy to support cmake but didn't want to have to<br>
>> > do the work himself. I'm hoping that the work Göran is doing on this now<br>
>> > can be turned over to Eliot when it is finished. I think there is agreement<br>
>> > that combining the excellent work of pharo build with Eliot's new vm work is<br>
>> > a very good thing to do. The work to merge the build environments is<br>
>> > already being done at 3D ICC. We are working on this for the Mac also but<br>
>> > have not discussed it with Ian yet.<br>
>> ><br>
>> > Ron Teitelbaum<br>
>> ><br>
>> >> -----Original Message-----<br>
>> >> From: <a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org">squeak-dev-bounces@lists.squeakfoundation.org</a> [mailto:<a href="mailto:squeak-dev-">squeak-dev-</a><br>
>> >> <a href="mailto:bounces@lists.squeakfoundation.org">bounces@lists.squeakfoundation.org</a>] On Behalf Of tim Rowledge<br>
>> >> Sent: Wednesday, November 06, 2013 9:04 PM<br>
>> >> To: The general-purpose Squeak developers list<br>
>> >> Subject: Re: [squeak-dev] A Bounty for CMake-ifying stack/Cog vm build<br>
>> > process<br>
>> >><br>
>> >><br>
>> >> Wow, no interest? Is it because make is painful or because nobody needs to<br>
>> >> make any more money?<br>
>><br>
>><br>
>> I actually have interest but I am currently reluctant,<br>
>> for time-capturing reasons in my personal and work life.<br>
>><br>
>> However, Here is what I would do:<br>
>><br>
>> • Start from Ians CMake work, and try to generalize it for the<br>
>> non-Linux platforms<br>
>> • Windows would be kind-of straight-forward,<br>
>> • For OS X, I would really want to have the Cocoa-based VM stuff<br>
>> (aka Squeak VM 5.4.7.x) integrated and proper Xcode files<br>
>> generated, especially to be able to have iOS VMs built automatically.<br>
>> Here, some information from John McIntosh would be helpfull, especially<br>
>> a simple walk-through.<br>
>> I have some experience with that[1]<br>
>><br>
>><br>
>> Despite all admiration I have for the way the PharoVM is built, there is one<br>
>> thing that bothers me:<br>
>> • You first somehow generate the VM sources (which is fine, and the automated way is amazing)<br>
>> • THEN, the a Script generates CMake-Files<br>
>> • CMake then generates Makefiles<br>
>> • and then finally a vm is compiled.<br>
>> This is one generating step too much, for my taste.<br>
>> Personally, I'd prefer CMake to just pick up the C-files generated by VMMaker,<br>
>> so that adding a new platform does not need to change the VMMaker…<br>
>><br>
>> The main big issue with 'platform-neutral' static source files, that they tend to<br>
>> grow with tons of #ifdef-s over time, reducing readability and creating a mess.<br>
>><br>
> My point is that one or another way you have to deal with platform differences,<br>
> and the way how i prefer to do it is using smalltalk code,<br>
> but not .m4 files, or .cmake files, or writing a medium novel long configuration files<br>
> using strange (better to say weird) scripting DSL.<br>
> I can express all build process logic in smalltalk, which does not lessens the amount<br>
> of work to deal with all platform nuances and dependencies etc, but at least it allows me to organize and shape it<br>
> into some manageable form, which is easy to change & learn.<br>
><br>
> And another difference is, that i prefer working with browser & classes than<br>
> with dozens of directories and files lying here and there.<br>
<br>
<br>
</div></div>I did not want to imply we have to do it my way, not at all.<br>
And you are certainly right. Smalltalk is a good way to do things.<br>
<br>
The only thing that got me thinking is,<br>
a lot of people use tools like CMake to drive build processes, and<br>
they know the edges of the domain very well. Building software can<br>
be quite complex: think Platforms, compiler quirks, SDK restrictions,<br>
cross compilations, to just name a few.<br>
CMake (even more than autotools) is quite good at these tasks,<br>
especially regarding the cross-platform part.<br>
If we now start to, effectively, reimplement CMake or autotools, we will<br>
run in the issues, those tools all have solved years ago. CMake even has<br>
beautiful output.<br>
<br>
I think it would take an tremendous effort to get a Build tool that<br>
(only thinking of the Squeak/Pharo VM)<br>
• can build well with different compilers (Clang/Gcc, probably Microsoft)<br>
• can handle the platform-discovery (Linux, OSX, Windows, RISC!)<br>
• can handle library discovery (finding stuff like libuuid)<br>
• can do cross-compilation and the signing-stuff (iOS, perhaps android)<br>
<br>
If we get this working, this would be amazing.<br>
I am a bit reluctant, it would be a lot of work for me…<br>
<div class="im"><br></div></blockquote><div> </div><div>hehe, do you think i felt something else when started work on trying make VM to be able to build automatically?<br></div><div>i doubt anyone can find it fun to grok through dozens of dusty old source & configuration files<br>
</div><div>in attempt to put some order there.<br></div><div>i did what i did, and now we using it to build pharo. <br></div><div>And you free to use hours we spent on what we did. as well as free to not, of course.<br></div>
<div>i don't wanna advertise or convince anyone because you can just download it and see by yourself.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<br>
<br>
><br>
> But sure thing, it is a question of taste. If you prefer to maintain this:<br>
> -------------------------<br>
<br>
</div>> [22 lines old CMAKE]<br>
<br>
> --------------------------<br>
> And/or this:<br>
> --------------------------<br>
<br>
> [96 lines autoconf/make/whatever]<br>
<div class="im"><br>
> ----------------------------<br>
><br>
> instead of plain smalltalk code, it is up to you.<br>
><br>
> But that's about 'too much' for my taste.<br>
<br>
</div>I concur.<br>
<br>
My impression is, we can choose from four “evils”[1]:<br>
1. Accept the status quo. Painful for starters with its 8+ ways<br>
of doing essentially the same and every single one has some kind of<br>
big drawback.<br>
2. Use CMake completely. Painful, because we have to maintain two<br>
bodies of knowledge, VMMaker and CMake.<br>
3. Use cmake through CMakeVMMaker. Painful, because it can not fully<br>
benefit from Smalltalk nor from CMake. You have always to make up your<br>
mind whether to implement something on the Smalltalk or the CMake level<br>
4. Have a Smalltalk-only build too. Painful, because it is going to take<br>
a lot of time.<br>
<br>
I can accept any of them, but the first :)<br>
2. and 3. have the benefits that they are already there, to certain degrees.<br>
(2. only in the Unix-vm part, done by Ian, 3. currently only used by the Pharo<br>
community)<br>
<br>
How shall we as the VM community[2] decide?<br>
<br>
Best<br>
-Tobias<br>
<br>
[1] not really evil, only each painful to a certain degree<br>
[2] Who are we actually?<br>
• The Pharo and Squeak people,<br>
• The Cuis people<br>
• The Newspeak People<br>
• The CogVM people<br>
• Whom am I missing?<br>
<br>
<br>
<br><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Best regards,<br>Igor Stasenko.
</div></div>