Re: xsltwin32config.h and jhbuild
- From: Daniel Veillard <veillard redhat com>
- To: James Henstridge <james jamesh id au>
- Cc: Federico Mena Quintero <federico ximian com>, GNOME Desktop <desktop-devel-list gnome org>
- Subject: Re: xsltwin32config.h and jhbuild
- Date: Sun, 3 Jul 2005 09:04:36 -0400
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
> 3. I rerun configure. This sets the revision number to N in
> 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.
> > * 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
> 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 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/
] [Thread Prev