[tlbuild] Re : Re: report on building locally on an old macos and a query

[jfbu]

----- Karl Berry <karl at freefriends.org> a écrit :
>     fmtutil [ERROR]: not building etex due to missing engine: pdftex
> 
> Strange. That error message comes from this code in fmtutil.pl:
> 
>   if (!TeXLive::TLUtils::which($eng)) {
>     ...
>       print_deferred_error("not building $fmt due to missing engine: $eng\n");
>       return $FMT_FAILURE;
> 
> where our which() function in TLUtils.pm simply iterates through each
> $dir of $PATH checking for -x $dir/$eng, if you see what I mean.
> So it's puzzling that I don't work.
> 
> If you add --no-error-if-no-engine=pdftex to the fmtutil command line,
> what happens? Then it should go ahead and try to run pdftex anyway.
> Would be interesting to see if it succeeds or fails.

It behaves this way:

$ which pdftex
./pdftex
$ fmtutil-sys --byfmt etex --no-error-if-no-engine pdftex 
fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order):
fmtutil:   /usr/local/texlive/2025/texmf-dist/web2c/fmtutil.cnf
fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes:
fmtutil:   /usr/local/texlive/2025/texmf-config/web2c/fmtutil.cnf
fmtutil [INFO]: writing formats under /usr/local/texlive/2020/texmf-var/web2c
fmtutil [INFO]: --- remaking etex with pdftex
fmtutil [INFO]: Did not find entry for byfmt=etex skipped
fmtutil [INFO]: disabled formats: 3
fmtutil [INFO]: not selected formats: 53
fmtutil [INFO]: not available formats: 1
fmtutil [INFO]: total formats: 57
fmtutil [INFO]: exiting with status 0

(I tried various ordering and using or not using = signs, same results).

To recap, here I temporarily renamed the pdftex binary in its normal
TeXLive location as xxxxpdftex, so it can't be found.  I have a legit
pdftex in the working directory and PATH is configured so that it is
seen.

The "fmtutil [INFO]: Did not find entry for byfmt=etex skipped" looks
like some part is gobbled...


It exists with status 0 but does not build a fmt file...


> 
>     perhaps the time with seconds of production is therein?
> 
> Yes, .fmt files include a timestamp.

ok. Then it would be great if the log files when running the binaries
could contain the information of that timestamp.... (I mean great for
me currently but possibly bad for the world at large).

> With minute resolution, as I
> recall.  Not sure. If you use the SOURCE_DATE_EPOCH envvar, possibly
> with FORCE_SOURCE_DATE=1, you should be able to control the time used.
> See the pdftex manual. We created these envvars so reproducible builds
> (of documents, not formats, but the same should apply) would be possible.

using 

export SOURCE_DATE_EPOCH="0"

and (required, in my testing)

export FORCE_SOURCE_DATE=1

I find that etex.fmt and pdflatex.fmt are now reproducible,

It does not work for tex.fmt (which I expect to be expected).

It does look compatible with my testing that the granularity is the
minute.

It is not the second at any rate as one can see with pdflatex.fmt which
takes more than one second at my locale to build.

Thanks,
JF

PS: I fetched the branch2025 luatex files and can confirm
on my darwinlegacy that the reported issues with integral
sign and its limits seem to be gone.

PPS: I will try again next year I guess but I had quite some difficulties
with building binaries (say only pdftex, or only luahbtex) with varying
C compiler options.  It appears that on the 15th I was actually building
again and again 3 or 4 times the same pdftex binary,
so my somewhat uniform speed tests on that
day were not so surprising. But the  main point remains, which is that
using Optimizing options for speed brings a relatively minor gain in
comparison to the circa 10% to 15% gain I get from compiling on my
hardware and environment.
The gain due to -O3 is in the range of 3%-4% maximum.