Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "CDT/Build/Doug"

< CDT
(Minimal project)
m (Design)
Line 1: Line 1:
== Design ==
+
== Overview ==
 
Here's my current thoughts on a new build model.
 
Here's my current thoughts on a new build model.
 
* Use org.eclipse.core.resources IBuildConfiguration to model build configs
 
* Use org.eclipse.core.resources IBuildConfiguration to model build configs

Revision as of 22:29, 2 August 2015

Overview

Here's my current thoughts on a new build model.

  • Use org.eclipse.core.resources IBuildConfiguration to model build configs
    • Allows for config specific references and references to configs for finer grain build dependencies.
  • Build configurations are bags of attributes
    • Adapt from IBuildConfiguration to ICBuildConfiguration which implements the bag
    • Bag stored per configuration as project properties (i.e. in .settings).
  • Builders implemented as real IncrementalProjectBuilders
    • Attribute in ICBuildConfiguration to know whether a given builder is enabled for a given config.
      • Allows for different builders to work on the same project, e.g. CMake and Xcode builders
    • Project Property page for editing builder settings that are stored in the attribute bag.
    • Builders can have a role in scanner discovery.
      • They know the include paths and macros used to generate the makefiles and some have the ability to report what they are.
  • Build configurations also have Toolchain
    • Contributes to build environment vars, e.g. PATH to find the tools to execute and other necessary env vars.
    • Scanner Discovery settings to find built-ins and parse build output
    • Error parsers to create error markers for compile and link errors
    • Binary parser to detect whether files are binaries and can be launched
    • Toolchains can be defined in extension, or in toolchain files (local or shared a la .launch files).
  • Relationship with Launch Configurations
    • One of the key tenants of the Launch Bar is that we should be able to determine what tools to use to build for and launch a given launch configuration.
    • Toolchains define a target os/arch for this purpose
    • Toolchains also include all tools needed for a given launch config, including debuggers, code coverage tools, and other run-time analysis tools.
    • As such, a given launch configuration (and launch mode?) map to a given build configuration.
  • Anticipated Builders
    • CMake
    • qmake
    • autotools
    • plain make, or whatever build command the user wants
    • Arduino builder that generates makefiles based on Arduino SDK metadata
    • CDT generated makefiles (backwards compat, deprecated?)
    • CDT internal (backwards compat, deprecated?)
  • Backwards compat issues
    • How to map IBuildConfiguration to IConfiguration
      • Use the default IBuildConfiguration that exists already to signal using old configs?
        • Actually, that would let us build the new system without breaking old ones
      • Project conversion?
        • Pretty ugly on startup. Would need to make sure things aren't too broken.
        • Prompt the user to convert?

Notes

Minimal project

Assuming we want to start from scratch (and then add back in the old stuff with a backwards compat layer), I'm trying the Arduino Projects and see if I can make them work. It's a great test bed and that's what it's there for.

Here are issues I've uncovered and things that seem to work

  • Project only contains the C and C++ nature and the Arduino nature which has a project builder.
  • How far can we get without using the ICProjectDescriptor? All that information should be in persistent properties.
  • Ran into a check in the AbstractPage class that disables property pages that inherit from it if the project doesn't have a project descriptor, or any configurations (isCDTPrj()).
  • All other pages worked and the indexer started up.
  • Overriding isCDTPrj to return true if the project has the C nature and adding checks to get rid of NPEs, we come up in a pretty sane state.
  • Except for the Preprocessor Include page. It's organized by configuration. It would have to change to map to core.resources build config, or we need to keep the list of ICConfigurationDescriptors in sync with them.
  • To start, I'll set up a sync so we can have both.
  • IConsoleParser gives us the hook to add build output parsers for error parsing and language settings providers.
    • The abstract build output parsers should probably move to the CDT core, the error parsers are already there.
  • Why do we have our own problem marker framework? Why don't the error parsers directly create the markers?
    • Only advantage I can see is that the framework checks for duplicates, which happens a lot with shared header files.
    • But that could be done with a shared method in the error parser parent class.
  • Why do we have the whole descriptor framework (.cproject)?
    • What's so bad about persistent properties in the IResource framework?
    • You can do hierarchical properties with property key's. Doing that for Arduino's property files.
  • Why does CDT have it's own BuildConsole. Why not use the TextConsole?
    • It gives us pattern matching and hyperlinking for free.
    • Or is it too slow?
  • Language Settings Provider
    • It was a good effort but the complexity of the Language Settings Provider is pretty scary.
      • The layers are pretty deep
    • It really depends on the legacy PathEntry framework and the ICProjectDescriptor framework
    • Can we build something simpler, that doesn't depend on either?
    • As far a I can tell, this is the only dependency left on the project descriptors which we could now get rid of.

Back to the top