[openi18n-im:01294] Re: [proposal] distribute parts of im-sdk separately

Hideki Hiura wrote:
>>From: Jens Petersen <[email protected]>
>>into separate packages.  In a sense quite a few of these already have
>>separate "maintainers" looking after them, so it is largely a matter of
>>just making separate releases of tarballs for each iiimf subproject.
> 
> Sounds good to me.

Sorry for taking so long to follow up on this.

> To maintain consistency for building of each parts, we need to think about
> how to rearrange the include files currently positioned semi-private 
> files.
> 
> Any suggestions?

So far what I have been doing is just to install "im-sdk/includes/"
in a system directory and then have IM_INIT point IM_INCLUDEDIR to that
directory, but I think it would be better if those private include files
were moved to the appropriate project dir subdirs, which should then install
(as semi-private if necessary).

("im-sdk/acfiles/" is okay of course since it can be used directly inplace for
bootstrapping the tarballs of subdirs.  At least with a small hack.)

I would like to suggest the following names for the separate tarballs:

doc			---> iiim-doc
gnome-im-switcher	---> iiim-switcher-applet
iiimecf			---> iiim-emacs
iiimgcf			---> iiim-gtk
iiimjcf			---> iiim-java
iiimqcf			---> iiim-qt
iiimsf			---> iiim-server
iiimxcf/*		---> iiim-xim ?
leif/<name>		---> iiim-le-<name>
lib/<name>		---> iiim-lib-<name>

So far I generated the following test tarballs which nearly all build.

iiim-gtk-12.1.50.tar.gz
iiim-leif-12.1.50.tar.gz  -- should be split up into LEs
iiim-lib-client-12.1.50.tar.gz      \
iiim-lib-eimil-12.1.2161.tar.gz      |
iiim-lib-protocol-12.1.50.tar.gz     |  it would be nice to merge some of these
iiim-lib-xiiimp-12.1.50.tar.gz      /
iiim-server-12.1.50.tar.gz
iiim-switcher-applet-12.1.50.tar.gz

I have some patches to acfiles and the various configure.ac and
Makefile.am files, needed to bootstrap them correctly so that they can
build outside the im-sdk tree, which I would like to commit soon.

One more issue is what to do with the version numbering of the individual
packages?  In my tests I just set them all arbitrarily to 12.1.50 (ie they
would all get released at version 12.2 say) but I'm not sure if that makes sense
in all cases?  In the longer term I expect the version numbers of individual
subpackages to start to diverge, but that does not matter: so the X.Y release
of iiim would be defined as the set of packages with version X_i.Y_i.
X_i.Y_i should only really get bumped up when there are changes to the package -
there is no need or point to bump up the version just to keep all the version in
sync: and some packages will surely need more frequent releases than others.

Does this all sound reasonable?  Please give comments and feedback.

Cheers, Jens