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

[gettimothy]

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?


What about the existing GNU auto-tools infrastructure? 


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


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. 






cordially,


tty











---- On Fri, 16 May 2014 16:17:39 -0700 Eliot Miranda<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
 
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140516/966a1a91/attachment.htm