[squeak-dev] No vm-display-x11 Plug-in After Building From
Source On FreeBSD 10.1
gettimothy
gettimothy at zoho.com
Mon Dec 15 14:58:56 UTC 2014
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
More information about the Squeak-dev
mailing list
|