Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CMake support in Eclipse CDT

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


Back to the top