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

[David T. Lewis]

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

Hi tty,

Usually I am using a 64-bit linux box, running either a 64-bit interpreter
VM (no compatibility libs) or Cog. I have the 32-bit libraries installed,
so I don't notice the difference one way or the other.

I now use an Ubuntu laptop, and cannot compile Cog on it (not a problem
for me because I have an older SuSE box that still works). Presumably this
is due to changes in the older build tools that are used in the Cog
branch, so I will be interested to see if your CMake configuration takes
care of the problem. The CMake build for trunk works fine, so there is a
good chance that it will help for Cog also.

As an aside, I'm not terribly impressed with Ubuntu at the moment, see for
example http://bugs.squeak.org/view.php?id=7812

Dave

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