Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Mon, Sep 12, 2016 at 1:47 AM, Tom Lane wrote: > Looks reasonable to me, we'll soon see what the buildfarm thinks. Thanks for the commit. I am seeing green statuses on the buildfarm. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

Michael Paquier writes: > On Sun, Sep 11, 2016 at 1:03 AM, Tom Lane wrote: >> It might accidentally fail to fail as-is, but likely it would be better >> not to be pushing garbage paths into extraincludes and extralibs when >> some of those options

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Sun, Sep 11, 2016 at 1:03 AM, Tom Lane wrote: > It might accidentally fail to fail as-is, but likely it would be better > not to be pushing garbage paths into extraincludes and extralibs when > some of those options aren't set. Right, we need to correct something here. But

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

Michael Paquier writes: > Thanks. I was a bit too lazy to look at the history to get this piece > of history out... And so the code that is presently in the MSVC > scripts should have been updated at the same time as those > compilations have been relaxed, but it got

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

Michael Paquier writes: > Thanks. I was a bit too lazy to look at the history to get this piece > of history out... And so the code that is presently in the MSVC > scripts should have been updated at the same time as those > compilations have been relaxed, but it got

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Thu, Sep 8, 2016 at 10:04 PM, Tom Lane wrote: > The core code has never used xslt at all. Yes. > Some quick digging in the git > history suggests that contrib/xml2 wasn't very clean about this before > 2008: > [...] > Both of those fixes postdate our native-Windows port,

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

Michael Paquier writes: > On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander wrote: >> Pretty sure this goes back to *our* XML support requiring both. As in you >> couldn't turn on/off xslt independently, so the "xml requires xslt" comment >> is that

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Thu, Sep 8, 2016 at 2:53 PM, Michael Paquier wrote: > On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander > wrote: > > Pretty sure this goes back to *our* XML support requiring both. As in you > > couldn't turn on/off xslt independently, so the

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Thu, Sep 8, 2016 at 9:39 PM, Magnus Hagander wrote: > Pretty sure this goes back to *our* XML support requiring both. As in you > couldn't turn on/off xslt independently, so the "xml requires xslt" comment > is that *our* xml support required both. > > This may definitely

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Thu, Sep 8, 2016 at 9:27 PM, Tom Lane wrote: > Michael Paquier writes: >> But I don't understand the reason behind such a restriction to be >> honest because libxml2 does not depend on libxslt. The contrary is >> true: libxslt needs libxml2. > >

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

On Thu, Sep 8, 2016 at 2:27 PM, Tom Lane wrote: > Michael Paquier writes: > > But I don't understand the reason behind such a restriction to be > > honest because libxml2 does not depend on libxslt. The contrary is > > true: libxslt needs libxml2.

Re: [HACKERS] Useless dependency assumption libxml2 -> libxslt in MSVC scripts

Michael Paquier writes: > But I don't understand the reason behind such a restriction to be > honest because libxml2 does not depend on libxslt. The contrary is > true: libxslt needs libxml2. Right. > Note as well that libxml2 does depend on ICONV though. Hm, is that