[tlbuild] dvisvgm

[Mojca Miklavec]

Dear Martin,

On 9 February 2017 at 09:59, Martin Gieseking wrote:
> Am 09.02.2017 um 05:11 schrieb Mojca Miklavec:
>>
>> I'm experiencing another problem:
>>
>> Making all in doc
>> stat: illegal option -- c
>> usage: stat [-FlLnqrsx] [-f format] [-t timefmt] [file ...]
>> make[2]: Entering directory `/path/to/dvisvgm-2.1.1/doc'
>> if [ `type -p asciidoc` ]; then \
>>         asciidoc -a icons -a 'iconsdir=.' -a badges -a
>> 'revnumber=2.1.1' --unsafe -bdocbook -dmanpage -o dvisvgm-man.xml
>> dvisvgm.txt; \
>>         sed -i "s#\(</refmeta>\)#<refmiscinfo
>> class='date'></refmiscinfo>\n\1#" dvisvgm-man.xml; \
>>     fi
>> sed: 1: "dvisvgm-man.xml": extra characters at the end of d command
>
>
> I guess, the stat command doesn't support option -c on macOS.

Indeed. The only flags listed by the man page are the following:

    -F
    -f format
    -L
    -l
    -n
    -q
    -r
    -s
    -t timefmt
    -x

> You can either
> drop the sed command from doc/Makefile.am or replace
>   stat -c %y
> with
>   stat -f %Sm
> for example. It just adds the modification date to the xml file.

Are you saying that the Debian devs didn't complain about
non-reproducible builds yet? :)

See:
    https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal

While "stat -f %Sm" works in principle, the patched Makefile[.in]
doesn't quite make it (I also tried to replace "stat -c %y $<" by
"stat -f %Sm", but I keep getting some "extra characters at the end of
d command"):

if [ `type -p asciidoc` ]; then \
asciidoc -a icons -a 'iconsdir=.' -a badges -a 'revnumber=2.1.1'
--unsafe -bdocbook -dmanpage -o dvisvgm-man.xml dvisvgm.txt; \
sed -i "s#\(</refmeta>\)#<refmiscinfo class='date'>Feb  9 10:37:32
2017</refmiscinfo>\n\1#" dvisvgm-man.xml; \
fi
sed: 1: "dvisvgm-man.xml": extra characters at the end of d command


In any case it would be a lot better if the upstream sources without
any patches worked out of the box. (I'm also not sure about timestamps
in the context of build reproducibility, but that's a lower priority
right now.)

>> The weird thing is that as soon as I re-run "make", the second attempt
>> works just fine.
>
> That's probably because asciidoc succeeded and created the required xml file
> with a current timestamp. When you call make again, the file is already
> there and doesn't need to be generated once more.

Ah, that makes sense, thank you.


One more question. I notice that the binary links against
    $prefix/lib/libgs[.X.Y].dylib
when I build it on a system with a number of preinstalled packages
(actually within the scope of a package manager). Dick's binary was
built on a clean system from TL directly and doesn't have any strange
dependencies.

Where exactly does that dependency on libgs get pulled in?

Some other dependencies that get pulled in, but I guess many of them
are expected and would be avoided if I build dvisvgm as part of TL:
    /opt/local/lib/libfreetype.6.dylib
    /opt/local/lib/libz.1.dylib
    /opt/local/lib/libgs.9.19.dylib
    /opt/local/lib/libpotrace.0.dylib
    /opt/local/lib/libkpathsea.6.dylib

Mojca