Difference between revisions of "Talk:CDT/Build/Doug"

Latest revision as of 11:22, 31 August 2015

Note that further discussions should happen on https://bugs.eclipse.org/bugs/show_bug.cgi?id=321443

Questions from Sergey:

1. Will the new build model support building multiple binary artifacts per project? Since each GTest is a separate binary, it doesn't make sense to create a separate project for every unit test.

<Doug> Well, the trick is, there is really no build model. Whatever system you're using to build, CMake, qmake, ..., decide those limitations. Having said that, we need to make sure we deal with multiple binaries in other places like the launch bar. How do we decide which binary to use for a given launch.

<Sergey> All *makes support building multiple binaries, don't they?

<Doug> Of course they do, well not sure qmake does, but whatever. They are a reality and we need figure out how to deal with them in the launch bar. Maybe for these cases we don't and let the user set up the launch configs themselves.

2. Have you looked at http://clang.llvm.org/docs/JSONCompilationDatabase.html

<Doug> Nope but I will.

Questions from Marc-Andre:

1. I consider CMake, qmake, autotools, CDT Makefile generator to be "build generators" (build configurators?). Those typically need to be ran once than you execute a build command such as make, ninja, etc. Would it not make sense to have the build generator concept separate from the builders?

<Doug> I thought about that. CMake provides a good example of that. The parameters you pass, like "-G Ninja", decides which build command to run next. And the build generators decide what parameters you can pass to the build command. So I think during a given invocation, they are tied together. Having said that, though, I imagine we'll want to provide a class for error parsing the build output like we do with make, or something like that. We should really walk through the use cases in more detail so we can decide.

2. "Right now the assumption is that there is only one build system per project, i.e. Qt, Arduino, CMake, etc.". That's not quite true I think. In the current model, you can have a configuration using the internal builder and another one with the GNU Make builder, and you can choose the toolchain per config too. This can be changed by the user in the project properties, C/C++ Build, Tool Chain Editor. A new project wizard could do step this up for the user if it wanted to.

<Doug>Cool, more questions! Keep them coming :). I'm actually talking about my new design in the quote. Everything is driven from the Builder and I don't have a mechanism yet for a Builder to ignore a given Config, e.g stop the Qt builder from assuming it owns a given build configuration. Shouldn't be too hard but need to figure out the best and cleanest way. It's just not a priority yet until we get a single build system per project right, which is by far the most common scenario.

3. "Also, the assumption is that Toolchains are independent of the build system. Hopefully that's true. If not we'll have to introduce another adapter layer to adapt Toolchains to build system specific Toolchains.". CMake has toolchain files for defining toolchains, so I see a need for generating toolchains dynamically. I think there are also other examples out there. I remember reading about Visual Studio 2010 having toolchain files as well.

<Doug>Well, you can't generate the scanner info algorithm or error parsers dynamically. You need to know at least what mechanisms are for the given toolchain. You can pick the toolchain dynamically, and you can alter the toolchain configuration, like PATH, dynamically. Everything is programatic and in control of the build configuration. So the CMake build configuration can take a look at the toolchain files and set things up properly.

4. Just a general comment on the page. It's not clear to me what the shortcomings of the current build system are. I think it would be good to identify the shortcomings then specify in what way the new system will solve them. From my perspective, I find it hard to wrap my mind around current system, so I'd like to see its complexity reduced.

<Doug>Well the good news is that I'll have a first cut of the build system in place in a week or so and it'll have build configurations for Arduino and Qt projects. It will be better to judge once you see the code. My main object is simplicity and the ability to totally control the build and it's settings while offering a least a little framework to hook things together. And no more dealing with the crazy IProjectDescriptor and friends and the ridiculously complicated managed build model when all you want is to store where qmake is located for a given config, or what board I'm building for with Arduino.

Question from Walter:

Any thought spent on parallel builds? I.e., e.g. the scanner discovery currently does not really support parallel builds over multiple directories at the same time...

<Doug> Build output parsing relies on the build tool to merge the output from the multiple threads in such a way it keeps the integrity of the command lines being spit out. Not sure how you resolve that other than fix the build tool. We are always looking for ways to figure out the includes and macros used by a build that don't rely on build output parsing. Some build tools, like recent CMake's, offer that. I think the builder needs to be more involved in scanner discovery to leverage that. I'll add that to the proposal.

Notes from Doug:

I'm putting in the Makefile generator for Arduino CDT projects. I'm taking the approach as proposed here. I am implementing an IncrementalProjectBuilder and peeling away the onion. The first thing I run into is that I need the CDT build config for the project. That immediately introduces a dependency on managedbuilder.core plug-in. That brings to mind my proposal to use the core resource build configs to represent configurations. We could then adapt that config to a bag of attributes. Or we could even use the project's persistent properties to store config information.