[Q] Package dependencies
stéphane ducasse
ducasse at iam.unibe.ch
Thu Nov 4 09:59:40 UTC 2004
I meant only one level of nesting
> MagmaServer
> requires MagmaClient
> and Ma Client Server
> and Ma Object Serialization
and not
> MagmaClient
> requires Ma Client Server
> and Ma Object Serialization
after I'm not sure that this is scaling well but more that inside
dependencies.
We are trying for SWII and we will learn in the process :)
Stef
On 3 nov. 04, at 22:19, Chris Muller wrote:
>
> Hi Stéphane, let me know if I'm interpreting your suggestion
> correctly. Are
> you saying to make each direct-prerequisite *and*
> indirect-prerequisite a
> direct-prerequisite. Thus, instead of having:
>
> MagmaServer
> requires MagmaClient
> requires Ma Client Server
> requires Ma Object Serialization
>
> I would have:
>
> MagmaServer
> requires MagmaClient
> and Ma Client Server
> and Ma Object Serialization
>
> MagmaClient
> requires Ma Client Server
> and Ma Object Serialization
>
> Ma Client Server
> requires Ma Object Serialization
>
> and in so keeping no more than one-level of prerequisites for any
> particular
> package, this would seem to clear up the problem as you said.
>
> Interesting, that sounds pretty good, but please tell me what you and,
> hopefully Avi if this ends up being in Monticello, think of this too.
> What if,
> upon marking a package dirty, it finds all packages that have that
> package as a
> direct-prerequisite and marks them dirty too, under the same process,
> therefore, *its* parents will also be marked dirty, all the way up the
> chain.
>
> So, in the original example:
>
> MagmaServer
> requires MagmaClient
> requires Ma Client Server
> requires Ma Object Serialization
>
> Marking Ma Object Serialization dirty causes Ma Client Server to be
> marked
> dirty causes MagmaClient causes MagmaServer.
>
> This may have a slight additional benefit that each package up the
> chain which
> also serves as an independently usable package (i.e., Ma Client
> Server) will
> have the latest version saved without having to force it dirty through
> some
> "non-change" (i.e., add / delete a space in some method, save to force
> package
> dirty, then save package). Instead, it's all automatic.
>
> I think you pulled me back to reality in terms of using prereqs. I
> need the
> tool to remember package-version compatibility, so I don't know what I
> was
> thinking when I suggested the possibility of undefining all of my
> pre-reqs.
>
>
>
> --- stéphane ducasse <ducasse at iam.unibe.ch> wrote:
>
>> chris
>>
>> I do not know if this is the solution but why not having a separate
>> and
>> empty package (called map after)
>>
>> MagmaServer 23
>> requires MagmaClient.24
>> requires MaClient.17
>> requires Ma Object Serialization 21
>>
>> Then when you change
>>
>> MagmaServer 24
>> requires MagmaClient.24
>> requires MaClient.17
>> requires Ma Object Serialization 26
>>
>> This way you always control a complete coherent pieces of working
>> together packages
>> but you do not have the problems you encountered.
>>
>> We will try to develop SmallWiki two this way and try to minimise
>> hardcoding dependencies
>> inside the packages.
>>
>> Note that ned at OOPSLA suggested to me not to have nested map because
>> this way
>> you are sure that you do not get twice and child with different
>> version
>> in separated nested maps.
>>
>> If you used this way of structuring your code I would appreciate that
>> you let us know if this is working.
>>
>> Stef
>
More information about the Squeak-dev
mailing list
|