| Re: [cdt-dev] CDT build config references versus Platform project references |
|
Thanks, John. That's great information. Our challenge has always been to push our square peg into the round hole we've inherited. I see there's still more work to be done there.
BTW, the way I describe it, all projects have build configurations. It's just that the vast majority only have one. And I do believe that if other project types had build configs, you'd see more of them with more than one. But we're almost too late in
the game to fix this without making things worse.
I'm going to prototype my active project idea and see if the workflows are better.
BTW, I also like the manage build configs dialog in VS. That's something else I'd like to see in CDT. VS just seems to have gotten this right, IMHO.
Doug.
From: Cortell John-RAT042 <RAT042@xxxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx> Date: Tuesday, 7 August, 2012 9:28 AM To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx> Subject: Re: [cdt-dev] CDT build config references versus Platform project references The work James did will allow the build configurations in a CDT project to be visible at the platform level. That opens up all sorts of possibilities. E.g., at Freescale, we've
been wanting to implement a clean-on-import feature. I.e., when you import an existing project (platform feature), you want the project cleaned. Problem with implementing that today is there's no way to get the project fully cleaned--you could only clean one
build configuration. Because of James' work, the platform now has the concept of a build configuration. Problem, though, is that CDT's configurations are still a CDT-ism. So, even if you enhance the platform's import feature to clean all build configurations,
it's not going to have any affect on CDT projects. Until we make CDT's build configurations be platform ones, James work has no actual benefit for CDT--at least none that I can see.
Now, the platform's Project References properties page is something that was not enhanced with James' work. That still only allows relationships at the project level. And of course, that has never been adequate for CDT, so that's why CDT has had its own Project References UI. Ideally, the platform's page should be enhanced to support build-configuration relationships, but that's not trivial. For one, it has to be done conditionally, since the concept of build-configurations are not relevant to most project types (in fact, I wonder if any projects other than CDT has it). So, James' platform contribution was a critical first step in addressing current limitations caused by CDT's build configurations being a CDT-ism. However, more work is needed. I still plan on bringing in the additional work James took but didn't commit to the CDT repo: making CDT's build configs accessible as platform ones. I've been sidetracked, but its still on my radar. John From:
cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Doug Schaefer [dschaefer@xxxxxxx]
Sent: Monday, August 06, 2012 9:26 PM To: CDT General developers list. Subject: Re: [cdt-dev] CDT build config references versus Platform project references Hmm, I thought the work James did with the platform would make this work better. Maybe not.
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.
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. 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. That way we should be able ensure we build only that config.
We kinda went part way there with the current build/manage config buttons.
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.
Thoughts?
Doug.
From: Cortell John-RAT042 <RAT042@xxxxxxxxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx> Date: Monday, 6 August, 2012 8:32 AM To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx> Subject: Re: [cdt-dev] CDT build config references versus Platform project references Doug,
To my knowledge, the Platform's project references page does nothing for CDT projects and can only serve to confuse the user. I recently opened a bugzilla against the platform as there is no clean way for products (plural) to suppress the platform's properties page: https://bugs.eclipse.org/bugs/show_bug.cgi?id=385431 We avoid it in CodeWarrior with a hack. We're hoping the platform will eventually give us a proper way to do it. John From:cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx]
on behalf of Doug Schaefer [dschaefer@xxxxxxx]
Sent: Thursday, August 02, 2012 11:08 PM To: CDT General developers list. Subject: [cdt-dev] CDT build config references versus Platform project references Hey gang,
Playing with some real world projects, I was trying to set up build configs for a group of projects. Each project could have up to 8 build configs. There's a executable project and about 5 library projects and I'm trying to set up the dependencies between
the executable and the libraries for configs of the same names. Now when you switch configs, it's actually pretty difficult to ensure that the configs are set the same for all projects. Luckily the CDT builders follows the config dependencies and ensures that
the dependent projects are build properly. However, the Platform project references will also trigger a build of potentially the wrong config, or build a project a second time, which is a waste of time.
So the question I have, do we really need to set the platform project reference when we create a build config dependency in the Paths and Symbols -> References tab?
The downside is Build All which may build things out of order, but then again, the CDT builder will redo the project builds as needed. Or is there a better way to do this?
Have we had this conversation before?
Thanks,
Doug.
|