[Openicc] Profile installation and association for Linux/Unix/X11

[Graeme Gill]

Markus Raab wrote:
> Unfortunately you are absolutely right. The reason is that mounting in the yet 
> unreleased 0.7 is a brand-new feature. But everybody is welcome to change the 
> situation and write backends!

I started looking into writing a JSON back end for Elektra 0.7,
so that I could see about linking in to Elektra if it's present
on a system, and use a common set of configuration keys with
Oyranos, to but didn't get very far.

It seems that building Elektra from source is not easy. My first attempt
on my Fedora Core 8 box resulted in errors such as:

./bootstrap.sh
> BOOTSTRAPPING ELEKTRA
> CLEANING UP DIRECTORIES
> CLEANING UP FILES
> LIBTOOLIZE
> You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
> ACLOCAL
> ./bootstrap.sh: line 56: aclocal-1.9: command not found
> AUTOHEADER
> AUTOMAKE
> ./bootstrap.sh: line 62: automake-1.9: command not found
> AUTOCONF
> configure.ac:28: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.

Looking into the bootstrap.sh file, I determined that I have
automake-1.10 and aclocal-1.10 as the default versions on this system,
which Elektra doesn't seem to want to use. I changed them to
1.7 as per the acceptable version range in the check below this
and then got this sort of thing:

./bootstrap.sh
> BOOTSTRAPPING ELEKTRA
> CLEANING UP DIRECTORIES
> CLEANING UP FILES
> LIBTOOLIZE
> You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
> ACLOCAL
> aclocal: configure.ac: 289: macro `AM_ICONV' not found in library
> AUTOHEADER
> AUTOMAKE
> configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found.
> configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE,
> configure.ac: that aclocal.m4 is present in the top-level directory,
> configure.ac: and that aclocal.m4 was recently regenerated (using aclocal).
> configure.ac: installing `./install-sh'
> configure.ac: installing `./mkinstalldirs'
> configure.ac: installing `./missing'
> benchmarks/Makefile.am:9: VALGRINDTESTS does not appear in AM_CONDITIONAL
> doc/Makefile.am:25: HAVE_XSL does not appear in AM_CONDITIONAL
> doc/Makefile.am:97: HAVE_MAN2HTML does not appear in AM_CONDITIONAL
> doc/Makefile.am:144: HAVE_DOXYGEN does not appear in AM_CONDITIONAL
> doc/Makefile.am:27: `SUFFIXES' is a target; expected a variable
> examples/Makefile.am: installing `./depcomp'
> /usr/share/automake-1.7/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL
> /usr/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
> src/backends/berkeleydb/Makefile.am:11: library used but `RANLIB' is undefined
> src/backends/berkeleydb/Makefile.am:11: 
> src/backends/berkeleydb/Makefile.am:11: The usual way to define `RANLIB' is to add `AC_PROG_RANLIB'
> src/backends/berkeleydb/Makefile.am:11: to `configure.ac' and run `autoconf' again.
> src/backends/berkeleydb/Makefile.am: installing `./compile'
> src/backends/berkeleydb/Makefile.am:15: Libtool library used but `LIBTOOL' is undefined
> src/backends/berkeleydb/Makefile.am:15: 
> src/backends/berkeleydb/Makefile.am:15: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
> src/backends/berkeleydb/Makefile.am:15: to `configure.ac' and run `aclocal' and `autoconf' again.
> /usr/share/automake-1.7/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL
> /usr/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
> src/backends/daemon/Makefile.am:6: library used but `RANLIB' is undefined
> src/backends/daemon/Makefile.am:6: 
> src/backends/daemon/Makefile.am:6: The usual way to define `RANLIB' is to add `AC_PROG_RANLIB'
> src/backends/daemon/Makefile.am:6: to `configure.ac' and run `autoconf' again.
> src/backends/daemon/Makefile.am:15: Libtool library used but `LIBTOOL' is undefined
> src/backends/daemon/Makefile.am:15: 
> src/backends/daemon/Makefile.am:15: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
> src/backends/daemon/Makefile.am:15: to `configure.ac' and run `aclocal' and `autoconf' again.
> /usr/share/automake-1.7/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL
> /usr/share/automake-1.7/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
> src/backends/filesys/Makefile.am:6: library used but `RANLIB' is undefined
> src/backends/filesys/Makefile.am:6: 
> src/backends/filesys/Makefile.am:6: The usual way to define `RANLIB' is to add `AC_PROG_RANLIB'
etc. etc.

Pressing on regardless with the resulting configure file, I get:

./configure \
 >         --bindir=/bin \
 >         --libdir=/lib \
 >         --sysconfdir=/etc \
 >         --mandir=/usr/share/man \
 >         --with-docdir=/usr/share/doc/elektra \
 >         --with-develdocdir=/usr/share/doc/elektra-devel \
 >         --disable-xmltest \
 >         --with-docbook=/usr/share/sgml/docbook/xsl-stylesheets
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking target system type... i686-pc-linux-gnu
> ./configure: line 1948: AC_LIBTOOL_WIN32_DLL: command not found
> ./configure: line 1950: AM_INIT_AUTOMAKE: command not found
> configure: Empty CFLAGS: yes
> ./configure: line 1967: gl_USE_SYSTEM_EXTENSIONS: command not found
> checking whether to enable debugging... no
> checking for lcov... no
> checking for genhtml... no
> LIBDIR=/lib
> ./configure: line 2204: syntax error near unexpected token `EXPERIMENTAL,'
> ./configure: line 2204: `AM_CONDITIONAL(EXPERIMENTAL, test x$elektra_experimental = xyes)'

Having failed with V0.7, I then tried to at least build it from the 0.6.10-2 RPM on
the source forge site, and got this:

rpmbuild --rebuild elektra-0.6.10-2.src.rpm
> Installing elektra-0.6.10-2.src.rpm
> warning: user aviram does not exist - using root
> warning: group aviram does not exist - using root
> warning: user aviram does not exist - using root
> warning: group aviram does not exist - using root
> error: Package already exists: %package debuginfo 

(Apparently this is a problem introduced by rpm-4.2)

I'm really not at all familiar with automake, and don't really want to know
any more about it (one of the reasons I chose a different build system for my
software was specifically to avoid having to get tangled up in automake and
friends), so I haven't pursued it any further. I'm not finding the documentation
within Elektra particularly easy to comprehend, so I was hoping to trace
the behavior of various back ends to determine what the back end API actually
consists of.

I guess I'll have to solve the profile<->device registration with
my own configuration files in /etc and $HOME, so until elektra stabilizes
and becomes a bit more portable, Argyll simply won't inter-operate with Oyranos
in regard to how display profiles are registered.

Graeme Gill.