Eclipse CDT Launching and Toolchains

I’m working on adding debugging for CDT’s upgraded Qt projects support. Looking at the legacy CDT launch delegates, I’m having a hard time figuring out how to reuse the parts that I need. I’m not sure the old delegates have the structure we need to support the automated workflows we’re trying to do going forward.

Of course, this is driven by the work we’ve done with the Launch Bar. UI look and feel aside, people love the workflows it enables. You select the thing you want to launch, where you want to launch it and a mode for the launch and you hit play and it goes off and builds the thing and launches it without any additional interaction. Of course you can customize things but you don’t really have to if you just want to keep things simple.

I guess the problem we have next is implementing that. We’re essentially using launch configuration delegates for all this. I’ve added a sub-interface that adds the launch target, i.e. where you want to launch, to the methods of the delegates. And really, the buildForLaunch and launch methods are the only ones you really should be extending. The pre and final launch checks don’t have the ILaunch so I’m not sure how they’re supposed to check anything other than the configuration is valid.

The issue I run into next is that for a launch mode like Debug, I need to know what debugger makes sense for the given launch. Unfortunately in CDT, we’ve pretty much hard coded gdb everywhere so it’s hard to tell it to use a different debugger. But for Qt, I want to eventually support the Windows debugger cdb as well as lldb where available. What’s the best mechanism to do that without creating delegates for them which, trust me, if you have multiple delegates per config type and mode, you’re in for a world of UX hurt.

One thing I keep coming to as I look at renewing how we build and launch in CDT is that these two things are intrinsically tied. For whatever reason, we’ve tried to separate them but workflows are so much better if they know about each other. Builds produce the symbol files that the debugger needs at launch time. And usually the format of those symbol files tell you what debugger you can use. And for most SDKs out there, you get a debugger along with your compilers and linkers anyway.

I really thing the debugger needs to be a part of CDT’s concept of toolchain. The new CDT build system asks the build configuration, which knows what toolchain is being used, to do the build. We should just ask it to do launches too. Now that’s just a crazy idea.

Of course, I’m doing a brain dump here as I think about it. I may change my mind especially as I try and implement this. I’d sure like to hear other peoples thoughts and what other CDT extenders do. Most vendors who do extend CDT don’t usually use CDT’s launch configurations. I can see why since they’re both too flexible and inflexible at the same time. I just wonder if others have thought about this.

One thought on “Eclipse CDT Launching and Toolchains

  1. Leo Treggiari

    I thought about this problem a few months ago for a different IDE. I’m not sure that any IDE in existence today solves the problem very well. What I think is true:
    – Build configurations and launch (run/debug) configurations are related
    – A user should not have to manually create a launch configuration before they run/debug the app, that they just built, for the first time. The user may find that they need to modify the launch configuration, and/or create additional launch configurations later, and should be allowed to do so, but there should be a default which normally “just works”
    – When I was a CDT committer, Java projects had no build configurations (only CDT did) but Java did have launch configurations. And so it may not be surprising that the relationship between the 2 concepts has not been fully worked out.

    As I considered the relationship, I wrote down a few notes re: what information build configurations and launch configurations contain:

    Build Configurations
    A build configuration provides the information required to build a project from sources and produce a specific executable. The executable targets a specific run-time platform (OS version + hardware).
    • There can be multiple build configurations for the same run-time platform – e.g.
    o Debug vs. Release executables
    o Free vs Paid editions of the same ‘app’
    • There can be different build configurations for different run-time platforms – e.g.
    o In mobile app development, iOS vs. Android vs. Windows vs. others
    Build configurations contain the following types of settings:
    • Build tool(s) and/or SDK selection – including specific versions
    • Options which apply to the build tool(s)
    • Source code selection – e.g. particular directories/files are used/ignored by a particular build configuration
    • Dependencies (e.g. libraries) – including specific versions
    • Run-time platform “manifest” settings

    Launch Configurations
    A launch configuration provides the information required to start running/debugging an executable / app package
    • There must be at least one launch configuration (or the necessary settings retrieved from somewhere…) per build configuration.
    • A launch configuration could be used by multiple build configurations, if the build configuration is the source of the path to the executable. Given that a launch configuration is also needed for an executable created ‘elsewhere’ (i.e. it was built outside of the IDE and there is no build configuration), both the build configuration and launch configuration probably contain the path to the executable.
    Launch configurations contain the following types of settings:
    • Debugger selection
    • Options for debugger – e.g. break at entry point
    • Executable and command line arguments
    • Connection information for remote devices
    • Launch environment (e.g. environment variables, working directory)

    The executable file / app package and information regarding what ‘platform’s it can run one may be in both the a build configuration and a launch configuration. Otherwise, the information is probably disjoint.

    A launch configuration is used to run the ‘app’, but in an IDE we want to check to see if the ‘app’ is up-to-date before we start running it. The build configuration is responsible for that and so the launch configuration should have a pointer to the build configuration – if one is available.

    In order for there to be a reasonable, default, launch configuration associated with every build configuration, whatever component created the build configuration should probably also create the initial default launch configuration. In CDT it makes sense for the tool-chain provider to be involved in this.

    But it is actually a little more complicated than this, because the ‘app’ created by a build configuration may be able to run on multiple ‘devices’ and there may be launch configuration settings which are device specific. So a build configuration should be able to create a default launch configuration for any supported ‘device’, as needed. Again, the tool-chain probably needs to be involved in creating these default launch configurations.

    I hope this helps.

Leave a Reply