Created attachment 20685 [details] [review]
proposed patch

You must explain your patches, for example the following sounds
just wrong: 

-libexslt_la_LIBADD = $(INSTALLED_XSLT_LIB) $(EXTRA_LIBS)
+libexslt_la_LIBADD = $(top_builddir)/libxslt/libxslt.la
$(LIBXML_LIBS) $(EXTRA_LIBS)

  Why do you do this ? In what environments did you test ?
It's very easy to change the configure.in to adapt to a new
process. But it's very hard to do so without breaking the build
in all the others configurations. Since your patch seems to take
no caution about the existing standard processing I don't feel
I can safely apply it. So 
  1/ explain what this patch is doing in detail and why
  2/ if changing some of processing for a specific option
     then make 100% sure that the change you introduce will
     not break the processing if that option is not enabled

  Sorry I can't apply this in the current state,

Daniel

Proposed patch try to fix build/check/install problems when libxml2
and libxslt are build outside source tree.

1.) configure options "--with-libxml-src" is replaced with
"--with-libxml-source" and "--with-libxml-build"
2.) COPYING should be in source dir
3.) install doc/*png files and target for html doc is
$(DESTDIR)$(TARGET_DIR)/html
4.) use $(source) in python dirs
5.) use "libxml build dir." for python tests

P.S.:
installed: libxml2-2.4.30 and libxslt-1.0.20 in /usr/{include|lib}
tests with: libxml2-2.5.10 and libxslt-1.0.32 - without installation

In this environment I cannot use INSTALLED_XSLT_LIB ;-)

I understand the reason for the patch. I do not understand and
actually disagree with some of the changes. What I ask you is
to provide explanation for the actual changes, in detail. Then
it will help avoiding breakage in other environments.
I pasted one of the change which I'm nearly 100% sure will completely
break nearly all other builds. And I cannot afford to break all
other builds because one person has a specific need and patched
the configure.in file without care, sorry !

Daniel

first lets see changes in ./doc/Makefile.am (outside subject of bug):

Without patch, after install, go to .../usr/share/doc/libxslt-1.0.32/html
and run 'grep html/libxslt API*.html' - output show that we should
install $(srcdir)/html/*.html into $(DESTDIR)$(TARGET_DIR)/html
Look into libxslt*html show that we should install
$(srcdir)/html/*.png files too.

I cannot config that my patch fix all broken links in html docs, only
most of them.

Can you agree with this changes ?

To me the API*.html are installed in /usr/share/doc/libxslt-1.0.33
not in /usr/share/doc/libxslt-1.0.33/html , I get
APIchunk7.html:<a
href="html/libxslt-xsltutils.html#XSLTSETGENERICERRORFUNC">xsltSetGenericErrorFunc</a>
and 
paphio:/usr/share/doc/libxslt-1.0.33 -> ls html/libxslt-xsltutils.html
html/libxslt-xsltutils.html

That mean in my setup, generated by installing on /usr, the links
are okay. So your patch would even break those as far as I can tell.
So no it seems I even disagree with that part of the patch, I prefer
to have a correct installation for the 99% of the people who get
the preinstalled package than tweak and break it for them in order
to fix some problem for the unfortunate people like you who don't
use the default installation.

Daniel

Daniel

:-/ very strange
doc/Makefile.am from current:
==================================================================
...
HTML_DIR=$(datadir)/doc
...
TARGET_DIR=$(HTML_DIR)/$(DOC_MODULE)/html
...
install-data-local: 
...
  -@INSTALL@ -m 0644 $(srcdir)/*.html $(DESTDIR)$(TARGET_DIR)
...
  -@INSTALL@ -m 0644 $(srcdir)/html/*.html $(DESTDIR)$(TARGET_DIR)
...
==================================================================
All *.html and html/*.html go in one folder, i.e. API*.html and
libxslt-*.html are installed in same folder.

CFLAGS="-O2 -Wall" ./configure --prefix=/usr --build=XXXX
make
make install DESTDIR=/tmp/checks/libxslt

Hum, okay, in that specific case this might be the RPM build
which moves things in the right place in my setup. I applied
that part of the patch, it makes sense . Did the same for libxml2.

  thanks,

Daniel

Created attachment 20809 [details] [review]
updated to CVS from 20031020

Env.:
- libxml2 (CVS-20031020) is build in source tree.
- libxslt (CVS-20031020):
  .../configure ... --with-libxml-src=<from_above>

attachment with id=20809 solve these problems when libxslt SOURCE !=
libxslt BUILD directory:

1.)
$ cd <BUILD>
$ <SOURCE>/configure ...
$ cd <SOURCE>
$ automake
...
Makefile.am: required file `./COPYING' not found

2.) AC_SUBST(LIBXML_SRC) and LIBXML_SRC in ./python/tests/Makefile.am:
ImportError: ..../libxslt/.libs/libxslt.so.1: undefined symbol:
xmlIsBaseCharGroup
make[2]: [tests] Error 1 (ignored)
make[2]: Leaving directory `.../python/tests'

3.) might is better python tests to be performed in <SOURCE>
-- basic.py
I/O warning : failed to load external entity "test.xsl"
-- exslt.py

Okay, I have applied the patch in attachment 20809 [details] [review], this make sense
overall,

  thanks,

Daniel

Commited to CVS,

Daniel

Created attachment 21235 [details] [review]
more against CVS from 20031106

About attachment with id=21235:
- exit code of xslproc for some test is non zero and execution of test
shell script break at this point on some system (tested on OpenBSD, on
linux we can found problem with command "make check SHELL="/bin/sh
-e") => Makefile must contain -(minus) before command
- use -path for "stand" test from tests/REC
- run tests from "tests/general" "tests/reports" in srcdir
- AC_ARG_PROGRAM is commented to suppress warning

Now I have only one difference:
=============
make[2]: Entering directory `XXXX/tests/documents'
1,2c1,2
< warning: failed to load external entity "foofile.xml"
< warning: failed to load external entity "foo_file.xml"
---
> warning: failed to load external entity
"XXXX/tests/documents/foofile.xml"
> warning: failed to load external entity
"XXXX/tests/documents/foo_file.xml"
make[2]: Leaving directory `XXXX/tests/documents'
=============
whose fix depend from warning message output(see #125670)


libxslt is tested with libxml2-2.6.2(that print line numbers) and
files tests/reports/*.err are fine.

All tests succeed on OpenBSD 3.1

This should be closed by release of libxslt-1.1.5,
                                                                                
  thanks,
                                                                                
Daniel

This should be closed by release of libxslt-1.1.5,
                                                                                
  thanks,
                                                                                
Daniel