Web lists-archives.com

Re: kdesrc-build / details




Answer below...

On 15.05.2018 03:06, Michael Pyne wrote:
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:

~/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


Thanks for this valuable information. It will take some time to process them in depth. Yesterday, I wrote a script that will help me to find all offending build directories in short time:

https://cgit.kde.org/scratch/gregormi/codestruct-util.git/tree/dev-kde/dev-kf5-check-builddirs

This way I hope to better find out when something goes wrong. :)

Gregor