On Wed, Jul 20, 2005 at 10:25:06PM -0400, DJ Delorie wrote: >> Except that "cp" is already used as a fallback for when "ln" doesn't >> work. If the tool is likely not to work after a "cp" then shouldn't the >> fallback condition be to always create a shell script (or .bat file)? > >One could argue that, in the case with ln/cp, we *know* we're dealing >with GNU tools which don't care where they are, but in the case with a >system (i.e. third party) tool, we don't know, hence the script.
Is that actually true, though? Doesn't GNU ld try to locate files relative to its invoked path? Is there a non-GNU ld out there which needs to reference things relative to its path? >There's also the complexity of locating a utility in $PATH, which may >even change between configure and make. > >IMHO for MinGW, we (1) know that we're using GNU tools, and (2) >realize we have an exceptional situation wrt the build system. I >think this justifies an exception test in that snippet of code. I hate seeing this kind of system exception in code. As much as I like MinGW, this is one of the things that bugs me about it. Adding window-isms to code can be like a creeping fungus. Danny Smith said this: >I just configure using --with-as=/path/to/original-as-for-target and I >don't run into the problem. Since we know that mingw uses GNU ld couldn't we prewire this action into configure by default and avoid the need for this kind of system-specific behavior in the makefile? cgf
