On 2012-04-15 11:27, Bron Gondwana wrote:
On Sun, Apr 15, 2012, at 01:31 AM, Дилян Палаузов wrote:
Hello,

at git://demo.aegee.org:143/cyrus-imapd.git , branch dpa/automake I have
patched cyrus-imapd/master to support Automake .

With the exception of perl and CUnit, I it works fine and permits
building in a directory, different from the source directory.  All
dependencies are moved to a single Makefile.am (except CUnit and Perl). The point with CUnit is, that I did not manage to get it running on my system, so I left it as is. The Makefile's generated from Makefile.PL do not permit compiling perl files in a directory, different from the
source directory.

I wonder if we can change from Makefile.PL to one of the more modern
Perl build systems...


I reckon the Perl side of things is due a refactor anyways, no?

I do not have the purify-tool, so I was not able to compile the
imap/imap.pure, imap/imap.quant, imap/lmtpd.pure, imap/muptead.pure,
imtest/imtest.pure, notifyd/notifyd.pure, ptclient/ptdump.pure,
ptclient/ptexpire.pure, ptclient/ptloader.pure and
timsieved/timsieved.pure targets.  Those are not transferred to
Makefile.am . I guess, the one who use those pure-things, can easily
extend Makefile.am to support them.

We don't use them.  I wonder if anyone actually does :)


Let's put a stake in the ground and remove them.

"make dist" shall build .tar.bz2 including all files. However I have
copied the dist-target from the old Makefile.in, removed all
Makefile.dist files. The one who make tarballs/snapshots shall consider
if it is wiser to use the Automake system to make tarballs, or the
system used so far (with git). So or so, the xversion.h file needs to
be generated by git.

So long as it can be done easily, I dno't much care.


Can configure.ac -> ./configure please be made in charge of xversion.h?

I'll log a ticket with this request.

I hope you will like the result.  Let me know, if you experience any
(compilation) problems, after merging the changes. I will respond promptly.

By the way, when approximately will be v2.5 released?

We don't know for sure. I had a good chat with Greg in Melbourne last
week about what still needs to be done.  My plan is to build a set of
bugs that need to be resolved, and make sure everything we're thinking
about is on that list!  Then we'll have a clearer idea.


Perhaps it's time we call a meeting to discuss 2.5.

Shall I announce tickets need to be created as per the #3669[1] model? Then if it isn't a ticket in Bugzilla it's not going to be planned. What do we think is a suitable timeframe for people to start creating tickets?

[1] https://bugzilla.cyrusimap.org/show_bug.cgi?id=3669

Regardless, I think we should merge your automake code now, so we have
a chance to test it for a while!

Please let me work on this for a few, so we have some more eyeballs rolling over this.

I propose we have Dilyan send in his SSH key for access to git.cyrusimap.org, and we set the distribution component to be assigned to him by default. Perhaps we rename the distribution component to build / autoconf / automake / autofoo?

Kind regards,

Jeroen van Meeuwen

--
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08

Reply via email to