Alexander Neundorf wrote:
> Maybe this is of interest: the Eclipse CDT developers are currently
> working on improved support for cmake:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=350206
> http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg29621.html
Yes, I noticed that too a few days ago.
My
Hi,
On Saturday, July 25, 2015 20:33:46 Stephen Kelly wrote:
> Aleix Pol wrote:
> > On Sat, Apr 18, 2015 at 11:56 AM, Stephen Kelly
> >
> > wrote:
> >> Stephen Kelly wrote:
> >>> The aim is to generate a structured file containing metadata
relating
> >>> the buildsystem.
>
On Sat, Apr 18, 2015 at 11:56 AM, Stephen Kelly steve...@gmail.com wrote:
Stephen Kelly wrote:
The aim is to generate a structured file containing metadata relating the
buildsystem.
I've been quiet on this thread for a while, so I think it is time for an
update.
I became more ambitious
Aleix Pol wrote:
On Sat, Apr 18, 2015 at 11:56 AM, Stephen Kelly
steve...@gmail.com wrote:
Stephen Kelly wrote:
The aim is to generate a structured file containing metadata relating
the buildsystem.
I've been quiet on this thread for a while, so I think it is time for an
update.
I
Stephen Kelly wrote:
The aim is to generate a structured file containing metadata relating the
buildsystem.
I've been quiet on this thread for a while, so I think it is time for an
update.
I became more ambitious in mid March and started prototyping a more-complete
design for CMake IDE
On Mon, Apr 06, 2015 at 19:08:37 +0200, Stephen Kelly wrote:
AFAICT, CMake does still know the command line in your output-target-flags-
once-in-ninja branch.
You just need to compute two outputs - once for writing the Ninja file
(containing variables), and again for writing the content
On Sat, Apr 04, 2015 at 14:32:51 +0200, Stephen Kelly wrote:
On 04/02/2015 10:29 AM, Anton Makeev wrote:
Just to make sure, you mentioned that this file should be deprecated with
this new metadata.json,
is that correct?
I'm not sure I mentioned that, just that it's an externally defined
Ben Boeckel wrote:
On Sat, Apr 04, 2015 at 14:32:51 +0200, Stephen Kelly wrote:
However, there are other users
of the compile-commands.json, so it will remain and the feature for
generation of it will not be deprecated.
Or, to be more clear - it doesn't need to be deprecated as a result of
On 04/02/2015 10:29 AM, Anton Makeev wrote:
I see, but how will having include_directories help ‘Add include
directory’-like actions?
I mean, simply having this list (without additional info like backtraces)
doesn’t seem to help much.
We'll have to see :).
So, in the end, we probably need
On 01 Apr 2015, at 00:41, Stephen Kelly steve...@gmail.com wrote:
Anton Makeev wrote:
The problem with the following format:
---
include_directories : [/foo, /opt]
compile_definitions : [DEF=\Foo\, OTHER_DEF=1]
compile_flags: [ -c ]
—
Is that it’s incomplete and cannot be used
On 01 Apr 2015, at 00:17, Stephen Kelly steve...@gmail.com wrote:
Anton Makeev wrote:
It comes from CMAKE_CONFIGURATION_TYPES, if project defined such a
variable. With default of Debug/Release/RelWithDebInfo/MinSizeRel
Ok.
So does this mean you have a parser for the existing
Anton Makeev wrote:
On 01 Apr 2015, at 00:41, Stephen Kelly
steve...@gmail.com wrote:
Anton Makeev wrote:
The problem with the following format:
---
include_directories : [/foo, /opt]
compile_definitions : [DEF=\Foo\, OTHER_DEF=1]
compile_flags: [ -c ]
—
Is that it’s incomplete
Tobias Hunger wrote:
On Wed, Apr 1, 2015 at 12:41 AM, Stephen Kelly steve...@gmail.com wrote:
Anton Makeev wrote:
The problem with the following format:
---
include_directories : [/foo, /opt]
compile_definitions : [DEF=\Foo\, OTHER_DEF=1]
compile_flags: [ -c ]
—
Is that it’s incomplete
Anton Makeev wrote:
Not only do we reed it, we also have the UI that allows user to interact
and the cached values. That means we’ll have CMakeCache parser anyways
and do not need these values in metadata.json file, as it was mentioned in
parallel discussion.
Yes, that's what I thought. I
I favor documenting the existing format, too.
Note added to issue with my vote.
D
On Wed, Apr 1, 2015 at 4:26 PM, Stephen Kelly steve...@gmail.com wrote:
Anton Makeev wrote:
Not only do we reed it, we also have the UI that allows user to interact
and the cached values. That means we’ll
Anton Makeev wrote:
The problem with the following format:
---
include_directories : [/foo, /opt]
compile_definitions : [DEF=\Foo\, OTHER_DEF=1]
compile_flags: [ -c ]
—
Is that it’s incomplete and cannot be used directly:
* include directories list misses compiler-defined search paths
On 21 Mar 2015, at 09:41, Stephen Kelly steve...@gmail.com wrote:
Anton Makeev wrote:
The other thing that seems troubling to me is that since file, target,
language compiler options are split into different parts of metadata, the
IDE need to know exactly how to assemble them back into
On 24 Mar 2015, at 00:54, Stephen Kelly steve...@gmail.com wrote:
Tobias Hunger wrote:
How about include_directories, compile_definitions and compile_flags?
So something along the lines of:
include_directories : [/foo, /opt]
compile_definitions : [DEF=\Foo\, OTHER_DEF=1]
On 30 Mar 2015, at 21:21, Alexander Neundorf neund...@kde.org wrote:
On Monday, March 30, 2015 19:04:10 Anton Makeev wrote:
On 24 Mar 2015, at 00:54, Stephen Kelly steve...@gmail.com wrote:
Tobias Hunger wrote:
How about include_directories, compile_definitions and compile_flags?
So
On Mon, Mar 30, 2015 at 7:04 PM, Anton Makeev
anton.mak...@jetbrains.com wrote:
Another item of note is that CMake does not know the compile flags as a
sequential container of individual flags currently, but it knows them as a
string (that's also why it appears as a string in my generated json
Stephen Kelly wrote:
I expect to require a few iterations to figure out what the metadata files
should contain in the end.
Just FYI, I have not forgotten about this and am working on an expanded
design to cover the reported needs.
Thanks,
Steve.
--
Powered by www.kitware.com
Please
Tobias Hunger wrote:
and
which kit (think set of compiler, Qt, some other settings) were used
to in the built in that directory.
Is this hypothetical? Currently I can add a compiler location and a Qt
location in QtCreator, and I can create a kit and give it a name and
partcular compiler
On Sat, Mar 21, 2015 at 9:41 AM, Stephen Kelly steve...@gmail.com wrote:
Anton Makeev wrote:
The other thing that seems troubling to me is that since file, target,
language compiler options are split into different parts of metadata, the
IDE need to know exactly how to assemble them back into
Tobias Hunger wrote:
Hi Anton,
you raised some good points, all of which I agree with:-)
On Thu, Mar 19, 2015 at 10:18 AM, Anton Makeev
anton.mak...@jetbrains.com wrote:
* If it is useful to preprocess/compile/assemble individual files from
IDEs, as made possible by the Makefiles and
Anton Makeev wrote:
The other thing that seems troubling to me is that since file, target,
language compiler options are split into different parts of metadata, the
IDE need to know exactly how to assemble them back into the compiler’s
command line (e.g. what flags go first file’s or
Tobias Hunger wrote:
On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly
steve...@gmail.com wrote:
* Make it possible for editors/IDEs to allow specifying the configuration
at build-time, where the IDE has that feature, and where a multi-config
generator is available. That is, QtCreator
Hi Anton,
you raised some good points, all of which I agree with:-)
On Thu, Mar 19, 2015 at 10:18 AM, Anton Makeev
anton.mak...@jetbrains.com wrote:
* If it is useful to preprocess/compile/assemble individual files from
IDEs, as made possible by the Makefiles and Ninja generators, we'll need
Hi Stephen,
On Thu, Mar 19, 2015 at 2:22 AM, Stephen Kelly steve...@gmail.com wrote:
* In Target Properties/Conditional Properties and optional
properties: Would it make sense to have a list of target_files, each
with a filepath and a type? That would be more similar to the targets
which also
Aleix Pol wrote:
By 'in scope' you mean 'used by the primary CMakeLists.txt files via
include() or find_package()' or something like that? OK, let's see if
that's the best source of that data or if we should add something new
internally in cmake.
By in scope I mean whether a variable or a
Nils Gladitz wrote:
On 03/11/2015 11:10 AM, Stephen Kelly wrote:
I'm starting to gather requirements and make sure the feature is
well designed to satisfy the needs we're already aware of, and fits with
the features CMake currently has.
Source file groups (as in defined by source_group())
On Saturday, March 14, 2015, Aleix Pol aleix...@kde.org wrote:
On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly steve...@gmail.com
wrote:
Hi,
Following from the thread here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394
On Sat, Mar 14, 2015 at 10:02 AM, Stephen Kelly steve...@gmail.com wrote:
On Saturday, March 14, 2015, Aleix Pol aleix...@kde.org wrote:
On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly steve...@gmail.com
wrote:
Hi,
Following from the thread here:
On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly steve...@gmail.com wrote:
Hi,
Following from the thread here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650
I'm
On 03/11/2015 11:10 AM, Stephen Kelly wrote:
I'm starting to gather requirements and make sure the feature is
well designed to satisfy the needs we're already aware of, and fits with
the features CMake currently has.
Source file groups (as in defined by source_group()) and target folders
(as
On 03/11/2015 11:10 AM, Stephen Kelly wrote:
Hi,
Following from the thread here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650
The discussion in that thread is
On Wednesday, March 11, 2015 11:10:30 Stephen Kelly wrote:
Hi,
Following from the thread here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu
s=12394
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu
s=12650
I'm starting to
Hi,
Following from the thread here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650
I'm starting to gather requirements and make sure the feature is
well designed to satisfy
37 matches
Mail list logo