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 when which
On Sun, Mar 15, 2015 at 6:17 PM, Peter Kümmel syntheti...@gmx.net 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
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 there.
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
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
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
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 could not
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
On Wed, Mar 11, 2015 at 3:15 PM, Ben Boeckel ben.boec...@kitware.com 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
Hi Aleix,
On Tue, Mar 10, 2015 at 1:25 AM, Aleix Pol aleix...@kde.org 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 tobias.hun...@gmail.com
wrote:
How about adding some information on what this is you are
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/files, ]
Any way
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
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
On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol aleix...@kde.org 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
On Wed, Mar 4, 2015 at 9:05 PM, Brad King brad.k...@kitware.com 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:
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/pgkbecv5p
On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol aleix...@kde.org 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
On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly steve...@gmail.com 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
On Monday, February 16, 2015 21:31:45 Aleix Pol wrote:
On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly steve...@gmail.com 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
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 point:
On Thu, Feb 5, 2015 at 6:03 PM, Aleix Pol aleix...@kde.org wrote:
On Mon, Feb 2, 2015 at 5:36 PM, Aleix Pol aleix...@kde.org wrote:
On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger tobias.hun...@gmail.com
wrote:
I gave this patch a try with the cmake project data.
I had hoped that this file
On Mon, Feb 2, 2015 at 5:36 PM, Aleix Pol aleix...@kde.org wrote:
On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger tobias.hun...@gmail.com
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
On Mon, Jan 26, 2015 at 9:15 PM, Tobias Hunger tobias.hun...@gmail.com 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
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
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
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 steve...@gmail.com wrote:
Aleix Pol wrote:
I'll attach it in this e-mail, to make sure it reaches.
PS:
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:
On Tue, Jan 20, 2015 at 3:47 PM, Brad King brad.k...@kitware.com 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
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 anton.mak...@jetbrains.com wrote:
Aleix Pol aleixpol@... 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
Aleix Pol aleixpol@... 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
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
cmake
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 project
On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev
anton.mak...@jetbrains.com 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
On Tue, Dec 23, 2014 at 1:30 AM, Aleix Pol aleix...@kde.org wrote:
On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev
anton.mak...@jetbrains.com 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
Hey Stephen,
On Sun, Oct 19, 2014 at 2:26 PM, Stephen Kelly steve...@gmail.com wrote:
No problem, thanks! I recently discovered that Creator makes fragile guesses
about source files and targets
Tobias Hunger wrote:
Hey Stephen,
On Sun, Oct 19, 2014 at 2:26 PM, Stephen Kelly
steve...@gmail.com wrote:
No problem, thanks! I recently discovered that Creator makes fragile
guesses about source files and targets
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
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 steve...@gmail.com wrote:
The first is should this be run in a terminal or is this
On 10/17/2014 06:44 AM, Tobias Hunger wrote:
On Mon, Sep 22, 2014 at 4:03 PM, Stephen Kelly steve...@gmail.com 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.
On Fri, Oct 3, 2014 at 3:52 PM, Rolf Eike Beer e...@sf-mail.de 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
On Thu, Oct 2, 2014 at 2:43 PM, Brad King brad.k...@kitware.com 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
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/plugin to use
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
On Wed, Sep 24, 2014 at 6:51 PM, Aleix Pol aleix...@kde.org wrote:
On Wed, Sep 24, 2014 at 3:55 PM, Brad King brad.k...@kitware.com 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,
On Fri, Sep 26, 2014 at 1:27 AM, Stephen Kelly steve...@gmail.com 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?
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 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 makefiles
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 in the
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 Wed, Sep 24, 2014 at 3:55 PM, Brad King brad.k...@kitware.com 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
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
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
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
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
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 as to why
On Fri, Sep 19, 2014 at 7:44 PM, Brad King brad.k...@kitware.com 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.
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
while but
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 dashboard
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 confusion
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
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 and
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 from
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
On Mon, Sep 8, 2014 at 2:51 PM, Brad King brad.k...@kitware.com 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
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 nuke it
On Tue, Sep 2, 2014 at 3:58 PM, David Cole dlrd...@aol.com 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
On Tue, Sep 2, 2014 at 9:45 PM, Alexander Neundorf neund...@kde.org 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
On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote:
On Tue, Sep 2, 2014 at 3:58 PM, David Cole dlrd...@aol.com 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...?
On Wed, Sep 3, 2014 at 5:48 PM, Alexander Neundorf neund...@kde.org wrote:
On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote:
On Tue, Sep 2, 2014 at 3:58 PM, David Cole dlrd...@aol.com wrote:
It makes sense. But what IDE are you referring to? Eclipse? Some other
concrete example?
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 Tue, Sep 2, 2014 at 1:03 PM, David Cole dlrd...@aol.com 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,
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 developers
On Fri, Aug 29, 2014 at 4:20 AM, Aleix Pol aleix...@kde.org 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
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
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
specific
On Mon, Sep 1, 2014 at 9:26 PM, David Cole dlrd...@aol.com 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,
77 matches
Mail list logo
