[Vm-dev] CMakeVMMaker what is repository for latest? and how to????????sync with source.squeak.org?

Eliot Miranda eliot.miranda at gmail.com
Fri May 16 23:55:36 UTC 2014


On Fri, May 16, 2014 at 4:38 PM, gettimothy <gettimothy at zoho.com> wrote:

>
> Hi Eliot.
>
>
>
> Hi Tty,
>
>     just to confirm form my POV, echoing Tim's point.  It is a hard and
> fast requirement that one be able to check out
> http://www.squeakvm.org/svn/squeak/branches/Cog  and build *without*
> invoking VMMaker.  VMMaker shoudl be invoked to create new versions of the
> generated source in http://www.squeakvm.org/svn/squeak/branches/Cog (e.g.
> src/vm/gcc3x-cointerp.c et al) but must *not* be a prerequisite for a build.
>
>
>
>
> Thanks for clarifying.
>
> There is a bit of a chicken and egg problem here. Namely, how are the
> CMakeLists.text and associated files going to get there in the first place?
>

In exactly the same way as the generated source files got into the tree.
 By starting up a VMMaker image and generating them.  You're missing the
point.  The point is not that VMMaker isn't used to generate source and/or
configurations.  It is.  The point is that it is not used during VM build.
 So the process to introduce a new configuration is...

1. fire up a VMMaker image, modify the configuration there-in and publish
the new CMakeVMMaker package.
2. generate the relevant configurations from that image
3. check-in the modified svn source tree
4. check out the svn source tree and build

Note that step 4 can ten be done on its own without doing steps 1. 2. & 3.
providing a repeatable VM build.



>
> What about the existing GNU auto-tools infrastructure?
>

You mean autoconf?  It's horrible isn't it?  Once it isn't necessary it can
be dropped.  But not until.


> I don't think it makes sense to have both GNU and CMAKE on the same source
> tree; am I wrong?
>

For the time being they can coexst.  In fact they do coexist already.  Once
the CMAKE stuff works the old unused autoconf stuff can be deleted.  But
not until.


>
> Assuming I am not, here is the approach.
>
> 1 get the existing source tree.
> 2. strip out the existing GNU stuff.
> 3. generate the new CMake stuff in place of the GNU stuff. (the tool
> currently invokes VMMaker as well--I can put something together that does
> not)
> 4. cmake. make.
>
> The Pharo stuff that I am emulating does invoke VMMaker, however, I am
> sure I can  bypass that and just put in the CMake stuff without
> re-generating code.
>
> However, Tim mentioned that sometimes launching and image to generate the
> CMake files is not possible. How then, to they get into the SVN tree so
> that the process becomes
>
> 1. svn co http://source.squeak.org/cmake_foo
> 2. cd Cog
> 3. cmake. make
>
> ?
>
> That's what I am confused over.
>

I don't know; I don't use cmake.  But that's what one can do with autoconf.
 And that's what one needs to be able to do with cmake.  Isn't it simply
that CMakeVMMaker generates cmake input files?



---- On Fri, 16 May 2014 16:17:39 -0700 *Eliot
Miranda<eliot.miranda at gmail.com <eliot.miranda at gmail.com>>* wrote ----

Hi Tty,

    just to confirm form my POV, echoing Tim's point.  It is a hard and
fast requirement that one be able to check out
http://www.squeakvm.org/svn/squeak/branches/Cog  and build *without*
invoking VMMaker.  VMMaker shoudl be invoked to create new versions of the
generated source in http://www.squeakvm.org/svn/squeak/branches/Cog (e.g.
src/vm/gcc3x-cointerp.c et al) but must *not* be a prerequisite for a build.


On Fri, May 16, 2014 at 10:33 AM, gettimothy <gettimothy at zoho.com> wrote:


Hi Tim.

 > Here is what I have in place so far:
>
> 1. Get the latest Cog tree from svn co
http://www.squeakvm.org/svn/squeak/branches/Cog
> 2. cd Cog/image/ and run script to build an image which:
> 2.a builds image with tools per current process.
> 2.b (additionally loads FT2Plus Toxic bypass)
> 2.c additionally load the CMakeVMMaker package from source.squeak.org(now loading from SmalltalkHub)
> 2.d Recursively copies the parent Cog source code to
image_directory/oscogvm/*
> 3.e Cleans the source tree to just source by finding and deleting all
GNU-Build artefacts (Makefiles, autotool stuff)
> 3. User launches new image with the pristine source tree underneath it.
> 4. Run process SqueakVMBuilder buildXYZ (same as pharo process, but
squeak names) to generate the source code and CMake stuff in the clean
source tree.
> 5. Run generated 'build.sh' script which invokes CMake and make.


It’s those last two parts that imply something is going a bit off-track
here.

Now don’t forget I’m a fan of VMMaker, after all I invented it 14 years ago
(actually so far as I can tell pretty much *exactly* ) but the convenience
of being able to do an svn co, hit the OS-appropriate buttons and
autoconfigure/build is considerable. Yes, I suppose one could have multiple
svn branches for the (many, many) different versions of *nix but making use
of the already existing CMake capability strikes me as more sensible.



Existing functionality is unchanged.
There is only 1 SVN branch.
VMaker is unchanged
My additions are non-intrusive.

Regarding existing CMake capability, I am leveraging what the pharo team
has already done.  It appears Ian's work is hand coded CMakeLists.txt in
trunk/platforms/unix and a configure script that generates the plugin CMake
files.

Regarding your ability to just svn co and run cmake, I agree that will be
nice and it can be done. However until the tool is mature we need something
that will work with what we have without getting in the way. I believe this
approach will accomplish that.

Hopefully I will have something in place tomorrow that you can test-drive.

cordially,


tty.






-- 
best,
Eliot






-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140516/51709ec9/attachment-0001.htm


More information about the Vm-dev mailing list