[Evolution-hackers] Re: camel-private.h not installed

[Not Zed <notzed ximian com>]

On Tue, 2005-08-30 at 09:39 +0200, Jules Colding wrote:
> On Tue, 2005-08-30 at 09:03 +0800, Not Zed wrote:
> > Hmm, well "private" gives a hint as to why it isn't ...
> > 
> > But I guess there are certainly locks that implementations need to use
> > (this wasn't always the case) from it.
> > 
> > I'm not sure how to get around this, I don't want it installed though.
> 
> Right now I am doing something like:
> 
> #include </home/evo/work/src/evolution-data-server/camel/camel-private.h>
> 
> which is awkward, to say the least, and not really an option for
> distributed code.

Well you don't need to do that anyway, you could path it in a -I thing.

> Access to a locking mechanism for externally developed components is
> really necessary unless they should use homegrown solutions, which is
> not an option either I guess.

Hmm, i'm not sure - it might depend on the particular lock.  It is
probably possible to get away with not using any of those locks but just
defining your own.  That's how camel-imap-* used to work, but because of
other problems (mainly complexity and races due to the the 4 levels of
interested parties, service, store, disco-store and imap-store), that
particular implementation was changed.

> I am really not qualified at all to hack on some way to extract the
> "to-be-public" parts of "camel-private.h". I would bet a really big part
> of my right arm that much in Evolution depend on hard to spot properties
> of the current implementation.
>  
> Any suggestions?

Given we are in hard code freeze, not sure; since moving it around
requires some macro changes, which i guess are code.

Which locks are you trying ot access?  Do you really need them?
Anything else in private is definitely private.

-- 
adfa(evolution-2.4:20087): gtkhtml-WARNING **: cannot find icon:
'stock_insert-url' in gnome