Discussion:
cmake and auto-generated sources
René J.V. Bertin
2018-09-21 12:46:53 UTC
Permalink
Hi,

I've asked this before on a KDE list, so apologies if you've seen the question already.

Is there a way to generate all the autogen stuff after running cmake? Often, if you import a fresh source tree of a cmake-based project into an IDE like kdevelop, cmake will be run to figure out the project content and dependencies, where headers are etc. Afterwards most parsing will thus succeed, but not that which requires headers and other stuff that is generated during a build (moc files, translated .ui files, ...). That is quite annoying for large projects.
I think qmake-based projects generate those things as the first step during a make, while cmake-based projects generate them on an as-needed basis.

Presuming that qmake-based projects have a dedicated target that could be built in isolation on user request, would it be possible to achieve this with cmake as well, without need to patch cmake itself?

On a related topic: it would be great if those auto-generated files didn't use relative include paths. That can break the build if you access a build directory during a make via a path containing symlinks on a system that does not normalise paths.

Thanks,
René
René J.V. Bertin
2018-10-09 10:23:48 UTC
Permalink
[re-sending amended version to the intended destination, apologies to Friedrich]

So, I have had some feedback on Qt's Interest ML, which only confirms what we already know: with cmake all automatic content is only generated during a full make. Idem with qmake, with some subtle differences.

Still waiting to hear if it would be *possible* to change this, but in the meantime we have one possible workaround, using a compiler option I used to use before I started using IDEs with syntax parsing: -fsyntax-only . A quick test shows that this argument is still supported by clang 6 and gcc 8. Simply adding it to the existing compiler command causes processing to stop after the syntax checking stage.

My old experience tells me that this can be a few orders of magnitude faster than doing a full code generation, and of course it doesn't actually generate any output in the build.dir. There's no reason that would have changed; I guess a full "build" with -fsyntax-only will be somewhat faster than a full no-change re-build using ccache.

I'll be checking this with a copy of KDevelop's sources, adding the option to CMAKE_C{,XX}_FLAGS . It will probably be necessary to run the build step with make -k because something is bound to complain about the missing object files. Even then I'm not certain the build will continue after encountering the first missing library target dependency.

After trying I'm certain: the 1st build (with -j4 -k) went to about 16% in 6'15" minutes (through KDevelop). That's slower than I hoped, even on a not-exactly-fast Intel N3150. A second run *outside* of KDevelop took that down to 5'38" minutes (and of course went just as far). The few sub-targets I tried to "build" this way also failed because of missing dependencies before they got to generating their own automatic content (ex. the KDevPlatformProject plugin).

This could probably go further if cmake had some kind of support for -fsyntax-only, where linker errors (due to missing files) are ignored. That could be a more generically useful option to propose to Kitware than some kind of solution to do all auto-generation through a dedicated build target, which they might (justifiably) consider as something to be handled at the Qt (and KDE?) level.

R.
Kevin Funk
2018-10-09 11:01:26 UTC
Permalink
Post by René J.V. Bertin
[re-sending amended version to the intended destination, apologies to Friedrich]
So, I have had some feedback on Qt's Interest ML, which only confirms what
we already know: with cmake all automatic content is only generated during
a full make. Idem with qmake, with some subtle differences.
Hey,

unfortunately it's still not directly related to KDevelop development.

Furthermore, it's particularly not interesting to the KDevelop *Users* mailing
list. Please refrain from posting further diary-style mails to this list.

While I agree your Qt/CMake improvement idea is sound, the actual issue never
really bothered me so far. And I *do* work on significantly larger projects
regularly. But this is not the right place to discuss your idea & the
implementation details.
Post by René J.V. Bertin
(snip)
After trying I'm certain: the 1st build (with -j4 -k) went to about 16% in
6'15" minutes (through KDevelop). That's slower than I hoped, even on a
not-exactly-fast Intel N3150.
A second run *outside* of KDevelop took that
down to 5'38" minutes (and of course went just as far). The few sub-targets
I tried to "build" this way also failed because of missing dependencies
before they got to generating their own automatic content (ex. the
KDevPlatformProject plugin).
I'll repeat myself, but I don't think a Intel Celeron N3150 is up for the task
for e.g. continuously working on big projects like KDevelop or LLVM (as you
do). Do yourself a favor and upgrade. Get a more powerful desktop box if
necessary (cheaper). I also remember you using a SSHD -- get a SSD. Use Ninja
files to achieve fast incremental builds, etc. pp..

I have a 4 year old Intel laptop with with roughly 3 times the computing power
and TDP of yours (comparing its CPU benchmark on said site), 12 GB RAM + fast
SSD, and I'm already annoyed by it's day-to-day slowness when working on
programming related tasks. An upgrade is due.

But I keep getting dragged into off-topic area; will not further comment on
this.

Regards,
Kevin
Post by René J.V. Bertin
This could probably go further if cmake had some kind of support for
-fsyntax-only, where linker errors (due to missing files) are ignored. That
could be a more generically useful option to propose to Kitware than some
kind of solution to do all auto-generation through a dedicated build
target, which they might (justifiably) consider as something to be handled
at the Qt (and KDE?) level.
R.
--
Kevin Funk | ***@kde.org | http://kfunk.org
René J.V. Bertin
2018-10-09 11:28:20 UTC
Permalink
Post by Kevin Funk
unfortunately it's still not directly related to KDevelop development.
Which is why I wasn't posting on the devel ML.
Post by Kevin Funk
Furthermore, it's particularly not interesting to the KDevelop *Users* mailing
list. Please refrain from posting further diary-style mails to this list.
?! This is about *using* KDevelop, not any other IDE that happens to use CMake instead of spinning its own project configuration cum build approach. Where else would I post about this and possibly get feedback from fellow users? You are not the only user on this list so please don't tell other users what they should or should not find interesting; just disregard posts that don't concern you. Everyone else apparently does (including me).
But whatever, I wasn't exactly planning to keep sharing to the void anyway.
Post by Kevin Funk
I'll repeat myself, but I don't think a Intel Celeron N3150 is up for the task
for e.g. continuously working on big projects like KDevelop or LLVM (as you
do). Do yourself a favor and upgrade. Get a more powerful desktop box if
necessary (cheaper). I also remember you using a SSHD -- get a SSD. Use Ninja
files to achieve fast incremental builds, etc. pp..
Neither budget nor space for that - and ninja's supposed performance advantages have never been apparent to me (it's just less flexible in practice).

R

Loading...