Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)
George, At the moment there is no overall way to do that for Pharo. For GemStone I have attributes for specific versions, so for GemStone I can write a spec like this: spec for: #common do: [...]. spec for: #gemstone do: [...]. spec for: #'gs2.4.x' do: [...]. spec for: #'gs3.x' do: [...]. So I can specific packages that are only loaded in GemStone 2.4 or GemStone 3.0. For Pharo I would imagine doing something like the following: spec for: #common do: [...]. spec for: #squeakCommon do: [...]. spec for: #pharo do: [...]. spec for: #'pharo1.0' do: [...]. spec for: #'pharo1.1' do: [...]. Then packages that were specific to 1.0 and 1.1 can be specified. I haven't added this to Metacello for Pharo, because I was kind of waiting for the need to appear rather than add a feature that noone needs, so I've been waiting for someone to ask for the feature:) Dale ----- "George Herolyants" <george.herolyants@gmail.com> wrote: | Thanks for the explanation, Dale! | | May be it's obvious and I'm asking stupid questions but then I don't | understand how can I specify in my configuration the differences | between the versions of the target platform? | | 2010/3/20 Dale Henrichs <dale.henrichs@gemstone.com>: | > George, | > | > The mcz files containing the Metacello configurations _are_ copied, | but the configuration itself is not modified in the scheme. | > | > The idea of using different repositories is to indicate which of the | many different projects are _expected_ or _known_ to work in Pharo1.1 | or Pharo1.0. | > | > For GemStone, I have createed a GemSource MetacelloRepository and I | have copied the metacello configurations that I know have been ported | to GemStone. I've done this so that folks can know what is supported. | I make sure that all of the tests run green and that all of the | configs in the GemSource MetacelloRepository can be loaded. | > | > It does not stop someone from loading a configuration into GemStone | that isn't in the GemSource MetacelloRepository, but if you do and run | into trouble, my answer will probably be that it hasn't been ported | yet. | > | > The same thing can apply to Squeak, but someone would have to step | up to testing/approving metacello configurations that run with the | various versions. | > | > Without this extra step of approval/testing, it's difficult for | someone that doesn't have their finger on the pulse of the latest and | greatest happenings to know what to expect ... | > | > Dale
Dale, Indeed, tags such as pharo1.0, pharo1.1, pharo1.2, etc. will likely be needed for some packages when we have universes for different Pharo versions. Cheers, Adrian On Mar 20, 2010, at 20:45 , Dale Henrichs wrote:
George,
At the moment there is no overall way to do that for Pharo. For GemStone I have attributes for specific versions, so for GemStone I can write a spec like this:
spec for: #common do: [...]. spec for: #gemstone do: [...]. spec for: #'gs2.4.x' do: [...]. spec for: #'gs3.x' do: [...].
So I can specific packages that are only loaded in GemStone 2.4 or GemStone 3.0.
For Pharo I would imagine doing something like the following:
spec for: #common do: [...]. spec for: #squeakCommon do: [...]. spec for: #pharo do: [...]. spec for: #'pharo1.0' do: [...]. spec for: #'pharo1.1' do: [...].
Then packages that were specific to 1.0 and 1.1 can be specified. I haven't added this to Metacello for Pharo, because I was kind of waiting for the need to appear rather than add a feature that noone needs, so I've been waiting for someone to ask for the feature:)
Dale ----- "George Herolyants" <george.herolyants@gmail.com> wrote:
| Thanks for the explanation, Dale! | | May be it's obvious and I'm asking stupid questions but then I don't | understand how can I specify in my configuration the differences | between the versions of the target platform? | | 2010/3/20 Dale Henrichs <dale.henrichs@gemstone.com>: | > George, | > | > The mcz files containing the Metacello configurations _are_ copied, | but the configuration itself is not modified in the scheme. | > | > The idea of using different repositories is to indicate which of the | many different projects are _expected_ or _known_ to work in Pharo1.1 | or Pharo1.0. | > | > For GemStone, I have createed a GemSource MetacelloRepository and I | have copied the metacello configurations that I know have been ported | to GemStone. I've done this so that folks can know what is supported. | I make sure that all of the tests run green and that all of the | configs in the GemSource MetacelloRepository can be loaded. | > | > It does not stop someone from loading a configuration into GemStone | that isn't in the GemSource MetacelloRepository, but if you do and run | into trouble, my answer will probably be that it hasn't been ported | yet. | > | > The same thing can apply to Squeak, but someone would have to step | up to testing/approving metacello configurations that run with the | various versions. | > | > Without this extra step of approval/testing, it's difficult for | someone that doesn't have their finger on the pulse of the latest and | greatest happenings to know what to expect ... | > | > Dale
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Adrian Lienhard -
Dale Henrichs