On Mon, 17 Jun 2013, at 10:07, Andrew DeFaria thusly quipped: > On 06/17/2013 08:12 AM, g...@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. -gmt -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple