[
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