On Wed, Apr 02, 2014 at 03:59:47 +0000, Trent Forkert wrote:
> My understanding of INTERFACE properties is that they are used when dealing with importing/exporting targets. If this is the case, I'm not sure of a case when text includes would need to be provided through this. Text imports work at compile time, literally putting a string of the contents of the specified file where the import() was.

They're also used within a project. This would be required if, e.g., a project installs modules intended to be text-imported and installs them to somewhere like /usr/include/d/_text/path/to/module.d. Granted, I have no idea if this even makes sense, but that would be one example :) . There also may be things like DDoc flags if cross-referencing is supported (such as where to look for any equivalent of Doxygen's .tag files).

> Yeah, I'm not sure there's much I can do about that. I have to choose between scanning textually imported files as dependencies (which they are) or supporting older compilers. Granted, the Ninja dependency resolution doesn't register text imports, since I have to specify the filename in the arguments. "-deps > <DEPFILE>" could work, but we would have to ensure that it comes last on the command line.

So I talked to Brad about the rationale behind the cmDepends files:

  - Fortran requires it because Fortran is Fortran[1];
  - Java is lacking compiler support; and
  - C is supported because it is considerably faster than the compiler
    (it looks at a target-at-a-time rather than per-TU so headers
    included multiple times are parsed once). One downside is that #if
    is completely ignored and if CMake can't find a file it assumes the
    build is sane and skips ignores the #include directive[2].

One way Brad suggested is to do this is to overload the (internal) -E cmake_depends command to do execute the D compiler internally, read the depfiles over a pipe and write a (Make-format) depfile itself. This would absolve Ninja from needing to read the DMD depfile format (at the expense of any non-CMake build system not also doing the work), but also mean that make VERBOSE=1 doesn't have the actual compilation command verbatim for easy inspection. It also means we're not executing the compiler then executing CMake to execute the compiler again with slightly different flags.

Honestly, I think supporting older, existing compilers is more important because they are usually harder to upgrade and the build tool should not dictate such things (to a point; complaining that GCC 1.0 is unsupported is just being a troll at this point :D ).

Also, if you can support a single-shot per-target dependency scanning like C, you'd likely beat the compiler anyways since you're only reading duplicate files once.

> "-deps=<DEPFILE>" doesn't output all the same information as "-deps > <DEPFILE>". Same holds for GDC and LDC equivalents.

That's…unfortunate :( . Though knowing where the -deps= writer lives in DMD (the implementation of the import keyword rather than the lexer), this probably doesn't surprise me.

--Ben

[1]At compile time, you may discover that you depend on a .mod file generated by another source file's compilation, and not just the .f file[3]. This means that A.f requiring B.mod from B.f can't be decided until B is compiled before A. You can make it work with depfiles and "compile iteratively until it discovers all the links", but that's asinine to request of users. AFAIK, D does not do such silliness. [2]Also unsupported is things like #include <MY_HEADER> under -DMY_HEADER=stdio.h silliness. Yes, this works (look at boost headers and search for BOOST_PP_FILENAME). [3]http://compgroups.net/comp.lang.fortran/gfortran-and-m/2696739