Is anybody able to build tdebase without HAL (WITH_HAL=OFF)?
Darrell
Le 11/08/2012 19:05, Darrell Anderson a écrit :
Is anybody able to build tdebase without HAL (WITH_HAL=OFF)?
Anybody?
I'm dead in the water unless I can build without HAL. (Bug report 1132.)
Thanks.
Darrell
In file: tdm/backend/CMakeLists.txt Look at section "include_directories" (line 14) (notice the self-explanatory comment just above ...)
Inside this section, add another line just after ${DBUS_TQT_INCLUDE_DIRS} ${DBUS_INCLUDE_DIRS}
And try again ...
Francois
Is anybody able to build tdebase without HAL (WITH_HAL=OFF)?
Anybody?
I'm dead in the water unless I can build without HAL.
(Bug report 1132.)
In file: tdm/backend/CMakeLists.txt Look at section "include_directories" (line 14) (notice the self-explanatory comment just above ...)
Inside this section, add another line just after ${DBUS_TQT_INCLUDE_DIRS} ${DBUS_INCLUDE_DIRS}
And try again ...
Turns out this failure is more fundamental. After comparing builds with WITH_HAL=ON and WITH_HAL=OFF, I noticed the latter build never looked for dbus-tqt and always failed.
I found success with the following temporary patch:
================================================= diff -urN tdebase/ConfigureChecks.cmake tdebase.new/ConfigureChecks.cmake --- tdebase/ConfigureChecks.cmake 2012-06-10 11:52:38.000000000 -0500 +++ tdebase.new/ConfigureChecks.cmake 2012-08-11 21:59:00.000000000 -0500 @@ -268,7 +268,7 @@ tde_message_fatal( "dbus-tqt-1 is required, but was not found on your system" ) endif( ) endif( ) - if( WITH_HAL ) +# if( WITH_HAL ) # check for dbus-tqt # dbus-tqt need Qt flags pkg_check_modules( DBUS_TQT REQUIRED dbus-tqt ) @@ -284,6 +284,6 @@ if( NOT HAVE_DBUS_QT3_07 ) tde_message_fatal( "dbus-tqt is required, but was not found on your system" ) endif( ) - endif( ) +# endif( )
endif( ) =================================================
I considered changing if( WITH_HAL ) to if( WITH_HAL OR WITH_TDEHWLIB ), but I don't know whether WITH_TDEHWLIB is dependent upon dbus-tqt. I don't know whether dbus-tqt is required for all builds.
I really don't know what is the best all-around long-term solution for all distros.
Darrell
On 08/11/2012 10:35 PM, Darrell Anderson wrote:
I really don't know what is the best all-around long-term solution for all distros.
Darrell
C'mon, sure you do :) It is a tight, well optimized update to the TDE codebase that provides all current HAL functionality with improved hardware detection and handling that works on all distros and releases -- without needing HAL. Problem solved!
Doing the 3.5.13 exercise had been a good exercise that has exposed some needed updates to my build process. I've still got a bit to do, but I anticipate by the end of next week to be able to jump back into R14. I sill need to finish the k9copy patch for ffmpeg as well. So much to do, so little time...
On 08/11/2012 10:35 PM, Darrell Anderson wrote:
I really don't know what is the best all-around long-term solution for all distros.
Darrell
C'mon, sure you do :) It is a tight, well optimized update to the TDE codebase that provides all current HAL functionality with improved hardware detection and handling that works on all distros and releases -- without needing HAL. Problem solved!
While it's not nearly as good as what you describe above, this is exactly what TDE now has in reaction to the HAL problem. Try compiling tdebase with the -DWITH_TDEHWLIB option and the -DWITH_HAL option both enabled and see if that fixes the build problem. If so, then CMake needs to be updated to handle this in a sane manner instead of having to enable two contradictory options to successfully build without HAL support. ;-)
Tim
While it's not nearly as good as what you describe above, this is exactly what TDE now has in reaction to the HAL problem. Try compiling tdebase with the -DWITH_TDEHWLIB option and the -DWITH_HAL option both enabled and see if that fixes the build problem. If so, then CMake needs to be updated to handle this in a sane manner instead of having to enable two contradictory options to successfully build without HAL support. ;-)
Building with -DWITH_TDEHWLIB and -DWITH_HAL won't resolve the build failures. The tdebase top level ConfigureChecks.cmake file is hard-coded only to test for HAL. That is why I mentioned I considered changing the cmake test from if( WITH_HAL ) to if( WITH_HAL OR WITH_TDEHWLIB ).
I don't know whether the new TDEHWLIB scheme is dependent upon dbus-tqt. If yes then the change in the cmake test would be valid. If the new TDEHWLIB scheme is not dependent upon dbus-tqt, then deleting the if( WITH_HAL ) test as I did in my temporary patch would seem a reasonable solution.
I don't know how all the parts connect, which is why I wrote I don't know the correct long-term solution for all distros.
Darrell
While it's not nearly as good as what you describe above, this is exactly what TDE now has in reaction to the HAL problem. Try compiling tdebase with the -DWITH_TDEHWLIB option and the -DWITH_HAL option both enabled and see if that fixes the build problem. If so, then CMake needs to be updated to handle this in a sane manner instead of having to enable two contradictory options to successfully build without HAL support. ;-)
Building with -DWITH_TDEHWLIB and -DWITH_HAL won't resolve the build failures. The tdebase top level ConfigureChecks.cmake file is hard-coded only to test for HAL. That is why I mentioned I considered changing the cmake test from if( WITH_HAL ) to if( WITH_HAL OR WITH_TDEHWLIB ).
I don't know whether the new TDEHWLIB scheme is dependent upon dbus-tqt.
While TDEHWLIB itself (i.e. the library code in tdelibs) is not, other previously HAL-dependent features in tdebase are still dependent on dbus-tqt. Therefore, tdebase is dependent on dbus-tqt even if the TDEHWLIB is in use.
Tim
While TDEHWLIB itself (i.e. the library code in tdelibs) is not, other previously HAL-dependent features in tdebase are still dependent on dbus-tqt. Therefore, tdebase is dependent on dbus-tqt even if the TDEHWLIB is in use.
Seems then that my temporary patch is best? Just delete the if( WITH_HAL ) test and build with dbus-tqt support regardless of how WITH_HAL or WITH_TDEHWLIB are set?
Darrell
While TDEHWLIB itself (i.e. the library code in tdelibs) is not, other previously HAL-dependent features in tdebase are still dependent on dbus-tqt. Therefore, tdebase is dependent on dbus-tqt even if the TDEHWLIB is in use.
Seems then that my temporary patch is best? Just delete the if( WITH_HAL ) test and build with dbus-tqt support regardless of how WITH_HAL or WITH_TDEHWLIB are set?
Darrell
I would check to see if either WITH_HAL or WITH_TDEHWLIB are set before requiring dbus-tqt; if neither are set then tdebase does not depend on it.
Tim
Seems then that my temporary patch is best? Just delete
the if( WITH_HAL ) test and build with dbus-tqt support regardless of how WITH_HAL or WITH_TDEHWLIB are set?
I would check to see if either WITH_HAL or WITH_TDEHWLIB are set before requiring dbus-tqt; if neither are set then tdebase does not depend on it.
I ran a tdebase build with WITH_HAL=NO, WITH_TDEHWLIB=NO and no related patching. The build fails with the same error about not finding dbus/dbus.h. The failure occurs when building tdm backend, in consolekit.c.
The only fix for now is not test at all to force building with dbus-tqt. If somebody desires to build tdm backend without consolekit support then some other build option and test is needed.
Darrell
Seems then that my temporary patch is best? Just delete
the if( WITH_HAL ) test and build with dbus-tqt support regardless of how WITH_HAL or WITH_TDEHWLIB are set?
I would check to see if either WITH_HAL or WITH_TDEHWLIB are set before requiring dbus-tqt; if neither are set then tdebase does not depend on it.
I ran a tdebase build with WITH_HAL=NO, WITH_TDEHWLIB=NO and no related patching. The build fails with the same error about not finding dbus/dbus.h. The failure occurs when building tdm backend, in consolekit.c.
Sounds like the code in consolekit.c is not properly guarded with #ifdefs, which would be set when dbus-tqt is found.
Tim
Seems then that my temporary patch is best? Just delete
the if( WITH_HAL ) test and build with dbus-tqt support regardless of how WITH_HAL or WITH_TDEHWLIB are set?
I would check to see if either WITH_HAL or WITH_TDEHWLIB are set before requiring dbus-tqt; if neither are set then tdebase does not depend on it.
I ran a tdebase build with WITH_HAL=NO, WITH_TDEHWLIB=NO and no related patching. The build fails with the same error about not finding dbus/dbus.h. The failure occurs when building tdm backend, in consolekit.c.
Sounds like the code in consolekit.c is not properly guarded with #ifdefs, which would be set when dbus-tqt is found.
Tim
Is there any good reason that dbus might not be available on a target distribution/system? If not, I would say to just make dbus a tdebase dependency and remove the if statements from around the dbus checks. If there is a good reason for dbus to be missing, then we will need to add another flag to build without dbus support and also add the requisite #ifdefs to the tdm consolekit code.
Thoughts?
Tim
On Aug 13, 2012 2:40 AM, "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:
Seems then that my temporary patch is best? Just delete
the if( WITH_HAL ) test and build with dbus-tqt support regardless of how WITH_HAL or WITH_TDEHWLIB are set?
I would check to see if either WITH_HAL or WITH_TDEHWLIB are set before requiring dbus-tqt; if neither are set then tdebase does
not
depend on it.
I ran a tdebase build with WITH_HAL=NO, WITH_TDEHWLIB=NO and no related patching. The build fails with the same error about not finding dbus/dbus.h. The failure occurs when building tdm backend, in consolekit.c.
Sounds like the code in consolekit.c is not properly guarded with
#ifdefs,
which would be set when dbus-tqt is found.
Tim
Is there any good reason that dbus might not be available on a target distribution/system? If not, I would say to just make dbus a tdebase dependency and remove the if statements from around the dbus checks. If there is a good reason for dbus to be missing, then we will need to add another flag to build without dbus support and also add the requisite #ifdefs to the tdm consolekit code.
Thoughts?
Tim
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
We should assume all users have dbus just like dcop
Sounds like the code in consolekit.c is not properly guarded with #ifdefs, which would be set when dbus-tqt is found.
Is there any good reason that dbus might not be available on a target distribution/system? If not, I would say to just make dbus a tdebase dependency and remove the if statements from around the dbus checks. If there is a good reason for dbus to be missing, then we will need to add another flag to build without dbus support and also add the requisite #ifdefs to the tdm consolekit code.
Thoughts?
The temporary patch now does that by removing the if( WITH_HAL ) test and presuming the existence of dbus-tqt, which doesn't build without dbus. As patched, the remainder of the cmake checks will halt the build with an error message when dbus-tqt is not found. I don't know the future plans for dbus, but for now I believe all distros still support and maintain dbus.
Perhaps someday a WITH_DBUS=NO flag or #ifdef qualifiers might be needed, but that day is not today.
On the other hand, the absence of HAL is very real today and the WITH_HAL=NO option is necessary for many distros.
Darrell
Sounds like the code in consolekit.c is not properly guarded with
#ifdefs,
which would be set when dbus-tqt is found.
Is there any good reason that dbus might not be available on a target distribution/system? If not, I would say to just make dbus a tdebase dependency and remove the if statements from around the dbus checks. If there is a good reason for dbus to be missing, then we will need to add another flag to build without dbus support and also add the requisite #ifdefs to the tdm consolekit code.
Thoughts?
The temporary patch now does that by removing the if( WITH_HAL ) test and presuming the existence of dbus-tqt, which doesn't build without dbus. As patched, the remainder of the cmake checks will halt the build with an error message when dbus-tqt is not found. I don't know the future plans for dbus, but for now I believe all distros still support and maintain dbus.
Perhaps someday a WITH_DBUS=NO flag or #ifdef qualifiers might be needed, but that day is not today.
On the other hand, the absence of HAL is very real today and the WITH_HAL=NO option is necessary for many distros.
Darrell
OK, go ahead and remove the WITH_HAL test around dbus-tqt, as that seems to be a reasonable solution.
Tim
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Francois Andriot -
Timothy Pearson