Hi David,

CMakeVMMakerSqueak wraps Ian's  CMake code 

Ian Piumarta ditched his earlier "autoblech" build and replaced it 
with a much better CMake process. I think this was about a half dozen 
years ago (!). Presumably he did that in part because of the problems 
that you are now experiencing. I also recall that there were some real 
issues with 32 and 64 bit library management that were intractable 
with autotools at the time, and that the CMake folks seem to have 
addressed reasonably well. 
 
Personally, I have very little patience for any of this stuff, so 
I am happy to make use of the CMake build that Ian provided. It works 
well, and has not had any of the 32/64 bit library management problems 
that autotools were encountering at that time. It also works on my new 
Ubuntu laptop with who knows what sort of compiler and build tools 
(more than I can say for the autotools builds). 
 
It is a complete mystery to me why anyone would want to reinvent this 
particular wheel. 
 

 
(with some small differences in plugin-approach that can be standardized via refactoring if needed).

I have differed with Pharo team in that CMAKE DRIVES THE PROCESS. We start with a working CMake and just encapsulate that in Squeak.

Ian's CMake code lives in CMakeVMMakerSqueak in the same way that the VM codebase lives in Squeak.


I look forward to discussing once I get the (minimal) beta-release for linux32 out today (which should be readily portable to Tim Rowledge's ARM platform and BJ's BSD platform and the gentleman who wants a SunOS port) .

Here is the short version of the project.

Stage 1. get Pharo code working on squeak--this worked fine and was easy.
Stage 2. Support Eliot's needs for number of platforms, languages, vm's and build types. I attempted to bolt this on with possibly the most ridiculous use of a Trait ever attempted in world history. That approach was abandoned when I discovered that a massive Trait is not loadable via monticello unless one has several decades available for download time.

Stage 3. was Study Ian's code and CMake--(light bulbs go light up in tty's brain).
Stage 4 was attempt to do both Pharo and Squeak and Ian's CMake with existing framework.
Stage 5. Abandon attempt to shoe-horn Ian's CMake into Pharo.
Stage 6. Implement CMake Template approach which are small classes that wrap CMake constructs and that output their contents to a stream (think Seaside Components)
Stage 7. Compare 6 output to Ian's code. They are pretty much tit-for-tat.

This tool just generates CMake. If there are problems with configuration and compilation, they are addressed by modifying the generated CMake. The resulting edits can then be incoorporated into an existing CMakeVMMakerSqueak Configuration or ported to a new configuration.

To use this tool, ONE MUST THINK IN CMAKE, which is what Ian did, which is how this project will progress.

Did I mention the tool is CMake driven ?

(:

cordially,

tty






 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141215/b9dd5a12/attachment.htm