Re: [Qt-creator] Generating QtCreator cmake project for given CMakeLists.txt from command line
On Friday April 15 2016 11:35:26 Hunger Tobias wrote: Hi >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). If that's the case then KDevelop may already have found a workaround. >> 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. > I meant making changes via Creator, must have been to an option variable (unused on the commandline). Are these changes supposed to survive even a clearing of the cmake cache? >directories can not cover this use case: You want to explicitly import such a >build directory. Fair enough! >You could set up your environment before you start Qt Creator... that way the >environment will be inherited by all projects. Of course. But that's something you have to remember, and it's not necessarily trivial on all platforms. BR, R. ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Generating QtCreator cmake project for given CMakeLists.txt from command line
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 ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Generating QtCreator cmake project for given CMakeLists.txt from command line
On Friday April 15 2016 07:59:38 Hunger Tobias wrote: Hi, >> Is there a way to prevent QtC from re-running cmake each time it feels like >> doing so? > >Creator will rerun CMake whenever it feels like doing so, because that is the >only way to get up-to-date information on the project. CMake is not very >forthcoming with information:-/ Yes, I know, but wouldn't it be possible to display a "I'd like to rerun cmake" indicator and let the user decide whether that's actually going to happen ... at his/her expense (= project information not being updated)? If you're using an IDE for a development workflow that doesn't take place completely in the IDE you probably prefer to have potentially out-of-date project information rather than having up-to-date information on a misconfigured project ;) FWIW, KDevelop also dropped its internal cmake parser, but uses the compile_commands.json file generated by cmake when called with -DCMAKE_EXPORT_COMPILE_COMMANDS=ON . As long as that file is present it will not launch cmake itself, but instead (apparently) count on it that cmake is called through make or ninja whenever necessary. In my case that usually means the appropriate environment is in place. Shouldn't this also work for QtC, supposing that it gets its information not by reading cmake's stdout by parsing some file maintained by cmake? 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). The big risk with auto-invocation of cmake on a build directory that is also under external control is that cmake doesn't put up a lock when it's running in a directory. >Creator will keep the configuration unless at least one of these conditions is >met: > >* The generator (ninja/make/etc.) used to set up a build directory does not >match up with the one used by the selected Kit. It'd be nice if it could simply adapt and use the generator from the configured directory, at least as an option. BTW, the ninja generator creates only a single, toplevel ninja file. Is it still possible to build only a sub directory of a project (i.e. one that has a Cmake file) with that generator? >* The cmake command that was run to set up a build directory is not the one >configured for the selected Kit. That should probably be optional, (much) more so than for the generator. >Creator no longer clears the cache if the Extra Generator "CodeBlocks" is >missing. Since what commit? I'm currently testing a built off last Friday's (Apr. 8th) code base, and at the very least it yells if I don't select a generator with the CodeBlocks generator. Is it possible that that extra generator causes a lot of overhead for larger projects? I just came across one where even a "make" invocation with nothing to do would take forever to complete, with most of the time spent in cmake itself. Never saw that before. >I do want to have proper "Import build directory" support for the next version. >That should then set up a matching kit for a build directory. That could do the trick too... A kit that will be added to the available kits "forever", or one that will be specific to that project? What version are we talking about (major, minor, ...)? ;) Reminds me: does QtC have something like profiles/presets for environment variables (that can be selected per project and are applied before running any configure or make command)? IIRC I've only seen per-project settings that'd have to be recreated for each new project. Cheers, René ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Why QtC does not use QDockWidget for most tool-panel
On Friday April 15 2016 06:06:12 Orgad Shaneh wrote: >> "Not a git repository" is normally what you get when executing a git >command outside of a git repository. Errrm I know I'm far from a git expert, but I thought that above remark should be sufficient to indicate that I did execute the magic formula from inside a git repository, i.e. a working copy (that was last refreshed Friday 8th). :P Maybe I should have said working copy instead of git repo, but AFAIK those terms are equivalent. >> >> Oh well, I'll see if I can get it some other way. > >You need to clone the repository before you can apply a particular change. > >Read the git introduction here: https://wiki.qt.io/Git_Introduction ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Generating QtCreator cmake project for given CMakeLists.txt from command line
On Do, 2016-04-14 at 18:19 +0200, René J. V. Bertin wrote: > I'm not sure if I really grasped everything outlined in the OP, but I think I > have a similar question for a comparable workflow that doesn't involve ROS or > catkin. > It does involve a distribution/packaging system that runs cmake (and make) in > a > tightly controlled environment and with highly specific commandline options. > When developing (or adapting) software in the context of that system it is > often > useful to be able to open a work directory (containing directories with the > [patched] source and an out-of-tree build directory) in an IDE, possibly even > (re)building parts of the code. > > It is trivial to let the system have cmake use the "CodeBlocks - Unix > Makefiles" > generator, but apparently that is not enough to let Qt Creator reuse the > configured build directory without re-running cmake. It is easy enough to re- > run > the correct configure command if QtC calls cmake only once, on the initial > import. It's a different story if it keeps doing this each time a project is > (re)opened. > > Is there a way to prevent QtC from re-running cmake each time it feels like > doing so? Creator will rerun CMake whenever it feels like doing so, because that is the only way to get up-to-date information on the project. CMake is not very forthcoming with information:-/ Creator will keep the configuration unless at least one of these conditions is met: * The generator (ninja/make/etc.) used to set up a build directory does not match up with the one used by the selected Kit. * The cmake command that was run to set up a build directory is not the one configured for the selected Kit. Creator no longer clears the cache if the Extra Generator "CodeBlocks" is missing. I do want to have proper "Import build directory" support for the next version. That should then set up a matching kit for a build directory. 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 ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Searching for names in locator with starting letters as it is in code-completion
Hi, David and Everyone. > there is already a suggestion for this feature at > https://bugreports.qt.io/browse/QTCREATORBUG-3111 Thanks for pointing out. I voted. By I wonder how votes influence things. May be there is like decision what for every 20 votes we increse priority 1 level? No? May be someone know how in JIRA get list of most wanted/voted bugs? > Vote on this suggestions if you would like to see it at some point in > creator, but to > be honest it hasn't currently the highest priority. :( I see Does only me feel that all fields outside of code-editor are like from old 90's ... we are used to edit and search names in one way and outside of code-editor all line-edit-boxes are like not for C++ devs ... they are like for word-editors *I mean that ctrl-left and ctrl-right does not respect uppercase "midle-points" (like is skips whole "setPlaintText" which is not the way it is in editor). Test this in search fields, renaming refactorings ... everythere! *Line-edit-boxes font is small (not the one you have selected for code editor) ... and I never found how font size of them can be increased. *And search in locator and search in code is also unaware that it is possible to search with middle-point letters. May be someone can point out other code-editor and code-completion features missed from line-edit-boxes all over QtC UI. So I am not clear why this whole situation is not important (P3 for bug 3111). It seems that if to subclass once from QLineEdit and add features we have in code-editor this can benefit ALL edit-boxes of QtC. I welcome everyone share thoughts about look and feel of QtC line-edit-boxes of is vs to code-editor look and feel. ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
