I sent an email to kde-core-devel detailing the problems I had
experienced
the other day with beta1. They say these should be fixed in beta 2.
Frank
Here's their reply:
Begin forwarded message:
> From: Alexander Neundorf <neund...@kde.org>
> Date: 19 December 2008 18:15:14 GMT
> To: kde-buildsys...@kde.org
> Cc: Allen Winter <win...@kde.org>, Frank Wilson <fr...@thefixedpoint.me.uk
> >
> Subject: Re: Fwd: Kde 4.2 beta1 feedback: Notes on cmake scripts
> Reply-To: neund...@kde.org
>
> On Friday 19 December 2008, Allen Winter wrote:
>> Forwarding to the buildsystem folks:
>> ---------------------------------------------------------------------------
>> -- Firstly I'd like to say thank you for an awesome kde 4.2 beta 1,
>> it's
>> looking really good.
>>
>> I would like to raise a few issues about the build scripts and offer
>> some suggestions.
>> I regret that I have not been able to try the latest "beta 2" that
>> was
>> released today, but I will try it as soon as I have time.
>
> Thanks for the feedback, but I think I have fixed all these issues
> just two
> weeks ago, i.e. after beta1, they should be in beta2.
> I'm building KDE currently with the stuff installed
> to /opt/kdesupport, /opt/kdelibs, /opt/kdepimlibs and /opt/kde4 (for
> all the
> rest), so that I think I have stumbled about all the same problems
> and fixed
> them.
>
> Please let us know if you still have problems with current svn trunk.
>
> Thanks
Alex
---------------
Here is the email i sent them:
Firstly I'd like to say thank you for an awesome kde 4.2 beta 1, it's
looking really good.
I would like to raise a few issues about the build scripts and offer
some suggestions.
I regret that I have not been able to try the latest "beta 2" that was
released today,
but I will try it as soon as I have time.
I am using GoboLinux. GoboLinux does not use the FHS, which means
certain
assumptions that are true for many distributions do not hold in this
case.
While installing KDE-4.2 beta 1 I ran in to 2 areas of trouble which
required three patches
in total.
The first trouble spot is with the cmake modules that kde-libs
installs on the system.
The "kdelibs-4.1.80/cmake/modules/FindKdepimLibs.cmake" file
specifies KDE4_LIB_DIR as the location for the kdepimlibs libraries.
This does not
work on GoboLinux because we do not install the whole of KDE to the
same prefix
instead we have /Programs/KDE-Libs/Current, /Programs/KDE-PIM-Libs/
Current,
/Programs/KDE-Base/Current, etc.
This means that in the Gobolinux case KDE4_LIB_DIR will point to
/Programs/KDE-Libs/Current, which is obviously the wrong prefix for
PIM-Libs.
I solved this by substituting CMAKE_LIBRARY_PATH in the place of
KDE4_LIB_DIR
and setting CMAKE_LIBRARY_PATH=/System/Links/Libraries where all
libraries can
be found.
I had a quick browse of kde web svn before sending this email and it
would appear
that FindKdepimLibs has changed quite a bit. I haven't had a chance to
read very deeply
into the code, but I hope that CMAKE_LIBRARY_PATH is used more instead
of KDE4_LIB_DIR.
The other problem I had was with KDE-Base-Workspace and KDE-Base-
Runtime locating
DBUS interface definitions in the scripts powerdevil/daemon/
CMakeLists.txt and
kwalletd/CMakeLists.txt. Both scripts originially used the variable
DBUS_INTERFACES_INSTALL_DIR
to refer to preexisting interface definition files. On a system where
all DBUS interfaces are
installed in the same location this is not a problem. However, on
GoboLinux each package
installs its DBUS interface definitions under the package prefix and
these are symlinked
to /System/Links/Shared/dbus-1/interfaces/ .
In the end this means when building either KDE-Base Workspace or
Runtime the build script
looks under the installation prefix and of course it won't find
anything there because
that prefix hasn't been created yet (and the files its looking for are
never going to be there anyway)!
To resolve this I substituted DBUS_INTERFACES_INSTALL_DIR with
KDE4_DBUS_INTERFACES_DIR
and set KDE4_DBUS_INTERFACES_DIR appropriately (i.e. to /System/Links/
Shared/dbus-1/interfaces)
when compiling KDE-Libs.
From browsing kde web svn, this seems to be the approach you are
taking now. I would like to strongly
encourage you to include this in the final release! :-)
I include my patches with this email for clarity. I apologise for
accidentally changing a WIN32 setting in
01-kwalletd-CMakeLists.patch this was not my intension and I do not
know if it is appropriate or not.
The patch is really just to illustrate the change I would make and by
the looks of the svn code I don't think you
will be needing it!
Do people on this list think it is likely that these amendments might
make the final release?
(Not my patches, just the general ideas!)
Thanks,
Frank Wilson
-----------------------------------
END OF MESSAGE
On 17 Dec 2008, at 14:28, Frank Wilson wrote:
> I have adjusted my patch now and I think I am approaching a
> workable solution. The idea of the new patch is to replace
> KDE4_LIB_DIR
> with CMAKE_LIBRARY_PATH instead of LIB_INSTALL_DIR.
> This seems to work although for KDE-Base-Workspace, which I have
> just compiled and installed, CMAKE_LIBRARY_PATH has to be
> set explicitly. If CMAKE_LIBRARY_PATH is not set, Compile
> fails at the cmake configuration stage. Otherwise, my compile
> of KDE-Base-Workspace went without a hitch!
>
> My gut feeling is that if we set CMAKE_LIBRARY_PATH
> and CMAKE_INCLUDE_PATH in the cmake recipes' Environment
> file we would eliminate the need to set this for many cmake recipes.
>
> I will try this later after I have tested a few more KDE4 recipes.
>
> Frank
>
> On 17 Dec 2008, at 12:36, Frank Wilson wrote:
>
>> Hmm... using LIB_INSTALL_DIR was a bad idea (for me at least).
>> Using that variable means the KDE will try and install itself outside
>> of its own directory (i.e. in /System/Links/Libraries). I should have
>> guessed,
>> I suppose!
>>
>> I'm unsure what the gobo way is now. I think what we need is to find
>> another variable to help locate these libraries. Questions I have to
>> answer are:
>>
>> * Have KDE set an appropriate variable for finding libraries that is
>> different
>> from the install location?
>> * Is it better to point each find_library statement to /System/Links/
>> Libraries
>> or should each statement point to the unique path of each library?
>> I suppose
>> the latter is closer to the gobo way, but harder to realize.
>>
>> Frank
>>
>> On 17 Dec 2008, at 12:07, Frank Wilson wrote:
>>
>>> Right I am going to just assume that WIN32 stuff was just
>>> accidentally
>>> changed with sed and is just a red herring....
>>>
>>> In my new patch I am just substituting KDE4_LIB_DIR for
>>> LIB_INSTALL_DIR,
>>> much like the old patch. I am still testing my recipes, but it looks
>>> like I
>>> still have to set LIB_INSTALL_DIR in the recipes for the other KDE4
>>> modules
>>> (such as KDE-Base- Workspace). This was not the case in the old kde
>>> 4.1.3
>>> recipes.
>>>
>>> Is LIB_INSTALL_DIR being set somewhere else? If so where?
>>> Can cmake vars be set by shell variables set elsewhere on the
>>> system?
>>>
>>> Thanks,
>>>
>>> Frank
>>>
>>>
>>> <01-FindKdepimLibs.patch>
>>>
>>> On 17 Dec 2008, at 10:51, Frank Wilson wrote:
>>>
>>>> By the way I should have made it clear that the patch applies to
>>>> KDE-
>>>> Libs 4.1.3.
>>>>
>>>> Frank
>>>>
>>>> On 17 Dec 2008, at 10:31, Frank Wilson wrote:
>>>>
>>>>> I am working on recipes for KDE 4.1.80 (the KDE 4.2 beta 1 release
>>>>> [1]).
>>>>> For some reason I found that I could not apply the patch [2] for
>>>>> 4.1.3
>>>>> to the new release. However I still think the new release needs to
>>>>> be patched in a similar way. I would like to have a better
>>>>> understanding
>>>>> of the current patch so i can re-implement it.
>>>>>
>>>>> The KDE build system assumes that KDE-Libs and KDE-PIM-Libs
>>>>> will be installed under the same hierarchy. This is probably the
>>>>> case
>>>>> under debian
>>>>> but not on a gobolinux system.
>>>>>
>>>>> I believe this is what the following part of the patch (along with
>>>>> similar parts) addresses:
>>>>>
>>>>> - find_library(KDE4_SYNDICATION_LIBRARY NAMES syndication PATHS $
>>>>> {KDE4_LIB_DIR} \
>>>>> NO_DEFAULT_PATH )
>>>>> + find_library(KDE4_SYNDICATION_LIBRARY NAMES syndication PATHS $
>>>>> {LIB_INSTALL_DIR} \
>>>>>
>>>>> However, I don't understand why the following has been changed:
>>>>>
>>>>> if (WIN32)
>>>>> - if (KDEPIMLIBS_DIR)
>>>>> - set (KDE4_INCLUDE_DIR ${KDE4_INCLUDE_DIR} $
>>>>> {KDEPIMLIBS_DIR}/
>>>>> include)
>>>>> - set (KDE4_LIB_DIR ${KDE4_LIB_DIR} ${KDEPIMLIBS_DIR}/lib)
>>>>> - else (KDEPIMLIBS_DIR)
>>>>> + if (LIB_INSTALL_DIR)
>>>>> + set (KDE4_INCLUDE_DIR ${KDE4_INCLUDE_DIR} $
>>>>> {LIB_INSTALL_DIR}/
>>>>> include)
>>>>> + set (LIB_INSTALL_DIR ${KDE4_LIB_DIR} ${KDEPIMLIBS_DIR}/
>>>>> lib)
>>>>> + else (LIB_INSTALL_DIR)
>>>>> file(TO_CMAKE_PATH "$ENV{PROGRAMFILES}" _progFiles)
>>>>> set (KDE4_INCLUDE_DIR ${KDE4_INCLUDE_DIR} ${_progFiles}/
>>>>> kdepimlibs/include)
>>>>> - set (KDE4_LIB_DIR ${KDE4_LIB_DIR} ${_progFiles}/kdepimlibs/
>>>>> lib)
>>>>> - endif (KDEPIMLIBS_DIR)
>>>>> + set (LIB_INSTALL_DIR ${KDE4_LIB_DIR} ${_progFiles}/
>>>>> kdepimlibs/
>>>>> lib)
>>>>> + endif (LIB_INSTALL_DIR)
>>>>> endif (WIN32)
>>>>>
>>>>> Shouldn't the body of this if statement [ if (WIN32) ] be ignored
>>>>> on
>>>>> gobolinux (or any variant of linux
>>>>> for that matter)? Or am I missing something?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Frank
>>>>>
>>>>> [1] http://kde.org/info/4.1.80.php
>>>>> [2]
>>>>> http://recipes.gobolinux.org/r/?list=KDE-Libs&ver=4.1.3-r1&file=01-FindKdepimLibs.patch
>>>>> _______________________________________________
>>>>> gobolinux-devel mailing list
>>>>> gobolinux-devel@lists.gobolinux.org
>>>>> http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
>>>>
>>>> _______________________________________________
>>>> gobolinux-devel mailing list
>>>> gobolinux-devel@lists.gobolinux.org
>>>> http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
>>>
>>> _______________________________________________
>>> gobolinux-devel mailing list
>>> gobolinux-devel@lists.gobolinux.org
>>> http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
>>
>> _______________________________________________
>> gobolinux-devel mailing list
>> gobolinux-devel@lists.gobolinux.org
>> http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
>
> _______________________________________________
> gobolinux-devel mailing list
> gobolinux-devel@lists.gobolinux.org
> http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
_______________________________________________
gobolinux-devel mailing list
gobolinux-devel@lists.gobolinux.org
http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
