Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] New Build System and cdt.core

The APIs are small on purpose and this forces my hand that way. I think provisional APIs are OK for things you're not sure about, but we've been doing build systems for many years now and I think we're pretty confident knowing what we need.

And, besides, with default methods I can add new methods to interfaces pretty easily, or I can use adapters if I'm adding new concepts. I don't expect to remove anything, if I do, it's a hint it shouldn't be there to begin with.

As an example, I currently ask toolchains if they support a ILaunchTarget. Since I plan on adding ILaunchTarget to the platform later, thus changing the package name, maybe it makes more sense to make an adapter for that and implement it at a higher level plugin that we can swap out later.

Just need to be smart about it.

On Fri, Apr 1, 2016 at 10:38 AM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
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

Hey gang,

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* 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 ;).

Thanks, Doug

cdt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top