Re: Why is it _still_ so freaking hard to get info with images?

[David Kastrup]

John Mandereau <address@hidden> writes:

> David Kastrup a écrit :
>> John Mandereau <address@hidden> writes:
>>   
>>> ..and input/lsr too.  I added toplevel info and intall-info target.
>>>     
>> No, you didn't.
> Oops, I meant info-install.

I don't think that is standard usage.  install-info would be the norm
when available.

>> make install bombs out, anyway:
>>   (/usr/bin/python /home/tmp/lilypond/stepmake/bin/install.py -c -d
>> /usr/local/share/lilypond/2.13.0/fonts/otf/ || true) &&
>> /usr/bin/python /home/tmp/lilypond/stepmake/bin/install.py -c -c -m
>> 644 ./out/emmentaler-11.otf ./out/emmentaler-13.otf
>> ./out/emmentaler-14.otf ./out/emmentaler-16.otf
>> ./out/emmentaler-18.otf ./out/emmentaler-20.otf
>> ./out/emmentaler-23.otf ./out/emmentaler-26.otf ./out/aybabtu.otf
>> ./out/CenturySchL-Ital.otf ./out/CenturySchL-BoldItal.otf
>> ./out/CenturySchL-Roma.otf ./out/CenturySchL-Bold.otf
>> /usr/local/share/lilypond/2.13.0/fonts/otf/ &&   (/usr/bin/python
>> /home/tmp/lilypond/stepmake/bin/install.py -c -d
>> /usr/local/share/lilypond/2.13.0/fonts/svg/ || true) &&
>> /usr/bin/python /home/tmp/lilypond/stepmake/bin/install.py -c -c -m
>> 644 ./out/emmentaler-11.svg ./out/emmentaler-13.svg
>> ./out/emmentaler-14.svg ./out/emmentaler-16.svg
>> ./out/emmentaler-18.svg ./out/emmentaler-20.svg
>> ./out/emmentaler-23.svg ./out/emmentaler-26.svg ./out/aybabtu.svg
>> /usr/local/share/lilypond/2.13.0/fonts/svg/ &&   (/usr/bin/python
>> /home/tmp/lilypond/stepmake/bin/install.py -c -d
>> /usr/local/share/lilypond/2.13.0/fonts/type1/ || true) &&
>> /usr/bin/python /home/tmp/lilypond/stepmake/bin/install.py -c -c -m
>> 644 ./out/feta11.pfb ./out/feta13.pfb ./out/feta14.pfb
>> ./out/feta16.pfb ./out/feta18.pfb ./out/feta20.pfb ./out/feta23.pfb
>> ./out/feta26.pfb ./out/feta-braces-a.pfb ./out/feta-braces-b.pfb
>> ./out/feta-braces-c.pfb ./out/feta-braces-d.pfb
>> ./out/feta-braces-e.pfb ./out/feta-braces-f.pfb
>> ./out/feta-braces-g.pfb ./out/feta-braces-h.pfb
>> ./out/feta-braces-i.pfb ./out/feta-alphabet11.pfb
>> ./out/feta-alphabet13.pfb ./out/feta-alphabet14.pfb
>> ./out/feta-alphabet16.pfb ./out/feta-alphabet18.pfb
>> ./out/feta-alphabet20.pfb ./out/feta-alphabet23.pfb
>> ./out/feta-alphabet26.pfb ./out/parmesan11.pfb ./out/parmesan13.pfb
>> ./out/parmesan14.pfb ./out/parmesan16.pfb ./out/parmesan18.pfb
>> ./out/parmesan20.pfb ./out/parmesan23.pfb ./out/parmesan26.pfb
>> /usr/local/share/lilypond/2.13.0/fonts/type1/ &&  true
>> Traceback (most recent call last):
>>   File "/home/tmp/lilypond/stepmake/bin/install.py", line 78, in <module>
>>     shutil.copy2 (f, dest)
>>   File "/usr/lib/python2.5/shutil.py", line 96, in copy2
>>     copyfile(src, dst)
>>   File "/usr/lib/python2.5/shutil.py", line 51, in copyfile
>>     fsrc = open(src, 'rb')
>> IOError: [Errno 2] No such file or directory: './out/CenturySchL-Ital.otf'
>> make[1]: *** [local-install-outfiles] Error 1
>> make[1]: Leaving directory `/usr/local/tmp/lilypond/mf'
>> make: *** [install] Error 2
>> address@hidden:/home/tmp/lilypond$   
> Did you call "make all" first?  I think it's not reasonable to expect
> "make install" to work if you haven't called "make all" first.

Nobody, I repeat, nobody I know _ever_ calls "make all".  What you do
instead is just to call "make" and assume that "all" will be the default
target.

>> As it stands, the most basic targets just don't work at all and/or need
>> parameters one could not possibly guess
> This is wrong, basic targets don't require any parameter; basic
> targets are not the one your bash completion show,
> I'm sorry.

When

    make
    sudo make install

does not work, then we _are_ talking about the most basic targets.

> That's why there is an INSTALL file in distributed tarballs,

I am talking about compiling from source git.  There is no top-level
file INSTALL in there.  Not even after autogen.sh.  There is no README.
There is a file HACKING but it has no relevance to compiling things.

> and we have it in PDF and HTML too on lilypond.org. LilyPond is
> probably not the only package that requires making all target before
> install.

I have no idea what it requires, and there are no files explaining it.
The normal invocation

    make && sudo make install

does not work.

>> It might be nice if some developers made it into a habit to try
>> building from a freshly checked out tree from time to time without
>> reverting to their secret knowledge.
>>   
> I spent a lot of time testing compilation and installation of Info
> docs a while ago (last time you reported problems IIRC), but I didn't
> notice it had been broken for two months by some (maybe untested)
> hack.  And please believe me that I have been making clean builds
> every day I change the sources or merge branches since I have a
> powerful enough machine; I test install targets less frequently,
> though.

Anyway, as it stands, there is no documentation in obvious places about
how to make things run, the build procedures are highly non-standard,
the targets are non-standard.

I am holding a talk tomorrow about Lilypond on a Linux conference.  That
is the state I am going to report.

It is a bit disappointing since the info documentation with images is
essential for really getting moving smoothly with Lilypond, and the
procedure for producing them is so broken or obfuscate that none, I
repeat none of _any_ lilypond precompilated versions that I know of
carries them, and there is no way even a clever user could be expected
to arrive at usable docs.

I am not stupid with either Unix, make, Emacs, and environments, and I
still have no working info documentation with images: I can only use it
from some obscure Documentation/User/out tree, and then obviously
cross-file references don't work.

And that is the state after several sessions (with months in between) of
pestering developers, and of trying for quite a number of hours to get
things going myself.

It is my opinion that Lilypond developers are shooting themselves quite
unnecessarily in the foot by the large discrepancy between the high
quality of the documentation and the probability of actually getting to
see it after a finite amount of effort.

This is hampering Lilypond adoption by end users, not least of all
because _all_ redistributors of Lilypond that I know of fail to produce
the documentation in workable shape.

-- 
David Kastrup