On Jan 9, 2014, at 9:50 AM, Yves Bailly <[email protected]> wrote:
> Le 08/01/2014 17:54, Jeandet Alexis a écrit :
>>> From what I understand your problem is that creator works as expected,
>> Or also open your project as kai said in the same sessions you can open
>> all of them separately and also open your top project then just activate
>> the one you want.
>
> But in this case I get two build directories for each subproject (simplified
> paths, add Debug/Release for each):
> - one in /builds/main_project/subproject_NN when building the top-project,
> - one in /builds/subproject_NN when building each of the sub-projects
> ...by default.
>
> Of course I can go through each subproject opened separately and point the
> build directory to the sub-main one. But that is *really* cumbersome...
>
> More specifically, what I would like is:
> - if I ask to build the top-project, all the sub-projects are build
> --> this is the current behaviour, perfect
> - if I ask to build one of the sub-project, only this one is build
> --> this is the current behaviour, perfect
> - if I ask to *run* the top-project, all the sub-projects are build
> --> this is the current behaviour, perfect
> - if I ask to *run* one of the sub-project, only this one should be
> build if necessary
> --> not the current behaviour, all subprojects are build (or checked
> at least)
The point is: We do not know if you want to only compile the sub-project.
Because most of the time this will be wrong, and lead to unexpected behavior of
the application that is run. Because if other subprojects, that the “current”
subproject depends on, have changes, these changes would not be compiled. You’d
need to manually go to all subprojects and explicitly compile them, to make
sure they are up to date when running the application. So, if you automatically
build before run, we ‘make’ your whole product, because it’s the only sane
thing to do.
Br, Eike
> To put this in context, I'm talking here about more than 150 sub-projects:
> opening them one by one is tedious.
> Indeed the "-j" switch helps, but not that much, and it's not relevent
> when using "nmake" (yes I know about "jom", which can't be used sometimes
> for some obscure internal reason).
>
> To avoid the doubled build directory, I found a rather easy way:
> - launch QtCreator, set default build directory to
>
> ../builds/%{CurrentProject:Name}-%{CurrentKit:FileSystemName}-%{CurrentBuild:Name}
> - open and configure the top-project, build it (takes a long time)
> - set default build directory to
>
> ../../builds/topproject-%{CurrentKit:FileSystemName}-%{CurrentBuild:Name}/%{CurrentProject:Name}
> - open and configure each sub-project
>
> At least the bunch of subprojects can be build in one go and don't have to be
> rebuild
> when opening each one :-)
>
> Regards,
>
> --
> /- Yves Bailly - Software developer -\
> \- Sescoi R&D - http://www.sescoi.fr -/
> "The possible is done. The impossible is being done. For miracles,
> thanks to allow a little delay."
> _______________________________________________
> 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, Tuula Haataja
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
