I also would like to see mysql made as optional rather than required. It is a huge program to have installed with no reason, and I just discovered that it has been whining and crying in the background every few seconds, probably for the last week, trying unsuccessfully to start, when I'm not using mysql for anything at all. 

Unless plans are to eliminate using sqlite as an option?

MySQL should be fully optional for digikam. Where does if fail without MySQL?

Marcel,

Because of this :

http://lxr.kde.org/source/extragear/graphics/digikam/CMakeLists.txt#192

If mysql executable are not found, digiKam won't to compile under MacOSX/windows. It's probably the same under Linux...

Gilles Caulier

Well we could use some finer CMake which does not fail directly when the program are not found. In that case, we'll need to disable the relevant option in the setup though by #ifdef.

Regarding comment #1: You certainly dont need to have any MySQL server running if you use normal SQLite.

Created attachment 59805 [details]
Make MySQL dependency optional

This is the patch I use in my custom ebuild for digiKam to avoid rather lengthy compilation of MySQL server on my old laptop. I hope it will be of use for a couple of folks out there in the internets.

Any news here? It would be nice to resolve this fairly trivial issue (also for 1.9)...

http://git.altlinux.org/people/gray_graff/packages/?p=kde4-digikam.git;a=blob;f=build-without-mysql.patch;h=23dd8ee346b93336c81e6448bfdd2ce95e968905;hb=43490c954b91078d1c49fb9eb8653cde2334417a

marflon,

Thanks for your patch.
... but it's build against 1.9.0. We working now for 2.0.0 release. 1.x branch is not maintained.

Can you build it against git master source code please ?

Thanks in advance

Gilles Caulier

Francesco,

This is an important patch to test about Mysql dependency. It can be a good exercise to play with CMake. 

Did you manage it ?

Thanks in advance

Gilles Caulier

Created attachment 59863 [details]
Make MySQL dependency optional -- patch against latest git

This patch is the same as previous but made against the latest git.
Although I haven't tested it properly -- I hadn't actually built fully working digiKam binary using it -- I've a strong sense that it does work.

Full testing would require me to build a couple of external shared libraries (libkface, libkmap) that I failed to find during a 5 minutes time span. Also, http://www.digikam.org/ contains outdated information like git url (should be git://, not http://), external dependencies, shared libraries and so on.

And looking for mysql server binary is off by default in this patch -- I think this is a right thing to do, but you may change it as you like.

(In reply to comment #9)
> Francesco,
> 
> This is an important patch to test about Mysql dependency. It can be a good
> exercise to play with CMake. 

always good to learn, I was near to include the FindMySQL.cmake from kdelibs but that one check for other things.

> 
> Did you manage it ?
> Thanks in advance
> Gilles Caulier

thinking a bit more about it IMHO the problem is in a different place;

Well, I've been a Gentoo developer in the past and created the /etc/init.d/mysql used there for some year until a better one replaced it recently.

Let me say it's not easy to manage a database server born to be a full blown server, not even only start it.
There are a miriad of little stupid things that can go wrong and with a large userbase GO wrong.

Magically you become the user personal sysadmin, go to debug the user problems again and again, please give me the logs, please repair that broken table etc.etc.
Also they require maintenaince, for mysql it's OPTIMIZE/REPAIR table for postgres is vacuum for oracle will be something else.

To sum it up mysql, and postgres are databases that should be managed as a system installation, managed explicitly from the user or possibly by the distros.

SQLite is another story, it's born to be an embeddable database, and does that work quite well.

Epilog:
I would suggest starting from digikam 2.0 to support mysql only as an external, already running database.

and PostScriptum
this whole thing apply also to amarok, coming kdepimlibs and every other kde part.

Git commit c29278c20c9cb7fc7bc2c123fd7bfafeb2e303a2 by Francesco Riosa.
Committed on 11/05/2011 at 16:05.
Pushed by riosa into branch 'master'.

optionally depend on mysqld executable

add an option ENABLE_INTERNALMYSQL (default enabled) to bypass the
search of mysqld executable, also define an entry HAVE_INTERNALMYSQL
in config-digikam.h

initial patch provided by <marflon at gmail.com>

CCBUG: 254533

M  +29   -17   CMakeLists.txt     
M  +3    -0    digikam/utils/config-digikam.h.cmake     

http://commits.kde.org/digikam/c29278c20c9cb7fc7bc2c123fd7bfafeb2e303a2

Git commit 8907ceb5ee89b4d822fec8d20433894439be125c by Francesco Riosa.
Committed on 11/05/2011 at 16:17.
Pushed by riosa into branch 'master'.

appliction disable "internal database"

When internal database has been disabled at compile time we don't know
how to start a server and widget should not show the option to use one.

Also for how cmake machinery work mysqldPath option is not empty but
contain "SERVERCMD_MYSQL-NOTFOUND", add a check for that.

When a digikam w/o mysqld support encounter a configuration file which
point to a "internal database" it threat the database as external and
will fail to connect to.

GUI:
BUG: 254533

M  +1    -1    databaseserver/databaseserver.cpp     
M  +10   -1    libs/database/databaseparameters.cpp     
M  +9    -0    libs/widgets/common/databasewidget.cpp     

http://commits.kde.org/digikam/8907ceb5ee89b4d822fec8d20433894439be125c

to be clear this patch DOES NOT disable mysql support which depend from how qt-sql has been compiled. That's why the option has been renamed to ENABLE_INTERNALMYSQL

At the moment until digikam developer discuss on #c11 I've left the option enabled by default