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. 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. 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? -- jules > On Mon, 2005-08-29 at 13:30 +0200, Jules Colding wrote: > > Hi, > > > > Shouldn't "camel-private.h" be installed along the other Camel headers? > > A lot of locking macros depend on it. > > _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
