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.
Difference between revisions of "CDT/NextGenBuild"
| Line 1: | Line 1: | ||
| + | '''Old Notes''' | ||
Welcome to attempt number 2 of a rework of the CDT build system. The first attempt was over ambitious. This time, the focus is explicitly on external builders, including external managed build systems such as autoconf, qmake, cmake, etc. The existing CDT managed build will be left alone, for now, but we'll investigate a path where this work could evolve into that space. | Welcome to attempt number 2 of a rework of the CDT build system. The first attempt was over ambitious. This time, the focus is explicitly on external builders, including external managed build systems such as autoconf, qmake, cmake, etc. The existing CDT managed build will be left alone, for now, but we'll investigate a path where this work could evolve into that space. | ||
Latest revision as of 20:45, 26 December 2015
Old Notes Welcome to attempt number 2 of a rework of the CDT build system. The first attempt was over ambitious. This time, the focus is explicitly on external builders, including external managed build systems such as autoconf, qmake, cmake, etc. The existing CDT managed build will be left alone, for now, but we'll investigate a path where this work could evolve into that space.
Looking back at the old standard make, it was pretty simple. The user provides their own build files and tells the CDT what external command to execute when Eclipse asks for a build. The output of that command is parsed with the error parsers to produce markers. Later we added scanner discovery, another parse pass of the build output discovered the options passed to the compiler. This was used to figure out the built-in paths and symbols as well as the ones the user specified for the project.
The next step in standard make's evolution needed to be to add a few managed build concepts to make it smarter. In particular, tool chain information was needed to help set up the build environment, set up the error parsers, and set up scanner discovery for the specifics of that tool chain.