Difference between revisions of "CDT/Build/Doug"

Revision as of 09:50, 29 July 2015

Design

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 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.