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 > module. > >> 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/ CMakeDMDT oMakeDeps. 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 > themselves. Correct. - Trent