Wayne Davison wrote: > On Mon, Jul 07, 2003 at 11:05:32AM +0200, Markus Werle wrote: > > make CC="distcc --verbose --hosts=\"mach:9999 sylvie:9999\" --disable-fallback > > --compiler=icpc" > > This has a potential problem of when to stop parsing distcc options and > when to start parsing compiler options (since the build's command-line > is just appended to this). You'd have to either add an end-of-distcc- > options marker (like a trailing "--"), or perhaps require that the > --compiler option always be specified as the last option to distcc.
OK, let us specify that _any_ command line option after --compiler=<compiler> is reached through to the compiler without further modification. No problem for the parser (sorry, for _my_ C++ parser, which I'd share with you if you do not find a better one). > Another problem is that a space-containing $CC value does not always > work with all projects, Could You give an example? > and any $CC value at all may not be honored by > some build setups. Thus, for me, I never set CC and just add a distcc > masquerade dir to my PATH (along with ccache): > PATH="/usr/lib/ccache/bin:/usr/lib/distcc/bin:$PATH" make > > In such a setup, there's no way to specify those command-line options to > distcc. I see the problem and a solution: If You dislike setting CC, how about a shell script /opt/my_distcc/bin/cc which calls distcc --verbose --hosts=\"mach:9999\" --disable-fallback --compiler=icpc and PATH=/opt/my_distcc/bin:$PATH > An alternative would be to have a control program that the user > could run to setup how distcc will run. For instance: > > distcc_control --verbose --hosts="mach:9999 sylvie:9999" --disable-fallback > --default-compiler=icpc My opinion is strongly against such a solution. 1. environment vars and default config files are like global variables. I found that a little redesign can let you get rid of those giving you more reliability and easier control. 2. A second tool that must be called with lasting side effects is unnecessary. Runtime behaviour is always controllable through command line args plus optional config file. A program which leaves the environment changed after termination is the worst case of all (IMHO) > Then, if the user runs distcc_control without any options, they'd get > a summary of how distcc was setup to run. distcc --help will present the defaults. > The control program could > either set environment variables or manipulate config-file settings in > a config dir, depending on how Martin wants to make it controlled. Martin, yes. I respond to him in a minute. (CC'ed to this ML). > If there is a change from the environment to files, it would have to be > flexible enough to not assume that ~/.distcc was the dir to manipulate > because the gentoo setup would not work well with this when HOME > changes during an emerge compile. E.g. I'd want root to manipulate the > config in /etc/distcc, and the portage user to fallback to this config > when there was no per-user config present in ~/.distcc. I current use > this method of choosing where the distcc hosts file should be stored > (in my distcc_probe perl script that scans available hosts and > manipulates the current host setup). Which brings us to the question, why a user tool must have config in /etc. This is unnecessary binding between the tool and the system. Just too comlicated: note that this discussion started because I wanted distcc to simply add some "-xc++" to remote calls. Markus __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
