On 14.08.2013, at 12:09, Sven Goericke <[email protected]> wrote:
> On 08/14/2013 11:51 AM, Daniel Teske wrote: >> On Wednesday 14 Aug 2013 11:46:08 Sven Goericke wrote: >>> Hi, >>> while implementing at least the "Add New Folder" option in generic >>> projects (and in turn get an overview how project management works) i >>> got some ideas for improvements: >>> >>> 1. Instead of maintaing a "<project>.files" list with files belonging to >>> the project define a set of file-extensions which should be used in the >>> project. So you no longer need to update the <project>.files outside >>> Creator but it will pickup all needed files on startup. >> No, that's in that way by design. Others have written scripts to easily >> update >> the .files file from their real build system. Since Creator watches that >> file, >> the project tree gets automatically updated. That's not possible with globs >> without watching the directory tree. (Which is impossible to do.) >> > Well, we use a make-target for that: > update_qtcreator_files: > $(verbose)find \ > $(filter-out ./,$(foreach > component,$(component_names),$($(component)_dir))) \ > $(foreach > component,$(component_unittest_names),$($(component)_dir)) > build Makefile version -type f > $(project).files > $(verbose)find . -name '*.[sd]dl' -type f | sed -e 's:\./::g' >> > $(project).files > $(verbose)find \ > $(foreach > component,$(component_names),$($(component)_include_dir)) \ > $(foreach > component,$(component_unittest_names),$($(component)_include_dir)) > -maxdepth 0 > $(project).includes > > It works, but i think it's annoying because you have to call "make > update_qtcreator_files" anywhere outside Creator. If you say there's no > other way i must accept that. But maybe we could add a menu or at least > a shortcut and an option where users can specify an arbitary command as > the "update creator files" command. Meaning one would only need to use a > shortcut to update the files. Tools > External (> Configure …) ? ++ Eike >>> 2. Preprocess-Makros per build-configuration. This should also be >>> possible. Defining them per build-config would at least help to distinct >>> between Debug and Release builds (and get the code-model updated per >>> config). >> How would the .config file look like then? >> > I would need to figure out that. Because the you can use conditional > Macros in the .config file (yes i use that for the different target > platforms i support) maybe one could do something like > > #if defined(QTC_GENERIC_BUILD_CONFIG_NAME) > #... (user defines here > #endif > > and add the QTC_GENERIC_BUILD_CONFIG_NAME to the defines for the > code-model when selecting the configuration in Creator. It's just an > idea, maybe it has to be done in another way. > >>> 3. Get rid of the default "all" and "clean" targets. Even if they are >>> widely used those targets are not a requirement in any generic >>> build-system. Also (as the word "generic" suggests even don't assume >>> that "make" is used as build-command). >> Yes, it should be just a command to run, which by default can be make. >> > Defaulting to make would be Ok (i guess most of Creator users depending > on the generic project manager use it with make)... > Sven > _______________________________________________ > Qt-creator mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/qt-creator -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
