CMMaker.oscog to fork or not to fork, that! is the question
Locked
 
|
Hi Eliot and David and Tim. Tomorrow I start the actual Smalltalk coding of the CMake stuff for Squeak. (My shell script that I thought would take 1 day took 5. sigh) While I am leaning towards a fork of the CMMakeVMaker work on Pharo, I will defer to you folks on that decision. Below are notes I had made a week ago about why I was leaning that way. -----begin notes I made a week or so ago---- For development purposes I am leaning towards creating a CMakeVMMaker.oscog clone of the existing CMakeVMMaker and incrementally adding platform/interpreter configurations starting with the Stack Interpreter. Much of the work will be cut-n-paste modifications of the existing work in CMakeVMMaker done by the pharo team as that is the guts of the pharo system. The Pharo environment (very clean, btw) has three layers to it (from top down they are). 1. PharoVMMaker 2. CMakeVMMaker 3. Source Tree and scripts from github. What is very interesting about pharo is that given 3) a git checkout, you can download, run and configure a new pharo image using a shell script provided with the git source. Launching the resulting generator.image you are presented a workspace with scripts invoking 1) PharoVMMaker which is a "wrapper" or "interface" to 2) CMakeVMMaker. This generates the sources and CMake files and from there you go to the build directory and build I like this approach and will be emulating it, but I do not think it is integrate the Squeak infrastructure into the existing package; here is why. 1. Squeak source tree from svn is a superset of the tree from git with a slight difference in naming for the default build. Where Squeak has unixbuild, nssprucogbuild, etc, pharo just has build. This "probably" has implications for the CMMake script generation that will not suffice for supporting the standard interpreter nor for the other flavors Eliot is developing. 2. If I attempt to merge the two approaches (git and svn, pharo build tree and squeak build tree) it will clutter the very clean work-flow pharo has. 3. As I develop this, I would like the squeak community to test-drive what I do. It is not appropriate for me to muddy the existing CMakeVMMaker with dev work 4. Assuming I can actually do this thing, I do not think a merge of the two projects would be too difficult ---end notes I made a week or so ago--- Please let me know your decision. cordially, tty : |
Re: CMMaker.oscog to fork or not to fork, that! is the question
|
|
Hi tty, I think that you are outlining a reasonable way to set up a build system, but if your objective is to get oscog and trunk VM builds to use a common build system based on Cmake, and if you want Ian and Eliot to adopt that approach, then I think you may be taking the long way around the problem. The platforms source tree is maintained in Subversion, not in git. The Cmake code that is used to set up the build is maintained along with the platform sources (e.g unix/plugins/FilePlugin/config.cmake goes with unix/plugins/FilePlugin). Those cmake scripts are also maintained in Subversion, such than any Cmake snippet that may be needed to customize the build for unix/plugins/FilePlugin is maintained in Subversion along with the related platform sources. It is certainly possible maintain the sources in git rather than Subversion, and it is also possible to generate the Cmake scripts from a Squeak (Pharo) image, thereby moving the version management into Monticello rather than Subversion. Both of these are possible, and the Pharo VM build demonstrates this quite nicely. I am not going to try to argue that one approach or another is better (I do have opinions on the matter, but we are not suffering here from a shortage of opinions). But if your objective is to get oscog and trunk VM builds to use a common build system based on Cmake, then developing another build system may not put you on a fast path toward that objective. Dave On Tue, May 06, 2014 at 06:19:26PM -0700, gettimothy wrote: > > Hi Eliot and David and Tim. > > > Tomorrow I start the actual Smalltalk coding of the CMake stuff for Squeak. (My shell script that I thought would take 1 day took 5. sigh) > While I am leaning towards a fork of the CMMakeVMaker work on Pharo, I will defer to you folks on that decision. > > > Below are notes I had made a week ago about why I was leaning that way. > > > -----begin notes I made a week or so ago---- > > > For development purposes I am leaning towards creating a CMakeVMMaker.oscog clone of the existing CMakeVMMaker and incrementally adding platform/interpreter configurations starting with > the Stack Interpreter. Much of the work will be cut-n-paste modifications of the existing work in CMakeVMMaker done by the pharo team as that is the guts of the pharo system. > > > The Pharo environment (very clean, btw) has three layers to it (from top down they are). > > > 1. PharoVMMaker > 2. CMakeVMMaker > 3. Source Tree and scripts from github. > > > What is very interesting about pharo is that given 3) a git checkout, you can download, run and configure a new pharo image using a shell script provided with the git source. > Launching the resulting generator.image you are presented a workspace with scripts invoking 1) PharoVMMaker which is a "wrapper" or "interface" to 2) CMakeVMMaker. > This generates the sources and CMake files and from there you go to the build directory and build > > > I like this approach and will be emulating it, but I do not think it is integrate the Squeak infrastructure into the existing package; here is why. > > > 1. Squeak source tree from svn is a superset of the tree from git with a slight difference in naming for the default build. Where Squeak has unixbuild, nssprucogbuild, etc, pharo just has build. > This "probably" has implications for the CMMake script generation that will not suffice for supporting the standard interpreter nor for the other flavors Eliot is developing. > > > 2. If I attempt to merge the two approaches (git and svn, pharo build tree and squeak build tree) it will clutter the very clean work-flow pharo has. > > > 3. As I develop this, I would like the squeak community to test-drive what I do. It is not appropriate for me to muddy the existing CMakeVMMaker with dev work > > > 4. Assuming I can actually do this thing, I do not think a merge of the two projects would be too difficult > > > ---end notes I made a week or so ago--- > > > Please let me know your decision. > > > > > cordially, > > > > > tty > > > > > > > > > : > > > > > |
|
|
Hi, if I can give an opinion, I would go through making a “SqueakVMMaker”, PharoVMMaker style. then you don’t need to fork the common base who will still be available for all platforms. Esteban On 07 May 2014, at 05:17, David T. Lewis <[hidden email]> wrote: > > Hi tty, > > I think that you are outlining a reasonable way to set up a build system, > but if your objective is to get oscog and trunk VM builds to use a common > build system based on Cmake, and if you want Ian and Eliot to adopt that > approach, then I think you may be taking the long way around the problem. > > The platforms source tree is maintained in Subversion, not in git. The > Cmake code that is used to set up the build is maintained along with the > platform sources (e.g unix/plugins/FilePlugin/config.cmake goes with > unix/plugins/FilePlugin). Those cmake scripts are also maintained in > Subversion, such than any Cmake snippet that may be needed to customize > the build for unix/plugins/FilePlugin is maintained in Subversion along > with the related platform sources. > > It is certainly possible maintain the sources in git rather than Subversion, > and it is also possible to generate the Cmake scripts from a Squeak (Pharo) > image, thereby moving the version management into Monticello rather than > Subversion. Both of these are possible, and the Pharo VM build demonstrates > this quite nicely. > > I am not going to try to argue that one approach or another is better (I do > have opinions on the matter, but we are not suffering here from a shortage > of opinions). But if your objective is to get oscog and trunk VM builds to > use a common build system based on Cmake, then developing another build > system may not put you on a fast path toward that objective. > > Dave > > > On Tue, May 06, 2014 at 06:19:26PM -0700, gettimothy wrote: >> >> Hi Eliot and David and Tim. >> >> >> Tomorrow I start the actual Smalltalk coding of the CMake stuff for Squeak. (My shell script that I thought would take 1 day took 5. sigh) >> While I am leaning towards a fork of the CMMakeVMaker work on Pharo, I will defer to you folks on that decision. >> >> >> Below are notes I had made a week ago about why I was leaning that way. >> >> >> -----begin notes I made a week or so ago---- >> >> >> For development purposes I am leaning towards creating a CMakeVMMaker.oscog clone of the existing CMakeVMMaker and incrementally adding platform/interpreter configurations starting with >> the Stack Interpreter. Much of the work will be cut-n-paste modifications of the existing work in CMakeVMMaker done by the pharo team as that is the guts of the pharo system. >> >> >> The Pharo environment (very clean, btw) has three layers to it (from top down they are). >> >> >> 1. PharoVMMaker >> 2. CMakeVMMaker >> 3. Source Tree and scripts from github. >> >> >> What is very interesting about pharo is that given 3) a git checkout, you can download, run and configure a new pharo image using a shell script provided with the git source. >> Launching the resulting generator.image you are presented a workspace with scripts invoking 1) PharoVMMaker which is a "wrapper" or "interface" to 2) CMakeVMMaker. >> This generates the sources and CMake files and from there you go to the build directory and build >> >> >> I like this approach and will be emulating it, but I do not think it is integrate the Squeak infrastructure into the existing package; here is why. >> >> >> 1. Squeak source tree from svn is a superset of the tree from git with a slight difference in naming for the default build. Where Squeak has unixbuild, nssprucogbuild, etc, pharo just has build. >> This "probably" has implications for the CMMake script generation that will not suffice for supporting the standard interpreter nor for the other flavors Eliot is developing. >> >> >> 2. If I attempt to merge the two approaches (git and svn, pharo build tree and squeak build tree) it will clutter the very clean work-flow pharo has. >> >> >> 3. As I develop this, I would like the squeak community to test-drive what I do. It is not appropriate for me to muddy the existing CMakeVMMaker with dev work >> >> >> 4. Assuming I can actually do this thing, I do not think a merge of the two projects would be too difficult >> >> >> ---end notes I made a week or so ago--- >> >> >> Please let me know your decision. >> >> >> >> >> cordially, >> >> >> >> >> tty >> >> >> >> >> >> >> >> >> : >> >> >> >> >> > |
|
|
In reply to this post by David T. Lewis
Hi David. Thanks for your thoughts. Some definitions: In the discussion let's let 1. VMMaker refer to Standard Interpreter build system including image,build tools and source tree from svn co http://squeakvm.org/svn/squeak/trunk 2. VMMaker.oscog refers to Cog Interpreter build system including image, build tools and source tree from svn co http://www.squeakvm.org/svn/squeak/branches/Cog 3. Pharo refers the pharo build system which uses VMMaker-oscog, git and CMMakeVMMaker tools Some principles: 1. I will NOT be touching or modifying VMMaker. 2. I will NOT be modifying the existing VMMaker.oscog build systems in any way. Eliot will not see ANY changes to existing infrastructure. (ok, an addition of a shell script and support files in Cog/image, but that's it) 3. I AM creating a parallel CMake system using the existing infrastructure. Ok, onto your concerns
I do not. My task is only to create a CMake system for VMMaker.oscog without touching the existing build systems.
Who needs the extra work? (: We have 1 source tree for the old Standard VM at: http://squeakvm.org/svn/squeak/trunk We have 1 source tree for the Cog work at: http://www.squeakvm.org/svn/squeak/branches/Cog The pharo team wanted git and did their thing.
I would love to hear them. I have emailed you directly with an attached .tgz file that can be extracted into the Cog/image directory from http://www.squeakvm.org/svn/squeak/branches/Cog with a current SVN checkout from svn co http://www.squeakvm.org/svn/squeak/branches/Cog the script does the following: 1. On VMMaker branch (cmakify.sh -s VERSION) (it basically extends the work done by Eliot in buildsqueak*.sh . my script goes to 11, though) a. creates a subdirectory named installStandardVMaker b. downloads Squeak VERSION c. copies the pristine Squeak.image/changes to a StandardVMaker.image/changes d. runs Squeak with a BuildStandardImage.st script to install the VMMaker tools on the StandardVMMaker.image e. downloads the source tree from http://squeakvm.org/svn/squeak/trunk and stores it where Squeak expects it relative to the installStandardVMMaker directory. f. Sets up sym-links for VMMakerTool g. copies in some .config files for VMMakerTool h. Adds a Workspace help text So, that task is done. Instead of going here:http://wiki.squeak.org/squeak/6177 and following the steps and links at the wiki. a newbie wanting to get up and running with the Standard VMMaker suite can do 3 things: VMMaker branch work is done. There are no changes to existing stuff. I have merely added a convenience script if people choose to adopt it. If it is adopted, the contents of the image.tty.tgz I emailed you will have to be added to SVN tree. 2. On VMMaker.oscog branch the same script is used and the behavior is similar. (cmakify.sh -c VERSION -t) (i.e. it mimics the existing buildsqueak*.sh scripts Eliot has) a. create a subdirectory named installCogVMMaker b. downloads the appropriate squeak VERSION to it c. copies the pristine .image and .changes files to CogVMMaker.image/changes d. runs squeak with the apprpriate Buildsqueak*.st smalltalk script to install the VMMaker.oscog tools from stable or trunk if specified with the -t switch e rsyncs the current Cog source tree into a subdirectory where the VMMaker.oscog tools can find it f. strips the synced source tree of all Gnu build artifacts g. sets up sym-links for VMMakerTool h. copies in some *.config files for VMMaker tool The Cog/image/installCogVMMaker directory can then be moved to wherever the developer wants it. So, I have VMMaker.oscog set up on squeak with a pristine, cleaned copy of the SVN tree residing underneath it ready to have CMakeLists.text files added to it. The original SVN is unchanged as are existing build scripts. A newbie can be up and running with the latest VMMaker.oscog or VMMaker environment in minutes. So, my goal of making it easy for a newbie is done, the existing infrastructure is unchanged and nobody's toes are being stepped on. Now on to the next step. Now, I need to add the CMakeLists.text files to the clean source tree. (An added benefit would be to have them actually work, but let's start simple (: ) There are two starting points for this: 1. The existing CMakeLists.text in the VMMaker source tree from http://squeakvm.org/svn/squeak/trunk 2. The existing CMakeVMMaker tool at source.squeak.org/VMMaker (If you are not familiar with it, it defines and generates CMakeLists.txt and puts them in the source tree) Estaban has stated:
I am cool with this. I was/am hesitant to clutter up the pharo team work, but if they are ok, me too. Another option is to fork CMMakeVMMaker and create CMMakeVMMaker.oscg You guys let me know. thx. tty |
|
|
In reply to this post by EstebanLM
Thanks Estaban cheers, tty |
Re: CMMaker.oscog to fork or not to fork, that! is the question
|
|
In reply to this post by EstebanLM
On Tue, May 6, 2014 at 10:11 PM, Esteban Lorenzano <[hidden email]> wrote:
+1
best, Eliot
|
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |