2015-01-26 16:13 GMT+10:00 Zoltán Balogh <[email protected]>:
> Hello Alexander, > > Have you tried to upstream your version? > Yes, inital one. But this was discarded because "unneeded" files is displayed in project tree, but it is useful for me. Also I totally have not time to process it and integrate to upstream (like my patch for Perforce plugin, it freezes in gerrit :-) and now I have no access to perforce VCS at all). Also, outside of upstream I can integrate any solutions that looks useful for me. So, I simple sync codebase approximately once a month or two and time to time implement new features. > > On 26.01.2015 04:47, Alexander Drozdov wrote: > > Hi Benjamin, > > You can look into my solution for CMake: > https://github.com/h4tr3d/cmakeprojectmanager2 > > You can look complete patch by making > git diff qtc-master > > Main differences from original CMake plugin: > 1. Display all files in project tree instead of cbp-related ones (cbp > tree and file system tree is merged). It looks like KDevelop work. And it > comform for me > 2. Save build-specific cmake parameters and reuse it on cmake-runs > 3. You can add/remove/rename files/classes from QtC (context menu items > activated). You still need to modify CMakeLists.txt manualy or use globbing. > 4. On the last week I modify CMake Run dialog: selectors to set build > type /Debug, Release, RelWithDebugInfo, MinimalSize/ and selectors to point > toolchain file was added. Also you can write embedded toolchain > description: > http://htrd.su/wiki/_media/zhurnal/2015/01/22/snimok_ehkrana_ot_2015-01-22_12_3a00_3a05.png > This information saves per-cmake runs and per-build configurations. > > > > > > 2015-01-23 20:16 GMT+10:00 Benjamin Zeller <[email protected]> > : > >> Hello all, >> >> its been a while since we last merged the upstream CMake plugin >> into our own Ubuntu-SDK codebase. As a result our current version >> is behind the most recent QtC release. >> Since the last merge there were a lot of things changed in the plugin >> that makes it almost impossible to merge it again, so we decided to >> start from scratch and since we have learned from the last time we >> want to first propose the refactoring steps we are going to work on. >> >> We decided to drop the idea of removing the "Run cmake" dialog but >> still need a possibility to have a cmake per Kit. >> >> So here are the steps, each one would be a self contained patch: >> >> Patch 1: >> -> Add a view to register multiple cmake instances to the system (in >> tools->options->Build&Run->cmake) >> * The user can select a default cmake tool that will be used for >> every build >> * do not add it to the Kit yet to keep the patch small >> * use a view like in the QtVersions settings page (treeview) >> * provide a central registry for all the cmake instances >> (CMakeToolManager) >> >> Patch 2: >> -> Make the cmake instances known to the Kits (CMakeKitInformation) >> * The run cmake dialog will pick up the cmake from the kit >> >> Patch 1 is rather big, but I do not see a way to break it down even >> more, but >> I'm open for suggestions :). >> >> Daniel, can you please tell me if this proposal as the base of our >> implementation >> is acceptable for you? >> >> Regards, >> >> Benjamin >> >> _______________________________________________ >> Qt-creator mailing list >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/qt-creator >> > > > > -- > WBR, Alexander Drozdov > http://htrd.su > > > _______________________________________________ > Qt-creator mailing > [email protected]http://lists.qt-project.org/mailman/listinfo/qt-creator > > > > _______________________________________________ > Qt-creator mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/qt-creator > > -- WBR, Alexander Drozdov http://htrd.su
_______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
