trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: February 2012

Re: [trinity-devel] tdebase dbus/dbus.h include wrong path

From: Darrell Anderson <humanreadable@...>
Date: Mon, 20 Feb 2012 15:40:37 -0800 (PST)
> -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