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
d...@lola:/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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
