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

CDT/NextGenBuild

< CDT
Revision as of 16:59, 22 February 2010 by Cdtdoug.gmail.com (Talk | contribs)

This page captures ideas for CDT's Next Generation Build system. Current target for this is CDT 8.0.

(Note this is a new page, previous ideas are recorded here)

Objectives

As I stated in my blog here, the main objective of the next generation CDT build system is to provide some level of unification to the different variants of CDT. Historically, it has been a struggle to come up with a build system that everyone would be happy with. As a result most major commercial products based on the CDT have their own build systems and hide CDT's. We need to break some assumptions and see what we can come up with to hopefully resolve this, or at the very least, provide a much more extensible build system.

Breaking Assumptions

Assumption #1 is that builds are either managed or unmanaged. Or more importantly, that there is only one way to manage a build and that's using CDT's managed build system. Autotools, CMake, and qmake, are great examples of managed build systems. They generate Makefiles just as CDT's managed build systems does. It makes sense to support these as first class citizens. Jeff and the Red Hat guys have done a great job with autotools, but it could be a lot cleaner if the CDT build systems was more extensible in that direction.

Assumption #2 is that the managed build system is one thing. It is in fact three things: a build model, a Makefile generator, and an internal builder. The Makefile generator uses an external builder to do the make. This external builder should be sharable with the other managed make systems. The Makefile generator and the internal builder use the build model. Again, the build model should be sharable as well.

Assumption #3 is that Scanner Discovery is one thing. It is two things: a build output parser, and a compiler built-ins calculator. Both of these things feed into the IScannerInfo interface. The external builder needs the build output parser to detect compiler settings. The compiler built-ins calculator should be part of the build model, where the appropriate implementation of the calculation is given by the tool definition. In fact, the build output parser should set the compiler options and the tool should provide the scanner info based on that.

Back to the top