Hi Andre,
Thanks for these comments. More follows:
Andre Poenitz wrote:
> On Tue, Jun 05, 2007 at 09:52:49PM +1000, John Pye wrote:
>
>> Sorry for a bit of a delay on this one. I thought I would follow up with
>> some comments though.
>>
>> Firstly,
>>
>> Jean-Marc Lasgouttes wrote:
[...]
>
>> The concept I had here was that one might be writing some software with
>> a tarball that contains both C code and supporting LyX documentation.
>> The documentation ultimately gets embedded into the application file in
>> the form of let's say a windows .CHM help file. Imagine that a developer
>> want to make some changes to a small part of the program and perhaps
>> some small change in the documentation. If the LyX build process were
>> somehow integrated with scons, then developer could just call 'scons'
>> and rebuild the necessary bits of the program code plus the missing bits
>> of the documentation. The dependency checker would have everything it
>> needed without launching the full-blown LyX application to build the
>> documentation. In this case, LyX would just do the job of perhaps
>> transforming .lyx to .tex; scons would do the job of compiling the .tex
>> file together with .png images together into a set of .html files and
>> then convert the .html files to .chm files...
>>
>
> People have successfully used plain Makefile for this purpose.
>
Although I am sure it can be made work (inefficiently), it just doesn't
seem like the architecture is right for this. More comment further below.
>
>> At present, because lyx uses its own build system, the efficiencies of
>> the above approach are not possible.
>>
>
> ?
>
> Which 'own' build system?
>
LyX *does* contain a build system. The following features:
* LyX can work out what image files need to be converted (dependency
tracking)
* LyX knows how to convert image files (build rules)
* The LyX GUI detects when an image file is changed and triggers an
updated file conversion (source file modification tracking)
* LyX instantiates tex in order to create a PDF file (multiple steps
to achieve required output file)
* LyX knows the order that things need to be built in (graph algorithms)
* LyX keeps a cache of converted image files and doesn't re-convert
them all every time (output caching)
* Build rules and file types can be specified by the user
(user-defined build rules)
* LyX contains certain hard-wired default rules (default build rules)
It may not be full-blown thing but I don't see any clear distinction
between where LyX functionality stops and where a 'full blown' build
system starts.
>
>> I think that perhaps it does need a build system. My thesis takes a good
>> five minutes to build, and there is absolutely no indication of how far
>> through it is, or what it's doing at any given point in time.
>>
>
> You know that it takes five minutes, and if it takes an average of two
> minutes to fill your coffee mug you'll know when 40% are done...
>
More coffee will only heighten my paranoia! Seriously, LyX is a GUI
application but it makes no effort at being GUI-friendly during the
document build process. It wouldn't be that hard to add a 'progress'
dialog box for this stuff? Run a separate thread for the build tools and
update the screen as they go? Helps to know when images are too large or
too detailed, or if something is hung, etc?
[...]
>
>> When I change things in 'sub-files' in my thesis (ie chapters) LyX
>> doesn't always correctly detect that something's changed, and it ends up
>> producing the same PDF file as before I made my changes. It seems that
>> there could be a missing link in the dependency tracking.
>>
>
> Makefile.
>
I think that this is a bug in LyX. LyX *must* be able to do this type of
dependency tracking 100% correctly if it is going to attempt it at all.
It is no good that it outputs the wrong document in this case.
[...]
>
>> So you mentioned that the build process is trivial but I think that the
>> above examples show that it's perhaps not so trivial, and perhaps if a
>> full-scale build system were used it might allow the LyX development
>> effort to reduce the amount of 'support code' that needs to be
>> maintained, so that you can focus on some of the more core LyX
>> functionality?
>>
>
> The point is that LyX is not a build system, cannot be, and does not
> want to be. If you need one (and you have shown good reasons for that)
> just use one. If you prefer Scons over make, so be it, but in both cases
> this is a solution _wrapping_ LyX, not a solution integrated in LyX.
>
My basic problem here is that LyX is not really wrap-able, because of
the way that it fires off an indeterminate number of sub-processes to
convert images and other source material. It works quite differently
from the usual tools that are called from a build script such as CPP,
GCC, flex, bison, SWIG, etc.
As I argued above, LyX contains *its own* build system: it defines tools
and file transformations, dependency tracking and caching. Because it
contains all of these things internally it makes using it within an
external build system much more difficult that it should be.
I think that good architecture going forward might be for LyX to divest
all of the build tracking stuff to an external program that specialises
in dependency tracking, caching, and parallel building, and to try to
re-use what others have already done in this area.
Thoughts?
Cheers
JP
