Re: [RFC] SMP dependency hell

On 05/02/11 06:06, Tsantilas Christos wrote:
> 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...
>

Heck no. That is exactly what we want to avoid. Simpler the tests can be
without loosing coverage the better.

You may have noticed I've pushed in a slightly improved version of my
patch. Did so because I have to move ahead with other bug fixes on trunk
and release. It seems to work okay for the dependency stuff. Solaris
shows syntax problems elsewhere.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.10
   Beta testers wanted for 3.2.0.4