CMake with D support early snapshot

[Trent Forkert]

On Wednesday, 26 March 2014 at 23:17:31 UTC, Ben Boeckel wrote:
>
> What about:
>
>   4. Add depfile support to Makefile generators.

That's basically what I'm doing, though only in the context of D.
cmDependsD::WriteDependencies() gets called for every D object,
and has the D compiler produce a dmd-style depfile of the 
relevant sources.
It then scans each of the

     foo (.../foo.d) : public : object (.../object.di)

lines, pulling the filepaths from the () to construct the file
depends.make in the correct CMakeFiles/<target>.dir, which 
contains a list
of lines like:

     .../foo.d.o: .../foo.d
     .../foo.d.o: .../object.di

> Yeah, seems so. If we could get rid of the cmDepends* stuff, 
> that'd be
> nice. I only see it included from 
> Source/cmLocalUnixMakefileGenerator3.*
> which means if the Makefile learns about depfiles, we can start 
> removing
> cmDepends* (yay!). I guess the IDE generators rely on IDE magic 
> to get
> dependencies correct?

Y'know, I didn't really know. So, I spent longer than I'd care to 
admit in a find|grep loop examining the source. Raw notes as I 
progressed are appended to the bottom of this post, but the 
takeaway is that there are only really four kinds of generators:

* Makefiles
* Ninja (Some depfile solution)
* Visual Studio (maybe VisualD will help handle things for us)
* XCode (absolutley no idea)

Everything else is implemented on top of those. All the non-VS 
non-XC generators ultimately go through cmLocalUnixMakefile3 and 
cmDepends, or they go through Ninja.

So, we'll still need to get Ninja, VS, and XCode dependency 
separately, but cmDepends handles the all other generator's 
dependency resolution.


>
> So...it looks like this is what we're aiming for:
>
>   - DMD/LDC
>     - Support make-style depfiles (optional; unlikely)
>     - Support filtering out excess dependencies (private 
> import, system
>       files) (preferred)

Right now I'm doing direct dependencies only, so if module foo 
imports std.stdio, it adds a dependency on stdio.di, but nothing 
else. I think we might actually want full (recursive) dependency 
listings though, because of how templates work. Alternatively, I 
can just check the module names and filter out std.* and similar.

>   - Ninja
>     - dmd depfile support (preferred; no comment from martine 
> yet)
>   - CMake
>     - Add depfile support to Make (preferred)
>     - Add dmd -> make depfile translator  (likely necessary[2])

Like I said above, that's what I'm doing in cmDependsD at the 
moment. Since Ninja, VS and XCode all do their own thing, I think 
its fine to leave that translator inside cmDependsD.

>
> --Ben
>
> [1]http://stackoverflow.com/a/16969086
> [2]The dmd-depfile format probably won't fly with make upstream 
> since
> make-depfiles aren't actually a thing with make, but gcc.

Whatever CMake does with their depends.make (I didn't go that 
deep), it works on all of the different Makefile generators CMake 
supports.

  - Trent

What follows is my notes as I sorted things out:

The method 
cmLocalUnixMakefileGenerator3::WriteDependLanguageInfo() calls 
into the cmDepends* system. This method is called by 
cmMakefileTargetGenerator::WriteTargetDependRules(). This in turn 
is called by WriteRuleFiles in 
cmMakefileExecutableTargetGenerator and 
cmMakefileLibraryTargetGenerator, which is called by 
cmLocalUnixMakefileGenerator3::Generate().

The cmLUMG3 will be set as the local generator for every 
cmGlobal*Generator except for Kdevelop, Ninja, VisualStudio and 
XCode.

Upon inspection:

* Kdevelop uses the Unix Makefile generator behind the scenes
* Ninja does its own thing
* VisualStudio does its own thing
* XCode appears to do its own thing

There are also cmExtra*Generators, for completeness, I'll inspect 
them too.

* CodeBlocks: uses another Makefile generator
* CodeLight: uses a Makefile generator or Ninja
* Eclipse: uses a Makefile generator or Ninja
* Kate: Makefile or Ninja
* Sublime: Makefile or Ninja