Hi David,
I just noticed/realised that now that we have multiple build slaves (thanks Tony!), we have a problem in that the CogVM build will fail on lfpdeb64/lfpdeb32 because those slaves don't have the makevm script. What's a good way to fix this? (Also, I'm guessing that the CogVM build should be limited to a 32 bit machine and, if we want to test its 64-bit-fitness, that we run a separate job (again limited, but to a 64 bit machine)) frank |
On Wed, Jul 24, 2013 at 08:22:42AM +0100, Frank Shearar wrote:
> Hi David, > > I just noticed/realised that now that we have multiple build slaves > (thanks Tony!), we have a problem in that the CogVM build will fail on > lfpdeb64/lfpdeb32 because those slaves don't have the makevm script. > > What's a good way to fix this? > Hi Frank, I will take a look and see what's going on, though it might be a day or two before I can get to it. The makevm script(s) are in the project workspaces of course, and I've been keeping them versioned (RCS) in my home directory on build.squeak.org. I guess this means I need to figure out how to save them with git like you have done with the other projects (sorry I have not really used git before, so I'll have to give it a try). That said, I would like to make it clear that the intent of the InterpreterVM and CogVM jobs on build.squeak.org is *not* to produce compiled VMs. Rather they are intended to produce source tarballs from the original Smalltalk source (VMMaker and other pieces) along with latest platform sources. The compilation step in those jobs is performed in order to verify that the generated sources are compilable, since at various times this may not be the case. I tried to make this clear in the project descriptions for InterpreterVM: "Update to bleeding edge VM platforms sources and VMMaker Smalltalk code. Generate C code for interpreter VM. Configure and build on this machine to verify source integrity. Create a tarball of sources for a Unix interpreter VM suitable for building on a Unix/Linux machine." Official releases of source tarballs and compiled Squeak VMs for Unix are at http://squeakvm.org/unix/." And for CogVM: "Update to bleeding edge oscog VM platforms sources and oscog VMMaker Smalltalk code. Generate C code for Cog VM. Configure and build on this machine to verify source integrity. Create a tarball of sources for a Unix Cog VM suitable for building on a Unix/Linux machine. Official releases of Cog VMs and sources are at http://www.mirandabanda.org/files/Cog/VM/. See http://www.mirandabanda.org/cogblog/ for additional information about Cog." There might be some value in maintaining automated builds of the latest VM sources, and if so we should definitely work this out with the authors and maintainers of the VMs. The key people right now are Ian Piumarta (author of the Unix VM and host of the squeakvm.org site that has served the VM community for many years), and Eliot Miranda, creator of Cog. I'm saying this because I do not want VMs on our build.squeak.org server to be perceived as official or supported VMs. Just as an example of why this could cause problems, if you were to take a compiled VM from the CogVM project on build.squeak.org and install it on your own computer at home, it would not work (because of the way that I specified the install directory in the build script). That would inevitably result in questions to Eliot that would waste his time and try his patience. Likewise for the standard Unix VM, if someone takes a compiled VM from build.squeak.org, it might work but if there is a problem there is no way that Ian can help, and it's a waste of his time if we create problems like that. > (Also, I'm guessing that the CogVM build should be limited to a 32 bit > machine and, if we want to test its 64-bit-fitness, that we run a > separate job (again limited, but to a 64 bit machine)) It depends on the intent of the job that you are setting up. If the intent is to see if you can successfully compile the VM, then there is nothing wrong with building a 32-bit Cog VM on a 64-bit machine, as long as the compiler options are set up right and the necessary 32-bit libraries are installed. Aside from that it should make no difference. On the other hand, if the intent is to test whether a compiled VM (such as a binary release from squeakvm.org or mirandabanda.org) will run on some target 32-bit or 64-bit machine, then yes you would definitely want to set up different jobs for that. We may need quite a lot of build slaves to test the various permutations of OS and CPU, but it might be a really useful thing if that could be done :) Dave |
On 24 July 2013 16:34, David T. Lewis <[hidden email]> wrote:
> On Wed, Jul 24, 2013 at 08:22:42AM +0100, Frank Shearar wrote: >> Hi David, >> >> I just noticed/realised that now that we have multiple build slaves >> (thanks Tony!), we have a problem in that the CogVM build will fail on >> lfpdeb64/lfpdeb32 because those slaves don't have the makevm script. >> >> What's a good way to fix this? >> > > Hi Frank, > > I will take a look and see what's going on, though it might be a day > or two before I can get to it. The makevm script(s) are in the project > workspaces of course, and I've been keeping them versioned (RCS) in my > home directory on build.squeak.org. I guess this means I need to figure > out how to save them with git like you have done with the other projects > (sorry I have not really used git before, so I'll have to give it a try). I'm happy to help out. If the makevm stuff was in a git repository, we could take a brand new slave and say "check out this repository, and run this file". Well, it doesn't have to be a git repository. It's just that github is so convenient! > That said, I would like to make it clear that the intent of the InterpreterVM > and CogVM jobs on build.squeak.org is *not* to produce compiled VMs. Rather > they are intended to produce source tarballs from the original Smalltalk source > (VMMaker and other pieces) along with latest platform sources. The compilation > step in those jobs is performed in order to verify that the generated sources > are compilable, since at various times this may not be the case. While I fully understand the nature of the InterpreterVM and CogVM jobs, it's certainly worthwhile repeating this so that people don't get the wrong idea. > I tried to make this clear in the project descriptions for InterpreterVM: > > "Update to bleeding edge VM platforms sources and VMMaker Smalltalk code. > Generate C code for interpreter VM. Configure and build on this machine > to verify source integrity. Create a tarball of sources for a Unix > interpreter VM suitable for building on a Unix/Linux machine." > > Official releases of source tarballs and compiled Squeak VMs for Unix > are at http://squeakvm.org/unix/." > > And for CogVM: > > "Update to bleeding edge oscog VM platforms sources and oscog VMMaker > Smalltalk code. Generate C code for Cog VM. Configure and build on > this machine to verify source integrity. Create a tarball of sources > for a Unix Cog VM suitable for building on a Unix/Linux machine. > > Official releases of Cog VMs and sources are at > http://www.mirandabanda.org/files/Cog/VM/. > > See http://www.mirandabanda.org/cogblog/ for additional information > about Cog." > > > There might be some value in maintaining automated builds of the latest > VM sources, and if so we should definitely work this out with the authors > and maintainers of the VMs. The key people right now are Ian Piumarta > (author of the Unix VM and host of the squeakvm.org site that has served > the VM community for many years), and Eliot Miranda, creator of Cog. > > I'm saying this because I do not want VMs on our build.squeak.org > server to be perceived as official or supported VMs. Just as an example > of why this could cause problems, if you were to take a compiled VM from > the CogVM project on build.squeak.org and install it on your own computer > at home, it would not work (because of the way that I specified the install > directory in the build script). That would inevitably result in questions > to Eliot that would waste his time and try his patience. Likewise for the > standard Unix VM, if someone takes a compiled VM from build.squeak.org, > it might work but if there is a problem there is no way that Ian can > help, and it's a waste of his time if we create problems like that. Totally. I _would_ like _vm devs_ to use the bleeding edge VMs. Or, rather, I would be very happy to supply CI support to the VM guys, if it's useful to them. For instance, I can see value in running the full suite of image tests on a cutting edge VM. >> (Also, I'm guessing that the CogVM build should be limited to a 32 bit >> machine and, if we want to test its 64-bit-fitness, that we run a >> separate job (again limited, but to a 64 bit machine)) > > It depends on the intent of the job that you are setting up. If the > intent is to see if you can successfully compile the VM, then there is > nothing wrong with building a 32-bit Cog VM on a 64-bit machine, as > long as the compiler options are set up right and the necessary 32-bit > libraries are installed. Aside from that it should make no difference. OK, that's good. > On the other hand, if the intent is to test whether a compiled VM (such > as a binary release from squeakvm.org or mirandabanda.org) will run on > some target 32-bit or 64-bit machine, then yes you would definitely want > to set up different jobs for that. We may need quite a lot of build > slaves to test the various permutations of OS and CPU, but it might be > a really useful thing if that could be done :) Agreed! frank > Dave > > |
Free forum by Nabble | Edit this page |