|Re: [cdt-dev] New Build System and cdt.core|
Sounds ok to me.
However, I am a little concerned about the new APIs introduced in cdt.core.
The new build system is under development and you will need to play around
and modify those APIs. Having them in their own plugin seemed safer.
Putting then in cdt.core will lock them up. This will make your life more difficult
and runs the risk of being forced to keep dead APIs in the future.
Maybe an internal package within cdt.core until things stabalize?
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Doug Schaefer [cdtdoug@xxxxxxxxx]
Sent: March 31, 2016 4:43 PM
To: CDT General developers list.
Subject: [cdt-dev] New Build System and cdt.core
As I work to integrate the new build system with existing systems in cdt.core, in particular the env var manager, scanner info provider, console with marker generation, etc., I find I'm migrating things back to cdt.core.
As a result, I'd like to complete that and remove my cdt.build.* plug-ins. It does mean adding a dependency from cdt.core to launchbar.core so I can get at ILaunchTarget which helps select toolchains to use with a build configuration. GIven I think you all have gotten used to dealing with that, it should be OK. Again, everything should be dormant unless you're using one of the new instantiations of the new build system, or I'll fix that.
As a historical note, with ACBuilder being in cdt.core, it reminds us that that's where build was originally, and IMHO, it's the proper home for it, or at least for the fundamental framework behind it. (also note the copyright date, it predates the open source launch of CDT ;).
Back to the top