Paul A. Rubin <[EMAIL PROTECTED]> writes:
> Is there a reason why it's now named tex2lyx.1.4.x.exe,
Yes.
I wanted LyX 1.3.x to work alongside LyX 1.4. LyX 1.3.7 is the most stable
version of LyX ever. LyX 1.4.1 isn't...
By configuring the build process "--with-version-suffix" I ensured that our
users' personal preferences are stored in
Documents and Settings\USER\Application Data\LyX14x
meaning that the LyX 1.3 preferences, personal layout files etc aren't
overwritten by things with different format expectations.
The renaming of the executables to lyx14x.exe and tex2lyx14x.exe isn't
actually needed on Windows (or on Mac) where these things are held in a
self-contained directory. They are needed on *nix platforms where you'd
expect to find lyx, lyx13x and lyx14x all co-existing in /usr/bin
Jean-Marc has proposed a patch that will remove these unnecessary
extensions for a "version-suffixed" Windows build.
> rather than tex2lyx.exe? (In other words, if I rename it to
tex2lyx.exe, am I going to cause something else to fail?)
In this instance, the only thing that LyX itself knows about are
"converters" which are defined in either your lyxrc.defaults file
(generated by running configure) or overridden by your own preferences.
The configure script has a bug that means it can't find tex2lyx
however it's named at the moment. That's been fixed. LyX itself has a
bug because it doesn't tell the configure script what the version suffix
of a "version-suffixed" tex2lyx is. Georg has proposed a fix to that.
Bottom line: the workaround for both bugs of renaming the thing to
tex2lyx.exe will work.
Hoping that this long justification/explanation of current
behaviour makes sense...
Regards,
Angus
