On 7 Oct 2002, Terry Griffin <[EMAIL PROTECTED]> wrote: > Not an attractive option. If I do that then I need another invocation of > the compiler with -M just to generate the .d files. That extra invocation > wipes out much of the gains from using distcc in the first place.
That would put in the situation of having a separate "make depend" stage, as is used by for example the Linux kernel. Of course this doesn't have to be run every time, only when you think the dependencies are out of date. Since updating dependencies doesn't require running the compiler but only the preprocessor it's actually pretty cheap. I'm not saying it's a great solution, but it is probably still a net win. Of course it goes against distcc's goal of not requiring changes to Makefiles, but if the compiler is wierd there's a limit to what we can do. > It seems like the way to deal with this, and other compiler oddities that > are sure to turn up in the future, is to write little wrapper scripts > around the compilers that account for differences. Think of it as a plug-in > architecture for distcc. If distcc wanted to support things very different to gcc then it would probably be needed. It may be needed if gcc behaviour varies greatly between versions, but with the exception of the case you've found that doesn't seem to be true. On the other hand, it would probably require either a specific configuration of which script to use, or for distcc to interogate "cc --version" and try to guess. Both of those are unattractive for various reasons. As you probably realized you can do this now just with "distcc mycc" where mycc is sh or perl or whatever to strip out some options. -- Martin _______________________________________________ distcc mailing list [EMAIL PROTECTED] http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
