Bug 331654 - cmake-git does not compile with ninja as build command
Summary: cmake-git does not compile with ninja as build command
Status: RESOLVED FIXED
Alias: None
Product: kdesrc-build
Classification: Developer tools
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Michael Pyne
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-01 19:18 UTC by Andreas Hartmetz
Modified: 2014-03-30 04:17 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 1.16


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Hartmetz 2014-03-01 19:18:52 UTC
From my config file:

global
[...]
  cmake-options -G Ninja -DCMAKE_BUILD_TYPE:STRING=debug
  custom-build-command ninja
[...]
end global

From the log file:

# kdesrc-build running: '/usr/local/bin/ninja'
# from directory: /home/horst/ksrc5/build/cmake-git
ninja: error: loading 'build.ninja': No such file or directory

ls -l ~/ksrc5/build/cmake-git -> contains a Makefile

The problem is probably that cmake-git is bootstrapped and the bootstrap build system doesn't support Ninja.

Reproducible: Always

Steps to Reproduce:
1. set up Frameworks 5 https://community.kde.org/Frameworks/Building
2. set custom build command ninja and -G Ninja for cmake
3. run kdesrc-build
Actual Results:  
Build fails at cmake-git

Expected Results:  
Build succeeds
Comment 1 Andreas Hartmetz 2014-03-01 19:55:30 UTC
The same problem occurs with karchive, kconfig, ...
Comment 2 Michael Pyne 2014-03-01 23:38:47 UTC
> The problem is probably that cmake-git is bootstrapped and the bootstrap build system doesn't support Ninja.

I would tend to agree with this (though I've had to disable Ninja builds here since support for them seems to have broken a bit with more recent CMakes).

However I would recommend moving the custom-build-command and cmake-options relating to Ninja to the KDE module-sets instead of making them global.

'custom-build-command' is very much a "trust me, I'm the user, I've got this" and having kdesrc-build try to guess when it might or might not be safe to actually allow the custom build command would only lead to someone else opening a bug that custom-build-command doesn't do a custom build. ;)

I actually had the same problem years ago with svn support, where I first added branch/tag options, which didn't always quite do the right thing.... so I added 'module-base-path', which was closer but didn't always do the right thing. Eventually I gave up and added 'override-url': "Trust me, I'm the user, download it from this exact link".

One thing I can do is to add a way to custom-build-command for getting back the "default" build system handling so that you can have a global ninja and a case-by-case exception from there. Would that help?
Comment 3 Michael Pyne 2014-03-30 04:17:54 UTC
Git commit 9fb3fb04d170478c922c5d85bb996f8f4b7ed82c by Michael Pyne.
Committed on 30/03/2014 at 03:39.
Pushed by mpyne into branch 'master'.

build-systems: Mask default options for non-default build systems.

This is a first-step hack to have non-default build systems ignore
global options which are related to the build system in use (e.g.
compile or make flags, install/uninstall options, etc.).

This should fix bug 331654 (now that I understand it better) and improve
the situation for bug 332789 (which would be the long-term fix when
implemented).
Related: bug 332789
FIXED-IN:1.16

M  +11   -8    doc/index.docbook
M  +31   -1    modules/ksb/BuildSystem.pm

http://commits.kde.org/kdesrc-build/9fb3fb04d170478c922c5d85bb996f8f4b7ed82c