On Thursday, 27 March 2014 at 01:16:57 UTC, Ben Boeckel wrote:
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.

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.

You're right that examine_d_source only worked at configure time, but cmDepends works at build time.

Ninja is fine with the 'deps = dmd' solution.

I will go with that then.

VS will need VisualD I
imagine (probably fine to require)

It absolutely does.

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.

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

Recursive public (non-static?) imports is the proper, minimal way to do it; you may be getting an import implicitly via another forwarding

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)

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.

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


 - Trent

Reply via email to