<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><blockquote type="cite"><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">If you run kpsewhich --debug=-1 --expand-path=\$TEXMFHOME,<br></span></font></blockquote><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">you will see what it's doing.</span></font></blockquote><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);"><br>I am sure kpsewhich does a lot, but does one need to do such a lot<br>such to tell where is TEXMFLOCAL and TEXMFHOME and TEXMFDIST ?</span></font><br></blockquote><div><br></div>Yes, one has to. Otherwise 20 years of expectation would be broken.</div><div><br></div><div>People regularly redefine TEXMFHOME and TEXMFLOCAL, and that might even happen on multiple levels (distribution makes first change, system admin another).</div><div><br></div><div>So besides:</div><div>* reading the main texmf.cnf</div><div>* searching for other texmf.cnf</div><div>* evaluating their contents</div><div>there is only hard coded path, and that is a no-go.</div><div><br></div><div><br></div><div>Let us go back to your Makefile: how many var-values do younormally need? 2? 3? Evaluating them once and saving costs 300ms.</div><div><br></div><div>Evaluating a complex Makefile with rules is probably more time consuming.</div><div><br></div><div>We do this caching of vars in many of our scripts, and that is definitely not the bottle neck.</div><div><br></div><div>I would invest time in other, that is to say possible, optimizations.</div><div><br></div><div>Norbert<br><div><span style="background-color: rgba(255, 255, 255, 0);">------------------------------------------------------------------------</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">PREINING, Norbert <a href="http://www.preining.info/">http://www.preining.info</a></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">JAIST, Japan TeX Live & Debian Developer</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">------------------------------------------------------------------------</span></div><span id="signature"></span></div><div><br>On May 1, 2015, at 6:51 AM, jfbu <<a href="mailto:jfbu@free.fr">jfbu@free.fr</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span><br><span>Le 30 avr. 2015 à 23:42, Karl Berry <<a href="mailto:karl@freefriends.org">karl@freefriends.org</a>> a écrit :</span><br><span></span><br><blockquote type="cite"><span> I may write a Makefile which will act after querying</span><br></blockquote><blockquote type="cite"><span> the repertories locations. But one tenth of a second</span><br></blockquote><blockquote type="cite"><span> for each kpsewhich call is a lot.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Save the result instead of making the same call thousands of times. I</span><br></blockquote><blockquote type="cite"><span>don't agree that 100 ms is such a horrible time to do all those</span><br></blockquote><blockquote type="cite"><span>filesystem operations. In fact, it seems rather quick to me.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> Could it be imagined to have some kpsewhichdir utility</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>1) I fail to see how making a utility restricted to a single variable</span><br></blockquote><blockquote type="cite"><span>could speed anything up. </span><br></blockquote><span></span><br><span></span><br><span>I probably did not express myself precisely. I am not targeting</span><br><span>a single variable; I am targeting the variables describing the main</span><br><span>repertories of the TeXLive installation</span><br><span></span><br><span></span><br><span></span><br><blockquote type="cite"><span>Surely what takes the time is looking for the</span><br></blockquote><blockquote type="cite"><span>config files in all the possible directories, and (more so) reading the</span><br></blockquote><blockquote type="cite"><span>ls-R file. </span></blockquote><span>one might need to do things to find packagefoo.sty via the </span><br><span>parsing of the ls-R files or system calls to ls, but why would these things</span><br><span>be needed for the main installation repertories ???</span><br><span></span><br><span>Perhaps many distributions set up environment variables thus</span><br><span>the speed penalty is not obvious to these users.</span><br><span></span><br><span></span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>2) Regardless, the idea of a utility dedicated to a single variable</span><br></blockquote><blockquote type="cite"><span>sounds wrong in principle to me and I don't think it should be done.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> the environment variable $TEXMFHOME </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>So far as I can see, if the envvar is set, its value is already (has</span><br></blockquote><blockquote type="cite"><span>always been) returned "instantly". The lookups are only done if they</span><br></blockquote><blockquote type="cite"><span>need to be.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>karl</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><span></span><br><span>I have none such environment variable and do not see why I should</span><br><span>set some</span><br><span></span><br><span>Jean-François</span><br></div></blockquote></body></html>