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 _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
