----- Original Message -----
From: "Angus Leeming" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, December 17, 2005 10:50 AM
Subject: Re: LyX 1.3.7pre5 some more progress in diagnosis
Stephen Harris wrote:
Addendum: I find that C:\Msys\1.0\bin or C:\texmf\miktex\bin
or C:\Python23 will work individually; but combinations like
Msys and Python, Msys and texmf, or Python and texmf, will
fail to run the configure script, requiring sh.exe configure.
I have installed to C:\LyX
Given your continued interest in this, together with the fact that you can
reproduce the problem (I cannot and, anyway, I've retired ;-)), perhaps
you might like to play with the installer yourself? You'll find the NSIS
scripts in the
I've also found that Perl and ImageMagick can't be included in a combo.
No two of: Perl, Imagemagick, texmf, Msys, or Python can be paired
with each other in the Win PATH prior to installing LyX1.3.7_pre5.
However, Ghostscript and Ghostgum can be in the PATH before, so
for instance Msys/ghostscript/ghostgum works.
My original problem was not exactly like Paul's report. If I restarted LyX
it would never eventually rebuild? itself and work; it always displayed the
textclass.lst error message, sorry, gotta close. I had two computers, one
of which was badly off (textclass.lst error) and the other behaved more
like Paul's symptom, a delayed initial startup.
That is a troubleshooting problem, not a programming problem, but I
thought the solution to making them behave the same might point the
way to the programming area which would produce this behavior. I'm
good at solving troubleshooting problems which is why I volunteered
to be a tester. Anyway, you can see that I haven't reproduced the
problem. but uncovered an exacerbation of the problem and its cause.
I thought of pre-existing PATH entries which apply to Lyx/helper apps
because not everyone reported the problem and there seemed to be a
pattern of experienced users, thus more likely to have LyX apps in the
PATH, as reporting problems. Newer users would not of course have
LyX apps in their PATH, especially installing LyX for the first time.
I reported that on my older machine, which never exhibited the problem,
that Python, Msys could both be pre-existing PATH entries and Lyx137
would install OK. Except that under File-->import, NoWeb and Latex
don't show up just Ascii line and paragraph imports. So sh configure
is needed to restore Noweb and Latex to the menu.
development\Win32\packaging\installer
sub directory of the LyX 1.3.x sources. Or, alternatively, you can grab a
slightly modified (for your benefit) set from
http://www.lyx.org/~leeming/installer.zip (200kB)
which will unzip to
installer\
COPYING
abi_util_fileassoc.nsh
download.nsh
io_download.ini
io_summary.ini
io_ui_language.ini
is_user_admin.nsh
lyx_configure.C
lyx_configure.dll
lyxfunc.nsh
lyx_32x32.ico
lyx_installer.nsi
lyx_utils.nsh
strtrim.nsh
lyx_languages\
danish.nsh
dutch.nsh
english.nsh
french.nsh
german.nsh
italian.nsh
spanish.nsh
swedish.nsh
The main logic of the script is in lyx_installer.nsi which contains a line
!define PRODUCT_SOURCEDIR "C:\Program Files\LyX"
If you want to try and build the installer yourself (so that you can add
commentary/debug info to the thing) you should
* edit this line to point to your installed LyX files
* install NSIS (http://nsis.sourceforge.net/Download)
* copy lyx_configure.dll to
C:\Program Files\NSIS\Plugins\lyx_configure.dll
* build the package as
C:\Program Files\NSIS\makensis lyx_installer.nsi
The NSIS pages come with extensive documentation and Uwe is now extremely
fluent in the NSIS scripting language; I'm sure that he'll be able to
advise you further.
Personally, I'd start by adding lots of comments to
* the sources of the script
* C:\Program Files\LyX\Resources\lyx\configure
* lyx_configure.C --- although this also will require you to
rebuild the lyx_configure.dll .dll
to help diagnose what's going wrong.
Take a deep breathe (IMO the NSIS language is horrible in the extreme) and
Good luck!
--
Angus
1.3.6 installed correctly on both machines. That means the problem could
be in the Windows environment, either software or hardware, and that the
1.3.7-pre5 installer is triggering an environmental/system conflict that the
1.3.6 did not produce. I've solved a very few number of problems in the
past by comparing an earlier working script with a later non-working script
and noticing differences (typos) in the syntax. Of course this would work
better if I understood the scripting or programming language. But I think
learning a programming language is outside the scope of responsibility
of a tester. Especially one you describe as horrible in the extreme; that
crosses the divide, IMO. I didn't realize when you posted the workaround
you meant that test reports should be discontinued. Perhaps Uwe can use
it. Anyway, you have made it clear you don't benefit from such a report.
Nevertheless, since you've gone through this much effort, I'll do a
bit of investigating... I forgot why you said that NSIS is being used.
I appreciated your compiling suggestions (still within a tech's purview)
considerably more than your become a NSIS developer suggestion.
Hope you are enjoying parenthood,
Stephen
