On Thu, Mar 27, 2014 at 00:38:05 +0000, Trent Forkert wrote:
> On Wednesday, 26 March 2014 at 23:17:31 UTC, Ben Boeckel wrote:
> > 4. Add depfile support to Makefile generators.
> That's basically what I'm doing, though only in the context of D.
No, I meant, using the DEPFLAGS during the make build (like ninja does)
rather than doing it at configure time.
> 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.
'git grep' is your friend :) . ('git grep -l cmDepends')
> So, we'll still need to get Ninja, VS, and XCode dependency
> separately, but cmDepends handles the all other generator's
> dependency resolution.
Ninja is fine with the 'deps = dmd' solution. VS will need VisualD I
imagine (probably fine to require), and XCode will need someone who
cares enough to look into it (not me...) ;) . A cursory search
finds a few solutions, but that's about the limit of my
attention span for XCode+D right now.
> 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.
Recursive public (non-static?) imports is the proper, minimal way to do
it; you may be getting an import implicitly via another forwarding
> 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.
I think I was unclear: I'd like to see the dependency resolution done at
build time, not configure time. That's why there'd be something like:
-cmake -DINPUT="$<" -DOUTPUT="$>" -P cmake_root/CMakeDMDToMakeDeps.cmake
-include $(wildcard *.d)
or something in the Makefile if depfile support is detected (that
snippet is a circular dependency, but maybe the CMakeDMDToMakeDeps.cmake
could be placed into the %.o recipe after the compile step and make
knows nothing of .dmd.d files. I'll have to ask Brad why Make was never
converted off of cmDependsC when DEPFILE support was added.
> 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
My suggestion is to remove the cmDepends calls with rules to chain up a
.d depends rule supplement when available.
> 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
My understanding (without looking): the extra generators basically do
some scaffolding to write IDE files which just tell the IDE how to run
the internal generator, possibly with a list of targets, sources, and
whatnot for those which can't manually inspect the build files