Re: xsltwin32config.h and jhbuild

[Daniel Veillard <veillard redhat com>]

On Wed, Jul 06, 2005 at 06:34:20PM +0800, James Henstridge wrote:
> I am sure that the file could be generated with a WSH script on
> Windows.  That should be available on all your Windows hackers systems,
> and doesn't depend on cygwin or mingw32.

  Actually after much testing and trial our Windows maintainer found
that javascript is the most common and relibale scripting lanaguage
on the various Windows distributions. See libxml2/win32, but we are getting
out of topic here.

> >>I would be surprised if that were true.  You have to *remove* the file.
> >>If you leave it in a conflict it doesn't compile.  To be honest, it has
> >>    
> >>
> >
> >  Then you never tried ! xmlwin32config.h and xsltwin32config.h are
> >not included by build driven by configure, they will just get overwritten
> >and the conflict with it (as conflict detection is made by searching for
> >the conflict delimiters in CVS). I don't see how you could get to such a
> >state.
> >  
> >
> I think it is possible to run into problems with these files if you do
> "cvs update", get a conflict and run "make" without rerunning autogen.sh.

  Case 1: build use configure, then the configure should be run after a CVS
          update, but if using configure, then it's on a platform where
	  xmlwin32config.h is not used (this file exists precisely because
	  the build system can't generate it), it's not #include'd and 
	  the conflict can't break the build.

  Case 2: build does not use configure, it relies on xmlwin32config.h being
          present, it is never regenerated locally (since build does not use
	  configure), and the version obtained from CVs is always without
	  conflict, the build can't be broken.

  Case 3: build use both, this mean you're building within the CVS checkout
          for both kind of architecture, and then yes you may have the problem
	  but this is rather insane to build Win32 within a CVS checkout'ed
	  tree done on Linux/Unix and modified locally due to a build.

If you're on case 3 I strongly suggest to CVS checkout separate trees for
your Win23/MSDev (or other exotic platform) build and for your Linux/Unix
builds.

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/