Difference between revisions of "CDT/NextGenBuild"

Revision as of 07:45, 23 February 2010

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 our current 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, and of course, the standard build. 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 used by CDT's parsers. 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.

Architecture Thoughts

Separate out makefile generation into it's own IncrementalProjectBuilder. Do the same for the external and the internal builders. The new project wizard sets up the list of builders for the given project type.

Have build output parser update the build model for a project. That means standard build uses the build model too and properly uses the "tool chain" setting. In fact, the build output parser can ask the tool chain to help scan build output.

ScannerInfoProvider gets scanner info from the build model, independent of the build system being used.

Error parsing managed through build model. We already do this for managed build, but make this more formal for all builds.