[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] CDT build config references versus Platform project references
|
Hi All,
On Tuesday, 7 August 2012, Doug Schaefer wrote:
Hmm, I thought the work James did with the platform would make this work better. Maybe not.
There's currently no shared UI code or this. It was thought that integrations would provide their own - and CDT being the only public integration meant the platform were happier to wait-and-see. That said, it wouldn't be hard...
I'm trying to figure out the best approach. I just get the feeling Build All builds too much, and Build Project builds doesn't build enough. And both have the opportunity to build multiple configs per projects instead of the one you care about.
Build configurations and config level references solve precisely this issue. It should result in just enough, and not too much being build.
What's starting to come to mind is an idea I first saw in Visual Studio, the idea of an Active Project (or StartUp project as it seems to be called now) and and Active Build Config. We could then add a Build Active Project command that would build that
project independent of the selection.
Yep, this is really useful! I have patches that perform this identical job (I think):
Basically it adds a build history to the build hammer. Much like the launch config, clicking the hammer then builds the last built configuration (and requirements).
We found this is how users work. While they work they build a particular configuration again and again and only switch between configs infrequently.
The other side of that is the Active Config, which would then set the active configs for all projects the Active project depends on based on the CDT's References.
This doesn't work as you can reference more than one config in another project. You can also have the application configuration in a project reference a library config in the same project.
The other thing bugging me is clean. I usually only want to clean a single project so I can kick it to rebuild. Yet the platform cleans that project and all the projects it depends on. In Java and other languages, maybe that's what you want to do. But
in C/C++ where projects are usually less coupled than that, you don't really want that. At least I don't think so.
Certainly I've flip-flopped on how much cleaning should happen. I don't think there's anything fundamental stopping this from working how you want (other than UI...).
Cheers,
James
