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:

    - 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.


[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

Reply via email to