[Qt-creator] Generating QtCreator cmake project for given CMakeLists.txt from command line

[Hunger Tobias]

Hi,

apparently I replied only to René directly... find the original reply inline.

On Fr, 2016-04-15 at 13:03 +0200, René J.V. Bertin wrote:
> On Friday April 15 2016 10:05:02 Hunger Tobias wrote:
> Was there a reason you replied off-list?

Carelessness.

> > In the end you need to have the kit and the actual configuration in your
> > build
> > directory to match up: Otherwise the code model will not function properly.
> > So I
> > think the use-case of having a kit and a completely different configuration
> > in
> > your build directory is nothing Creator needs to support.
> 
> There's no point in supporting completely different configurations indeed, but
> the fact a feature could be used to work with such a senseless configuration
> doesn't mean it cannot have a valid reason to exist ...

I think this will no longer be an issue when you can just import an existing
build directory.

> > Creator has no internal cmake parser.
> 
> I know.
> 
> > We get most information out of the
> > codeblocks file.
> > 
> > For Qt Creator 4.0 all I did was to improve on the workflow for using cmake
> > projects. I did not yet look into how we can get more/better information out
> > of
> > cmake.
> 
> OK, so maybe my hint about the compile_commands.json file will serve a purpose
> :)

Thanks for the hint.

That file will probably work well, as long as you do not end up building one
source file as part of several targets (e.g. an executable and a test).

> > > The alternative would be to provide a way to control exactly how cmake is
> > > called, command and arguments (and record that information, contrary to
> > > earlier QtC versions that didn't remember the cmake arguments).
> > 
> > Qt Creator 4.0 should do that.
> 
> In the version I have I only see a way to change settings from the cache. But
> changes made there apparently can get lost.

Not those you do from inside Creator. Those sometimes did get lost before, too.

> > Yes, CMake is far from ideal for IDEs:-/
> 
> Is autoconf/automake/configure really that much better?

autoconf/automake are definitely easier to work with for IDE integration. At
least they have one defined set of outputs. CMake produces whatever it wants.

> > That is what importing a build directory is for. For now I do not think this
> > is
> > much of an issue since Creator should only pick up build directories that
> > happen
> > to be named like Qt Creator names them:-)
> 
> That's the automatic pickup, yes. But imagine a Debian (or other distribution)
> maintainer working on code and its packaging. If that involves a number of
> not-so-trivial patches it becomes useful to import the project and its
> existing build directory in an IDE, and evidently that IDE should then be as
> well-behaved as possible (i.e. only change things by explicit user request ...
> like source files ;))

Yes, I am not arguing that point. But the current "automatic" pickup of build
directories can not cover this use case: You want to explicitly import such a
build directory.

> > No. If you ask creator to use a certain cmake, then creator should not use
> > some
> > other cmake behind your back.
> 
> I should probably have removed those remarks after reading your idea of
> creating a kit off the build configuration.
> 
> > No idea, I never checked that.
> 
> Forget it, must have been something in the project itself. Just a redundant
> make invocation takes over 4 minutes with 4 parallel cmake processes running
> at 100% CPU.
> 
> > Yes, these kits are added forever (once you actually import the build
> > directory).
> 
> I'd probably want to have an option to disable that particular feature. Esp.
> if those kits take *all* cmake arguments into account (including the one that
> points cmake to the source directory!). QtC already keeps picking up kits for
> Qt build trees I keep around and I'd never use for building against, at some
> point something's gonna give ;)

Considering that you probably have a limited number of cmake binaries, compilers
and Qt versions, kits are bound to repeat themselves;-)

> > Kits can have their own set of environment varibales. fro a while now.
> 
> Yes, that I know. But you have to set them every time. It'd be convenient to
> have presets (profiles) that you configure once (and edit "centrally"), and
> then pick the appropriate one when creating a new project.

I am not sure that this is a common use case.

You could set up your environment before you start Qt Creator... that way the
environment will be inherited by all projects.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B