Ok, a9 posted. "Aaron Stone" <[EMAIL PROTECTED]> said:
> Nope nothing stupid on your end, just mine. The new Makefile.am requires > some changes to acinclude.m4 to define the *ALIB variables. > > I'll post a9 ASAP with the directories and other cleanups. > > Sorry, a8 doesn't build without libSieve, but a9 will! > > Aaron > > > Ilja Booij <[EMAIL PROTECTED]> said: > > > Hi All, especially Aaron, > > > > I have trouble compiling the code with the a8 patch. Mainly because I > > cant seem to get libSieve to compile.. But also because it's, for now, > > impossible to compile without the libSieve headers. The new Makefile.am > > does not really solve this problem, because it does not work.. > > * It uses subdirectories for storing the sorting code. Which files > > should go in to those directories? > > * It uses @SORTALIB@ and @AUTHALIB@, but they are not mentioned > > anywhere in the other autotools files. Should there be something > > included in acinclude.m4? > > > > Aaron, could you correct this (or am I doing something extremely > > stupid?) > > > > Ilja > > > > On Dec 22, 2003, at 10:26 AM, Aaron Stone wrote: > > > > > Cool, glad that insert_messages() abstacts the physmessage stuff. I > > > kinda got > > > that from a quick read, but no time this weekend to read into it that > > > much. > > > > > > The db_copymsg() changes will be included in a9... although if you'd > > > like, I > > > can send a separate patch to the list if you want to include it sooner. > > > > > > I was actually quite disappointed with the state of the Sieve > > > interface; I > > > thought I had it a lot farther along than it actually is :-\ Anyways, > > > I wrote > > > it for libSieve-2.2.0pre1 and this week I'm going to have pre4 which > > > has a lot > > > of things changed and really a lot of things fixed. > > > > > > For now, just getting the LMTP daemon, the unified delivery layer and > > > the > > > sort/ directories set up should take enough of everyone's time, and > > > are not > > > even affected by the broken Sieve situation -- just don't ./configure > > > --with-sieve. Once the framework is in CVS, I'll focus on the Sieve > > > issues. > > > > > > Aaron > > > > > > > > > Ilja Booij <[EMAIL PROTECTED]> said: > > > > > >> Hi, > > >> On Dec 20, 2003, at 6:33 AM, Aaron Stone wrote: > > >> > > >>> Just following up to my own message here, I went ahead and tried out > > >>> the > > >>> directories thing in my own source tree, and it works like a charm. > > >>> I'm going > > >>> to do some more hacking on the lmtp/sorting/sieve patch set and get > > >>> version a9 > > >>> up onto the SourceForge project this weekend, or maybe Monday > > >>> afternoon. > > >> I'll just start testing with the a8 patch. And when you're finished > > >> with the a9 version (and everything works :) ), we'll use that one. > > >>> > > >>> Oh, Ilja, I noticed that you changed the return type of db_copymsg() > > >>> again. I > > >>> gave you a polite time about it, then later a hard time about it... > > >>> so > > >>> now > > >>> I'll spare no mercy! db_copymsg() really really must give back the id > > >>> number > > >>> of the new message that it has created! I patched it to add the > > >>> fourth > > >>> arg: > > >>> > > >>> int db_copymsg(u64_t msg_idnr, u64_t mailbox_to, > > >>> u64_t user_idnr, u64_t *newmsg_idnr); > > >>> > > >>> Lemme know if that works right, or if I have to fiddle with > > >>> physmessage or > > >>> something crazy like that... I'm not sure yet if I understand how to > > >>> use the > > >>> physmessage layer. Uh, actually, I'm just ignoring it and pretending > > >>> that the > > >>> higher level functions like db_insert_message() take care of > > >>> physmessage for > > >>> me. Is that the case or do I need to rewrite to support physmessage > > >>> directly? > > >> You're completely right. I thought I changed it to return the > > >> message_idnr as a call-by-reference parameter. But I didn't.. > > >> > > >> You're correct that functions like db_insert_message() will take care > > >> of the physmessage table. No worries about that. > > >> > > >> Ilja > > >> -- > > >> IC&S > > >> Stadhouderslaan 57 > > >> 3583 JD Utrecht > > >> telnr. 030-6355730 > > >> faxnr. 030-6355731 > > >> > > >> PGP-key: > > >> http://www.ic-s.nl/keys/ilja.txt > > >> > > >> _______________________________________________ > > >> Dbmail-dev mailing list > > >> [email protected] > > >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > >> > > > > > > > > > > > > -- > > > > > > > > > > > > _______________________________________________ > > > Dbmail-dev mailing list > > > [email protected] > > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > > -- > > IC&S > > Stadhouderslaan 57 > > 3583 JD Utrecht > > telnr. 030-6355730 > > faxnr. 030-6355731 > > > > PGP-key: > > http://www.ic-s.nl/keys/ilja.txt > > > > _______________________________________________ > > Dbmail-dev mailing list > > [email protected] > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > > > -- > > > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
