[Vm-dev] Error compiling Cog.
Mariano Martinez Peck
marianopeck at gmail.com
Thu Mar 31 07:30:32 UTC 2011
On Wed, Mar 30, 2011 at 11:52 PM, Igor Stasenko <siguctua at gmail.com> wrote:
> On 30 March 2011 20:11, Mariano Martinez Peck <marianopeck at gmail.com>
> wrote:
> >
> >> >
> >> >
> >> > ((Smalltalk at: #ConfigurationOfCog) project
> >> > version: '1.5') load: 'VMakerWithCmake'.
> >> >
> >> > and that's all :)
> >>
> >>
> >> So, if you know how to do that, please do. And i will happily integrate
> >> it.
> >>
> >
> >
> > Find the ConfigurationOfCog attached. As an example, I've created the
> > version 1.6 and baseline 1.4
> >
> > Notice that in the baseline I added:
> >
> > spec repository: 'http://www.squeaksource.com/VMMaker';
> > package: 'CMakeVMMaker' with: [spec requires: #('Cog') ] .
> >
> >
> > and in the version I added:
> >
> > package: 'CMakeVMMaker' with: 'CMakeVMMaker-IgorStasenko.51'.
> >
> > So...for new versions, the only thing you will need to do is to set that
> > version, just the same you do with the rest.
> >
> > So..this:
> >
> > Gofer new
> > squeaksource: 'MetacelloRepository';
> > package: 'ConfigurationOfCog';
> > load.
> >
> > ((Smalltalk at: #ConfigurationOfCog) project
> > version: '1.5') load.
> >
> >
> > ((MCHttpRepository location: 'http://www.squeaksource.com/VMMaker'
> user:
> > '' password: '')
> > versionFromFileNamed: 'CMakeVMMaker-IgorStasenko.51.mcz') load.
> >
> >
> > now is reduced to:
> >
> >
> > Gofer new
> > squeaksource: 'MetacelloRepository';
> > package: 'ConfigurationOfCog';
> > load.
> >
> > ((Smalltalk at: #ConfigurationOfCog) project
> > version: '1.5') load.
> >
> >
> Nice. Thanks.
>
> >
> >>
> >> I'd like to note to everyone:
> >>
> >> - an automated build process works, but its not perfect. (but its
> >> much better than we had before ;)
> >>
> >> So, a criticism and help or ideas how to improve it is welcome.
> >>
> >> >
> >> > Another idea is to put in the #description of each version of
> >> > ConfigurationOfCog, which is the expected version of git to work. I
> used
> >> > to
> >> > do this wtih SVN and ConfogurationOfVMMaker.
> >> > this way we can map from the other side ;)
> >> > even more...in the description you can directlty put which sohuld be
> the
> >> > git
> >> > command.
> >> >
> >>
> >> Well, that will be unnecessary, because multiple git snapshots may
> >> work with same configuration.
> >
> > The same the other way arround ;)
> > The same VMMaker version can work with different git snapshos
> >
> >>
> >> (You may fix or change some platform code, which not requires any
> >> changes on VMMaker side).
> >>
> >
> > or vice-versa
> >
> >>
> >> This means that my scheme keeps correspondence in direction
> >> source => VMMaker
> >>
> >
> > but why not adding VMMaker -> source
> > also ?
> >
> how you suppose to do that?
> In configs then you need to put an array of git commits which working
> with your config? Or what?
>
> And then i will be forced to commit sources to git, while
> configuration of it to load is not there yet (because only after
> commit
> i can get an url to these sources and then put it into config and
> finally upload new config to squeaksource).
>
> It looks a bit complicated, isnt? And extra manual work..
>
Yes, maybe. My thught was this procedure:
1) You commit on Git, and it you get version XXX. This changes on Git needs
changes on VMMaker so:
2) You create a new version of ConfigurationOfCog. Let's say YYY. In that
moment, that version is blessed with #development and in the descript you
put something like saying that it should work with Git versions > XXX.
Example:
versionYYY: spec
<version: 'YYY' imports: #('1.4-baseline') >
spec for: #common do: [
spec blessing: #development.
spec description: 'Should be used with Git version > XXX'.
spec
package: 'FFI-Pools' with: 'FFI-Pools-eem.3';
package: 'SharedPool-Speech' with: 'SharedPool-Speech-dtl.2';
package: 'Balloon-Engine-Pools' with:
'Balloon-Engine-Pools-JB.2';
package: 'Qwaq-VMProfiling-Plugins' with:
'Qwaq-VMProfiling-Plugins-JB.5';
package: 'Sound' with: 'Sound-StephaneDucasse.62';
package: 'VMMaker-oscog' with: 'VMMaker-oscog-IgorStasenko.54';
package: 'Alien-Core' with: 'Alien-Core-IgorStasenko.68';
package: 'Cog' with: 'Cog-eem.44';
package: 'CMakeVMMaker' with:
'CMakeVMMaker-IgorStasenko.51.mcz'.
].
3) when there is a new commit ZZZ in git that requires a new version of
VMMaker, then you:
3.a) close the previous version (you put blessing:#version)
3.b) change the description so that it closes the range.
Example:
versionYYY: spec
<version: 'YYY' imports: #('1.4-baseline') >
spec for: #common do: [
spec blessing: #release.
spec description: 'Should be used with Git version > XXX nad < ZZZ
'.
spec
package: 'FFI-Pools' with: 'FFI-Pools-eem.3';
package: 'SharedPool-Speech' with: 'SharedPool-Speech-dtl.2';
package: 'Balloon-Engine-Pools' with:
'Balloon-Engine-Pools-JB.2';
package: 'Qwaq-VMProfiling-Plugins' with:
'Qwaq-VMProfiling-Plugins-JB.5';
package: 'Sound' with: 'Sound-StephaneDucasse.62';
package: 'VMMaker-oscog' with: 'VMMaker-oscog-IgorStasenko.54';
package: 'Alien-Core' with: 'Alien-Core-IgorStasenko.68';
package: 'Cog' with: 'Cog-eem.44';
package: 'CMakeVMMaker' with:
'CMakeVMMaker-IgorStasenko.51.mcz'.
].
And then of course, you create the new version if ConfigurationOfCog, let's
say NNN
versionNNN: spec
<version: 'NNN' imports: #('1.4-baseline') >
spec for: #common do: [
spec blessing: #development.
spec description: 'Should be used with Git version > ZZZ '.
spec
package: 'FFI-Pools' with: 'FFI-Pools-eem.3';
package: 'SharedPool-Speech' with: 'SharedPool-Speech-dtl.2';
package: 'Balloon-Engine-Pools' with:
'Balloon-Engine-Pools-JB.2';
package: 'Qwaq-VMProfiling-Plugins' with:
'Qwaq-VMProfiling-Plugins-JB.5';
package: 'Sound' with: 'Sound-StephaneDucasse.62';
package: 'VMMaker-oscog' with: 'VMMaker-oscog-IgorStasenko.54';
package: 'Alien-Core' with: 'Alien-Core-IgorStasenko.68';
package: 'Cog' with: 'Cog-eem.44';
package: 'CMakeVMMaker' with:
'CMakeVMMaker-IgorStasenko.51.mcz'.
].
and like that....
What do you think? If you really understand it, it is not hard. It seems
quite easy for me and it gives us even more traceability.
Cheers
Mariano
> >>
> >> in that way for each source snapshot you know which version of VMMaker
> >> you should use.
> >> But not in reverse order.
> >>
> >>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110331/d085c9f1/attachment-0001.htm
More information about the Vm-dev
mailing list