GNOME Bugzilla – Bug 327515
distribution broken for builds where builddir != srcdir
Last modified: 2014-08-26 10:18:13 UTC
The tarball for libxslt 1.1.15 ships with libxslt/xsltconfig.h (and libxslt/xsltwin32config.h) included. These are normally generated by configure, so should not be included in a distribution. In particular, they override the files created by configure if builddir != distdir (leading to build failure if libxml2 has no module support, because the shipped headers use have WITH_MODULES = 1).
typo: should be "builddir != srcdir", not "builddir != distdir" in the above comment
xsltwin32config.h is needed for MSC windows users, who can't use configure. Not a bug ! Not GNOME either ! Certainly not a major bug from a GNOME point of view. 90+% of my windows users are using MSC to compile their code I guess. If you start by doing crazy stuff like cross-compiling for windows on Linux, then the very first thing to do is to not make things even more twisted by not building in the source dir, nuff' said ! Daniel
If you read the original report, you will see that my main mention is of libxslt/xsltconfig.h, with xsltwin32config.h only mentioned as an aside (and for that file I certainly accept the "win32 users can't run configure" argument). I also made no mention of cross-compilation as it affected both a straight build and a cross build. The header hides the one that is generated by configure, which is most certainly a bug, and would affect anyone who specifies specific configure options (such as --without-plugins) while building outside $srcdir (which is quite a reasonable situation, especially if a package needs to be built in multiple configurations (gcc3, gcc4, cross, ...)). If you feel that anything non-cookie-cutter is not Gnome, then fine, I will resubmit on the mailing list - but this IS a bug.
Okay then this need to be reopened, I think I undestand the issue better now, can probably be done easilly by removing the source version within configure.in before regenerating them Daniel
Well that would work, except that it would break for a read-only srcdir. Are both headers only in the distribution for non-configure Windows targets? If so, why not put them in the win32 subdir and have configure.js copy them in place (or use -I$srcdir/win32 to pull them in)? They'd still be available that way, without interfering with "normal" configure-based builds.
> Are both headers only in the distribution for non-configure Windows targets? yes But anything changing the way Windows build or use works should really be discussed on the list, I can't represent those users viewpoint ! Daniel
> > Are both headers only in the distribution for non-configure Windows targets? > yes > > But anything changing the way Windows build or use works should really be > discussed on the list, I can't represent those users viewpoint ! OK - I'll send a report of this problem to the list; if/when a solution is agreed there (and implemented), this item can then be closed.
Problem seems to be gone in most recent version 1.1.28 (Nov 2012), so marking as fixed.