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/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list