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.
> >>
> >> I've been qu
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.
>>
>>
>> I've been quiet on this thread for a while, so I think it is time for an
>> update.
>>
>>
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.
>
>
> 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 M
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 in
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 conten
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 resul
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
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
> On 01 Apr 2015, at 23:13, Stephen Kelly wrote:
>
> Anton Makeev wrote:
>
>>> On 01 Apr 2015, at 00:41, Stephen Kelly
>>> wrote:
>>>
>>> Anton Makeev wrote:
>>>
The problem with the following format:
---
"include_directories" : ["/foo", "/opt"]
"compile_definitions" : ["D
Tobias Hunger wrote:
> On Wed, Apr 1, 2015 at 12:41 AM, Stephen Kelly wrote:
>> Anton Makeev wrote:
>>
>>> The problem with the following format:
>>> ---
>>> "include_directories" : ["/foo", "/opt"]
>>> "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"]
>>> "compile_flags": [ "-c" ]
>>> —
>>>
Anton Makeev wrote:
>
>> On 01 Apr 2015, at 00:41, Stephen Kelly
>> wrote:
>>
>> Anton Makeev wrote:
>>
>>> The problem with the following format:
>>> ---
>>> "include_directories" : ["/foo", "/opt"]
>>> "compile_definitions" : ["DEF=\"Foo\"", "OTHER_DEF=1"]
>>> "compile_flags": [ "-c" ]
>>> —
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 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 have CMakeCach
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.
> On 01 Apr 2015, at 00:41, Stephen Kelly 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 cann
> On 01 Apr 2015, at 00:17, Stephen Kelly 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 CMakeCache.txt
On Wed, Apr 1, 2015 at 12:41 AM, Stephen Kelly 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 cann
Tobias Hunger wrote:
> I think we can combine the include_directories, compile definitions
> and flags ourselves though when that is needed for us to run the
> compiler. I do not see the need to have the full command line that
> would be run for each and every file, which is how I read "full
> com
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
Anton Makeev wrote:
> Agree, the IDE should not do any automatic stuff, when user doesn’t expect
> it. Though, the use-case here is quite different:
> Consider a project that have 'add_directory(missing_dir)’ in one of the
> CMakeLists files. If IDE were aware that missing_dir/CMakeLists.txt is a
On Mon, Mar 30, 2015 at 7:04 PM, Anton Makeev
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
>> currently).
>
> Th
> On 30 Mar 2015, at 21:21, Alexander Neundorf wrote:
>
> On Monday, March 30, 2015 19:04:10 Anton Makeev wrote:
>>> On 24 Mar 2015, at 00:54, Stephen Kelly wrote:
>>>
>>> Tobias Hunger wrote:
How about include_directories, compile_definitions and compile_flags?
So something al
On Monday, March 30, 2015 19:04:10 Anton Makeev wrote:
> > On 24 Mar 2015, at 00:54, Stephen Kelly wrote:
> >
> > Tobias Hunger wrote:
> >> How about include_directories, compile_definitions and compile_flags?
> >>
> >> So something along the lines of:
> >>
> >> "include_directories" : ["/foo",
> On 24 Mar 2015, at 00:54, Stephen Kelly 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 21 Mar 2015, at 09:41, Stephen Kelly 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 the compil
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 k
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"]
> "compile_flags": [ "-c" ]
Quoting Anton:
Anton Makeev wrot
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
>> partc
On Sat, Mar 21, 2015 at 9:41 AM, Stephen Kelly 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 the compil
Hi Stephen,
On Sat, Mar 21, 2015 at 9:18 AM, Stephen Kelly wrote:
>> Could you add have a "configuration list" key in the top level of each
>> file that lists all available configurations (including itself)? That
>> might be the lowest overhead solution that does not require parsing
>> extra fil
Tobias Hunger wrote:
> On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly
> 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 provides user-
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
> wrote:
>> * If it is useful to preprocess/compile/assemble individual files from
>> IDEs, as made possible by the Makefiles and Ninja generators,
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 lang
Tobias Hunger wrote:
>>>sources: [ {
>>>language: "C++",
>>>type: sources,
>>>defines: "FOO=1",
>>>include_paths: "/usr/include",
>>>files: [ "/full/path/a.cpp", "/full/path/b.cpp" ]
>>>},
>>>{
>>>language: "C++",
>>>type: headers
Hi Stephen, everyone.
First of all, many thanks for pushing this forward and spending your time to
prepare the proposal.
My comments are inline.
> Goals include:
>
> * Make it possible for IDEs to access the compile-related information for
> autocompletion and code navigation etc purposes.
>
Hi Anton,
you raised some good points, all of which I agree with:-)
On Thu, Mar 19, 2015 at 10:18 AM, Anton Makeev
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
> to design that.
> http
Hi Stephen,
On Thu, Mar 19, 2015 at 2:22 AM, Stephen Kelly 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 are a li
Tobias Hunger wrote:
> Hi Stephen,
>
> sorry for being late to the party again:-)
>
> I am just reading your documentation.
Great, thanks for all this. Did you also read the unit test and generated
file?
I'm working on updating my branch based on all of the feedback in this
thread so far.
>
On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly 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 provides user-interface for
> choosing de
Hi Stephen,
sorry for being late to the party again:-)
I am just reading your documentation.
Some nits:
* In the "Introduction" you say CMAKE_GENERATE_METADATA needs to be
ON, in "Generating Metadata" it needs to be set to a version number.
* In "Metadata Contents/Optional Properties" you prop
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_g
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
On Sat, Mar 14, 2015 at 10:02 AM, Stephen Kelly wrote:
>
>
> On Saturday, March 14, 2015, Aleix Pol wrote:
>> On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly
>> wrote:
>>> Hi,
>>>
>>> Following from the thread here:
>>>
>>>
>>> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/107
On Saturday, March 14, 2015, Aleix Pol wrote:
> On Wed, Mar 11, 2015 at 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.cmak
On Wed, Mar 11, 2015 at 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
>
> I'm starting to g
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 i
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
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
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
49 matches
Mail list logo
