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/NewBuild/Standard"

< CDT
Line 12: Line 12:
  
 
One of the build targets can be pinned as the source of scanner info for a file in a project and/or the default action when the build project command is issued.
 
One of the build targets can be pinned as the source of scanner info for a file in a project and/or the default action when the build project command is issued.
 +
 +
=== Launch Support ===
  
 
How do we support Standard Builds with the Launch Bar? It's not easy. Projects that use such freeform build systems do not allow for a reproducible pattern that we can use to derive the binary for a given Launch. And most such projects have multiple unrelated binaries. Here are some options:
 
How do we support Standard Builds with the Launch Bar? It's not easy. Projects that use such freeform build systems do not allow for a reproducible pattern that we can use to derive the binary for a given Launch. And most such projects have multiple unrelated binaries. Here are some options:
  
 
- Use the existing paradigm of per binary launch configurations. Need to specify a Build Target for a given launch config. That gives us a toolchain that we can use to select Launch Targets that the toolchain supports. Problem, though is that we can't create the launch config until a build is done. But having said that, we do know what the last Build Target was before creating the executable and we can use that as a default.
 
- Use the existing paradigm of per binary launch configurations. Need to specify a Build Target for a given launch config. That gives us a toolchain that we can use to select Launch Targets that the toolchain supports. Problem, though is that we can't create the launch config until a build is done. But having said that, we do know what the last Build Target was before creating the executable and we can use that as a default.
 +
 +
=== Build Output Parsing ===
 +
 +
Build output parsing has long been a mainstay for CDT. It scans build output in an attempt to understand the compile command for a given file and derive options that affect parsing. We would need to continue to follow this strategy for the freeform Standard builds.
 +
 +
We can continue to follow that strategy by scanning every build and asking the selected toolchain to interpret them and store the appropriate options for the given file being compiled.
 +
 +
There are some systems that allow for a "dry run" of the build which we could use to quickly gather this information at index time. We should be able to designate a build target that fills that role for a given project, folder or file.

Revision as of 12:42, 28 June 2016

Standard Builds with the New Build System

The New Build system provides uber flexibility by pruning down the build model to it's bare essentials required for the CDT features to work. One of the key focuses of the framework is to provide scanner info so that the CDT's parsers can properly parse the code when populating the index, providing content assist, semantic and syntactic colouring, etc.

Since it's simpler, we should be able to do a pretty good job of Standard build. It was a huge mistake to move standard build on top of the massive managed build framework. But it did teach us one thing. In order to enable CDT features when working with Standard Build, you need to know the ToolChain. Without it, scanner info is a big guess. With it, we can do a pretty good job of figure it all out.

The other important feature of Standard build that we too often forget about is the Make Targets feature. It facilitates running a build command with a set of arguments in a given directory of the project. This is very typical of how developers work when on the command line with large projects. Such projects often implement a recursive make system that lets them build at any point of the directory structure and do a scoped build.

One of the big issues with the current Make Targets View is that it's pretty hidden. It also replicates the directory hierarchy in the Project Explorer. You end up having to navigate two trees to get the job done. I guess this made sense at the time as the Make Targets view predates using the Common Navigator for the projects view. In theory we should be able to merge the two adding virtual nodes to the project hierarchy and menu items to create, delete, edit, and invoke Build Targets. (The other problem is assuming it only does Make Targets when they can run any command).

To integrate with scanner info, build targets need to have an associated toolchain. A default toolchain can be set at the project and preference levels.

One of the build targets can be pinned as the source of scanner info for a file in a project and/or the default action when the build project command is issued.

Launch Support

How do we support Standard Builds with the Launch Bar? It's not easy. Projects that use such freeform build systems do not allow for a reproducible pattern that we can use to derive the binary for a given Launch. And most such projects have multiple unrelated binaries. Here are some options:

- Use the existing paradigm of per binary launch configurations. Need to specify a Build Target for a given launch config. That gives us a toolchain that we can use to select Launch Targets that the toolchain supports. Problem, though is that we can't create the launch config until a build is done. But having said that, we do know what the last Build Target was before creating the executable and we can use that as a default.

Build Output Parsing

Build output parsing has long been a mainstay for CDT. It scans build output in an attempt to understand the compile command for a given file and derive options that affect parsing. We would need to continue to follow this strategy for the freeform Standard builds.

We can continue to follow that strategy by scanning every build and asking the selected toolchain to interpret them and store the appropriate options for the given file being compiled.

There are some systems that allow for a "dry run" of the build which we could use to quickly gather this information at index time. We should be able to designate a build target that fills that role for a given project, folder or file.

Back to the top