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 been
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 misnomer
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
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
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
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
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
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 [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 it's not.
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 you
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
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
Any of these
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 [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 with
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.
If there's no objection I'll apply in a day or two.
cheers
andrew
Index: configure
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
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
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
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
20 matches
Mail list logo
