Created attachment 21562 [details]
kipi-plugins-0.1.4-no-libgpod-automagic-dep.patch

Arnd, Angelo, Valerio, Gerhard, ...

Somebody can check if this patch is fine. If yes, feel free to apply it on svn (:=)))

Gilles

This patch is already in Gentoo portage (testing branch) for about 2 weeks, thus probably live-tested by fair amount of people. See http://bugs.gentoo.org/show_bug.cgi?id=191195#c4

Matěj

hmm why should we use an option to avoid compiling a ipod export?
I mean we don't have it for other plugins... we just test if we can build them
(we have the all dependencies) and if not we disable it.

So if that plugin cannot build but passes all the tests, there is a bug on it IMO....

my 2 €cents
Angelo

In reply to comment #4:
While current behaviour is perfectly OK for binary based distros, individual developers and enthusiasts, it is huge pita for source based distros, such as Gentoo.

Let me explain:
In source distros, user usually control what features will be enabled or disabled in particular package by some distro-specific way, resulting in --with-feature or --without-feature being automatically passed to package's ./configure. However, this is used also to mark actual dependencies of a package, for example, if she opts to enable ipod support in kipi-plugins, they will have dynamic dependency on libgpod.

Assume following scenario:
1. Uses installs Amarok with ipod feature enabled, which in turn pulls libgpod as a dependency.
2. She installs kipi-plugins _without_ ipod feature enabled, because she is not interested in transferring photos to iPod. (thus no libgpod dependency is recorded to kipi-plugins)
3. She uninstalls Amarok, which in turn uninstalls libgpod, because distro's package manager thinks that it is no longer needed by any package.
4. User's kipi-plugins break, because library they linked against, libgpod, is no longer present on the system.

Step 4 happens because distro's package manager was not able to disable ipod support in kipi-plugins. My patch solves it.

This is one of many scenarios when such breakage can happen. Among possible solutions, patching package's build system is far the best. Please see already posted http://www.gentoo.org/proj/en/qa/automagic.xml for details.

Regards,
         Matěj

well, i could take a look at it but I don't agree in releasing it for ipodexport and have a different behaviour for any other plugins.
I don't know much of gentoo, i will ask for it to Valerio.
Anyway I can't get why one can change a configure option to build his own package (i believe it's not the default behavior) and can't write something like "build_libgpod=no ./configure" that is already in? ...don't know why it is though...

BTW packages for binary based distro must be built so if packager doesn't add the libgpod dependency ipodexport plugins won't build anyway, except in the casi it is already on his system...

>I don't agree in releasing it for ipodexport and have a different behaviour for >any other plugins. 

I'm agree with you...

Gilles

Ok I see your point (comment #5) but leaving the user decide if enabling or not an option, in the case of plugins, should mean --with/without-feature with feature (IMO) equal to the plugin itself, not the libgpod to avoid compiling it. Is it ok for you? Gilles can we do something like that, i mean allow disabling all the plugins?
In such a way the test won't be done if and only if user add --without-ipodexport, in this case.

> Ok I see your point (comment #5) but leaving the user decide if enabling or not an option, in the case of plugins, should mean --with/without-feature with feature (IMO) equal to the plugin itself, not the libgpod to avoid compiling it. Is it ok for you?

Okay, you decide, the name not really important.

> Gilles can we do something like that, i mean allow disabling all the plugins?

If you let me comment on that, I don't think it's worth the effort. I think it's worth only for optional plugins, that have external dependency. (in which case it would be more reasonable to name --with{,out}-stuff after a dependency and not after the feature.
Example: --without-libtiff    build kipi-plugins without Acquire Images, RAW Converter and JPEG Lossless plugins. (default=check)
and not three separate options to effectively disable linking against libtiff)

If you want, I can try to write a patch for you. (dealing with all optional external dependencies)

Thanks for your effort,
    Matěj

Matěj your help is more than welcome of course, but before starting let's see
another point of view. 
We're talking about plugins and even if i can see the external lib dependency
point, i can't get why for user should be easier removing a lib dependency instead of a plugin. I mean you talked about ipod-export and said that user can think he/she doesn't need it, so he/she should disable libgpod (in your example), that sonunds odd to me, i would disable the plugin instead.

OTOH you could be right in the case, as it happened, kipi-plugins has been released with libgpod X dependency, but stable system has libgpod X-1, in such a case --without-libgpod is right, but --without-ipodexport either. 

WDYT?

> We're talking about plugins and even if i can see the external lib dependency point, i can't get why for user should be easier removing a lib dependency instead of a plugin. I mean you talked about ipod-export and said that user can think he/she doesn't need it, so he/she should disable libgpod (in your example), that sonunds odd to me, i would disable the plugin instead.

Oh yes, you are right..

So, I imagine we could solve it like this:
* Create a section in configure.in.in, with:
    1. build_libgpod=no ### for every conditionally needed library
    2. AC_ARG_ENABLE(ipodexport,
           AC_HELP_STRING([--disable-ipodexport], [disable iPod Export plugin. Requires libgpod. [default=enable]]),
           [enable_ipodexport="$enableval"; build_libgpod="$enableval"],
           [enable_ipodexport=yes; build_libgpod=check]
       )
       ### for every plugin
* envelop every check for conditionally needed library in:
    if test "x$build_libgpod" != "xno"; then    (already done for libgpod)
    (and die if build_libgpod===yes and not found, but do not die if build_libgpod=check)
* add AM_CONDITIONAL(compile_XX, [test "x$enable_xx" != "xno"]) for plugins that don't already have a AM_CONDITIONAL.
* tweak configure.in.bot not to print "Library not found" for non-needed libs

Anyone has clue how to do it without writing AC_ARG_ENABLE for every plugin?

Also, I changed --with-feature to --enable-feature, see http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_130.html and http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_node/autoconf_131.html

Comments welcome,
    Matěj

It sounds good to me. Gilles? Any comments from other kipi developers?

>           [enable_ipodexport="$enableval"; build_libgpod="$enableval"],
>           [enable_ipodexport=yes; build_libgpod=check]

..this should be further tweaked so it does not overwrite previous build_libgpod value (in case 2 plugins have same dependency), I'm aware of that.

I'll start working on that when it receives ack from other kipi devs.

I think it's OK, make all plugins compilation indipendent is good : it follows the plugin philosopy and will surely make source-based distro users more happy :)

Regards, 
Valerio

it's ok for me. You can provide a patch ;) 
I've seen no answers from Gilles, but he said he agrees in having the same behaviour for any plugins. This way is, so....

Angelo,

It's fine for me. But by default all plugins must be enable (if all depencies are available of course). If the users (packager) want to disable one depency, it must necessary specify it to command line.

Note : 

1/ libkipi depency is always mandatory, else no plugin can be compiled.
2/ A report must be writed somewhere to describe witch depencies have been disable during compilation.
3/ This depencies management must be backported to KDE4. Angelon it's a good exercice to start to learn CMake...

Achim, it's fine for you about Debian packaging ?

comment #17: Yes it must work as you said.

About backport, i can't start working on kde4 untill mandriva 2008.0 is out, I'be too many things to do by now :/

Created attachment 21745 [details]
kipi-plugins-0.1.4-builsystem-tweaks-v1.patch

After a few days of autoconf/automake/m4/shell torture, I'm proud to announce
v1 of my patch. ;)

Depending on where you patch, do it with -p1 or -p2.

Features:
* As ./configure --help says, it is now possible to enable or disable every
kipi plugin, defaulting to enable, if depencencies are meet.
* It should also simplify adding new patches, it would require adding 2 lines
to configure.in.in and 5 lines to Makefile.am.
* Dependencies are handled automatically, each plugin can have multiple
dependencies and one dependency can be shared by multiple plugins. You list
them only once for each plugin.
* configure.in.bot is tweaked so it shows most accurate and helpful
information. (including what plugins will and will not be built, what libs will
and will not be used, what libs would be needed to enable not-presently-enabled
plugins)

To resolve:
* Current behaviour is to fail when --enable-feature was given to ./configure
and dependencies for feature are not satisfied. Is it feasible?
* what about sync and imagesgallery plugins? They weren't listed in Makefile.am


P.S.: It's quite late now, so there may be naughty mistakes in my patch.
Nonetheless it works for me, but YMMV, so give it a good testing please. I'm
open to all comments and improvements.
P.P.S.: Some day, I may fall in love with cmake. If it happens, there is a
possibility I would do something similar for KDE4 kipi-plugins.

Matěj Laitl, your foolish buildsystem tweaker.

> Created an attachment (id=21745)
>  --> (http://bugs.kde.org/attachment.cgi?id=21745&action=view)
> kipi-plugins-0.1.4-builsystem-tweaks-v1.patch

Great thanks, Gilles can you give it a look now? I'll do it tonight.
 
> * what about sync and imagesgallery plugins? They weren't listed in Makefile.am

The first is in progress, the latter has to be removed at all.... since it has been
obsoleted by htmlexport.
 
> P.P.S.: Some day, I may fall in love with cmake. If it happens, there is a
> possibility I would do something similar for KDE4 kipi-plugins.

You're more than welcome ;)
Gilles if it is all ok we must add him as a contributor....

On Monday, 1. October 2007, Gilles Caulier wrote:
> Angelo,
> 
> It's fine for me. But by default all plugins must be enable (if all depencies are available of course). If the users (packager) want to disable one depency, it must necessary specify it to command line.
> 
> Note : 
> 
> 1/ libkipi depency is always mandatory, else no plugin can be compiled.
> 2/ A report must be writed somewhere to describe witch depencies have been disable during compilation.
> 3/ This depencies management must be backported to KDE4. Angelon it's a good exercice to start to learn CMake...
> 
> Achim, it's fine for you about Debian packaging ?


I can't see a problem with your suggestion Gilles.

Achim
> 
> 

SVN commit 722604 by anaselli:

Added configure options to disable plugins provided by Matej Laitl
CCBUG:  149666

 M  +103 -13   Makefile.am  
 M  +2 -1      NEWS  
 M  +102 -55   configure.in.bot  
 M  +182 -79   configure.in.in  


WebSVN link: http://websvn.kde.org/?view=rev&revision=722604

I added the patch and should be released into kipi-plugins 0.1.5-beta1
After tests we can can close it, if you've submitted kde-imaging mailing list you should read a pre-release mail soon.
Thanks,
   Angelo

On Sunday 07 of October 2007 20:07:47 Angelo Naselli wrote:
> I added the patch and should be released into kipi-plugins 0.1.5-beta1


Great, someone could please verify if jpeglossless depends on tiff? It is (and 
was) listed as it does not depend on it, but inside a text reported to user 
opposite was said.

> After tests we can can close it, if you've submitted kde-imaging mailing
> list you should read a pre-release mail soon. Thanks,
>    Angelo


If this is a question to me - Yes, I'm now subscribed.

    Matěj

> someone could please verify if jpeglossless depends on tiff? 

Fo non JPEG files, JPEGLossLess plugin use ImageMagick (run time depency). So it do not depand of libtiff...

Gilles

So I suppose this should definitely be closed, thanks to all involved people.

SVN commit 725111 by anaselli:

SVN_SILENT: updated

CCBUG: 149666

 M  +12 -0     NEWS  


WebSVN link: http://websvn.kde.org/?view=rev&revision=725111