[Vm-dev] tty's hypothesis on configH in CMakeVMMaker

[gettimothy]

Hi David




Are you on Linux 32 (no compat libs) or something else. I am ready to start boiler-plate coding the CMake configurations and I would like to target your system first to get your input on the system.

 Philosophical points of view aside, I have the uncomfortable feeling that 
some (all?) of the people in this discussion may have never bothered to look 
at how Ian's CMake build actually works. 
 
To put it simply: It implements the approach that Eliot is trying to advocate. 
And it works. 




You are correct. At the time CMake was greek to me and its a non-trivial system. Then, on my "to fork or not to fork" email we decided to go with the existing project.


 
 
Modifying the system to incorporate Ian's approach on a refactoring pass should be easy as most CMake content is encapsulated in a few base classes that can be modified to return Ian's code in place of what it returns now. 







My own personal opinion: Philosophically, I tend to favor Igor's point of view 
(put things in the image as much as possible). But in practice, this is a case 
where the implementors of CMake are in a better position to deal with platform 
differences than we (the Squeak/Pharo community) can afford to do. 
 
Furthermore, the organization that Ian created puts the responsibilities 
where they belong, with minor customizations for the various plugins and 
modules located in their respective platform source directories where needed, 
and overall control of the CMake configuration and build located in a small 
set of CMake files. 
 



I agree.  


My approach is to get the existing CMakeVMMaker platform ported to Squeak for all the perumutations that Eliot requires with all the builds functioning identically to what happens in GNU build.


Once that is done, refactor to put in improvements such as you suggest. 


I think the exercise of creating all those builds with the existing framework will provide insight into what could be better.


I can then look at Ian's code with a grain of understanding of what he did and evaluate that.







To speak plainly, I have a hard time understanding why something that is well 
designed and implemented by its original author needs to be reengineered and 
reimplemented by every new person with a new opinion. Why not just support and 
contribute to the original author? What's so difficult about that?



 

I think you are going to vastly prefer coding the cmake build system in Smalltalk to editing CmakeLists.text etc by hand.







I think another benefit will be the increased amount of eye-balls on the CMake system because it is so easy to modify in  Smalltalk and have
others contribute improvements.


Finally, the system is a joy to use, if I may say so myself. Instead of editing cmake files and build scripts and acincludes.m4, I am editing Smalltalk classes.





Outputting an entire CMake build tree happens in milliseconds with a message to a platform's builder.




SqueakLinux64x86w32CompatBuilder
       configureA: #Linux64x86w32BitSqueakCogV3SlackwareNoGLConfig forBuildType: #build;
      generate.  


 


Now admittedly that looks odd-ball because my system is an oddball system, but all builds have the same structure, so in "normal land"





SqueakLinux32x86Builder 
       configureA: #Linux32x86SqueakCogV3Config forBuildType: #buildAssertITimerHeartbeat;
       generate 


 and BOOM! code is in place ready to run. Open a terminal go to the cmake.build.linux32x86/squeak.cog.v3/build.assert.itimerheartbeat/ and run build.sh and the build kicks off.

If you get an error, the message tells you, you go to Smalltalk class and fix it there. and repeat. It is MUCH faster and intuitive then editing raw CMake and acinclude.m4 files.


Looking down the road, you will be able to automate all builds from smalltalk with something like:




[SqueakCMakeVMMakerAbstractBuilder availableBuildTypes do: [:type | 
       SqueakLinux32x86Builder configureA: #Linux32x86SqueakCogV3Config forBuildType: type; 
            generateSources;
             generate 


     ]] on: ProvideAnswerNotification do: [:ex | ex resume:true]

 
Which will invoke VMMaker to comipile all sources for that platform and generate all the build trees.


A moment's reflection will tell you that the enterprising Seaside Developer can put a front end on this sucker and put in a very user friendly way for people to download custom builds
If it was a wizard thingy, the steps could be:


1. select your target operating system from a drop down box
2. select your platform (x36, ArmV.6, x64)
3...
4. select your built in plugins
5. select your external plugins
6. ...
7. do you want to build this yourself or do you want us to do it?
7.a I will build myself
8. Your code is ready to download and compile here:






So, in summary, 


We CAN put the Ian stuff in place with a refactoring pass.
Its a non-trivial project, so code-smells like this are to be expected on an early release.
The system should get more eyeballs on the build system
We are making it much easier for newbies to get up and running building the VM.


Hope that helps


tty
















-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140617/4fde038f/attachment.htm