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

[John Mandereau]

David Kastrup a écrit :
> I don't think that is standard usage.  install-info would be the norm
> when available.
>   
Will fix this, but see below my request.


> > > make install bombs out, anyway:
> > >
> > > 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$   
> > >       
What does "grep NCSB config.make" (at top of the build tree) does say?  
Are mf/out/Century*.otf files
generated if you call "make" again? Did you get an error from a clean 
working tree, or with already a lot of
stuff in out subdirectories?


> 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.
>   
In LilyPond, it is.

> 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.
We didn't expect self-compilers to start compiling LilyPond directly with a
Git snapshot; we probably should generate README INSTALL and other top files
in out/ when running autogen.sh and inform the user.



> Anyway, as it stands, there is no documentation in obvious places about
> how to make things run, the build procedures are highly non-standard,
>   
Which standard build procedure are you talking about?  We organize the 
makefiles in an way appropriate
to the size and history of the project.

> the targets are non-standard.
>   
Please report which /end-user/ targets are non-standard besides 
*-install ones, which should be install-*.


> I am holding a talk tomorrow about Lilypond on a Linux conference.  That
> is the state I am going to report.
>   
I hope you will report the ease of installing precompiled binaries 
(except for MacOSX) and unpacking
precompiled documentation available on lilypond.org.

> 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.
>   
This is a bit biased: it works for several people, so please don't make 
hasty generalizations.
As for shipping Info docs (and more generally compiled docs) in 
precompiled binaires,
I'd not be surprised if the long compilation times and additional 
dependencies that can't be
required by configure but that are listed in INSTALL/Application Usage 
make some packagers
reluctant to do it, even in case it works out of the box -- do you know 
many software projects
where the documentation takes something like 4 times the time for 
building the program?
We don't get any reports for documentation compilation and installation 
from people outside
the development team besides you, whereas we sometimes get reports about 
compilation issues
for the main program.  Does it show that packagers are a bit less 
concerned by distributing the
documentation?  I don't know.

> 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.
>   
If you are not willing to hack our makefiles, which I perfectly 
understand, please no longer try to
get it work other than using documented make targets.  We still welcome 
any constructive pestering,
though.

> 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.
>   
Han-Wen and Jan made a huge effort to produce precompiled binaries and 
documentation; as they started
distributing good working ones (with GUB), the continuous flow of emails 
about broken package for system
X on arch Z suddenly decreased, and we haven't taken so much care to 
self-compilers because of the lack of
human resources.

Best,
John