Re: [RFC] SMP dependency hell

On 02/04/2011 03:56 PM, Amos Jeffries wrote:
> On 04/02/11 22:31, Tsantilas Christos wrote:
>> On 02/04/2011 08:38 AM, Amos Jeffries wrote:
>>> Christos,
>>>
..............
>>
>> The main problem is that all libraries under src/ are not real libraries
>> but just objects collections. It does not make sense to try use them as
>> libraries.
>> Real libraries should have a hierarchical dependency (I am not sure if I
>> am using the right words here.)
>
> I understand what you are trying to say, but it is false. These
> libraries are as real as any. The difference is a single compiler switch
> and a few bytes in the start of the binary.

Yes this is a library. I am talking about the way the libraries used. In
squid3 they are used as objects collections, not as libraries.
Or even better they are parts/modules of squid, not libraries.

>
> These libraries should have the same task+information groupings as any
> 'real' library. With a task each performs layer on top of other tasks
> which may be existing in themselves or in another library elsewhere.
>
> The 'glue' code that links two libraries strongly together must go in
> the "upper" one. So that the upper layer 'knows' about the lower layer
> but the lower only knows itself.
>
> In this case IMO the SNMP and MGR are high layers the IPC is lower yes?

Yes. What really needed here, is a part of the Coordinator be
implemented outside the ipc library, or ipc/mgr and snmp included in
one library.

But again this is only a very small part of the problem. Inside ipc AND
in other libraries there are calls to simple files. As an example in
ipc library there are calls to comm.cc file, which is not a library.

This is not a real problem or bug, this is how squid is build. I am OK
with that, I do not believe, we should change it.
The problem begins when we are trying to put the parts/modules of the
squid to work as libraries.

I do not know which is the correct way to solve this. Maybe a solution
is to include all objects used to build squid when we are building the
tests...

>
> The other objects you mention are separate problems, which may or may
> not need to be solved. ie Store pulls in many things but itself is
> needed only when MGR is.
>
>>
>> In general, I do not know if it is worth to spend all of this time
>> trying to make this tests to work :-(
>
> It's worth a little but not too much. Where a small change can fix it do
> so. Otherwise stub_*.cc it until a larger refactor can be done.
>
> In the background I'm playing with graphing tools today to see if we can
> scan the code and produce a image of the dependencies. To plan a better
> long-term fix.

>
> Amos
Received on Fri Feb 04 2011 - 17:06:18 MST