Re: xsltwin32config.h and jhbuild

[Daniel Veillard <veillard redhat com>]

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/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/