On 26 March 2014 23:17, Ben Boeckel <maths...@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.