[Vm-dev] Error compiling Cog.

Mariano Martinez Peck marianopeck at gmail.com
Sun Apr 3 11:47:41 UTC 2011


So..you don't like it ? ;)  no problem :)

On Thu, Mar 31, 2011 at 9:30 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
> 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/20110403/4760f683/attachment.htm


More information about the Vm-dev mailing list