In experimenting with projects, products, and components, I was tracing file searches (using Linux, teTeX 3.0 and kpathsea).
From the cont-eni.pdf manual (p. 26 of the PDF file), explaining more about components and project structure:
Many TEX implementations look for a file in all directories and subdirectories when a requested file is not in the current directory. This is not only time--consuming but may lead to errors when the wrong file (a file with the same name) is loaded.
For this reason ConTEXt works somewhat differently. A file that is not available on the working directory is searched for on the parent directories.
I agree with this reasoning. But as implemented, if the current and parent directories fail, ConTeXT will look in the TEXINPUTS search path. Is that the intended behavior when looking for project files? Probably not ideal for the project file, though maybe it is useful for the resulting environment file? For finding figures, the behavior is clear: look in the local (.) and then the global directories, and that's it. For finding files specified by \input, the behavior is also clear (use TEXINPUTS). So I wondered whether the intention for finding project files was also equally clear: look in . and in (grand)parent directories (I've increased the number of levels to three). Here's the test.tex file I used: \startcomponent blah \product null \project abcd \stopcomponent $ texexec -passon="-kpathsea-debug 32" --once test >& log $ grep abcd log | grep kpse_find kdebug:kpse_find_file: searching for ./abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ../abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ../../abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ../../../abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ./abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ../abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ../../abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ../../../abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for abcd of type tex (from TEXINPUTS environment variable) The last search, for 'abcd', runs through the entire TEXINPUTS path. The other searches have directories specified, so they will look only in those directories. -Sanjoy `A society of sheep must in time beget a government of wolves.' - Bertrand de Jouvenal
Sanjoy Mahajan wrote:
In experimenting with projects, products, and components, I was tracing file searches (using Linux, teTeX 3.0 and kpathsea).
From the cont-eni.pdf manual (p. 26 of the PDF file), explaining more about components and project structure:
Many TEX implementations look for a file in all directories and subdirectories when a requested file is not in the current directory. This is not only time--consuming but may lead to errors when the wrong file (a file with the same name) is loaded.
For this reason ConTEXt works somewhat differently. A file that is not available on the working directory is searched for on the parent directories.
I agree with this reasoning. But as implemented, if the current and parent directories fail, ConTeXT will look in the TEXINPUTS search path. Is that the intended behavior when looking for project files? Probably not ideal for the project file, though maybe it is useful for the resulting environment file?
For finding figures, the behavior is clear: look in the local (.) and then the global directories, and that's it.
For finding files specified by \input, the behavior is also clear (use TEXINPUTS).
So I wondered whether the intention for finding project files was also equally clear: look in . and in (grand)parent directories (I've increased the number of levels to three).
Here's the test.tex file I used:
\startcomponent blah \product null \project abcd \stopcomponent
$ texexec -passon="-kpathsea-debug 32" --once test >& log $ grep abcd log | grep kpse_find kdebug:kpse_find_file: searching for ./abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ../abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ../../abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ../../../abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ./abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ../abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ../../abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for ../../../abcd of type tex (from TEXINPUTS environment variable) kdebug:kpse_find_file: searching for abcd of type tex (from TEXINPUTS environment variable)
The last search, for 'abcd', runs through the entire TEXINPUTS path. The other searches have directories specified, so they will look only in those directories.
the reason for the global search is that environments can be in your local tree (tex/context/user) 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.com | www.pragma-pod.nl -----------------------------------------------------------------
Hans Hagen
Sanjoy Mahajan wrote:
The last search, for 'abcd', runs through the entire TEXINPUTS path. The other searches have directories specified, so they will look only in those directories.
the reason for the global search is that environments can be in your local tree (tex/context/user)
Right, so the broad search should happen for environment files. But in the example, the project files are also searched for broadly, and I think that search could be confusing. -Sanjoy
Sanjoy Mahajan wrote:
Hans Hagen
wrote: Sanjoy Mahajan wrote:
The last search, for 'abcd', runs through the entire TEXINPUTS path. The other searches have directories specified, so they will look only in those directories.
the reason for the global search is that environments can be in your local tree (tex/context/user)
Right, so the broad search should happen for environment files. But in the example, the project files are also searched for broadly, and I think that search could be confusing.
environemnts projects products and components share the same code, so if you want this restriction, you should file a feature request 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.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (2)
-
Hans Hagen
-
Sanjoy Mahajan