Re: [Evolution-hackers] camel eds work progress



I'm ready to have this moved. I've got no pending commits to camel that
will be difficult to merge once the move happens, so now is an excellent
time for me to have it moved as well.

so please, the sooner the better :)

Jeff

On Tue, 2004-11-16 at 22:13 +0800, Not Zed wrote:
> 
> Ok, just an update on this.
> 
> In the branch i've got camel building in eds.  At the moment i tied
> the library version name to $BASE_VERSION, the same with the package
> config name.  I've run everything off the top-level configure rather
> than doing on in the camel dir - mainly since i don't know how to do
> cross dependencies like needing libedataserver otherwise (oh, and its
> simpler).
> 
> Even though camel is split, the package-config stuff just lists both
> libraries - i'm not sure what to do about that, i guess i need a
> camel-provider.pc too.  Also, not sure how i do lib dependencies with
> libedataserver, and whether just listing the .la handles that.
> 
> Some of the other things i'm not sure about, where to put things,
> libexec i've put in ${libexecdir}/camel/${BASE_VERSION}, but the
> includes i've just put in ${privincludedir}/camel instead.  The former
> can't follow the same .../evolution-data-server-${BASE_VERSION}/ as
> the headers because, well thats the name of the actual server.  I'm
> kind of inclined to put the camel headers in its own
> ${includedir}/camel/${BASE_VERSION}/camel thing, to separate it a bit,
> but its 6 to one, half a dozen to the other really.  Anyone care?
> 
> I removed the installation of the camel provider's headers, they never
> should've been installed.  And I fixed up camel's 'make check' to
> hopefully run 'in the build tree' without having to do make install.
> I haven't tried any dist type checks though.
> 
> I'm running this version now, it seems to be working, although i need
> to test to make sure its not just using other installed libraries.
> 
> Now the next bit, I think Jeff could commit any of his outstanding
> code to cvs, then JP can copy the camel rcs files across to
> evolution-data-server/camel, then Jeff can just generate a patch from
> any changes made after that point when the changes are merged since it
> wont build until then.  (this is such a pain with timezones).
> 
> All my stuff is in cvs, so tonight would be good for me, and it wont
> affect anything anyway since everything is still on the branches.
> 
> Z
> 
> On Mon, 2004-11-15 at 17:55 +0800, Not Zed wrote:
> > 
> > Hi,
> > 
> > Just giving a short progress report on the camel in eds thing.  I've
> > had to make a few decisions along the way and i'm bringing them up
> > here since nobody is ever around on irc when I am.
> > 
> > The story so far:
> > 
> >       * I've branched evolution and eds with
> >         notzed-camel-eds-branch.  
> >       * I've split camel into two parts, libcamel, containing the
> >         core object, stream, mime processing and message system, and
> >         libcamel-provider, containing all the store, vfolder, remote
> >         streams, etc.  
> >       * I've moved fully things from e-util to libedataserver,
> >         removing them from e-util.  e-memory.c, e-msgport.c,
> >         e-sexp.c, e-trie.c, some i updated from the core, some are
> >         new.  Some other things should probably follow, like
> >         e-account/e-account-list, which are surely out of date.  The
> >         current duplication is very very bad.  
> >       * I've removed the no longer used e-path.c from e-util.  
> >       * I've moved e-iconv from gal/util to libedataserver, camel is
> >         completely gal-independent now.  
> >       * I've added a bunch of fugly stuff to eds's configure.in,
> >         some of this is now duplicated in eds, so some of the
> >         conditional stuff should be based on eds's tests not
> >         duplicated, not sure what to do with it yet.  
> >       * I've made camel in it 2 calls, camel_init and
> >         camel_provider_init.  
> >       * I've fixed all the code in all the modules to use
> >         libedataserver's version of various things that were in
> >         e-util.  
> >       * I fixed a bunch of linking errors - libraries not on link
> >         lines or function names mistyped, so unless its really
> >         necessary and people running dumbly-setup distros whine too
> >         much, the fixes should wait till I merge back. 
> > So the main changes outside of camel itself are just
> > e-util->libedataserver moves, i think everything except mail was
> > already linking to it anyway.
> > 
> > Wow, this sucked.  But it should be nearly there already.  I'm
> > thinking to actually move libcamel to eds, it should be copied on
> > the cvs server, then do everything on the new version only from that
> > point on.  This reqiures some syncing with Jeff, JP, and I most
> > probably - the other modules aren't important.
> > 
> > Z
> > 
> > 
> > -- 
> > 
> > Michael Zucchi <notzed ximian com>
> > "Free Software, putting the Free
> > back in Free Market."
> > Novell's Evolution and Free
> > Software Developer
> -- 
> 
> Michael Zucchi <notzed ximian com>
> "Free Software, putting the Free
> back in Free Market."
> Novell's Evolution and Free
> Software Developer
-- 
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
fejj ximian com  - www.novell.com

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]