Community
Participate
Working Groups
For CDT 8 we will configure the platform build configurations (to match CDT build configurations) and use the delta from them to optimise multi-configuration managed build.
Created attachment 196920 [details] wip 1 This is first cut patch extracted from our build and rebased against today's HEAD. I've smoke tested it - it compiles and uses Platform build configurations and seems to build simple projects with references. It does a number of important things: - Update CDT to allow references to multiple configurations (Bug 317229) (cdt's RefsTab isn't updated to use the new API). - BuildConfigReconciler creates platform build configurations from the CDT Build Configurations - CommonBuilder no longer builds references - the platform orchestrates this. I'm sure this patch will rot pretty quickly, so the following repos contain the in context: https://github.com/jamesblackburn/cdt-core https://github.com/jamesblackburn/cdt-ui https://github.com/jamesblackburn/cdt-mbs-core https://github.com/jamesblackburn/cdt-mbs-ui
I will likely take this on after Juno
Most excellent. Thanks John! :)
Heads up. I've started working on this (again, for post-Juno), and James' solution technically breaks API compatibility, meaning we're looking at CDT 9.0 for next June if we use it as-is. The breaks I've seen so far are probably benign in practice. E.g., public interface ICConfigurationDescription is given some new methods. This is an interface clients aren't supposed to extend or implement, and clients probably aren't doing so. Unfortunately, it was never marked with @noextend and @noimplement. James solution adds those annotations, but of course, that in and of itself is considered an API breaking change. Naturally, there's probably a way to do this without breaking API--it'll just end up being a lot uglier and client-unfriendly. Does anyone foresee other changes that will require a major version bump in June 2013?
I would be in favor of marking ICConfigurationDescription with @noextend and @noimplement and bumping major version. If we begin using the new platform API introducing platform build configuration that is by itself may warrant bumping. It is likely it could change behavior of core/build CDT APIs related to configurations.
I don't see that a version upgrade is necessary over this, as iirc I don't think it's possible to extend that interface. So really it's jus documentation, not breakage (and an API filter will suffice). Do let me know of any issues / if I can help in anyway.
(In reply to comment #6) > I don't see that a version upgrade is necessary over this, as iirc I don't > think it's possible to extend that interface. So really it's jus documentation, > not breakage (and an API filter will suffice). I suggested exactly that (see parallel email thread on cdt-list), but so far it's gotten a luke warm response. It comes down to how much confidence we can claim that the interface hasn't been extended or implemented by a client. You say it's not possible, but do you truly mean that or do you mean it's very unlikely? Big difference. > Do let me know of any issues / if I can help in anyway. Thanks. I may have questions for you at some point.
I agree with James on this (great to hear from you James!). Someone would have to be crazy to implement or extend ICConfigurationDescription. I think an API filter would be fine.
(In reply to comment #8) > I agree with James on this (great to hear from you James!). Someone would have > to be crazy to implement or extend ICConfigurationDescription. I think an API > filter would be fine. My day is getting better.
Another example of API breakage the solution calls for silencing: protected field ChangeConfigAction.fProjects has been removed. I think the assumption here is that the field's protected qualification was inadvertent and unnecessary, and that clients have not taken advantage of it. I'll put together a complete list of these things at the end of my merge. Just wanted to give another example of the sort of things the solution will call for silencing.
(In reply to comment #10) I agree with James and Doug and don't think that ChangeConfigAction.fProjects changes the situation.
This bug was assigned and targeted at a now released milestone (or Future or Next that isn't being used by CDT). As that milestone has now passed, the milestone field has been cleared. If this bug has been fixed, please set the milestone to the version it was fixed in and mark the bug as resolved.
