Nope nothing stupid on your end, just mine. The new Makefile.am requires some changed 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 > >> Dbmail-dev@dbmail.org > >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >> > > > > > > > > -- > > > > > > > > _______________________________________________ > > Dbmail-dev mailing list > > Dbmail-dev@dbmail.org > > 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 > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
