Angus Leeming wrote:
Maybe something that would be fun and not too time consuming, allowing
you to participate, would be to write a short paper on the wiki
sketching out this "configure-on-demand" solution. It may be clear in
your head, but it's not in mine :)
Take a snippet like this from configure:
--
define(CHECKLATEX2E,[
## Check whether this is really LaTeX2e
rm -f chklatex.ltx
cat >chklatex.ltx <<EOF
\\nonstopmode\\makeatletter
\\ifx\\undefined\\documentclass\\else
\\message{ThisIsLaTeX2e}
\\fi
\\@@end
EOF
if eval ${LATEX} chklatex.ltx </dev/null 2>/dev/null \
| grep 'ThisIsLaTeX2e' >/dev/null; then
:
else
LATEX=
ac_result="not useable"
fi
rm -f chklatex.ltx chklatex.log])dnl
dnl
# Search LaTeX2e
SEARCH_PROG([for a LaTeX2e program],LATEX,pplatex latex2e
latex,CHECKLATEX2E,dnl
[lyx_check_config=no])
latex_to_dvi=$LATEX
test -z "$latex_to_dvi" && latex_to_dvi="none"
--
What it does is to check whether we have a working LaTeX by producing a
small document. This pattern is repeated a bunch of times: We try to run
a bunch of different alternative names of these programs, check the
output, and decides what name to use, or decide that program is not
available.
In addition to the snippet above in configure, there is corresponding
code that reads the configuration from a file, the code which uses the
configuration, and there is a special LyX teamplate document which
describes the results from the configuration, and presents this in the
Help menu. Add to this list the stuff you are doing now in the
installer, where you are adding OS specific installation tests and
download links for these packages. So the information about this is
scattered in a bunch of related, but different places.
Inside LyX, we use this configuration information when we are to produce
a DVI file. But in fact, we use old information: We use the information
that was recorded in a configuration file. So, let's assume that the
last time we ran this test, we failed to find a working LaTeX. Then LyX
greys out those commands in the GUI that need this command. There is no
explanation for the user. The expert users will learn to check some
fancy document in the Help menu, but the novice users are lost.
The first improvement is that LyX can rerun the check before greying out
the item. It might be that LaTeX was installed since configure. The next
step is that it could help the user resolve the situation. Instead of
greying out the option, it could open a dialog which said: LaTeX is
missing. Click here to download and install LaTeX. And after the
installation, it could rerun the test, and the command would succeed.
The first time LyX is started, it will run all the tests, and provide a
dialog where the user can check-off which missing components to download
and install. By putting this stuff in LyX itself, it is readily
available when needed.
(Writing this, it occurs to me that an alternative is to use NSIS for
some of this.)
So the point is to centralise all of this information into one place in
the form of a class that handles detection, downloading/installation,
explaning to the user, and the use of the detected information. In other
words, use C++ to implement a small domain specific language for the
full circle that revolves around run-time configuration issues.
This is basically a base interface class in C++, a bunch of toolboxes
for the different kinds of tests (running and interpreting the results
of commands), and all the configuration instances that implement
whatever they need to do.
An added benefit by having such a toolkit is that it can be made
available for other programs, such as tex2lyx and similar which also
need this kind of external package configuration support.
Does this help?
Regards,
Asger
