Re: kdesrc-build: cmake should take local (instead of system-wide) cmake modules
- Date: Mon, 14 May 2018 21:06:04 -0400
- From: Michael Pyne <mpyne@xxxxxxx>
- Subject: Re: kdesrc-build: cmake should take local (instead of system-wide) cmake modules
On Sat, May 12, 2018 at 02:23:47PM +0200, gregor.mi.sw wrote:
> On 10.05.2018 02:22, Michael Pyne wrote:
> > On Wed, May 09, 2018 at 01:12:10PM +0200, gregor.mi.sw wrote:
> >> Am 09.05.2018 08:19 schrieb Ben Cooksley:
> >>> On Wed, May 9, 2018 at 9:28 AM, gregor.mi.sw <codestruct@xxxxxxxxxx>
> >>> wrote:
> >>>> On 08.05.2018 23:15, Milian Wolff wrote:
> >>>>> On Dienstag, 8. Mai 2018 22:40:39 CEST gregor.mi.sw wrote:
> >>>>>> Hello,
> >>>>>> I have a question regarding kdesrc-build and CMake.
> >>>>>> I setup the build environment variables and ran kdesrc-build and got
> >>>>>> a
> >>>>>> compiler error kinfocenter.
> >>>>>> Now it shows the correct (local) path for solid (but not the other
> >>>>>> ones).
> >>>>>> Is
> >>>>>> there an environment variable or something I have to set to tell
> >>>>>> Cmake to
> >>>>>> always look for local modules first?
> > This is all sort of odd.
> > Regarding the difficulty finding CMake packages, kdesrc-build sets
> > CMAKE_PREFIX_PATH already, based on your chosen install location (set by
> > 'prefix' or the compatibility 'kdedir' option).
> > If you're installing to /usr or /usr/local then maybe that is why CMake
> > is finding system libraries? Roman Gilg actually recently submitted a
> > patch to fix this (https://phabricator.kde.org/D12739), if that's what
> > the problem is.
> >>>>> Try CMAKE_PREFIX_PATH. See e.g. this old blog post on the matter:
> >>>>> https://blogs.kde.org/2008/12/12/how-get-cmake-find-what-you-want-it
> >>>> Thanks for the hint. The variable was already set:
> >>>> CMAKE_PREFIX_PATH=/home/gregor/kde/usr:
> >>>> In the blog post, it is said, that CMAKE_PREFIX_PATH is searched
> >>>> _first_. I
> >>>> find it strange that I had to uninstall the system-wide devel package
> >>>> in
> >>>> order to have cmake pick up the library in /home/gregor/kde/usr. And
> >>>> for the
> >>>> other libraries it still uses /usr. Any idea how to investigate this
> >>>> further?
> >>> If you have previously run CMake without setting CMAKE_PREFIX_PATH you
> >>> will need to remove your build directory first, otherwise it will
> >>> reuse modules it has already found.
> >> Hello Ben, I already removed the build dir (forgot to mention that). I
> >> assume that it should be sufficient to delete the build dir of the
> >> application that should be configured
> >> (/home/gregor/kde/src/build/kde/workspace/kinfocenter/) and not also
> >> those of the imported libraries (KF5Service, KF5Solid, KF5Wayland etc.).
> >> I wonder if there is maybe an additional (global) cmake cache or a
> >> special behaviour of kdesrc-build.
> > There's no special behavior for kdesrc-build here (though there is a
> > cache, default .kdesrc-build-data in the same directory as your
> > kdesrc-buildrc).
> > However the CMake package to find when a CMake module config file is
> > loaded is based on the CMake paths when the module config file was
> > *installed*. So all imported libraries would have be reinstalled to
> > fully fix the paths.
> I assume "be reinstalled" also means "be rebuild" because otherwise wrong precompiled files would be
> installed again, right?
Yes, that's right.
> > I've had these problems over the years and I've almost always found it
> > easier just to remove the CMake module config files entirely before
> > reinstalling to force it to be regenerated.
> Do you mean those files: /home/gregor/kde/usr/lib64/cmake/* or another location? Why only the CMake
> module config files if a complete rebuild is required (--refresh-build)?
If your path is like mine then yes. In my case, they are files at ~/kde-5/lib64/cmake/*.
For instance if I run ~/kde-5/lib64/cmake/KF5I18n/*Config*.cmake I get:
and these files refer to other CMake metadata within the same directory.
Other CMake modules trying to find KF5::I18n will, if CMake finds these
*Config.cmake files in its search path first, end up using the metadata
embedded in these files to pull in KF5::I18n and its dependencies.
So if CMake finds a system set of *Config.cmake files it will end up
pulling in other dependencies from the system and potentially end up
linking against the wrong libraries.
> I still have some hope I can save this total re-compilation which takes at least 1 hour for me to
> reach applications like kinfocenter. Spordically, I want to code during the week after work in the
> evening and I find myself struggeling to get the dependencies build ready. And when it is ready, the
> time for this day is over :-). And a few days/weeks later a similar story. If I don't code every day
> this setup time is a major obstacle to reach a point where productive coding is possible. Thanks for
> clarifying some of the build details which makes it easier to better figure out when a complete
> rebuild is necessary.
I see you've already added some wishlist items, and I'd just ask to keep
them coming. kdesrc-build is very streamlined in the way *I* use it
(user-local install, no system KDE to speak of anymore) but I want it to
be productive for everyone, especially those without much time to
develop (this describes my case as well :( ).
In fact kdesrc-build's first version (back when it was kdecvs-build) was
meant to be run completely headless (i.e. from cron) so that it could
run overnight while I was sleeping and wouldn't fall prey to times where
I'd forget to set the right environment variables first and ruin hours
of potential build time as a result.
> > It may be easiest to remove the install directory completely and use
> > "kdesrc-build --refresh-build" to avoid interference from
> > previously-installed cruft.
> I now ran
> $ kdesrc-build --include-dependencies --refresh-build kinfocenter
> which recompiles everything. Now, the CMakeCache.txt files seem to
> contain the correct paths, e.g.
One final tip I'd offer is, if you have enough disk space, to consider
tools like ccache https://ccache.samba.org/ which can greatly speedup
Using it with kdesrc-build is mostly a matter of making sure that
ccache's symlinks are first in your PATH (compared to the actual
- Michael Pyne