Yes. I realize that. As I push forward with the new build system, which I now having running for the CDT Qt plug-ins and qmake, I really need to see the CMake support in the CDT so I can help with it. The qmake support is setting the direction. CMake shouldn’t
be too difficult and will be a good test to how I’ve hooked up the Toolchain classes which handle the scanner info provider, error parsers, etc. I think it’s ready to start. Feel free to look at the QtBuildConfiguration and friends to see how it’s done.
Doug.
Hi Martin, Hi Doug,
Seems like we have multiple projects in parallel aiming to provide CMake integration into CDT. Here is a link to my one (I would write 'the other one', but I'not sure if there are only two... )
https://github.com/rungemar/cmake4cdt
much discussion was done here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=350206
I really would like to bundle forces to proceed faster or reach more completion. I plan to continue working on it the next weeks to have something we can use internally before starting to adopt to the new build model. Unfortunately,
I still spend much of my time figuring out the internals of Eclipse and CDT and how to hook into them (like switching built-in settings scanner and error parsers depending on the CMake generator settings ).
cheers
Martin
Von: Doug Schaefer <dschaefer@xxxxxxx>
An: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
Datum: 2015-11-29 18:29
Betreff: Re: [cdt-dev] CMake support in Eclipse CDT
Gesendet von: cdt-dev-bounces@xxxxxxxxxxx
On 2015-11-27, 4:28 PM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of Martin
Weber" <cdt-dev-bounces@xxxxxxxxxxx on behalf of
fifteenknots505@xxxxxxxxx> wrote:
>Am Freitag, 27. November 2015, 19:56:35 schrieb Doug Schaefer:
>> Cool, thanks Martin. We have to be careful looking at it with copyrights
>> and stuff, unless you donate it.
>
>It is already under EPL, and since I did it for myself for use at work,
>no
>problems to donate it.
>But at the current time, please consider my plugin being a user
>experience
>study. It is still tied too much to the CDT managed build API and as such
>has
>a confusing UI.
We will still need an IP review when we bring it in. It’s not a licensing
issue but a copyright one. But we’ll worry about that when we get there.
>
>>
>> In the end though, I want to build CMake support on top of the new build
>> system which should eliminate the problems you mention, and possibly
>> introduce new ones. I¹m well into the Qt qmake support and it¹s turning
>> out really well.
>
>IMHO, IDEs should concentrate on the developers by providing code
>completion/Goto declaration/etc stuff. From my experience with CI and as
>a
>programmer, I would always prefer to have some kind of build script: IDEs
>come and go, scripts last longer.
>Concerning CDT, I wish CDT would concentrate more on its scanner/indexer
>qualities and provide an API that allows to build tool integrators to
>feed
>the indexer with include paths and #defines from a build-script generator
>or
>build-output parser.
>CDT should *not* concentrate on build-script generation, there should be
>an
>extra project on eclipse.org that only cares about that -- at least for
>languages, that need extra buildscript generation step. (Remember, cmake
>is
>not focused on the C/C++ language, it can be used for fortran, java, and
>other languages.)
I think that’s the direction we’re heading. That’s why I consider the new
build system a “no” build system. It provides a simpler mechanism to
integrate other systems that do the build while getting the information we
need for the parsers, error markers, etc.
I think we have a really good focus on our index and the whole source
discovery system. Nathan and Sergey are doing a great job there.
Integrating an external index would be a lot of work. If someone wants to
do that, I’m all for it. In the meantime what we have is pretty good.
>
>
>>
>> The one thing I haven¹t thought of is a CMakeLists.txt editor. We have
>
>I use <http://cmakeed.sourceforge.net/eclipse/>. It provides syntax
>highlighting and code completion (for cmake 2.8.x), but forgets undo
>history,
>if you save the file.
Ah, yes. I’ll take a look at that.
Thanks!
Doug
>
>Cheers,
> Martin
>
>> >
>> >[1] https://marketplace.eclipse.org/content/cmake4eclipse
>> >[2] https://github.com/15knots/cmake4eclipse
>> >[3] https://github.com/15knots/cmake4eclipse/tree/cmake_builder
>>
>> _______________________________________________
>> 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
>
>--
>Cd wrttn wtht vwls s mch trsr.
>
>
>_______________________________________________
>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
_______________________________________________
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
|