CMake with D support early snapshot

[Iain Buclaw]

On 26 March 2014 23:17, Ben Boeckel <mathstuf at gmail.com> wrote:
> On Wed, Mar 26, 2014 at 22:52:43 +0000, Trent Forkert wrote:
>> However, if we have gdc produce make-style dependencies (which will
>> still require processing to get CMake to be happy), that requires me
>> to put a special case in the C++ that I'd rather not have.
>
> I'm fine with either, but make-style is preferred since it can exclude
> system files (which I've asked LDC about supporting as well; should ask
> dmd too).
>
>> The way I see it, there are three possibilities here:
>> 1. Keep gdc producing make-style deps, and deal with that as needed.
>> 2. Have gdc produce dmd-style deps, and let the patched Ninja you
>> mentioned use that.
>> 3. Have a separate flag registered for the two different styles of
>> dependencies.
>>
>> I'm quite partial to number 3, as I could then use that to check
>> which flags are defined for which style is supported, and act
>> accordingly. I prefer that to hardcoding "gdc does this. Anything
>> else does this other thing."
>
> What about:
>
>   4. Add depfile support to Makefile generators.
>
> It seems that it shouldn't be *too* hard[1] to do. Obviously, dmd-style
> deps will still have problems with make, but we could try and ask the
> dmd and ldc upstream to at least support Make-style dependency files
> (this would mean old dmd/ldc + make isn't supported, but at least Ninja
> would be an option there). If that fails, some CMake code to generate
> Make-style .d files from dmd-style shouldn't be too bad (some regex
> matching and character escaping should do the trick).
>

Ain't the dmd-style deps legacy from a failed D build system?

It's just kept around cause more recent/current build systems /may/
find it's output useful.