|
|
| (2 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | This page captures ideas for CDT's Next Generation Build system. Current target for this is CDT 8.0.
| + | '''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. |
| | | | |
| − | (Note this is a new page, previous ideas [[CDT/BuildModel61|are recorded here]])
| + | 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. |
| | | | |
| − | === Objectives ===
| + | 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. |
| − | | + | |
| − | As I stated in [http://cdtdoug.blogspot.com/2010/02/understanding-cc-build-systems.html 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.<br>
| + | |
| − | | + | |
| − | === UI ===
| + | |
| − | | + | |
| − | Put Configurations into the project tree. And/or Make Targets too.
| + | |
| − | | + | |
| − | === Current Issues ===
| + | |
| − | | + | |
| − | Things that still need to be worked out.
| + | |
| − | | + | |
| − | What of configurations? One idea was to allow each configuration to use a different build system.
| + | |
| − | *The Eclipse Builder mechanism doesn't really allow for that which is why we did it ourselves
| + | |
| − | *Are configurations a managed make concept only? Use Make Targets or something similar for external builder.
| + | |
| − | *I was having issues with multiple managed build systems and how to deal with overlapping build files anyway.
| + | |
| − | *Or do configurations make us go down this path with a CDT builder which is a composite builder.
| + | |
| − | | + | |
| − | One of the main cases for multiple build systems was to support remote builds. Where do remote builds fit into this scenario? Internal, External, Remote? Where remote does a file sync first, or something???
| + | |
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.
