CMake with D support early snapshot

[Ben Boeckel]

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[1] few[2] solutions[3], 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
module.

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

    %.o: %.d
    %.d: %.dmd.d
        -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
> cmLocalUnixMakefileGenerator3::Generate().

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

--Ben

[1]http://dblog.aldacron.net/2010/03/22/d-for-xcode-now-with-dmd-support/
[2]http://michelf.ca/projects/d-for-xcode/
[3]http://prowiki.org/wiki4d/wiki.cgi?EditorSupport/AppleXcode