configure.ac improvements, part 1

[Fab]

Since nk reintroduce dbus-glib in README.html (r7597), I decided to investigate to know exactly where it is required :

$ grep -R 'dbus.glib' src/* | grep -v '.svn'
src/common/dbus_support.py:     import dbus.glib
src/common/zeroconf/zeroconf.py:        import dbus.glib
src/gajim-remote.py:    import dbus.glib
src/music_track_listener.py:    import dbus.glib
src/network_manager_listener.py:import dbus.glib
src/notify.py:  import dbus.glib
src/remote_control.py:          import dbus.glib

Ok, dbus.glib and dbus are optionally needed everywhere, not only for zeroconf.

It means that configure.ac lies : currently, dbus is checked only if the remote option is enabled :

if test "x$enable_remote" = "xyes";then
	PKG_CHECK_MODULES([DBUS], [dbus-1 >= 0.60])

I think that configure.ac must reflect the needs and requirements of the program, else it is useless. That's why I improved it, I cut out it in several parts :

• the begining of the file is the same as the old
• ./configure options
• packages and libs checks (gtk, dbus, etc...)
• another part from the old configure.ac
• the last part, where we decide to build (or not) the modules/features, and where we produce the following output :

*****************************
  Configure options :
    --enable-remote .... yes
    --enable-gtkspell .. no
    --enable-idle ...... yes
    --enable-trayicon .. no
    --enable-nls ....... yes

*****************************
  Dependencies found :
    dbus-1 ........... yes
    dbus-glib-1 ...... yes
    gtkspell-2.0 ..... yes
    xscrnsaver ....... yes
    xscrnsaver libs .. yes
    gettext .......... yes

*****************************
  Build features:
    nls .............. true
    spell check ...... false
    idle module ...... true
    remote control ... true
    trayicon ......... false

*****************************

I'll attach the patch (r7566 is reversed by it).

Notice that I haven't introduce zeroconf and avahi, it's for my next ticket.

[Fab]

configure.ac.patch

[asterix]

the problem with this patch, is that we check for headers of dbus-glib. and we don't need headers.

if I don't install libdbus-glib-1-dev ./configure don't find dbus-glib-1. Is there a way to depend only on the compiled library ?

[Fab]

Replying to asterix:

the problem with this patch, is that we check for headers of dbus-glib. and we don't need headers. if I don't install libdbus-glib-1-dev ./configure don't find dbus-glib-1. Is there a way to depend only on the compiled library ?

astérix, je vais parler en français, sinon je ne vais pas réussir à faire passer mes idées.

Comment çà fonctionnait avant ? C'est quelle macro qui check le header ? PKG_CHECK_EXISTS ? alors dans ce cas, oui, mea culpa, une erreur de copié collé : pas besoin de checker les headers pour les runtime dep.

PKG_CHECK_MODULES([DBUS], [dbus-1 >= 0.60 dbus-glib-1 >= 0.60]) 
AC_SUBST(DBUS_CFLAGS) 
AC_SUBST(DBUS_LIBS) 

HAVE_DBUS=yes
HAVE_DBUS_GLIB=yes

Mais çà ne veut pas dire que vous ne devez pas checker les runtimes deps : vous utilisez un langage interprété. ok, vous utilisez python, ok. mais les runtimes deps doivent être présentes si l'on veut le support d'une feature à la compilation.

La solution est la suivante, pas besoin de système de plugin.

Si avahi est présent à la compilation, si --disable-zeroconf n'est pas donné, alors le répertoire src/common/zeroconf est installé. A l'éxécution, si le répertoire est présent, la checkbox est présente, sinon non. Vous, en tant que développeurs, vous devez juste vous assurer que le support zeroconf ne peut pas être activé si le répertoire n'est pas présent.

Pourquoi pour les packagers, çà ne change rien : ne sont t'ils pas sensés tester leur paquet avant de le lancer en production ? ne sont t'il pas sensés mimer le comportement de l'utilisateur final qui n'en a rien à faire du ./configure ? comment font-ils pour le tester ? ils sont bien obligés d'installer toutes les runtimes deps pour vérifier qu'ils n'y a pas de bug majeur !

Alors que les runtimes deps soient installées avant ou après le configure, qu'est ce que çà change pour leur building farm ? Bien sûr en théorie les runtimes deps peuvent être installées après la compilation, et c'est ce que l'utilisateur final pourra faire !

Le packager de phpmyadmin ne teste pas son paquet après l'avoir terminé ? comment fait t'il pour le tester sans apache et sans mysql sur sa building farm ? il envoie son paquet en production sans le tester ?

Sur mon système, tu vois bien que si je demande à installer phpmyadmin, apache et php sont installés en premier :

# emerge -pv phpmyadmin

These are the packages that would be merged, in order:

Calculating dependencies     ... done!
[ebuild  N    ] net-www/apache-2.0.59-r2  USE="apache2 ldap ssl -debug -doc -mpm-itk -mpm-leader -mpm-peruser -mpm-prefork -mpm-threadpool -mpm-worker (-selinux) -static-modules -threads" 0 kB 
[ebuild  N    ] dev-lang/php-5.1.6-r8  USE="apache2 bzip2 cli crypt curl exif gd iconv ldap mysql ncurses nls pcre readline reflection session spell spl ssl truetype unicode xml zlib -adabas -apache -bcmath -berkdb -birdstep -calendar -cdb -cgi -cjk -concurrentmodphp -ctype -curlwrappers -db2 -dbase -dbmaker -debug -discard-path -doc -empress -empress-bcs -esoob -fastbuild -fdftk -filepro -firebird -flatfile -force-cgi-redirect -frontbase -ftp -gd-external -gdbm -gmp -hardenedphp -hash -hyperwave-api -imap -informix -inifile -interbase -iodbc -ipv6 -java-external -kerberos -libedit -mcve -memlimit -mhash -ming -msql -mssql -mysqli -oci8 -oci8-instant-client -odbc -pcntl -pdo -pdo-external -pic -posix -postgres -qdbm -recode -sapdb -sasl -sharedext -sharedmem -simplexml -snmp -soap -sockets -solid -sqlite -sybase -sybase-ct -sysvipc -threads -tidy -tokenizer -vm-goto -vm-switch -wddx -xmlreader -xmlrpc -xmlwriter -xpm -xsl -yaz -zip" 0 kB 
[ebuild  N    ] dev-db/phpmyadmin-2.9.1.1  USE="-vhosts" 0 kB 

Total: 3 packages (2 new, 1 reinstall), Size of downloads: 0 kB

Pour les distribs binaires, çà ne change rien, pour les distribs sources, çà change tout. Si vous ne le faîtes pas, si dans 20 ou 30 ans, gajim a 50 runtimes deps gérées de cette façon, gajim sera totalement inutilisable sur les distributions sources, notamment gentoo. çà sera du pur délire, le comportement de gajim changera alors que l'utilisateur n'a rien demandé, et gajim passera pour un logiciel mal conçu, tout çà au nom des great features of python, et du manque de volonté des packagers.

[asterix]

it was the same behaviour before, but we should fix that. I know nothing about automake. I tried to fix but I'm not able. I don't know how PKG_CHECK_EXISTS work. and it's the same for dbus. I need libdbus-1-dev to be installed in order to have the HAVE_DBUS var set to yes.

in pack PKG_CHECK_EXISTS call pkg-config --exists --print-errors dbus-1

but it seems pkg-config know package exists only if -dev is present. Is there another way to detect if dbus is installed ?

[Fab]

Normally, pkg-config check for a metadata file. On my system : /usr/lib/pkgconfig/dbus-1.pc

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
system_bus_default_address=unix:path=/var/run/dbus/system_bus_socket
sysconfdir=/etc
session_bus_services_dir=/usr/share/dbus-1/services

Name: dbus
Description: Free desktop message bus
Version: 1.0.1
Libs: -L${libdir} -ldbus-1  
Cflags: -I${includedir}/dbus-1.0 -I${libdir}/dbus-1.0/include

$ pkg-config --modversion dbus-1
1.0.1

On your system, if this file is installed by the -dev package, then pkg-config require the -dev package.

But I don't understand why you want to fix this. The configure script is for people who want to build the package : the packagers. This people must install the required files to build it.

For BINARY distros, end-users don't need the configure script, don't need the Makefile, they just download BINARY files, no ? configure and Makefile are for the packagers, it's their job, if they want to build Gajim from scratch, then the packagers must install -dev packages.

This is the diffrence between BINARY and SOURCE distros. Am I wrong ?

[asterix]

you're not wrong, but here we don't build something that require headers of dbus lib, we just want to check if dbus is installed and which version. so headers are not needed. but indeed dbus-1.pc is installed by -dev package. so it's only related with my distro. I guess there is not clean way to detect which dbus version is installed than using pkg-config ? what about running dbus-launch --version ?

[Fab]

what about running dbus-launch --version ?

Ok, so you can do this if you want, you parse the output, and if the version is matching, then it's ok.

But you must do this for each runtime dep, the packager must install each runtime dep before build time to add the feature's support in gajim. Please, tell me if you will do this in the future or not, it's the only solution to correctly install gajim on sources distros, I want to know if I waste my time.

[asterix]

ok let's say -dev is required to know which version is installed. parsing the output of dbus-launch --version is not very easy .. is it ?

now about the fact that packager have to install every runtime dep, I'm not sure. how to solve this situation: I am the packager of debian package. gnome-python-extra is in debian. So I don't want to build the included trayicon module, but just add an optional dependancy of my package to GPE. with your solution, if I put the option --enable-trayicon the included sources will be compiled. If I set --disable-trayicon, gajim won't use the one in GPE. With the current solution, I just remove files from debian package, they are not compiled, and that's all.

[junglecow]

Replying to asterix:

ok let's say -dev is required to know which version is installed. parsing the output of dbus-launch --version is not very easy .. is it ?

I don't see why it should be very difficult:

>>> import commands
>>> o = commands.getoutput('dbus-launch --version')
>>> print o
D-Bus Message Bus Launcher 1.0.1
Copyright (C) 2003 Red Hat, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>> map(int, o.splitlines()[0].split(' ')[-1].split('.'))
[1, 0, 1]

It won't be this simple because of error checking, and because version output may vary, but difficult? no.

[Fab]

parsing the output of dbus-launch --version is not very easy .. is it ?

$ VERSION=$(dbus-launch --version | grep 'D-Bus'); VERSION=${VERSION##* }; echo $VERSION

I'm not sure to understand the problem between GPE and the trayicon module.

• if you know that the correct version of GPE is installed on your distro, then you can take the decision to not build the module (--enable-gpe-trayicon --disable-own-trayicon).
• if end-users may or cannot install GPE, then you must build the module (--enable-gpe-trayicon --enable-own-trayicon). At execution, if GPE is here, it's cool, if not, your own module is used.

You are the packager of a binary system, you take the decisions for end-users, you must assume your decisions, else they would all migrate on a source system. I don't understand why you remove the files from the package to not build them.

For sources distros, it change everything, because we can control if required deps are here or not, and enable or disable options. I know that I ask you for a total reorganization of gajim's structure. If you don't do it, gajim will die gradually on sources systems with each new optional runtime dep added in the future, but if you do it, gajim will be completely metamorphosed, and you will have total control on your application. This is just options at build time, it will not kill you. It's your choice, but you have to do it today. You didn't choose python for its performances of execution, you choose it for its power ? Power is nothing without control.

[asterix]

and how to compare versions in string ?

$ if [ "1.0.1" > "10.60" ]; then echo "yes"; fi
yes

What I propose is to have this --disable-zeroconf option, after all that doesn't hurt, and enable the possibility to remove corresponding files from installed files. But I don't think packager (or builder for sources distro) need to have dbus installed to install files. So make install will install all files except if --disable-zeroconf is installed. So I don't see the need to check dbus version in coonfigure. If version of dbus is too old, things depending on dbus won't work and that's all ... or maybe we can print a warning at biuld time. but that's not very usefull for binary distro, user can have different version then builder.

[Fab]

Replying to asterix:

and how to compare versions in string ?

#!/bin/bash

VERSION=2.3.12 ;

FIRST=${VERSION%%.*};
echo 'first='$FIRST;

SECOND=${VERSION#*.};
SECOND=${SECOND%%.*};
echo 'second='$SECOND

THIRD=${VERSION##*.};
echo 'third='$THIRD;

if [ $FIRST -gt 3 ]; then
	echo yes
else
	if [ $SECOND -gt 4 ]; then
		echo yes
	else
		if [ $THIRD -gt 13 ]; then
			echo yes
		else
			echo no
		fi
	fi
fi

If version of dbus is too old, things depending on dbus won't work and that's all ... or maybe we can print a warning at biuld time. but that's not very usefull for binary distro, user can have different version then builder.

D-Bus is not included in the same category, because it is required by anothers optionals runtime deps which bring something to gajim (libnotify, zeroconf, ...), or required by your owns apps (--enable-remote) : dbus alone doesn't bring anything to gajim, it is just a bridge between 2 apps, no ?
In this case, --disable-dbus is obviously not needed, a warning is sufficient at execution. Do you check its version before using it ? gtk and pygtk are checked, but I don't see dbus. If the version doesn't match, do you disable all the components which need it ?

[Fab]

astérix : I believe that there was a terrible mistake between us.

Have a look at this revision.

This this the first import in the trunk of the configure.ac file from the zeroconf branch done by dkirov. dkirov is on gentoo, right ?

That's explain why he ran a pkg-config on dbus. That appeared completely logical to me, for 2 reasons :

• on gentoo, the headers are always installed, so why not run a pkg-config on all the runtime deps ?
• I thought that the packagers on the other distros made the same thing to build and test their packages (it was written for dbus in the configure.ac !), until you teach me the opposite :

you're not wrong, but here we don't build something that require headers of dbus lib

At the beginning, I wanted to know if it was possible to create options for configure.

Now I understand that you don't want to check the versions of the runtimes deps, and in extreme cases it's your problem, but what prevents you from creating options ? Why don't you create one module by runtime dep in order to give the possibility to desactivate the corresponding option at build time, and thus to really desactivate the optional feature definitively ? Not for dbus, but for the others which bring a feature to gajim. If the builder wants that, why don't you give him this possibility ? I don't see why python couldn't do it.

[asterix]

"What I propose is to have this --disable-zeroconf option"

"what prevents you from creating options ?"

I don't understand. please contact me by jabber to talk about that

[Fab]

Yes, zeroconf is the beginning, what I wanted to say, this is : why not to make the same thing with libnotify for example. This is an optional runtime dep which bring a function to gajim, if you create a module with all functions and bindings for libnotify, you can control if this module will be installed or not at build time. Once that the installation is over, if the module is here, you use it, if not, this means that the user doesn't wanted the support of libnotify at build time, even if it is installed. All the functions and bindings for libnotify will not be in the core of gajim. I contact you as soon as possible.

[Fab]

I cannot contact you now, so I will put my ideas here.

Anonymous said in the other ticket :

Optional run-time deps are one of the great features of Python.

You said in the other ticket :

IMHO it's an advantage of python, no need to recompile to add an option.

So I ask the question :

if it's really an optional runtime dep, explain me why I can't remove the code which manage it when the application is installed without breaking the application ? I should have the possibility to add an optional runtime module to add one feature's support.

This is the possibilities of Python.

[asterix]

because code for zeroconf for example is deeply inserted in gajim. grep zeroconf in src/*.py and you'll see that it'sa mentionned in several modules. maybe it's not the best design of source code .. but it's the one in gajim for the moment.

[Fab]

Never mind. Thanks anyway.

[anonymous]

I still would like to talk with you, could you give me your jid or contact me at asterix (aT jabber , lagaule doT org