[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: CMake: include paths for a file
From:       Milian Wolff <mail () milianw ! de>
Date:       2013-11-16 21:00:05
Message-ID: 106515880.OORBgG8lOk () minime
[Download RAW message or body]

On Saturday 16 November 2013 21:41:21 Alexander Neundorf wrote:
> On Saturday 16 November 2013, Milian Wolff wrote:
> > On Saturday 16 November 2013 19:11:07 Dominik Haumann wrote:
> > <snip>
> > 
> > > In other words, clang can be used as command line tool for *perfect*
> > > code
> > > completion. However, this only works when all the include paths are
> > > known. cmake has the option -DCMAKE_EXPORT_COMPILE_COMMANDS=on to
> > > generate a compile_commands.json file. Therein, each compile command
> > > also contains the include paths, so this would be a way to extract the
> > > necessary "-I..." information for all required include paths from cmake.
> > > 
> > > Is there another more elegant way than parsing these lines manually?
> > 
> > I would also be interested in this. If there is nothing like that yet,
> > would something like this be accepted upstream?
> > 
> > Generally, I'd love to have something in CMake directly which would enable
> > us to get rid of our custom CMake implementation in KDevelop. What I have
> > in mind is e.g. a JSON file which contains a list of targets, the files
> > they include, as well as the corresponding defines and includes for these
> > targets.
> > 
> > Something like this:
> > 
> > {
> > myTarget: {
> > 
> >   path: "relative/to/project"
> >   files: ["foo.cpp", "bar.cpp", ...]
> >   defines: ["ASDF=FOO", ...]
> >   includes: ["relative/to/project/sub", ...]
> > 
> > }, ...
> > }
> 
> That would simply be an additional generator for cmake. It's a bit of work
> (not really much), but that's exactly what the generators are for.
> If it is generic and complete enough, maybe others would be interested in
> using this too.
> It may be possible to include information in which file (CMakeLists.txt) the
> target has been added. I'm not sure, I think currently this information is
> not readily available in CMake, but it should be doable.

Great, seems like I should get an introduction from Stephen on this sometime 
and get this into a working state and upstream it. That could easily get rid 
of thousands of line of semi-functional code in KDevelop ;-)

One thing: Can I specify multiple generators for CMake? I.e. could both (Ninja 
or Makefile) _and_ $IDE files be created? As far as I can see this is not 
possible - correct? Would anything speak against this? It should be faster to 
only run cmake once over a project to analyze it after all. Outputting some 
data at the end is probably fast anyways.

> > Once we have that a bunch of cmake commands for tooling, such as "add
> > $file
> > to target $foo" or "create new $target with files $foo as
> > library/executable/test" or similar.
> 
> Well, that's the other way round.

Sure, I know. What I have in mind is a tooling API similar to what qbs is 
supposed to have. With it, an IDE can give users fancy features like what I 
mentioned above.

> The file above would be json generated by cmake from the CMakeLists.txt, it
> wouldn't be input to cmake.
> Have you seen Stephens work on adding support for QML input to cmake ?

Yes, but then I'd need the same set of tools which automatically add the 
desired changes at the correct places.

Bye
-- 
Milian Wolff
mail@milianw.de
http://milianw.de
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]