Libtool and Support for Shared Libraries

[Jeroen van Meeuwen (Kolab Systems)]

On 2012-05-10 17:32, Bron Gondwana wrote:
> On Thu, May 10, 2012 at 04:03:26PM +0200, Дилян Палаузов wrote:
>> Hello,
>>
>> >While we're at it, I'd love to split things like 'mailbox.c' which 
>> are
>> >really libraries into a separate directory from 'imapd.c' which is 
>> a
>> >system daemon only run by master from cyrus.conf and separate again
>> >from cyr_dbtool.c which is a tool designed to be mainly run by 
>> humans.
>>
>> I would suggest, that
>> the sources of libcyrus are moved to src/lib/cyrus,
>> the sources of libcyrus_min are moved to src/lib/cyrus_min,
>> the sources of libimap are moved to src/lib/imap,
>> the sources of libsieve are moved to src/lib/sieve,
>> the sources of the services from imap/ are moved to src/service,
>> probably the installable header files are moved to src/include,
>>
>> and then check what to do with the remaining files.
>>
>> With services I mean fud, imapd, lmtpd, pop3d, smmapd and 
>> sync_server.
>

May I suggest the services end up in src/libexec/ perhaps?

> There's still things like master as well.  I'd really like to move
> that elsewhere so the name 'master' doesn't clash with the git branch
> name 'master'.  It makes a few commands more annoying to run.
>
> src/master or something would be better.
>

It could still match remote 'src' branch 'master' - if we consider 
renaming the installed utility to cyrus-master, why not name the source 
file cyrus-master as well? A location could be (this is the only service 
process to be executed, really) src/sbin/.

The utilities could live in src/bin/ (cyrus-quota, cyrus-mbpath).

> But - it will invalidate basically every patch out there,

Yes indeed it will, and we have another (huge) pending task; fixing the 
indentation.

> so I
> don't want to embark on something like this until we've merged
> everything we're planning to merge, and everyone has advance notice
> of the plan.  Even the automake changes so far have been quite
> invasive.
>

I agree. This tidying up is going to majorly invasive - don't forget we 
want to merge in caldav before this happens as well.

I strongly recommend any major really tidying things up is postponed to 
2.6.

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