Re: xsltwin32config.h and jhbuild

[James Henstridge <james jamesh id au>]

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.

>>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?

>>    * 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.

>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.

If you want the conflicts to be ignored by the revision control system,
then the file can't be tracked as source.

James.