Re: xsltwin32config.h and jhbuild

[James Henstridge <james jamesh id au>]

Daniel Veillard wrote:

>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.
>  
>
Surely it would be possible to generate the file using tools available
on Windows.  I know that the scripting support on Windows is not as good
as on Unix systems, it should be up to the task of scanning the
configure.in file for the version number, and scanning the CVS/Entries
file for the ChangeLog version number.

In the long term it might be worth asking one of the Windows developers
to take a look at this.  It would remove the need to store the file in
CVS, and give more accurate version information in the win32 builds.

>>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.
>  
>
You know from this particular context that the conflict can be ignored,
since the file gets regenerated by configure.  In the general case, an
automated build tool can't assume that conflicts can be ignored.

(and for the record, jhbuild does give the user the option to ignore the
conflict and continue with the build on the error, or rerun configure).

James.