[Protux-devel] config.h

[Martin Herren]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hej,

i noticed that the ./configure generated config.h file has been added to
protux in CVS in the process of moving away from autotool.
~ - First i think that's illogical and contradictory to have this
autostuff file here and especially now.
~ - Second even using autotools this file has _nothing_ to do in CVS
because it is generated by ./configure, and contains ./configure options
and machine / installation specific defines.
~ - Last there are even some risks involved using these defines as they
don't reflect the actual configuration anymore (as it is not generated
by ./configure anymore) and some some things are redundant with protux.pro.

For example in config.h:
/* Protux resources directory */
#define RESOURCES_DIR "/usr/local/share/protux/"

and in protux.pro:
resources.path = /usr/local/share/protux

so changing the resources path involves changing it at (at least) two
different unrelated places...one is currently used for compilation and
the other one for installation, and if they are not the same protux will
compile but won't run (and you have to kill protux :-( as it won't even
recognise <<ESC>>).

Also in config.h:
/* Version number of package */
#define VERSION "0.26.0"

and in protux.pro:
VERSION = 0.26.0

Also all the
#define HAVE_LIBASOUND 1
#define HAVE_LIBM 1
#define HAVE_LIBOGG 1
#define HAVE_LIBPTHREAD 1
#define HAVE_LIBVORBIS 1
from config.h should be removed as they don't reflect the installation
where protux is compiled anymore.

I'm not completely against moving away from autotools to qmake (even if
i had to autostuff back my CVS checkout of mustux and protux in order to
compile it as it's not possible to use ./compile with my
configuration/installation of Qt), but moving to qmake means to stop
doing it in the autotool way, and to do it the qmake way.

That means we'll have to use qmake's way to retrieve the resource_dir
and version_number in protux, and if there is no qmake way to do it
we'll just have to hardcode it somewhere... which can even be in a
config.h, but not in an autotool config.h, and in this case it has to be
clearly stated somewhere that the enduser has to edit protux.pro and
config.h file prior to run ./compile... but please without having stuff
redundantly defined at both places...

It was too complicated for the (non-programmer) end-user to run
./configure and perhaps giving it one or two options to handle special
stuff like non-common installation... now we ask this same end-user to
have to edit a header file... (did all end-user learn C++ in the meantime ?)

Ok, i hope we'll find a clean way to handle resource_dir, version and
other stuff... But seeing stuff defined redundantly just scares me...
and sooner or later someone will spend some nights chasing a ghost bug
just because of this...

/Martin

(this mail is not intended to offend anyone, but sometimes things have
to be done one way, or the other way. Most often both way are able to
coexist. But you just can't make it in between these two ways.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFB/RxWENZb8plGFLQRAjJRAJ0TGyrRDwC/ugqvj4fqkX9FvJE60wCfcvpO
wpimDIeKvWWY680EtGicJfY=
=IB2D
-----END PGP SIGNATURE-----