CMake with D support early snapshot

[Ben Boeckel]

On Wed, Mar 26, 2014 at 22:52:43 +0000, Trent Forkert wrote:
> However, if we have gdc produce make-style dependencies (which will
> still require processing to get CMake to be happy), that requires me
> to put a special case in the C++ that I'd rather not have.

I'm fine with either, but make-style is preferred since it can exclude
system files (which I've asked LDC about supporting as well; should ask
dmd too).

> The way I see it, there are three possibilities here:
> 1. Keep gdc producing make-style deps, and deal with that as needed.
> 2. Have gdc produce dmd-style deps, and let the patched Ninja you
> mentioned use that.
> 3. Have a separate flag registered for the two different styles of
> dependencies.
> 
> I'm quite partial to number 3, as I could then use that to check
> which flags are defined for which style is supported, and act
> accordingly. I prefer that to hardcoding "gdc does this. Anything
> else does this other thing."

What about:

  4. Add depfile support to Makefile generators.

It seems that it shouldn't be *too* hard[1] to do. Obviously, dmd-style
deps will still have problems with make, but we could try and ask the
dmd and ldc upstream to at least support Make-style dependency files
(this would mean old dmd/ldc + make isn't supported, but at least Ninja
would be an option there). If that fails, some CMake code to generate
Make-style .d files from dmd-style shouldn't be too bad (some regex
matching and character escaping should do the trick).

> It should be noted that (AFAICT), the Ninja generator is the only
> thing that even considers ${CMAKE_DEPFILE_FLAGS_<lang>}. All the
> Makefile generators (basically everything but Ninja, VS, and possibly
> XCode) use the cmDepends system.

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?

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)
  - 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])

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