On Sun, Jul 03, 2005 at 08:56:11PM +0800, James Henstridge wrote: > Daniel Veillard wrote: > > > now s/xslt/xml/g there is the exact same mechanism for libxml2, and > >it never breaks, though libxml2 module ChangeLog is updated way more > >frequently > >than libxslt one, why ? I undestand your analysis, but I don't understand > >why libxml2 doesn't break too. > > > > > I have seen the problem occur with both libxml2 and libxslt. I don't > know why Federico has only seen it with libxslt.
ah, okay, that was not reported. > >>The only way to really fix this problem is one of: > >> > >> * remove the file from CVS, and only include it in the tarballs > >> > >> > > > > which mean I can't get Windows testers using CVS > > > > > Why can't the necessary file be generated by Windows users? because configure doesn't run for people using standard Windows tools. > >> * don't store the ChangeLog revision number inside the file. > >> > >> > > > > annoying but I could do that to the windows specific version, not a big > > deal > > > > > Note also that the version number stored in that file probably won't > match the version number of the ChangeLog when doing a checkout. > Consider the following sequence: > > 1. ChangeLog is at revision N > 2. I make changes to one of the source files and add an entry to the > ChangeLog > 3. I rerun configure. This sets the revision number to N in > xml2version.h > 4. I commit the changes, which increases the revision number of > ChangeLog to N+1 > > So it won't accurately tell what the checked out version contains. If I > leave out step 3, the version number gets even further out of sync. It > seems that it would be easier to leave it out entirely. Well it's important to have at least an idea, but I will drop this from build for Windows users. > >also > > > > * modify jhbuild to have a specific rule about that file. > > > > > That's not going to happen. This issue is not a jhbuild specific issue > -- it is likely to affect anyone building libxml2 and libxslt from CVS, > since your build setup frequently generates conflicts. people building from cvs like me just ignore that conflict, build and it just works. jhbuild decides that the fact there is a conflict means a build must not be attempted, it's jhbuild decision to operate under that mode, and that's why it breaks in that case. It's not an human behaviour, it's jhbuild behaviour. > If you want the conflicts to be ignored by the revision control system, > then the file can't be tracked as source. I will remove the revision number from the generated file as I want Windows users to be able to build from CVS. 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