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