CMake with D support early snapshot

[Trent Forkert]

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