dennisveatch at bellsouth.net
Mon Mar 23 13:39:32 CET 2009
On Sunday 22 March 2009 11:01:05 pm Dennis Veatch wrote:
> On Sunday 22 March 2009 8:30:35 am Dennis Veatch wrote:
> > Been playing around with a new default_cmake function for build.lunar.
> > There isn't all that much to it really. Just using the the cmake entries
> > in the kde4 BUILD modules and poking that into default_cmake. It will
> > work for those cmake+modules that use " cmake ." and "cmake
> > $SOURCE_DIRECTORY". I have tried with; kdelibs4, kdebindings4, avidemux,
> > telepathy-qt, and others. If you want to give it a spin here it is.
> Here is a slight change to the last patch. All it does is add a
> default_cmake_build to include default_make. Have not found a cmake
> dependent module that has failed to build.
> One thing I would like to incorporate is the ability of build.lunar (or
> appropriate script) to, in a sane way, detect if it should use
> default_build or default_cmake_build.
> Any thoughts about about how to do that is appreciated. One thought was to
> do something like PSAFE such as CMAKE=yes. Not real fond of that idea, nor
> looked at the logic to make it happen.
> Another thought. Alter the run_build function starting on line 396. The
> idea here is to test for the presence of CMakeLists.txt, if there, then
> default_cmake_build, else default_build. AFAICT from the cmake
> documentation, any project using cmake, will at the minimum have
> CMakeLists.txt in its top level directory.
> Anyway, that's about as far as the gray matter has gotten. So feel free to
> critique on any level.
Here is a third installment. Just a simple elif test for CMakeLists.txt, if !
then default_build. It works with a number of modules that do not have a
BUILD, and those with BUILD+cmake. Not seen any issues as yet. Anyway, here
You can tuna piano but you can't tune a fish.
It's worth the spin.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1916 bytes
Desc: not available
More information about the Lunar-dev