On 5/20/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
contrib is a misnomer at best. When 8.3 branches I intend to propose
that we abandon it altogether, in line with some previous discussions.
We can change the configure help text if people think it matters that
much - which seems to me much m
Nikolay Samokhvalov wrote:
The current CVS' configure is really confusing: it has "--with-xslt"
option, while there is no XSLT support in the core. At least let's
change the option's comment to smth like "build with XSLT support (now
it is used for contrib/xml2 only)"...
contrib is a misnom
On 4/15/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
Well, if we're going to make libxslt an explicit thing, then it'd be
trivial to add an xslt transformation function into the core, and then
I think we can claim equivalent support. But we'll have to check the
details, of course.
I have bee
Andrew Dunstan wrote:
> I don't think it should go away until we provide for equivalents in
> core, at least optionally.
Well, if we're going to make libxslt an explicit thing, then it'd be
trivial to add an xslt transformation function into the core, and then
I think we can claim equivalent sup
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Peter Eisentraut wrote:
But the policy is that the presence of features in the final build
should not depend on the incidental presence of features in the build
environment. Either you select a feature, then it's built, or y
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Peter Eisentraut wrote:
>>> But the policy is that the presence of features in the final build
>>> should not depend on the incidental presence of features in the build
>>> environment. Either you select a feature, then it's built,
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> But the policy is that the presence of features in the final build
>> should not depend on the incidental presence of features in the build
>> environment. Either you select a feature, then it's built, or you
>> don't, then
Bruce Momjian wrote:
Andrew Dunstan wrote:
Peter Eisentraut wrote:
And if it is, then you have several options:
. don't configure with libxml, or
. don't build contrib modules from the contrib Makefile (use the
individual module Makefiles instead), or
. change the xml2 Makefile
Peter Eisentraut wrote:
Andrew Dunstan wrote:
The attached patch adds a test for libxslt/xslt.h and only builds
contrib/xml2 if it's found,
But the policy is that the presence of features in the final build
should not depend on the incidental presence of features in the build
envir
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The attached patch adds a test for libxslt/xslt.h and only builds
contrib/xml2 if it's found, which I think should handle Peter's
objection, as well as unbreak the buildfarm. (The patch is large because
cvs diff seems to have beha
Andrew Dunstan wrote:
> The attached patch adds a test for libxslt/xslt.h and only builds
> contrib/xml2 if it's found,
But the policy is that the presence of features in the final build
should not depend on the incidental presence of features in the build
environment. Either you select a featu
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The attached patch adds a test for libxslt/xslt.h and only builds
> contrib/xml2 if it's found, which I think should handle Peter's
> objection, as well as unbreak the buildfarm. (The patch is large because
> cvs diff seems to have behaved a bit oddly
Bruce Momjian wrote:
Andrew Dunstan wrote:
Peter Eisentraut wrote:
And if it is, then you have several options:
. don't configure with libxml, or
. don't build contrib modules from the contrib Makefile (use the
individual module Makefiles instead), or
. change the xml2 Makefile
Bruce Momjian wrote:
Andrew Dunstan wrote:
Peter Eisentraut wrote:
And if it is, then you have several options:
. don't configure with libxml, or
. don't build contrib modules from the contrib Makefile (use the
individual module Makefiles instead), or
. change the xml2 Makefile
Andrew Dunstan wrote:
> Peter Eisentraut wrote:
> >> And if it is, then you have several options:
> >> . don't configure with libxml, or
> >> . don't build contrib modules from the contrib Makefile (use the
> >> individual module Makefiles instead), or
> >> . change the xml2 Makefile
> >>
> >
Peter Eisentraut wrote:
And if it is, then you have several options:
. don't configure with libxml, or
. don't build contrib modules from the contrib Makefile (use the
individual module Makefiles instead), or
. change the xml2 Makefile
Any of these could be worth considering, but it needs
Andrew Dunstan wrote:
> Well, how often is libxslt missing when libxml is present, in
> practice?
A local sample shows a probability of 100%.
> And if it is, then you have several options:
> . don't configure with libxml, or
> . don't build contrib modules from the contrib Makefile (use the
> in
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Since contrib/xml2 seems to be staying with us at least for now, this
small patch enables it to be built and installed from the contrib
Makefile when --with-libxml is given to configure.
contrib/xml2 also requires libxslt.
Well, how oft
Andrew Dunstan wrote:
> Since contrib/xml2 seems to be staying with us at least for now, this
> small patch enables it to be built and installed from the contrib
> Makefile when --with-libxml is given to configure.
contrib/xml2 also requires libxslt.
--
Peter Eisentraut
http://developer.postgres
19 matches
Mail list logo
