|
As far as including toolchains with CDT, I am working with the Foundation to see how we can get toolchains to install with CDT. I definitely want that for Arduino. I wouldn’t mind seeing something similar for Raspberry Pi. And maybe there’s something we
can do with qemu. We could then have an exemplary environment for these little devices that work out of the box for new users and for our own testing.
I think we can do that with the Eclipse Marketplace at least which allows GPL components. I need to understand where the line is drawn.
BTW, Qt Creator actually ships as a part of Qt which in turn only provides the 32-bit MinGW GNU toolchain (from what I remember). It relies more on cross toolchains being installed elsewhere as well.
I guess in theory, it’s really the responsibility of the platform owners to put these things together. We at QNX do that for our QNX customers. For these open platforms, I’m not sure who those owners would be.
Doug.
On 2015-03-16 01:08 PM, Jesper Eskilson wrote:
On 2015-03-16 16:09, 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.
I think Ninja (http://martine.github.io/ninja/) has a license which allows for bundling it as a binary, and is intended to consume autogenerated build files.
That would be my first choice.
I've used Ninja before in conjunction with CMake and it was really great and fast. So it I interstand correctly, CDT would generate some intermediate output to describe the build dependencies, builds options, etc and Ninja would execute the build? I don't know
how easy it would be to include Ninja binaries into CDT but at least it has an Apache License. Going further, I always thought it would be great to include a fully working toolchain with CDT (Qt Creator, Codeblocks do or did that).
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
|
