Re: xsltwin32config.h and jhbuild
- From: Daniel Veillard <veillard redhat com>
- To: Federico Mena Quintero <federico ximian com>
- Cc: GNOME Desktop <desktop-devel-list gnome org>
- Subject: Re: xsltwin32config.h and jhbuild
- Date: Fri, 1 Jul 2005 05:58:02 -0400
On Thu, Jun 30, 2005 at 09:41:48PM -0500, Federico Mena Quintero wrote:
> Hi,
>
> A few days ago I did "cvs remove" of libxslt/libxslt/xsltwin32config.h
> because it got CVS conflicts on every update, as it is a generated file.
> It was breaking every jhbuild session, and I got annoyed. So I removed
> it, and managed to piss off Daniel and Windows users. Apologies for
> that :)
no problem, note that my reaction was related to not having asked first
before commiting a change to libxml2. The technical problem need to be solved
of course (i.e. this file need to be generated, but Windows users cannot
run configure to generate it, that's why it is in CVS so that Windows CVS
users don't get stuck with a missing file).
> I just added that file back, and I'm sure I'll get CVS conflicts again
> inside jhbuild. Daniel says that libxml should have the same problem
> with xmlwin32version.h, which is also a generated file. However, this
> has never presented any problems on my builds.
>
> Does anyone know why libxslt breaks but libxml doesn't?
libxml2/include/libxml/xmlwin32version.h[.in] contains the same
kind of set of informations as the one on the libxslt side, is generated
in the same way, and doesn't seems to break jhbuild.
Is there any special rule applied within jhbuild on one side and not
another ? Couldn't that file be removed or ignored in case of CVS checkout
conflicts ?
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]