Make libicu required by default?

Milan Crha mcrha at redhat.com
Wed Feb 3 01:29:29 PST 2016


	Hello,
I'd like to ask for your opinion to make libicu required by default.
Even the release notes say it's required for RSCALE support, I didn't
pay much attention to it and simply updated the package. As the
previous package didn't need libicu, and it is not installed by default
in the build system, then I didn't notice it missing and I lost the
RSCALE support due to it. I guess I'm not the only one.

What I suggest is to require libicu by default, but add a cmake
parameter to disable this requirement, thus make it still an optional
dependency. That way the packagers will notice the new feature much
easily and will be able to decide.

The evolution-data-server (using autotools, not cmake) has such things
too, for example for UOA (Ubuntu Online Accounts) support, which is
enabled by default and if the library isn't found during ./configure it
stops and prints:

    checking for LIBSIGNON_GLIB... no
    configure: error: 

    	    libsignon-glib not found (or version < 1.8)

    	    If you want to disable Ubuntu Online Accounts support,
    	    please append --disable-uoa to configure.

That way one gets a hint to re-run ./configure with added
--disable-uoa parameter, to not build UOA support, or that he/she
should install other library and do not lost functionality.

In case of libical and ICU library more accurate would be --without-icu,
probably, but the cmake uses completely different way of doing the same
than autotools/configure.

I believe it'll be better to "propose" complete library build by
default, rather than remove functionality silently (it's not completely
silent, there is one line in the build log about missing ICU library,
but there is a similar line about missing doxygen, which I didn't
realize what it is used for, because even with that installed there is
no documentation installed with 'make install'. I didn't check closely
how the doxygen is used in libical, and this request is about something
completely different, thus back to the point...).

	Bye,
	Milan



More information about the libical-devel mailing list