CMake with D support early snapshot

[Ben Boeckel]

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