[squeak-dev] No vm-display-x11 Plug-in After Building From Source On FreeBSD 10.1

David T. Lewis lewis at mail.msen.com
Mon Dec 15 15:28:38 UTC 2014


Hi tty,

Sounds good :-)

Dave

> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>




More information about the Squeak-dev mailing list