On Mon, 17 Jun 2013, at 10:07, Andrew DeFaria thusly quipped:
On 06/17/2013 08:12 AM, gmt@malth.us wrote:
Why not simply fix the "not very well written configure scripts and
makefiles"instead? BTW I've never come across a single one of those.
Where are you getting yours?
Can't answer this offhand (aware you didn't ask me :P) but, under the
misguidance of PM's like Gentoo(portage) and rpm(build), when combined
with poorly and/or belligerently written packaging scripts, this can
happen incessantly. But that mostly only comes up when building
Frankencygwins. Sometimes you can fix it by forcing something like
--prefix=///usr/local.
I'm trying to understand the reluctance towards "fixing the problem" and
instead
the insistence on "putting a band aid on it". So in the above, why would
you not
instead do --prefix=/usr/local?
This is indeed a band-aid in the truest sense of the metaphor. It relies
on the specificity of POSIX's reservation of "//" for platform purposes (and
cygwin's correct implementation of same) -- unlike "//", anything matching
the regex "^///[/]*$" is, indeed, equivalent to "/". So, as if the POSIX
"//" reservation wasn't an obscure enough fact, here is a way to /really/
impress people at cocktail parties :)
As to why not fix the upstreams committing these atrocities, it's the
obvious reason -- occasionally one encounters a large body of dense,
non-fixable-by-sed/perl, poorly commented "spaghetti" script-code that makes
"clever," deep usage of the assumption that "//" == "/". Being able to turn
this feature off at one's option would enable them to rule out "//" as a
problem when they suspect it might be, and have the additional benefit of
not having to fix such code, in order to run it.