On 23.03.2015 21:15, Alexander Neundorf wrote:
On Sunday, March 15, 2015 18:00:25 Nils Gladitz wrote:
The build system that CMake generates knows the header dependencies and
decides when which files need rebuilding.
CMake itself doesn't know. How header dependencies are determined and
where and
On Sunday, March 15, 2015 18:00:25 Nils Gladitz wrote:
> On 15.03.2015 16:42, Tobias Hunger wrote:
> > Hi Peter,
> >
> > CMake does know all the headers or it could not decide which files
> > need rebuilding.
>
> The build system that CMake generates knows the header dependencies and
> decides wh
Tobias Hunger wrote:
> This JSON file can be a step forward here: It is actually meant to be
> used by IDEs, it has a format straight forward to parse, it does not
> depend on the generator used, it will (hopefully;-) end up being
> documented, it provides versioning, etc. I see some potential the
On Sun, Mar 15, 2015 at 6:17 PM, Peter Kümmel wrote:
> The idea was that qtcreator then also could parse and change the
> CMakeLists.txt file (like it is done with qbs files, I assume).
That would be a nice to have feature, yes, but I doubt that this will
ever be an option with cmake. And I perso
On 15.03.2015 16:42, Tobias Hunger wrote:
Hi Peter,
CMake does know all the headers or it could not decide which files
need rebuilding.
How would making cmake parse a file in the syntax of another build
system help creator understand existing cmake projects?
The idea was that qtcreator then a
On 15.03.2015 16:42, Tobias Hunger wrote:
Hi Peter,
CMake does know all the headers or it could not decide which files
need rebuilding.
The build system that CMake generates knows the header dependencies and
decides when which files need rebuilding.
CMake itself doesn't know. How header depen
Hi Peter,
CMake does know all the headers or it could not decide which files
need rebuilding.
How would making cmake parse a file in the syntax of another build
system help creator understand existing cmake projects?
This is not about extending cmake language: It makes cmake generate
another des
On Saturday, March 14, 2015 09:40:41 Peter Kümmel wrote:
> On 12.03.2015 16:24, Tobias Hunger wrote:
> > A list of *all* headers used during the building of the target would
> > be fine. There is no need to filter that list down in any way.
> >
> > CMake has that information: Without it cmake coul
On 12.03.2015 16:24, Tobias Hunger wrote:
A list of *all* headers used during the building of the target would
be fine. There is no need to filter that list down in any way.
CMake has that information: Without it cmake could not possibly know
when a cpp file needs rebuilding. It would not be as
On Wed, Mar 11, 2015 at 3:15 PM, Ben Boeckel wrote:
> On Tue, Mar 10, 2015 at 01:25:16 +0100, Aleix Pol wrote:
>> >>"output" :
>> >> "/home/kde-devel/tmp/llvm/build/lib/libLLVMPowerPCInfo.a",
>> >
>> > Can this be a list?
>> It's 1 output per target, no?
>
> Not on Windows with .dll a
Hi Aleix,
On Tue, Mar 10, 2015 at 1:25 AM, Aleix Pol wrote:
> Thank you for taking some of your time.
Thank you for doing the work:-)
> On Sat, Mar 7, 2015 at 11:46 AM, Tobias Hunger
> wrote:
>> How about adding some information on what this is you are actually
>> building here? CMake has the
On Tue, Mar 10, 2015 at 01:25:16 +0100, Aleix Pol wrote:
> >>"output" :
> >> "/home/kde-devel/tmp/llvm/build/lib/libLLVMPowerPCInfo.a",
> >
> > Can this be a list?
> It's 1 output per target, no?
Not on Windows with .dll and .lib splits.
> >>"sources" : [ "/list/of/cpp/fi
Hi Tobias,
Thank you for taking some of your time.
On Sat, Mar 7, 2015 at 11:46 AM, Tobias Hunger wrote:
> Hi Aleix,
>
> thank you for the ping:-)
>
> Since I am not fully fluent with cmake (have not really used it in a
> couple of years) and sometimes have a bit of trouble following the
> discus
Aleix Pol wrote:
> I just pushed my change into a github clone for easier testing and
> reviewing. https://github.com/aleixpol/CMake
Hi Aleix,
Thanks for your efforts.
Here are some things that are required before a feature like this can be
committed to the cmake repo:
* Discuss the feature w
On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol wrote:
> Dear cmake'rs,
> I'm rewriting the KDevelop plugin from scratch to fetch the information from
> the build directory.
>
> Now in the first implementation I'm using the compile_commands.json file
> that cmake already can generate for some time. It
Hi Aleix,
thank you for the ping:-)
Since I am not fully fluent with cmake (have not really used it in a
couple of years) and sometimes have a bit of trouble following the
discussion about the details of this patch, I took the liberty to
copy/paste (and part of) one of the example files you put u
On Wed, Mar 4, 2015 at 9:05 PM, Brad King wrote:
> On 03/02/2015 09:10 PM, Aleix Pol wrote:
>> I created a new version of the patch:
>> http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE-v2.patch
>
> Thanks.
>
>> Samples:
>> LLVM: https://paste.kde.org/pelr1dit
On 03/02/2015 09:10 PM, Aleix Pol wrote:
> I created a new version of the patch:
> http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE-v2.patch
Thanks.
> Samples:
> LLVM: https://paste.kde.org/pelr1ditp
> A small random KDE project: https://paste.kde.org/pgkbec
On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol wrote:
> Dear cmake'rs,
> I'm rewriting the KDevelop plugin from scratch to fetch the information from
> the build directory.
>
> Now in the first implementation I'm using the compile_commands.json file
> that cmake already can generate for some time. It
On Tue, Mar 3, 2015 at 2:15 AM, Aleix Pol wrote:
> On Mon, Feb 16, 2015 at 10:44 PM, Alexander Neundorf wrote:
>> On Monday, February 16, 2015 21:31:45 Aleix Pol wrote:
>>> On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly wrote:
>>> > Aleix Pol wrote:
>>> >> Hi guys,
>>> >> It's been since August
On Mon, Feb 16, 2015 at 10:44 PM, Alexander Neundorf wrote:
> On Monday, February 16, 2015 21:31:45 Aleix Pol wrote:
>> On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly wrote:
>> > Aleix Pol wrote:
>> >> Hi guys,
>> >> It's been since August with this. I understand we're all busy but this
>> >> ste
On Monday, February 16, 2015 21:31:45 Aleix Pol wrote:
> On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly wrote:
> > Aleix Pol wrote:
> >> Hi guys,
> >> It's been since August with this. I understand we're all busy but this
> >> step is important for KDevelop as well as for other IDE's and I
> >> wo
On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly wrote:
> Aleix Pol wrote:
>
>> Hi guys,
>> It's been since August with this. I understand we're all busy but this
>> step is important for KDevelop as well as for other IDE's and I
>> wouldn't like this to rot.
>>
>> Please, let's keep it moving forwa
Aleix Pol wrote:
> Hi guys,
> It's been since August with this. I understand we're all busy but this
> step is important for KDevelop as well as for other IDE's and I
> wouldn't like this to rot.
>
> Please, let's keep it moving forward.
As far as I'm aware, it needs to move forward from this po
On Thu, Feb 5, 2015 at 6:03 PM, Aleix Pol wrote:
> On Mon, Feb 2, 2015 at 5:36 PM, Aleix Pol wrote:
>> On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger
>> wrote:
>>> I gave this patch a try with the cmake project data.
>>>
>>> I had hoped that this file would contain all the information an IDE
>>
On Mon, Feb 2, 2015 at 5:36 PM, Aleix Pol wrote:
> On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger
> wrote:
>> I gave this patch a try with the cmake project data.
>>
>> I had hoped that this file would contain all the information an IDE
>> might need, but there seems quite a bit missing for that
On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger wrote:
> I gave this patch a try with the cmake project data.
>
> I had hoped that this file would contain all the information an IDE
> might need, but there seems quite a bit missing for that. E.g. there
> is no information on which files are used to
I gave this patch a try with the cmake project data.
I had hoped that this file would contain all the information an IDE
might need, but there seems quite a bit missing for that. E.g. there
is no information on which files are used to build a target. What am I
missing?
Best Regards,
Tobias
On Mo
On 01/25/2015 08:26 AM, Tobias Hunger wrote:
> I just had a bit of time to play with cmake this weekend: Is this
> patch available somewhere by now?
Aleix sent it in a message of this thread on 2015-01-09:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12061
Some
Hi Everybody,
I just had a bit of time to play with cmake this weekend: Is this
patch available somewhere by now?
Best Regards,
Tobias
On Sat, Jan 10, 2015 at 7:23 PM, Stephen Kelly wrote:
> Aleix Pol wrote:
>
>> I'll attach it in this e-mail, to make sure it reaches.
>>
>> PS: there's no chan
On Tue, Jan 20, 2015 at 3:47 PM, Brad King wrote:
> On 12/18/2014 09:02 PM, Aleix Pol wrote:
>> I would like to propose this as a final version of this patch.
>> http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch
>
> For reference, this was also attached
On 12/18/2014 09:02 PM, Aleix Pol wrote:
> I would like to propose this as a final version of this patch.
> http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch
For reference, this was also attached in a later message of this
thread on 2015-01-09:
http:/
Aleix Pol wrote:
> I'll attach it in this e-mail, to make sure it reaches.
>
> PS: there's no changes system for cmake like reviewboard, is there?
Nope, review is communicated on the mailing list, but if you want you can
push the patch on a branch in a public repo. It could be more convenient.
On Thu, Jan 8, 2015 at 5:42 PM, Anton Makeev wrote:
> Aleix Pol writes:
>
>>
>>
>> I'd really appreciate your feedback on the patch I provided, I'll be
>> happy to provide the information you miss.
>> Aleix
>
> Aleix, could you please point me to the most recent patch version?
>
>
>
>
>
>
>
>
Aleix Pol writes:
>
>
> I'd really appreciate your feedback on the patch I provided, I'll be
> happy to provide the information you miss.
> Aleix
Aleix, could you please point me to the most recent patch version?
--
Powered by www.kitware.com
Please keep messages on-topic and che
On Tuesday, December 23, 2014 01:30:58 Aleix Pol wrote:
> On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev
...
> > * No progress indication. Since the generation may take several minutes,
> >
> > providing feedback is crucial.
>
> I never found such case, I would argue that a project which has a
>
On 2014-12-22 19:30, Aleix Pol wrote:
> On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev wrote:
>> * No progress indication. Since the generation may take several minutes,
>> providing feedback is crucial.
>
> I never found such case,
ParaView. (To a lesser extent, VTK.)
> I would argue that a pro
On Tue, Dec 23, 2014 at 1:30 AM, Aleix Pol wrote:
> On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev
> wrote:
>> Hey everyone,
>>
>> We are developing CLion at JetBrains that utilizes CMake as its main project
>> model. Stephen Kelly timely drew our attention to this discussion, and I’d
>> like
>>
On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev
wrote:
> Hey everyone,
>
> We are developing CLion at JetBrains that utilizes CMake as its main project
> model. Stephen Kelly timely drew our attention to this discussion, and I’d
> like
> to share some thoughts. Here are the general ones and I’ll al
Aleix Pol wrote:
> Hi,
> I would like to propose this as a final version of this patch.
> http://proli.net/meu/kdevelop/0001-cmake-Add-option-to-generate-target-metadata-for-IDE.patch
>
> I have a working proof of concept in KDevelop already I'm quite happy
> with.
>
> Any thoughts?
Just some q
On Wed, Oct 15, 2014 at 1:46 AM, Aleix Pol wrote:
> On Fri, Oct 3, 2014 at 3:52 PM, Rolf Eike Beer wrote:
>>
>> Brad King wrote:
>> > On 10/01/2014 07:46 PM, Aleix Pol wrote:
>> > > I'm very interested in getting this in and iterating forward.
>> > >
>> > > Any comments? How do changes get integr
Tobias Hunger wrote:
> Hey Stephen,
>
> On Sun, Oct 19, 2014 at 2:26 PM, Stephen Kelly
> wrote:
>> No problem, thanks! I recently discovered that Creator makes fragile
>> guesses about source files and targets
>>
>> https://codereview.qt-project.org/#/c/96594/1/src/plugins/cmakeprojectmanager/cm
Hey Stephen,
On Sun, Oct 19, 2014 at 2:26 PM, Stephen Kelly wrote:
> No problem, thanks! I recently discovered that Creator makes fragile guesses
> about source files and targets
>
> https://codereview.qt-project.org/#/c/96594/1/src/plugins/cmakeprojectmanager/cmakeproject.cpp,unified
>
> so I wo
Tobias Hunger wrote:
> Sorry, I am a bit late with replying to this... I do not follow this
> list too closely and got distracted by mails in between where I could
> not contribute anything:-/
No problem, thanks! I recently discovered that Creator makes fragile guesses
about source files and tar
On 10/17/2014 06:44 AM, Tobias Hunger wrote:
> On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly wrote:
>> Afaik, CMake does not know all the files included by your cpp files.
>> However, some buildsystems can add them to the list of sources if desired
>> for better IDE integration.
>>
>> https://gi
Sorry, I am a bit late with replying to this... I do not follow this
list too closely and got distracted by mails in between where I could
not contribute anything:-/
On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly wrote:
>> The first is should this be run in a terminal or is this a GUI. Not
>> sur
On Fri, Oct 3, 2014 at 3:52 PM, Rolf Eike Beer wrote:
> Brad King wrote:
> > On 10/01/2014 07:46 PM, Aleix Pol wrote:
> > > I'm very interested in getting this in and iterating forward.
> > >
> > > Any comments? How do changes get integrated?
> >
> > My main concern is that the format has not bee
Brad King wrote:
> On 10/01/2014 07:46 PM, Aleix Pol wrote:
> > I'm very interested in getting this in and iterating forward.
> >
> > Any comments? How do changes get integrated?
>
> My main concern is that the format has not been proven with a
> corresponding implementation of an actual IDE/plug
On Thu, Oct 2, 2014 at 2:43 PM, Brad King wrote:
> On 10/01/2014 07:46 PM, Aleix Pol wrote:
> > I'm very interested in getting this in and iterating forward.
> >
> > Any comments? How do changes get integrated?
>
> My main concern is that the format has not been proven with a
> corresponding impl
On 10/01/2014 07:46 PM, Aleix Pol wrote:
> I'm very interested in getting this in and iterating forward.
>
> Any comments? How do changes get integrated?
My main concern is that the format has not been proven with a
corresponding implementation of an actual IDE/plugin to use it.
Once we start pro
On Wed, Sep 24, 2014 at 6:51 PM, Aleix Pol wrote:
> On Wed, Sep 24, 2014 at 3:55 PM, Brad King wrote:
>
>> On 09/22/2014 07:15 PM, Aleix Pol wrote:
>> > {
>> > version: "1.0",
>> > targets: [...]
>> > }
>>
>> Yes. The version number could either be maintained as its own
>> thing, or just the CM
On Fri, Sep 26, 2014 at 1:27 AM, Stephen Kelly wrote:
> Aleix Pol wrote:
> > Hi,
> > Here's another iteration of the patch [1].
>
> Thanks for this.
>
> Can you tell me why exportName is part of the output?
>
>
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11009
>
Aleix Pol wrote:
> Hi,
> Here's another iteration of the patch [1].
Thanks for this.
Can you tell me why exportName is part of the output?
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11009
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages
Anton Makeev wrote:
> Hey everyone,
>
> We are developing CLion at JetBrains that utilizes CMake as its main
> project model. Stephen Kelly timely drew our attention to this discussion,
> and I’d like to share some thoughts. Here are the general ones and I’ll
> also comment on separate messages i
On Thursday, September 25, 2014 07:14:38 Anton Makeev wrote:
...
> Here is why I think the discussed functionality should not be a separate
> generator:
>
> CLion doesn’t have it’s own project model nor is intended as build tool
> replacement. Currently, the only option for CLion users is makefile
Hey everyone,
We are developing CLion at JetBrains that utilizes CMake as its main project
model. Stephen Kelly timely drew our attention to this discussion, and I’d like
to share some thoughts. Here are the general ones and I’ll also comment on
separate messages in the thread.
We’ve managed to
On Wed, Sep 24, 2014 at 3:55 PM, Brad King wrote:
> On 09/22/2014 07:15 PM, Aleix Pol wrote:
> > {
> > version: "1.0",
> > targets: [...]
> > }
>
> Yes. The version number could either be maintained as its own
> thing, or just the CMake version number could be used. Either way
> the Help/variab
On 09/22/2014 07:15 PM, Aleix Pol wrote:
> {
> version: "1.0",
> targets: [...]
> }
Yes. The version number could either be maintained as its own
thing, or just the CMake version number could be used. Either way
the Help/variable/CMAKE_OUTPUT_PROJECT_TARGETS.rst documentation
should specify the
On Fri, Sep 19, 2014 at 7:44 PM, Brad King wrote:
> On 09/18/2014 08:10 PM, Aleix Pol wrote:
> > I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to
> > enable the generation of the file.
> > I also renamed the file to ProjectTargets.json.
> >
> > http://www.proli.net/meu/kdevelop
On 09/20/2014 09:18 AM, Stephen Kelly wrote:
> I don't know why I added it.
>
> There is also a 'new'
>
> +location += "/";
>
> in that patch further down which might be removable.
Thanks for pointing that one out too. I've removed both with a
commit message that explains one hypothesis a
Tobias Hunger wrote:
> The first is should this be run in a terminal or is this a GUI. Not
> sure whether cmake has that information.
CMake only knows whether the WIN32_EXECUTABLE property has been set on a
target.
http://www.cmake.org/cmake/help/v3.0/prop_tgt/WIN32_EXECUTABLE.html
The proper
On 09/22/2014 03:39 PM, Stephen Kelly wrote:
Nils Gladitz wrote:
Might be nice for platforms where RPATHs aren't supported (e.g. Windows)
though a generic, non IDE specific solution might be preferable:
The proposed ProjectTargets.json isn't particularly IDE specific. That's
only the motivat
Nils Gladitz wrote:
> Might be nice for platforms where RPATHs aren't supported (e.g. Windows)
> though a generic, non IDE specific solution might be preferable:
>
The proposed ProjectTargets.json isn't particularly IDE specific. That's
only the motivation.
Thanks,
Steve.
--
Powered by ww
On 09/20/2014 09:57 PM, Tobias Hunger wrote:
Hello!
Sorry for breaking the threading, I only joined this ML just now to
comment on this thread:-) Thanks Stephen for pointing me here!
I am not a regular cmake user (used to be a couple of years ago), but
I im interested in this topic since I work
On Friday, September 19, 2014 21:53:40 Alexander Neundorf wrote:
> On Friday, September 19, 2014 13:44:45 Brad King wrote:
> ...
>
> > * Don't IDEs want to know the list of source files so they can
> >
> > be used for editing?
> >
> > I haven't looked at what the Extra generators produce in a
Hello!
Sorry for breaking the threading, I only joined this ML just now to
comment on this thread:-) Thanks Stephen for pointing me here!
I am not a regular cmake user (used to be a couple of years ago), but
I im interested in this topic since I work on Qt Creator. While cmake
currently is not ou
Brad King wrote:
> I'd really like to hear from others on the file format itself.
>
> * There needs to be support for multi-config generators.
This presumable affects the "directory" and "location".
I wonder what the usefulness of putting "exportName" in the file is? Is it
possible there is co
Brad King wrote:
> Steve, do you remember why it was added? All lines below
> that append a slash before appending other content, so it
> will always end up with a double slash. Is there any reason
> you see that it cannot be removed?
I don't know why I added it. Perhaps to deal with a dashboar
On Friday, September 19, 2014 13:44:45 Brad King wrote:
...
> * Don't IDEs want to know the list of source files so they can
> be used for editing?
>
> I haven't looked at what the Extra generators produce in a
> while but since they are meant for IDEs they would be a good
> reference for the in
On 09/19/2014 01:57 PM, Rolf Eike Beer wrote:
> I see duplicated slashes in the JSON file.
It looks like those come from cmTarget::GetLocationForBuild.
An extra
+ if(!location.empty())
+{
+location += "/";
+}
appears to have been added by this commit:
Remove the Location member fr
Am Freitag, 19. September 2014, 13:44:45 schrieb Brad King:
> On 09/18/2014 08:10 PM, Aleix Pol wrote:
> > I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to
> > enable the generation of the file.
> > I also renamed the file to ProjectTargets.json.
> >
> > http://www.proli.net/meu
On 09/18/2014 08:10 PM, Aleix Pol wrote:
> I added a CMAKE_OUTPUT_PROJECT_TARGETS variable that can be used to
> enable the generation of the file.
> I also renamed the file to ProjectTargets.json.
>
> http://www.proli.net/meu/kdevelop/cmake-targetsdata.patch
Thanks. I made some style updates an
On Mon, Sep 8, 2014 at 2:51 PM, Brad King wrote:
> On 09/03/2014 12:12 PM, Aleix Pol wrote:
> > On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote:
> >> I still don't understand why this shouldn't be an additional
> ExtraGenerator.
> >
> > Because it's not possible to change the generat
On 09/03/2014 12:12 PM, Aleix Pol wrote:
> On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote:
>> I still don't understand why this shouldn't be an additional
>> ExtraGenerator.
>
> Because it's not possible to change the generator of a build directory
> once it's set up. You need to nu
On Wed, Sep 3, 2014 at 6:12 PM, Aleix Pol wrote:
> On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf
> wrote:
>
>> On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote:
>> > On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote:
>> > > It makes sense. But what IDE are you referring to? Eclipse
On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf wrote:
> On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote:
> > On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote:
> > > It makes sense. But what IDE are you referring to? Eclipse? Some other
> > > concrete example? Or just "any IDE and t
On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote:
> On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote:
> > It makes sense. But what IDE are you referring to? Eclipse? Some other
> > concrete example? Or just "any IDE and this feature should work everywhere
> > CMake works...?"
>
> I'm wor
On Tue, Sep 2, 2014 at 9:45 PM, Alexander Neundorf wrote:
> On Tuesday, September 02, 2014 09:58:37 David Cole via cmake-developers
> wrote:
> > It makes sense. But what IDE are you referring to? Eclipse? Some other
> > concrete example? Or just "any IDE and this feature should work
> > everywher
On Tue, Sep 2, 2014 at 3:58 PM, David Cole wrote:
> It makes sense. But what IDE are you referring to? Eclipse? Some other
> concrete example? Or just "any IDE and this feature should work everywhere
> CMake works...?"
>
>
I'm working on KDevelop, I know for a fact though, that other IDEs are
loo
On Tuesday, September 02, 2014 09:58:37 David Cole via cmake-developers wrote:
> It makes sense. But what IDE are you referring to? Eclipse? Some other
> concrete example? Or just "any IDE and this feature should work
> everywhere CMake works...?"
AFAIK it is kdevelop4, and the goal is that develo
It makes sense. But what IDE are you referring to? Eclipse? Some other
concrete example? Or just "any IDE and this feature should work
everywhere CMake works...?"
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitw
On Tue, Sep 2, 2014 at 1:03 PM, David Cole wrote:
> > Ok, how does it sound if we have a variable, such as
> > CMAKE_EXPORT_COMPILE_COMMANDS?
> > Let's say, CMAKE_EXPORT_TARGETS_INFORMATION.
>
>
> I would prefer CMAKE_EXPORT_TARGETS_FILE, or some name that implies it
> is a filename value, with t
> Ok, how does it sound if we have a variable, such as
> CMAKE_EXPORT_COMPILE_COMMANDS?
> Let's say, CMAKE_EXPORT_TARGETS_INFORMATION.
I would prefer CMAKE_EXPORT_TARGETS_FILE, or some name that implies it
is a filename value, with the value of the variable being the name of
the file to generate.
On Mon, Sep 1, 2014 at 9:26 PM, David Cole wrote:
> The approach looks reasonable, but having it unconditionally spit out a
> file in cmGlobalGenerator regardless of generator is probably not what we
> want. Seems like it should be based on a variable, or be in a specific
> generator, or somehow
On Monday, September 01, 2014 15:26:12 David Cole via cmake-developers wrote:
> The approach looks reasonable, but having it unconditionally spit out a
> file in cmGlobalGenerator regardless of generator is probably not what
> we want. Seems like it should be based on a variable, or be in a
> speci
The approach looks reasonable, but having it unconditionally spit out a
file in cmGlobalGenerator regardless of generator is probably not what
we want. Seems like it should be based on a variable, or be in a
specific generator, or somehow have a limited scope.
HTH,
David C.
--
Powered by www
On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol wrote:
> Dear cmake'rs,
> I'm rewriting the KDevelop plugin from scratch to fetch the information
> from the build directory.
>
> Now in the first implementation I'm using the compile_commands.json file
> that cmake already can generate for some time. It
87 matches
Mail list logo
