Work on Windows installer

Yu Jin technikmagma at gmail.com
Wed May 13 05:30:51 UTC 2020


Ive been studying the code for windows installer and understand it pretty
well now. However the more I understand it, the more I find it hardly
readable and not intuitive. There are many little things that can be made
more elegant, but also the whole setup of the files and how they are
structured is somewhat misleading for someone who is not the author and
tries to understand it. I think that I could make it more enjoyable to work
with. I have a few ideas already: things like using NSISList plugin, which
allows creating Lists (like Arrays); reducing the code by using NSIS’s own
functions instead of the ones created by the authors for the installer
(e.g. StrLoc (NSIS function) vs StrPoint (in LyXUtils.nsh)); removing
leftovers from the bundle installer; and even consequently using logiclib
instead of mixing it with the jump commands. Also trying to separate the
code from the rest (like docu, patchnotes) to different folders, reorganize
!include commands and put some more descriptive comments.

Besides that, I think that some functions/sections are programmed in a
confusing way, like dictionaries sections. Detection functions are probably
a little old now and can't reliably find what they should (this is
specifically the case for texlive detection function when texlive is not
added to path). Therefore I would like to rewrite some functions tbh. Also
the declaration file with its many compile time constants is very annoying
to me, because NSIS has no intellisense like C++.

I dont know what to do about this whole thing, because, well... the
installer works and can be maintained as it is now. And sinse I am fairly
new contributor here (and actually fairly new to programming in the first
place), I would like to ask for advice. Basically there are multiple
options:

1. I could rewrite everything that I think is doable in a much better way,
this would mean actually creating a new installer, then checking the old
one function by function and then deciding which to rewarite and which to
adopt. This would have a potential of new bugs and I would probably share
it once it is all finished.

2. Make multiple smaller changes to the current installer always sharing
and continuing after they have been accepted. This would take a hell lot of
time and require to make sure that the installer still works after each
change. The result would probably be not as good as in 1.

3. leaving it as it is and forgetting about it.

First option is most appealing to me, well, I probably dont have to tell
you why (fun and challenge). If I were to do any work on the installer,
then of course I would make sure, that it remains all of it's functionality
(e.g. silentinstall) and if I run into problems, I would ask for advice and
talk about progress as this would take some time.

That said, besides some NSIS experiments I have not done anything on this
yet and wanted to talk first to avoid the situation of silently doing
something big in my corner without anybody else knowing about it.

Please let me know your thoughts.


Eugene
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20200513/479fc988/attachment.html>


More information about the lyx-devel mailing list