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/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
