Thanks. I am not using the CPLUS_INCLUDE_PATH variable. I checked the CmakeCache.txt file and there is indeed the given paths:

DBUS_INCLUDEDIR:INTERNAL=/usr/include DBUS_INCLUDE_DIRS:INTERNAL=/usr/include/dbus-1.0;/usr/lib/dbus-1.0/include

Changing the include path in consolekit.h got me one step further (as expected) and the next header in the same path was missed.

I will try with -DWITH_HAL=ON and then try adding one level deeper (where the header lives) to the CMakeCache.txt: DBUS_INCLUDE_DIRS:INTERNAL=* /usr/include/dbus-1.0/dbus*;/usr/lib/dbus-1.0/include

CMakesMyHeadAche

Jay

On Mon, Feb 20, 2012 at 10:04 PM, Darrell Anderson humanreadable@yahoo.comwrote:

...

While compiling from latest git (20th Feb 2012) i got as far as tdebase. At around the 90% mark it failed.

git/tde/main/tdebase/tdm/backend/consolekit.c:31:23: fatal error: dbus/dbus.h: No such file or directory

compilation terminated.

consolekit.c contains the following include:

#include <dbus/dbus.h>

when the actual headers path is /usr/include/dbus-1.0/dbus/dbus.h

Rebuilding now with a symlink to see how far i get.

I recall running into that problem a while back. I don't remember what caused the problem. That might have been when I discovered the -DWITH_HAL option defaults to OFF. I set that option to ON and I think then the problems disappeared.

The cmake configuration files should automatically detect the dbus-1.0 files. In the tdebase build directory, check the CMakeCache.txt file for lines like this:

DBUS_CFLAGS:INTERNAL=-I/usr/include/dbus-1.0;-I/usr/lib/dbus-1.0/include DBUS_INCLUDE_DIRS:INTERNAL=/usr/include/dbus-1.0;/usr/lib/dbus-1.0/include

DBUS_STATIC_CFLAGS:INTERNAL=-I/usr/include/dbus-1.0;-I/usr/lib/dbus-1.0/include

DBUS_STATIC_INCLUDE_DIRS:INTERNAL=/usr/include/dbus-1.0;/usr/lib/dbus-1.0/include

DBUS_TQT_CFLAGS:INTERNAL=-I/opt/trinity/include;-I/opt/trinity/include/dbus-1.0;-I/usr/include/dbus-1.0;-I/usr/lib/dbus-1.0/include

DBUS_TQT_INCLUDE_DIRS:INTERNAL=/opt/trinity/include;/opt/trinity/include/dbus-1.0;/usr/include/dbus-1.0;/usr/lib/dbus-1.0/include

DBUS_TQT_STATIC_CFLAGS:INTERNAL=-I/opt/trinity/include;-I/opt/trinity/include/dbus-1.0;-I/usr/include/dbus-1.0;-I/usr/lib/dbus-1.0/include

DBUS_TQT_STATIC_INCLUDE_DIRS:INTERNAL=/opt/trinity/include;/opt/trinity/include/dbus-1.0;/usr/include/dbus-1.0;/usr/lib/dbus-1.0/include

HAL_CFLAGS:INTERNAL=-DDBUS_API_SUBJECT_TO_CHANGE;-I/usr/include/hal;-I/usr/include/dbus-1.0;-I/usr/lib/dbus-1.0/include

HAL_INCLUDE_DIRS:INTERNAL=/usr/include/hal;/usr/include/dbus-1.0;/usr/lib/dbus-1.0/include

HAL_STATIC_CFLAGS:INTERNAL=-DDBUS_API_SUBJECT_TO_CHANGE;-I/usr/include/hal;-I/usr/include/dbus-1.0;-I/usr/lib/dbus-1.0/include

HAL_STATIC_INCLUDE_DIRS:INTERNAL=/usr/include/hal;/usr/include/dbus-1.0;/usr/lib/dbus-1.0/include

Also, FWIW, by any chance are you setting the CPLUS_INCLUDE_PATH environment variable? I had all kinds of weird build problems using that variable, which is some kind of oddball carry over in Slackware build scripts from days long past.

Oh, I just built everything today in Slackware 13.1 against Qt3. So the package does build. :)

Darrell

---

To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

-DWITH_HAL option defaults to OFF. I set that option to ON and I think then the problems disappeared.

Nailed it! Thanks so much Darrell .... it would have taken me an age to find this. Do you use this for all packages?

Ah! So my memory is not so fuzzy after all! :)

I believe that specific build option applies only to tdebase.

When I convert a build script from automake to cmake, I first open the CMakeLists.txt file in the package sources root directory. The list of available build options will there. I always review them because most options are disabled by default. I think Serghei believes that to be the safe conservative approach, but he can speak for himself if he feels so inclined. :)

Regardless, for now I am building full robust packages rather than "light" packages because that is the best way for me to help debug. Therefore I always reverse the default -DBUILD_ALL=OFF to ON and then set only a few options to OFF. One example is tdebase -DWITH_PAM=OFF because Slackware does not use PAM.

Oh, before I forget, a similar speed bump exists with tdepim. Be sure to explicitly enable -DWITH_SASL=ON otherwise users will be unable to use TLS/SSL with KMail logins. You'll want that feature enabled even when building "Trinity Light."

After I populate my build script -DWITH options I then compare them to the previous automake configure options and ensure nothing obvious is missing. Comparing the older automake options to cmake is not always a brain-dead one-to-one comparison. Sometimes I have to dig a little to ensure the old automake configure option is supported. Serghei is pretty doggone good at this and I don't recall him missing very much. Often the ConfigureChecks.cmake file will provide clues that the appropriate tests are performed. If you look at the tdebase ConfigureChecks.cmake, you'll see a test for whether HAL support is requested. There is a test for dbus too.

I think because some distros no longer support HAL that in their case the cmake test for dbus still succeeds but with those that still use HAL I think the dbus test fails. I'm just guessing, but sounds plausible.

Darrell