On Thu, Mar 27, 2014 at 01:52:00 +0000, Trent Forkert wrote:
> I've tested this by creating a wrapper script around dmd to log calls
> to it in a file. Using that, I can confirm that cmDependsD does
> nothing at configure time. Granted it didn't refresh the deps file
> when I updated my D code, but...
> I've also tested with a simple C project (to confirm I no D-related
> bugs get in the way) that depend.make is generated and updated at
> build time. After building, I went and updated my C file to point to
> a new header it hadn't touched before, re-ran make (not cmake), and
> checked that depend.make listed now the header as a dependency (it
> did). To be extra sure, I reverted the change to the C code, and ran
> make again. depend.make was updated to remove the header dependency.
> The reason cmDependsD didn't update deps at build-time when I tried
> appears to be a matter of implementing another method I haven't got
> to yet.

Well, that shows my ignorance of now cmDepends works. I now see that it
is hooked through 'cmake -E cmake_depends' and not run during configure
(as it living within a generator led me to believe). So the goal of
using the compiler for this rather than C++ code would be to not have
the C++ code in the first place. I'd guess it'd also have make build a
lot faster (CMake performance being another recent and ongoing focus of

> Yeah, I'm set up to work on Windows and Linux at the moment. Despite
> using a Macbook, I almost never touch OS X ^_^.

XCode updates are a cause for dread from CMake developers. Lots of
things always break :( . I don't know if I'll be able to find any
willing victims (currently, Ninja bails ASAP on Fortran; making XCode do
so for D is probably workable until someone cares enough to write

> I can do something like that if its needed, I think. cmDependsFortran
> appears to generate dependency rules that call CMake, and 'cmake -E
> cmake_depends ...' is the command that is actually used to generate a
> depend.make. But, as I said above, cmDepends is a build-time thing.
> It's more obtuse about it than the Ninja generator is, but it is
> still build-time.

I'll have to ask Brad what he perfers for cmDepends* going forward. I
don't know the full ramifications of removing it.


Reply via email to