Bug 6622 – rdmd --makedepend lists "dmd.conf" and "dmd"

// --- k.d --- // (empty) // ---------- // --- m.d --- import k; void main(){} // --------- [Bug] # rdmd --makedepend m.d m.d : /Library/Compilers/dmd2/osx/bin/dmd.conf k.d /Library/Compilers/dmd2/osx/bin/dmd # rdmd rdmd build 20110906 ... # _ [Expected results] # rdmd --makedepend m.d m.d : k.d # _ _____ (Side note: I'm using this to build makefile dependencies on the fly, like this SERVER_D_FILES = $(shell rdmd --makedepend src/server.d | cut -d : -f 2) Can anyone figure out a simple workaround for this, except adding all the files manually? Side note 2: It would be nice if DMD could handle this on its own hint hint...) _____ PS. Very nice release anyway! thanks

(This is D 2.055)

This is somewhat expected behavior: if you update your compiler or edit the compiler's configuration, the whole project should be rebuilt. Do you think that rdmd should omit listing these dependencies in its --makedepend output?

Ah, I see. Well, that does sound well-meaning. Hm, but, how can rdmd --makedepend claim to know which dmd-binary I'm using in my Makefile? How does it even know I'm going to use dmd, and not gdc, or ldc? I suppose the tool being named "rdmd" could imply dmd is assumed, but then again, outputting text to be used in a Makefile implies rdmd is trying to be a part of a Makefile-work-flow. Ok, I realize I've just assumed that, maybe it isn't (?), but if it is, then I think including "dmd.conf" and the "dmd"-binary makes rdmd a bit presumptuous. So, yes, I think these files should be omitted. Although I don't have the expertise to say anything decisive about this. Is this the convention in Makefiles? Is the g++-binary usually listed as a dependency? I have no idea. As long as rdmd at least outputs d-files I'm happy! *** In any case, here's how to just get the d-files from the --makedepend output, and this is probably embarrassingly obvious, but for Makefile-hobbyists like me it's good stuff : ) D_FILES_WITH_PATHS = $(filter %.d, $(MAKEDEP_OUTPUT))

"Hm, but, how can rdmd --makedepend claim to know which dmd-binary I'm using in my Makefile? How does it even know I'm going to use dmd, and not gdc, or ldc?" At the moment, RDMD itself is very DMD-specific. It only ever uses DMD to build things and to check dependencies. I don't know whether or not there are any plans to broaden the scope to include LDC or GDC (although I doubt a well-written pull request for it would be rejected - not that I'm any authority on the matter.) As for which DMD is used, it's always whichever one would be called if you just typed "dmd" on the command line. So, whichever one is on the PATH. (And of course, on Windows, if there's a 'dmd' in the current directory, then that takes priority, as is always the case on Windows.) RDMD doesn't directly choose which dmd executable and dmd.conf/sc.ini to consider dependencies. It actually gets that information the same way it gets the list of .d files: from calling "dmd -deps=filename". The output of that includes the .d files and also its own path and the dmd.conf/sc.ini file used. You do raise a good point though. Obviously "rdmd --makedepend" is intended to generate output for a makefile. And it does make sense that when using make, it's the makefile's job to choose the exact compiler to use (even if that happens to just be "the default one on the PATH"). So it would seem "rdmd --makedepend" should be completely compiler-independent. OTOH, I can see a couple possible points against omitting these two files from "rdmd --makedepend": 1. What if you do want dmd.conf/sc.ini considered a dependency in the makefile? It'd be a fair bit of work. You'd have to figure out which DMD is the default on the PATH (assuming the makefile is just invoking plain old "dmd"). The you'd have to figure out which dmd.conf/sc.ini would get used. 2. What if the code includes something like this?: // I probably have these identifiers wrong, but whatever. version(DMD) include foo_dmd; else version(GDC) include foo_gdc; else version(LDC) include foo_ldc; Or something like this: // "LittleEndian" was changed to "littleEndian" in DMD 2.055 // Basically, this could be anything in Phobos that's changed // between two versions of DMD. static if(__traits(compiles, Endian.littleEndian)) include foo_A; else include foo_B; Point #2 leads me to believe that the *only* correct solution is to optionally be able to tell RDMD which compiler you want (and at what path), and then consider the output from "rdmd --makedepend" to be specific to that particular compiler installation. Therefore, I think I'm inclined to consider the current behavior correct (and I'll file an enhancement request for "tell RDMD which DMD to use" if one doesn't already exist). This does make it more important for RDMD to properly support LDC/GDC in general (which, IMO, it should support anyway). Regarding your *.d-filtering workaround, that might need to be modified slightly (depending what exactly you're doing). I think it's possible that some of the dependencies output could be .di files. Also, any .obj files passed into rdmd should probably be in there, too (If they don't, I'd probably consider that a bug.) Also .lib/.a files, too, at least once issue 6431 is fixed. There might be some other extensions, too. So all of those files should ideally make their way into the makefile. (Although I never use make, so I'm no expert on it.)

"(and I'll file an enhancement request for "tell RDMD which DMD to use" if one doesn't already exist)" Here: issue 6628

Sorry, that was pretty long-winded, so let me summarize: I believe the current behavior is correct. Why? Because the list of .d dependencies is *inherently* dependent on the *specific* compiler, anyway. Due to the language itself, there's no getting around that. So even if dmd.exe and dmd.conf/sc.ini are omitted, the results of "rdmd --makedepend" are *still* dependent on the specific compiler used. Why is the .d list dependent on the specific compiler? Because there might be conditional includes: // I probably have these identifiers wrong, but whatever. version(DMD) include foo_dmd; else version(GDC) include foo_gdc; else version(LDC) include foo_ldc; // "LittleEndian" was changed to "littleEndian" in DMD 2.055 // Basically, this could be anything in Phobos that's changed // between two versions of DMD. static if(__traits(compiles, Endian.littleEndian)) include foo_A; else include foo_B;

(In reply to comment #6) > Why? Because the list of .d dependencies is *inherently* dependent on the > *specific* compiler, anyway. Question: if the output of "rdmd --makedepend" is only usable on the current system, is there still a valid use for it? Why not just use rdmd? Using "rdmd --makedepend" to generate makefiles ready for redistribution can be seen a valid use case when the user knows that their code base does not contain imports which change depending on the environment - in which case, this bug report would be valid.

"Question: if the output of "rdmd --makedepend" is only usable on the current system, is there still a valid use for it? Why not just use rdmd?" "Using "rdmd --makedepend" to generate makefiles ready for redistribution..." To be honest, even if the output of "rdmd --makedepend" were 100% portable, I'm still not sure I see a compelling reason to use it to generate redistributed makefiles. (At least if rdmd gains support for ldc and gdc, that is.) The user would still need a D compiler, and if they have that, they should have rdmd (Side note: If rdmd does support ldc and gdc, then there's no reason why it shouldn't come packaged with those too. Or at least be trivially installable with one or two simple commandline statements). So why pipe it all through make? It would only create a need for people to re-generate the makefile when source files are added or renamed, and wouldn't provide any benefit (after all, rdmd can be invoked from a makefile). "...when the user knows that their code base does not contain imports which change depending on the environment" That strikes me an error-prone, inadvisable thing to rely on.

Interesting! I can see this is a bit more complex than I thought. I don't know the convention here but as I opened this and all, I thought I'd just say that I'm happy with this bug being closed! Not saying that I know if it should be or not. Anyway, it seems including these files is the "right thing to do", even if perhaps not practical for me specifically, but of course I'm not demanding that :) Just don't make this feature disappear! It's immensily useful when building several targets from one single code base that mixes D with other langauges. I'd rather give up coffee than --makedepend! (Ok, maybe not, still, very close..)

"Question: if the output of "rdmd --makedepend" is only usable on the current system, is there still a valid use for it? Why not just use rdmd?" Now that I think about it more, yes, even then it could still be useful if you need to do anything else with the .d files besides just send them to the compiler.

OK, let's close this issue. It should be easy to filter or manually edit out bits of the resulting makefile to get it to the level of specificity you need, whereas leaving dependencies out could lead to some unexpected consequences.