On Thu, Jan 11, 2007 at 06:39:56PM +0100, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > The attached patch avoids the need to differentiate the kind of path
> > style returned by external_path on cygwin depending on whether Qt/X11
> > or Qt/Win is used for building.
> >
> > It also avoids an ugly #ifdef and solves a bug related to including
> > something through the external material inset (this bug only affects
> > a Qt/Win build, because of external_path).
>
> Can you explain please how that patch changes the external material inset? I
> don't see it in the patch, and according to former statements from you it
> does not matter at all for windows programs whether we use \ or / in file
> names, so I can't see how external_path could have any influence on the
> external material inset. If it has I suspect that there is a bug elsewhere
> (e.g. another instance of using "\" paths internally, that means a missing
> call of internal_path) that this patch only hides.
It goes in the following way.
Symptom: When using the external inset to include an xfig file, after
View->DVI an error dialog appears telling that the .pstex_t file is
missing. Running by hand the fig2pstex.py script, all necessary files
are regularly produced, but when that script is run by lyx, the .pstex_t
file is indeed missing in the tmpdir.
Reason: In ExternalSupport.C, the placeholders are substituded by a call
to subst_path() which uses external_path when use_latex_path is false.
Then, Converters::convert() is called with the to_file parameter in
Windows style ("c:/cygwin/tmp/..."). This would not be a problem by itself,
and indeed the conversion succeeds, but then in Converters::move() the
test "if (from == to) return true;" fails, because from="/tmp/...", but
to="c:/cygwin/tmp/...", so program flow goes ahead. The "from" and "to" file
are the same file indeed, and it gets opened at the same time for reading
and writing. At the end of the process you would get a mangled file, but
then the "from" file is deleted, so the "to" file disappears, too...
I never noticed this problem because when I build lyx for my personal use,
I always patch it such that external_path always returns a posix path,
and I introduce a windows_path function which I use in addFontResources
and restoreFontResources. I was always scared to propose a not well
designed patch, but now I think this one is acceptable.
--
Enrico
