[Evolution-hackers] Re: About evolution-data-server/libedataser and evolution/e-utils

[Harish Krishnaswamy <kharish novell com>]

On Thu, 2005-11-24 at 16:33 +0800, Irene wrote:
> Hi, Harish 
> 
> I built evolution 2.6 on my Solaris X86 the other day. The build process
> was successful, however, as soon as I started evolution-2.6, it crashed.
> We investigated this problem and arrived at the following conclusions:
> 
> camel_vee_folder_hash_folder in
> evolution-data-server/camle/camel-vee-folder.c invokes functions
> including md5_init, md5_update and md5_final. The fact is, two copies of
> md5_utils.[c|h] with exactly same functions defined, exist in the
> evolution system, one in evolution-data-server/libedataser and the other
> in evolution/e-utils. 
Right. This is the result of an incomplete migration of the files and
the existence of duplicates is a known structural issue - though we have
not seen bugs/functional breakage yet. This just explains why the
problem has existed w/o crying for attention for this long- we do need
to fix it.


> Camel-vee-folder.c includes
> evolution-data-server/libedataserver/md5-utils.h, but when evolution
> runs, the md5_* functions in evolution/e-utils/md5-utils.c instead of
> those in evolution-data-server/libedataserver/md5-utils.c are invoked,
> which we think should not be the case. 
> 
Building with an eye for this detail (building against the right
function) solves this problem. This is why it works on Linux, i guess. I
need to see how Solaris x86 handles this.

> When we went further into this issue, we saw that there's a huge lot of
> duplication in evolution-data-server/libedataser and evolution/e-utils.
> With such duplications, similar problems may surface in the future when
> one copy of the code is modified while the other remains unchanged. 
> 
> We think that something should be done to solve this problem. 
yes. let us get this discussed on the meeting next week. I would love if
someone can volunteer to do a detailed audit on this duplication and
chalk out how we can get rid of the cruft. (In some cases, I suspect
they may not be exact duplicates and both may be required in that form
by different pieces). 

Takers, you can count on me to chip in to lend a hand :-)

Cheers,
Harish