On 13 June 2017 at 05:47, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Michael Paquier wrote:
>> On Tue, Jun 13, 2017 at 3:13 AM, Alvaro Herrera
>> <alvherre@2ndquadrant.com> wrote:
>> > Ashutosh Sharma wrote:
>
>> >> Yes, that's right, Win64 download uses lib64 path and in my case i had
>> >> renamed lib64-> lib and bin64-> bin which i guess is not a right thing
>> >> to do. I think, we should allow Solution.pm to detect the platform and
>> >> make a decision on the library path accordingly. Attached patch does
>> >> that. Please have a look let me know your thoughts on this. Thanks.
>> >
>> > Uh, that's pretty odd. Is it something libicu-specific? Because I
>> > don't see any other occurrence of \lib64\ anywhere in the MSVC build
>> > scripts.
>>
>> I do some low level packaging on Windows (libxml2, libxslt, etc.), and
>> the compilation code usually allows you to usually use the
>> installation paths you want. At the end using only lib/ looks more
>> generic to me, and I did the same renaming as Ashutosh after unzipping
>> their files. There is already "Program Files" and "Program Files
>> (x86)" to make such distinctions.
>
> Oh my. And then they say Microsoft has the brightest minds in the
> planet ... (apparently they're all at Facebook nowadays actually. Go
> figure.)
Personally I think that
Program Files (x86)
was added to punish people who fail to handle paths with spaces
properly and finally make sure that everything got fixed. Because
apparently "Program Files" wasn't annoying enough already.
Ha, as if. People hard-code PROGRA~1 (the DOS shortname). And their
scripts explode if there are no shortnames assigned or Program Files
(x86) isn't PROGRA~1, it's PROGRA~2 or something else. You can't use
%ProgramFiles(x86)% outside cmd.exe scripts.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services