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 <codestr...@posteo.org> > >>> 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: ~/kde-5/lib64/cmake/KF5I18n/KF5I18nConfig.cmake ~/kde-5/lib64/cmake/KF5I18n/KF5I18nConfigVersion.cmake 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. > KF5CoreAddons_DIR:PATH=/home/gregor/kde/usr/lib64/cmake/KF5CoreAddons. Great! 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 repetitive builds. 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 compilers). Regards, - Michael Pyne