[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 22:40:02
Message-ID: 4026741.pF5Je6Fnjf () minime
[Download RAW message or body]

On Saturday 16 November 2013 23:36:12 Alexander Neundorf wrote:
> On Saturday 16 November 2013, Milian Wolff wrote:
> > 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?
> 
> This is what the "extra" generators are for in CMake, which I added in 2007.
> :-)
> 
> They consist of a "normal" generator, i.e. Makefile or ninja, and an
> additional generator which is run afterwards, which outputs some information
> for IDEs.
> This is currently used for Eclipse, CodeBlocks, Sublime and (still)
> KDevelop3 and (not yet merged) for kate.
> 
> If you want to, have a look at Source/cmExtraEclipseCDT4Generator.cxx/h.
> This iterates over all targets, over all sources files and puts information
> into xml for Eclipse.

Ah great, thanks now I get it!

> > 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.
> 
> Not quite sure what you mean ?

The above answers it for me. That way we can run cmake once and get both, 
Makefiles and IDE info and don't have to run cmake twice (which will probably 
be slower, which is what I meant).

> > > > 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.
> 
> I don't know much about qbs. Can you elaborate ?

Me neither, they just told me that there is apparently "deep IDE integration". 
Something which is still missing from CMake to my knowledge.

Assume a user creates a new file. The IDE can then ask him:

- do you want to add this new file to one of these targets: A, B, ...
- do you want to create a new target?

If he picks one of the above, what do you do? Right now, everyone needs to do 
some magic file operations and hope he doesn't screw the CMakeLists.txt in the 
process. If there'd be some kind of tooling for that shipped with CMake, it 
would be awesome. To add a file to a target e.g. you'll need to parse the file 
and add the file path to the correct set(SRCS foo.h ...) e.g. This we do 
already in KDevelop, I just hope we can get rid of this code long-term as 
well. If it's shipped with cmake, it's going to be much better maintained 
_and_ other IDE's can make use of it as well!

Anyhow, this is really OT to both, the thread started by Dominik, and 
kwrite/kate in general ;-) Sorry for that guys!

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]