Long compile time

Long compile time

[David Arnold]

All,

For me, the most frustrating thing about ConTeXt seems to be the long time
it takes to compile. I've read the texexex.pdf file and there are some nice
hints in there to reduce the compile time. I still have two questions.

1. Can I reduce to a minimum the compile time by entering a comment in the
first line of my file, something akin to

%output=pdf

that I use frequently? If this can be done, what is an optimal comment line
for limiting the compile time?

2. Suppose I have a master document with 

\input chap1
\input chap2
\input chap3

etc. Suppose I am working in chap3.tex and I only want to compile chap3. Of
course, I can comment out 

%\input chap1
%\input chap2

but then I lose the correct numbering of pages, chapters, etc. Is there a
better procedure?

Re: Long compile time

[Hans Hagen]

David Arnold wrote:

> For me, the most frustrating thing about ConTeXt seems to be the long time
> it takes to compile. I've read the texexex.pdf file and there are some nice
> hints in there to reduce the compile time. I still have two questions.

That's the sacrifice for a parameter driven package. 

> 1. Can I reduce to a minimum the compile time by entering a comment in the
> first line of my file, something akin to
> 
> %output=pdf
> 
> that I use frequently? If this can be done, what is an optimal comment line
> for limiting the compile time?

Sometimes texexec --fast runs a bit faster. To prevent multiple runs,
say 

  texexex --once .....

> 2. Suppose I have a master document with
> 
> \input chap1
> \input chap2
> \input chap3
> 
> etc. Suppose I am working in chap3.tex and I only want to compile chap3. Of
> course, I can comment out
> 
> %\input chap1
> %\input chap2
> 
> but then I lose the correct numbering of pages, chapters, etc. Is there a
> better procedure?

A rather old feature of context is project support (pre texexec time,
when we were making collections of educational materials):

(project file: course.tex)

\startproject course 

  \environment commonsetups 

  \product     book 
  \product     exercises 
  \product     answers 
  \product     examn

\stopproject 

(environment file: commonsetups.tex)

\startenvironment commonsetups

  all kind of (layout) setups 

\stopenvironment 

(product file: book.tex) 

\startproduct book

  \project     course

  \environment booksetups 

  \component   chap-1
  \component   chap-2

\stopproduct 

(component file: chap-1.tex)

\startcomponent chap-1

  \project course 
  \product book 

  ... chapter 1 ... 

\stopcomponent 

etc etc 

Now you can say: 

texexec book 
texexec chap-1
texexec chap-2

etc

It is possible to set up context in such a way that the book refs etc
migrate to the individual chapters, but this only makes sense in special
cases. 

Maybe this relieves the pain of speed. 

Hans

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
-----------------------------------------------------------------

Re: Long compile time

[Gilbert van den Dobbelsteen]

>
> 2. Suppose I have a master document with
>
> \input chap1
> \input chap2
> \input chap3

I usually do not use this mechanism (though it is a simple, and solid one).
In context you can use products, and projects. This is not very well
documented I guess, so you have to experiment a little. On the other hand,
it is reasonably simple.

The project stuff has a few commands. Suppose I would like to write a
manual, consisting of several chapters. The project here is clearly the
manual, and each chapter could be called a product:

FILE: manual.tex:

\startproject manual

\environment s-man-01        % Location is *not* in pre-amble: experiment

\product chap-001
\product chap-002
\product chap-003

\stopproject

FILE: chap-001.tex

\environment s-man-01

\startproduct chap-001
\projects manual     % this is optional: experiment

blahblah

\stopproduct

The file s-man-01:

\startenvironment s-man-01

Def's for layout and-the-like

\stopenvironment

OK, what does this bring you (beside some extra typing work)?

1. You can compile the chapters seperately. Ok, the page numbers and
section-numbering wouldn't be correct, but all references and the layout
would be.

2. You can compile the entire product. Ok, that's trivial?

3. You could have differnet authors working on different chapters.

4. Since they all use the same style file, layout will be consistent.

5. The style file in included only once when you compile manual.tex. The
seperate chapters also include the style file (the \environment), but
context *knows* it already included the style file in manual.tex. This is a
bit more complex than I describe here, but experiment where yo put the
\environment command in the project/product and you'll find lots of usefull
combinations.

6. If you write multiple manuals, and you carefully setup the stuff, you can
re-use chapters over and over again.

There is also a lower level command: \startcomponent, \stopcomponent. This
is below the product (a project is composed with products, a product is
composed with components).

So if you setup things carefully, it could save you some time.

Good luck, Gilbert.

Re: Long compile time

[David Arnold]

All,

I have now had several people make a project suggestion as a means of
assembling the various pieces of a large task. Hans has described the
procedure below. I would like to give this a try, but I have a few
questions before restructuring my documents.

1. Do you recommend that I pursue this technique? I think yes?

2. Here's how I like to structure my project directories;

f:\book
f:\book\chap1
f:\book\chap2
f:\book\chap3
f:\book\chap4
f:\book\chap5
f:\book\chap6
f:\book\chap7
f:\book\chap8
f:\book\chap9
f:\book\chap10

The directory f:\book contains my master document, master.tex. Each of the
directories f:\book\chapi contains a file called chapi.tex and all of the
files needed to construct that file, *.eps, *.pdf, *.m (matlab files), *.mp
(Metapost files), etc. Each directory has a SIGNIFICANT number of files.
This is how I like to work, because chunking everything into one directory
would quickly become unmanageable, at least for me.

Now, knowing these parameters, am I still a candidate to use this
project--product approach?

At 12:40 PM 8/29/99 +0200, you wrote:
>David Arnold wrote:
>
>> For me, the most frustrating thing about ConTeXt seems to be the long time
>> it takes to compile. I've read the texexex.pdf file and there are some nice
>> hints in there to reduce the compile time. I still have two questions.
>
>That's the sacrifice for a parameter driven package. 
> 
>> 1. Can I reduce to a minimum the compile time by entering a comment in the
>> first line of my file, something akin to
>> 
>> %output=pdf
>> 
>> that I use frequently? If this can be done, what is an optimal comment line
>> for limiting the compile time?
>
>Sometimes texexec --fast runs a bit faster. To prevent multiple runs,
>say 
>
>  texexex --once .....
> 
>> 2. Suppose I have a master document with
>> 
>> \input chap1
>> \input chap2
>> \input chap3
>> 
>> etc. Suppose I am working in chap3.tex and I only want to compile chap3. Of
>> course, I can comment out
>> 
>> %\input chap1
>> %\input chap2
>> 
>> but then I lose the correct numbering of pages, chapters, etc. Is there a
>> better procedure?
>
>A rather old feature of context is project support (pre texexec time,
>when we were making collections of educational materials):
>
>(project file: course.tex)
>
>\startproject course 
>
>  \environment commonsetups 
>
>  \product     book 
>  \product     exercises 
>  \product     answers 
>  \product     examn
>
>\stopproject 
>
>(environment file: commonsetups.tex)
>
>\startenvironment commonsetups
>
>  all kind of (layout) setups 
>
>\stopenvironment 
>
>(product file: book.tex) 
>
>\startproduct book
>
>  \project     course
>
>  \environment booksetups 
>
>  \component   chap-1
>  \component   chap-2
>
>\stopproduct 
>
>(component file: chap-1.tex)
>
>\startcomponent chap-1
>
>  \project course 
>  \product book 
>
>  ... chapter 1 ... 
>
>\stopcomponent 
>
>etc etc 
>
>Now you can say: 
>
>texexec book 
>texexec chap-1
>texexec chap-2
>
>etc
>
>It is possible to set up context in such a way that the book refs etc
>migrate to the individual chapters, but this only makes sense in special
>cases. 
>
>Maybe this relieves the pain of speed. 
>
>Hans
>
>-----------------------------------------------------------------
>                                          Hans Hagen | PRAGMA ADE
>              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
>      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
>-----------------------------------------------------------------
>
>
>

Re: Long compile time

[Hans Hagen]

David Arnold wrote:

> I have now had several people make a project suggestion as a means of
> assembling the various pieces of a large task. Hans has described the
> procedure below. I would like to give this a try, but I have a few
> questions before restructuring my documents.
> 
> 1. Do you recommend that I pursue this technique? I think yes?
> 
> 2. Here's how I like to structure my project directories;
> 
> f:\book
> f:\book\chap1
> f:\book\chap2
> f:\book\chap3
> f:\book\chap4
> f:\book\chap5
> f:\book\chap6
> f:\book\chap7
> f:\book\chap8
> f:\book\chap9
> f:\book\chap10
> 
> The directory f:\book contains my master document, master.tex. Each of the
> directories f:\book\chapi contains a file called chapi.tex and all of the
> files needed to construct that file, *.eps, *.pdf, *.m (matlab files), *.mp
> (Metapost files), etc. Each directory has a SIGNIFICANT number of files.
> This is how I like to work, because chunking everything into one directory
> would quickly become unmanageable, at least for me.
> 
> Now, knowing these parameters, am I still a candidate to use this
> project--product approach?

It all depends on where your project / product files go. Concerning
figures, you can set up the directories used with 

  \setupexternalfigures[directory={commaseparatedlist}] 

like: 

  \setupexternalfigures[directory={mps,eps,pdf}] 

For tex and other files, you can set the directories with:  

  \usepath[commaseparatedlist]

like: 

  \usepath[book,anotherbook,yetanotherbook]

To prevent problems with clashing files (think of context picking up a
tuo file from another path because your tex does recursive search)
depending on the file searched, context restricts the search. Figure
files for instance are search on the current path or one of the global
paths as set up (unless one of these is enabled). Environments are
searched upto three levels down (up) the tree, which means that you can
put shared environemnts, abbreviation definitions, etc in a parent
path.  Context really does its best to limit the search time. 

Hans

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.nl
-----------------------------------------------------------------