|
I think the complexity comes most from the per resource settings, which are pretty magic to keep things in scale.
The actual model you see in the plugin.xml is mainly the build model I started with (IToolChain, ITool, IOption, etc). And it served the purpose of generating Makefiles. It’s not too bad. It’s morphed a little as things were tacked on to handle edge cases,
like dynamic enum values and such. The big problem, though, is that it was built around the extension point. At the end of the day, I don’t think that is an effective way of describing complex toolchains. We should really start with a Java API, let it be fully
dynamic, and use the plug-in.xml and potentially other sources to populate the model.
And, yes, we probably do want to keep compatibility, but I’d to that through a conversion. There’s already the mechanism in place to do that.
Doug.
Hi Doug,
I agree with pretty much all of what you said. I think it's important to keep the ability to change all the build settings from the UI so that the user does not have to write build files, just like you mentioned in the last point. For people who don't know,
it's currently possible to have a project that generates Makefiles for you based on the build settings changed in the UI and the build is executed externally using make. I think the idea of generating files and delegating to an external builder is good enough
so that we don't need an internal builder. I have to admit that I'm not an expert of the current MBS/CDT 4.0 build system but I'm not sure how much of the complexity come from the fact that there is an internal builder or the fact that there are "managed"
build settings. Most of the things you specify in plugin.xml are about build settings which are needed regardless of whether the build is done internally of generating Makefiles (correct me if I'm wrong!). Ideally, all the builders and compilers would have
nice APIs that would describe options, build setups, tools, etc but I don't know how close we are to that (Boost.build API?).
>From my perspective, I am going through old code and removing very old things (starting with the UI) and slowly getting a better understanding. One concern that I had was about workspace backward compatibility. Do we want to support importing old (pre MBS/CDT
4.0) projects? I think we'd probably want to still support importing MBS/CDT 4.0 projects.
Marc-Andre
On 2015-03-16 11:09 AM, Doug Schaefer wrote:
Hey gang,
Another thing we discussed at EclipseCon and there seems to be at least a little momentum behind it is a redo of the build system. It’s gone a long way in probably the wrong direction since I started with the build model 10 years ago or so. But we continue
to struggle without someone maintaining it on a regular basis. We really need to simplify it so we can at least jump in quickly and fix anything that goes wrong there.
I think we’re a lock that the June 2016 release will be a major CDT release, 9.0, which gives us a great opportunity to get this done. I just want to make sure we do it as a community and not repeat the mistakes of the past. I’ll set up a wiki where we
can capture ideas, but we should really start by agreeing on a number of requirements.
To that end, here’s my quick thoughts on where I’d like to see us go:
- Make it easy to support alternative build systems like Autotools, CMake, Qt’s qmake, Boost.Build, etc.
- Make sure we can get what we need for the parsers out of any build system.
- Make sure we support external builds. You shouldn’t need to start up Eclipse to build.
- And that means removing the internal builder (sad, I dreamed of that but it’s too much of a burden now)
- Support Visual Studio/Xcode style build settings. Not ever user knows how to write build files.
The big one is the internal builder. Much of the build model was created to support it. If we remove it as a requirement, we can probably simplify a lot of things. But it does mean we need an external build system to be present on the users machine which
will be a challenge on Windows.
And I’m sure there’s more. I’d love to hear from you and what you think we should do.
Thanks,
Doug
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
