On 11/16/09, Paul Smith <psm...@gnu.org> wrote: > On Mon, 2009-11-16 at 19:55 -0500, Mike Shal wrote: > > d! How the heck should you or I know what files need to be modified > > just because a new header was added? > > > Are you kidding me? You BETTER darn well know. Otherwise, your code > will not compile, or even worse it may compile but give you completely > incorrect results. You can't just go around adding headers without > knowing what impact that will have on the code!
No, I wasn't kidding about that either. I guess in my head I was comparing it to the case where you modify an existing header. Here, I expect make to re-compile every C file that is affected by the change. That way I know which files don't compile in case I did something wrong. I don't try to memorize all the C files that include that header. Similarly, if I add a new header, I expect make to re-compile every C file that is affected by the change. That way I know which files don't compile in case I did something wrong. I don't try to memorize all the C files that tried to include that header earlier in their include path, but didn't because it wasn't there. Ignoring the specifics of make for a moment, I don't see why these two cases should be so different that the build system is responsible for handling the first case, but the user is responsible for the second. > But, you seem to have discovered a way to do what you want and this > discussion has moved away from technical solutions into the murky realm > of process and "best practices", so it seems a good place to stop. Sorry to hijack the thread -- I'll get off my soapbox now :). But for the record, I wasn't really advocating having a crazy include path with config.h's strewn all over the place. That would drive me crazy too... -Mike _______________________________________________ Help-make mailing list Help-make@gnu.org http://lists.gnu.org/mailman/listinfo/help-make
