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
