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
m (Origins)
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
'''Standard Builds with the New Build System'''
+
== Standard Builds with the New Build System ==
 +
 
 +
=== Origins ===
 +
 
 +
In the beginning CDT had a pretty simple build system. It just executed a shell command at the root of the project. It was later enhanced with the Make Targets View to be able to set up builds through a multi-directory level project. Large projects are often structured that way to allow developers to work in their parts of the project without having to build the often massive world.
 +
 
 +
We then introduced Managed Build as an optional system to help developers who were used to IDEs managing the builds for them. It generated a set of Makefiles and called a shell command to perform the build. An extensive build model was created to generate a UI for the build settings and to feed the Makefile generator.
 +
 
 +
At that point we had two build systems and they were pretty separate. We had to come up with a name for the original one and settled on "Standard". It's horrible name, but we couldn't think of anything better.
 +
 
 +
In those days, the Managed build system was a client of Standard Build. Then the Managed Build system was greatly enhanced and a decision was made to build the Standard one one top of that turning the world upside down and pretty much forcing all CDT builds to be managed builds.
 +
 
 +
But times have changed and there are external build systems that do a pretty good job of generating Makefiles based on some Domain Specific Language or other modeling technique. We needed the CDT build system to allow integration of those systems without having to make them "managed builds" in the CDT sense since they have their own build models. We just need to call their tools at the right time.
 +
 
 +
Now we have the New Build system for CDT 9.0 that takes a step into the past to bring out some of the good ideas we had back then and go forward, once again where the Managed build system is optional and we can add support for these new external managed build systems easily.
 +
 
 +
=== What's old is new again ===
  
 
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.
 
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.
Line 12: Line 28:
  
 
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.

Latest revision as of 15:39, 28 June 2016

Standard Builds with the New Build System

Origins

In the beginning CDT had a pretty simple build system. It just executed a shell command at the root of the project. It was later enhanced with the Make Targets View to be able to set up builds through a multi-directory level project. Large projects are often structured that way to allow developers to work in their parts of the project without having to build the often massive world.

We then introduced Managed Build as an optional system to help developers who were used to IDEs managing the builds for them. It generated a set of Makefiles and called a shell command to perform the build. An extensive build model was created to generate a UI for the build settings and to feed the Makefile generator.

At that point we had two build systems and they were pretty separate. We had to come up with a name for the original one and settled on "Standard". It's horrible name, but we couldn't think of anything better.

In those days, the Managed build system was a client of Standard Build. Then the Managed Build system was greatly enhanced and a decision was made to build the Standard one one top of that turning the world upside down and pretty much forcing all CDT builds to be managed builds.

But times have changed and there are external build systems that do a pretty good job of generating Makefiles based on some Domain Specific Language or other modeling technique. We needed the CDT build system to allow integration of those systems without having to make them "managed builds" in the CDT sense since they have their own build models. We just need to call their tools at the right time.

Now we have the New Build system for CDT 9.0 that takes a step into the past to bring out some of the good ideas we had back then and go forward, once again where the Managed build system is optional and we can add support for these new external managed build systems easily.

What's old is new again

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