Difference between revisions of "CDT/Build/Doug"

Revision as of 21:47, 28 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
  • target os/arch so we can tell whether the build configurations supports a given IRemoteConnection for the Launch Bar.
  • Toolchains can be defined in extension, or in toolchain files (local or shared a la .launch files).
• 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.