Texi2html requirement -- 1.80 is out
Hello, Texi2html 1.80 is out! Do you think it's all right to remove support for "makeinfo --html" in one week? I think we should support Texi2html 1.80 during all 2.12 series and not require Texi2html from CVS again before we start 2.13. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Keep git-update-changelog.py?
Do we want to keep buildscripts/git-update-changelog.py? This script was designed to update Savannah CVS with changes made in git.or.cz Git repository during the transition between the two revision systems. We no longer need this script for this purpose, but with a bit of hacking we could still use it to generate a ChangeLog for changes made since 2.10. However, I don't think a ChangeLog would be really useful: IMO curious people should install Git, download the Git repository and browse the Git history, which is much more powerful than reading a ChangeLog. In brief, I'm for removing this script from current sources. Please complain if you disagree. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.12.1 out; announcements and normal stable
Le vendredi 02 janvier 2009 à 13:34 +, Ian Hulin a écrit : > Grahame, His name is Graham. > Can you, John or Han-Wen do > gmane.comp.gnu.lilypond.announce? Some time has flown since 2.12.1, so I just did it. We are a bit confused, as 2.12 stable series begin while tasks with high responsability (building binaries and making releases) are took over and the GOP (Grand Organization Project) starts. By the way, I hope you consider joining the GOP to help us making LilyPond better. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributor/user split in docs
Le jeudi 01 janvier 2009 à 21:26 -0800, Graham Percival a écrit :
> While I was working on the new website, I realized that the info I
> was adding would work better as a manual rather than a few web
> pages. Therefore, in Feb (after 2.13 starts), I'll be creating a
> new manual: the Contributor's Guide.
This has already been suggested by several people including Bertalan
(sorry for the names I can't remember right now), but this idea lacked
the spark you just triggered off.
> (I /was/ going to call it the Developer's Guide, but then I
> realized that "DG" has rather a unfortunate meaning amongst
> computer geeks in my generation, and if my friends heard that I
> was working on the "new DG manual" I'd never live it down. :)
"CG" is fine, as not all contributors are developers, if you define a
developer as somebody who writes code, possibly as a secondary task,
e.g. along packaging.
> This will contain the INSTALL docs, doc policy, "working with
> texinfo" stuff, the git guide, info about what all the branches
> are, where to find gub, any potential tips to translators or
> bugfixers, code style, policy for bug reports, checklist for
> normal and major releases, etc. Generally, I'll be combining all
> the README documents that nobody (including me) looks at and
> putting them all in one place.
Good idea, but if we go for replace READMEs in plain text with a guide
written in Texinfo, we should make sure this guide is always available
in its latest revision and in a compiled form; this would be currently
http://kainhofer.com/~lilypond/
> I'll also try to write down all
> the `oral tradition' knowledge about lilypond that various people
> have.
It's not possible to achieve this completely unless you do surgery on
these people's brain :-)
> ... actually, on second thought, perhaps I don't need to wait. I
> don't think that anything in there should be translated; the
> translators need to read enough English to understand the main
> docs so they should be able to handle their instructions, and (for
> better or worse) we do everything else in English.
Of course.
> John, your opinions as both Translation Guy and the person who'd
> be adding the stubs for this to the build system?
I suggest this guide lives in
Documentation/devel/contributors-guide.texi, with .itexi files as
necessary. In addition to including this in HTML/PDF documentation
building ("make web"), what about adding a toplevel make target
"devel-doc"?
> (starting from next Sep, I should have a linux machine powerful
> enough to build lilypond, so my excuse will be gone. However,
> until then... ;)
Unless you have no machine that runs a Unix-like system with at least
512 MB RAM and a 1GHz CPU, your excuse will be gone as soon as I've
documented the makefiles structure in the Guide.
Cheers,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch review for fret diagrams
Le vendredi 02 janvier 2009 à 18:37 +, Carl Sorensen a écrit : > I haven't heard anything back on this patch, probably because I chose a bad > subject line. I'd appreciate if it could be reviewed. The recommended subject is "[PATCH] subject of the patch" regardless of the form of the patch (Git-formatted, plain Git diff or using Rietveld). I'm not qualified to review this patch, but I think a one week delay is not unreasonnable. If you already know all details and criterions for judging the quality of your patch, you could just review it yourself and push. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
SCons support in LilyPond
Hi Jan, Have you any plan for maintaining Scons support in LilyPond? The Python code hasn't been updated to be compatible with Python 2.6/3.0, and it calls scripts in stepmake/bin or buildscripts that have been removed several years ago. If we have no interest in maintaining this, I propose to remove it (SConscript files and buildscripts/builder.py), in order to avoid confusion for people who discover the sources or maintainers like me who update Python code and makefiles. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: using \include for remote files
Le vendredi 02 janvier 2009 à 16:11 -0600, Jonathan Kulp a écrit : > It occurred to me today that it would be nice if Lilypond could use > \include to include files that are hosted on a website, the way html > pages use stylesheets. Something like this: > > \include "http://www.websiteaddress.com/definitions.ly"; > > Is this something that's feasible? I tried just adding that line to a > file of mine and of course it said the file was not in the search path > and couldn't be found. This looks like a pie-in-the-sky feature: we'd have to add networking support in LilyPond, it's not obvious to support it for all OSes; maybe using a Python script for downloading would work? In the meantime, best I can recommend is including the file in your project and/or writing a makefile with a rule that uses wget to download the file and redownload when it has changed on the remote side. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: using \include for remote files
Le vendredi 02 janvier 2009 à 23:26 +0100, Valentin Villenave a écrit : > Gosh, John was faster than me :) I was this time only, but I go back to studies next Tuesday. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: About Learning Manual
Hello, Le vendredi 02 janvier 2009 à 16:50 +, Sawada, Yoshiki a écrit : > I am translating LilyPond Learning Manual Ver. 2.11.62 (not the latest > Version) > to Japanese (see > http://irjb.s346.xrea.com/wiki/LilyPond+Learning+Manual.html). Congratulations for this big amount of work! Would you like it to be included in LilyPond sources for inclusion in the official documentation? The pros and the cost are explained at http://lilypondwiki.tuxfamily.org/index.php?title=Translations_portal#Integrating_translations_in_LilyPond_main_project > 1. Appendix B > In the line 203 - 204 in the HTML code of Ver. 2.12.1: It says "object sizes > are > intervals with a left and right point", but I can not understand it. Could you > give me an example which shows an object size expressed by intervals? > > 2. Appendix B.1 > In the line 70 in the HTML code of Ver. 2.12.1: It says "TODO Find a simple > example". Please replace it an actual example, if you can. Carl or somebody else may want to process your comments now, but the Scheme tutorial should be rewritten anyway. > 3. Changes list from Ver. 2.11.62 to the latest Version. > I am translating LilyPond Documentation Ver. 2.11.62, but the latest version > is > 2.12.1. So, I want to get the changes list from Ver. 2.11.62 to Ver. 2.12.1. > Can > I get it? If you use Linux, you can get the sources easily following instructions from http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=blob_plain;f=Documentation/TRANSLATION;hb=lilypond/translation Then you can get the full changes patch by issuing git diff release/2.11.62-1 release/2.12.1-1 Append Documentation/user to the command above to restrict the patch to files in that directory. Best -- John Mandereau LilyPond translations meister ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SCons support in LilyPond
Le samedi 03 janvier 2009 à 20:54 +0100, Jan Nieuwenhuizen a écrit : > I was hoping someone would see the beauty of scons and > junk our stepmake cruft ;-) I'm afraid it is too late to resurrect SCons, or too early if you prefer. I remember a number of packages used a so-called revolutionary program named SCons, I no longer encounter it. Maybe it's superior to stepmake system, but we recently consolidated the makefiles enough (e.g. support for -j make flag, cleaning up documentation compilation) so that we can concentrate on other problems. > > I propose to remove it (SConscript files and buildscripts/builder.py) > > Sure. I will include this removal in the patch that splits stuff in buildscripts. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: contributor/user split in docs
Le vendredi 02 janvier 2009 à 18:52 -0800, Graham Percival a écrit : > I'll have the pdf on my > website for GOP, and after the first few weeks, this document > shouldn't be changing much, so the normal stable release will be > fine. IMHO a few weeks won't be enough for stabilizing the Guide, but I guess this will be no problem you upload the conributors' guide to lilypond.org, a simple cron job could do. > It's perfectly possible. We all swap jobs, and read the CG. > Whenever we can't figure out something, or whenever the old > job-person points out a mistake, we fix the CG. Trust me, my > "RTFM is the only answer" would ensure that we have complete docs > within a few weeks. :) Again, I think a few weeks are not enough, this is rather an ongoing process. > Now, you might question whether it's *worth* swapping jobs. I > don't think it is, so I'm not suggesting that we do it. I'm just > pointing out that it *is* possible. And perhaps the most important, it's sometimes necessary. I think it's not worth swapping jobs, though. > Documentation/devel/ sounds great. Sold! > I don't think we need a devel-doc... actually, could this dump the > texinfo into text? That could be a cheap workaround for looking > at the HTML or PDF in the latest release on lilypond.org. Agreed. [Off-topic below] > Welcome to the wonders of my $350 eeepc 701. My pride and joy, > and my life for the next five months. :) Small is beautiful :-) I still prefer Emacs (as you'd prefer Vim) over any other text editor. > gperc...@nagi:~$ cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 13 > model name : Intel(R) Celeron(R) M processor 900MHz > stepping: 6 > cpu MHz : 630.078 > ... > > I keep all my svn/git checkouts on /sd, of course. I suppose > there's plenty of disk space to compile stuff on it, but... > 630 Mhz. This is the frequency in idle state, it should increase to 900 MHz every time the CPU becomes busy. It may take 3 hours to build all of LilyPond and documentation on your computer from a clean tree, which is reasonable if you do it once a week and rely on unclean builds the rest of the time; it would between 1 and 2 days to build all GUB, which less reasonable. > And I don't like pushing the hardware on this thing, > since I'm in serious trouble if anything happens to it. I've pushed my Celeron M with 504 MB RAM (8 MB for shared video mem) for 3 years with various big CPU-consuming tasks (compiling Gnome, Gentoo, Linux kernel as Fedora RPM, LilyPond and the doc, and (unsuccesfully) GUB), the fan has always been noisy and it was often hot enough to heat my room. I had to replace the DVD drive recently, but besides this that box still works well, especially with Fedora 10. Unless you can't easily apply the vendor warranty nor find cheap components for replacement, I wouldn't make worry about pushing the hardware if I were you; but I can understand you'd like to be careful... for example I don't know how quickly you'd reach the SD write count limit with intensive usage. > In case you're wondering, the 3/4 size keyboard is fine after the > first few weeks. It's just like moving from cello to violin. :) I wouldn't like to move from the oboe to the oboe piccolo :-) Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: About Learning Manual
On 2009/01/04 14:08 +, Sawada, Yoshiki wrote: > Yes, it is my hope to provide LilyPond community with my translation. > I am not a professional for music or translation, so my Japanese > document is not so good. But I hope someone will brush it up. You may want to contact Yoshinobu Ishizaki who has translated lilypond.org. I hope including your translation in LilyPond will bring you more suggestions and contributions. > WARNING: Please consider install optional programs: texi2html >= 1.79 > (installed: 1.78) You can find Texi2html 1.80 (for Texi2html odd numbers mean "get the sources from CVS") at http://savannah.nongnu.org/download/texi2html/ Note that because of a version control nitpick, a new release of Texi2html (1.82) will be out in a few days. After untarring it, the usual trio ./configure make make install will install it (you may need to do "chmod +x configure" first). It is recommended to install packages from sources in $HOME or /usr/local instead of /usr, --prefix option of configure script allows you to do it, "./configure --help" documents more options. > ERROR: Please install required programs: mpost > > I am using Ubuntu 8.10. To get mpost you must install a TeX distribution, I hope Texlive is available for Ubuntu, otherwise you can either install the old and no longer maintained teTeX distribution or download Texlive DVD ISO image. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Keep git-update-changelog.py?
Le dimanche 04 janvier 2009 à 20:54 -0200, Han-Wen Nienhuys a écrit : > Please junk Done, and did the same for metapost-*.make. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Re: Remarks about the building process
Hi Han-Wen,
Sorry for the quite unreasonable delay, but I hope I've sorted out GCC
warnings mentioned in this thread.
Le samedi 08 novembre 2008 à 16:59 -0200, Han-Wen Nienhuys a écrit :
> +#define EPSNULL 1e-12
> this looks fishy. Why another EPS value? Joe?
I apologize for this obviously wrong patch, I must have messed up recent
and old patches. I'll organize my patches in a better way from now,
with different directories for submitted and unsubmitted patches.
> + if ((where
> + && current_reps == SCM_EOL) || scm_is_pair (current_reps))
> {
>current_reps = scm_cons (what, current_reps);
>where->set_property (reps, current_reps);
>
> this is wrong. In your version, where can be NULL if current_reps is
> a pair, which lead to a crash. Please double check all of the changes
> that may seem cosmetic.
I've done my best with my current understanding to do right changes.
BTW I'm trying rietveld, please review
http://codereview.appspot.com/11867
Best,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SCons support in LilyPond
Le dimanche 04 janvier 2009 à 00:39 +0100, John Mandereau a écrit : > I will include this removal in the patch that splits stuff in > buildscripts. I actually made two commits, because these two issues only intersect at builder.py and these commits are large enough. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: About Learning Manual
On 2009/01/05 12:31 +, Sawada, Yoshiki wrote:
> Then, I did as following:
> ./autogen.sh
> ./configure
> make
> make install
You needn't install LilyPond to work on translations, but it is very
good you can build it. Have you tried "make web"? See Application
Usage -> Install -> Compiling from source -> Building documentation for
details.
> Because I do not have langdefs.py in buildscripts,
Where did you read you should have langdefs.py in buildscripts/? It was
moved to python/ months ago, and I did update documentation bits:
"""
commit 591dcd1740655062b541f2ca273147882bea3f9d
Author: John Mandereau
Date: Sat May 24 09:48:38 2008 +0200
Update TRANSLATION
"""
> I copyed
> http://lilypond.sourcearchive.com/documentation/2.10.33-2ubuntu1/langdefs_8py-source.html
> to buildscripts. Then I added the line into langdefs.py:
> ja = LanguageDef ('ja', 'Japanese')
> and changed:
> LANGUAGES = (site, fr)
> to:
> LANGUAGES = (site, ja)
This is a very old version of langdefs.py, which can't work with current
makefiles and other Python scripts.
> But, when I do:
> make ISOLANG=ja new-lang
> in Documentation, it says:
Cd into Documentation/, save anything precious in ja/, then do
rm -rf ja
make ISOLANG=ja new-lang
and only then update python/langdefs.py.
Good luck,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Directory name of aux is invalid
Le lundi 05 janvier 2009 à 15:32 +, Trevor Daniels a écrit : > I have a git problem with your recent commit > c553fc2251b508befebd1dc297c4baa898463f34 to clean up the build scripts. > The reason is that aux is a reserved word in Windows, along with a few > others like com, lpt1, nul, prn, Lpt4, and no directory can be given these > names. The effect is that I can't update my git repository from > origin/master, which in turn means I can't push. Aargh. This commit also implies creation of scripts/aux/. I don't enjoy so much saying this, but the limitation we hit is worthwhile: Windows sucks, I wish there were only Unix OSes. :-) > Do you have any suggestions to get round this? What about replacing aux/ with auxiliar/ or helper/? "auxiliar" is the Spanish for "to aid", it's only one character shorter than "auxiliary", but it's nicer than ugly abbreviations longer than "aux" like "auxi" or "auxil". Well, this is kind of urgent for you Trevor, so let's not discuss too long: I'm renaming "aux" to "auxiliar". Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: release note translations
Hi Till! Till Rettig a écrit : Was there already discussion on translating also the NEWS part of the documentation? It might not be really used by many people when 2.12 has become normality but for the moment it might be interesting since it also has a direct link from the news entry on lilypond.org. In other words: I suppose we would provide more updated 2.12 versions, especially with updated translations. In one of them it might also be nice to have the NEWS page integrated. I'm sure it's worth translating the News document, it's up to you to decide whether you find more important to do this than translating and updating the three main manuals. I think we can't take a global decision for all languages, because translations are in quite different states depending on the language; e.g. the French docs are so outdated that I'd rather not direct translators' enthusiasm towards translating News. The work involved in adding support for translated news is very minor, I'll do it as soon as one of you translators commit on lilypond/translation a file named Documentation/LANG/topdocs/NEWS.tely. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation/devel/
Graham Percival a écrit : Could I get this dir created and added to the build scripts? I'd like to move the stuff from web-gop/texinfo/contributing into there, so that Carl can see what's there and add to it. Done. BTW I'll look at integrating Texinfo docs in web-gop after Jan. 19th, as I'm quite busy with studies this week-end and next week. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.12.1 for cygwin?
Frédéric Bron a écrit : Hi, is there a chance that we have a 2.12.1 release for cygwin? Using 2.10.33 on cygwin was great, I'd love to switch to 2.12.1. Have you already tried MinGW binary available on lilypond.org? You can run it from Cygwin if you set the PATH accordingly, and it is probably much faster than the Cygwin binaries. HTH, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation/devel/
Hi Graham, Graham Percival wrote: If anybody doesn't like it (and doesn't know/feel like fixing it), just revert that commit. Reverting commits is not good for the moral. It's best not to break compilation on master though, so I suggest you create a branch dev/gpercival if you like. That said, I'll keep fixing makefiles for your commits until you can do it yourself. Anyway, if anybody knows how to fix it, please do. Done. OTHER KNOWN PROBLEMS - eventually we might want macros.itexi to be in Documentation/. Or maybe not. I don't mind where it lives, but let's not duplicate it unless necessary, see Git master history. - large sections are completely unformatted. Or rather, they're formatted for text files rather than texinfo. I'll fix that one of these days. I'll insert and format contents from Documentation/TRANSLATION and lilypond.org README. John: I waffled over whether to add a "Translation" section in Docs and Website, or whether to add a "Translation" chapter which would include a Docs and Website section. You did the former and that's fine, as many informations on . Most of all -- and the reason I added this with all its current problems -- I want us to start dumping info here, rather than split between old website info, public emails, wiki, private emails, etc. Git detailed commit messages are (or should be) one of the most valuable sources of code documentation, e.g. the best way to start documenting makefiles infrastructure is reading the output from find -name GNUmakefile |xargs git log GNUmakefile.in make stepmake (use -p git flag to read comments in the diffs). > Here's my thoughts about what your priorities should be, if you give them any weight whatsoever. :) I'd like to, but besides real life I must also manage the three new French translators. 1. Support the Frogs. They have energy and whatnot, copmletely unlike me right now. Now, I don't think there's anything you can do for them directly. That said, I will, although I won't react daily. 2. Get GUB setup and working. Whatever bugs you find and fix will be less that I'll encounter. Since I'm using kainhofer, I'll probably find bugs (in x64) that you don't find, but getting GUB more stable will still help. I'm running a x86_64 box too. 3. If you want to earn my undying gratitude and love, log in to kainhofer (if you can) and get GUB working on that. If manage to build correct binaries on my machine, I'll leave getting GUB working on kainhofer to somebody else: getting GUB to build on a variety of machines is cool, but not necessary; getting GUB to build on at least one machine by is necessary, though. 2+3: one way or another, we should start releasing more often, and I lack experience at debugging build failures, and don't anticipate having the energy to learn to do so in the next few weeks. I wouldn't have the energy to coordinate GOP, manage releases and build binaries too; from this point of view, it is understandable that Han-Wen and/or Jan made a distinction of Release Meister and Build Meister jobs on lilypond.org recruitement section. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] my contribution: barCheckNumber to endSpanners
Graham Percival a écrit : On Sat, Jan 10, 2009 at 08:12:49AM +0100, Frédéric Bron wrote: - I have mainly copied documentation from the Notation Manual. Would be better to enter the documentation only once because if the function changes, we have to change the doc. at two locations. Definitely -- but where were these docs from the NR? Please give specifics so that we can (probably) delete them from the NR. I propose to adopt either of the following solutions: 1. Define a macro for each predefined command: the docstring of each function \foo would be stored in a macro named @musicFunctionFoo, which would be used both in the Identifiers page and throughout the manual in "Predefined commands" sections. 2. For each music function, add link from "See also" sections to the Identifiers page, with HTML/PDF anchors made with @nodes. I'm all for 1: there are already a lot in cross-references in our docs that are necessary, this is difficult enough to read so we should avoid needing them whenever possible. The first solution makes information duplication in the output documentation only, not in the sources. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] my contribution: barCheckNumber to endSpanners
Carl D. Sorensen a écrit : I propose something different. I think the current NR documentation is right, with a usage description in the section of the NR, and a short description from the docstring in the appendix that lists all music functions. The reason I use the Identifiers page is that it's a quick read of available functions -- if it gets longer because we have usage instructions it won't be as useful to scan quickly. Good point, but this is not incompatible with what I proposed: I think the short documentation string is useful even throughout the NR, it documents the function prototype in a concise way, which allows to concentrate on usage details in the explanation. If we want to move to having this documentation all in the music functions (which may be a good idea, but will require some substantial rewriting of the documentation building system, IMO), we should have *two* documentation strings in the music function: 1) a description string, which is like the current docstrings, and 2) a usage string, which is like the current text from the NR. I think the effort vs. gain of maintanibility ratio is not worth doing this. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.12.1 for cygwin?
Frédéric Bron a écrit : That's what I did before 2.10.33. But then, cygwin came with the right lilypond version and I preferred switching to cygwin. I have now installed mingw version of lilypond. However, who/how was lilypond added to cygwin? Bertalan Fodor used to do it when MinGW binaries didn't exist (before 2.8 series IIRC), I'm not sure he still does. You might help yourself by looking for the Cygwin package information. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git patch won't apply
Neil Puttock a écrit : Hi Carl, 2009/1/10 Carl D. Sorensen : Any thoughts on what is wrong or how I can get this patch to apply? It applies OK using `git am'. BTW git-apply should be used for patches without authoring information, i.e. patches not made with git-format-patch. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git patch won't apply
Carl D. Sorensen a écrit : fatal: git apply: bad git-diff - expected /dev/null on line 46 Patch failed at 0001. When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". Any other ideas? You might want to try rm input/new/printing-the-bar-number-for-the-first-measure.ly before applying. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation/devel/
Hi Reinhold, Reinhold Kainhofer a écrit : So, apparently, ./conftest can't find the libltdl.so.3 any more (which it was linked against), since the tools directory is no longer in LD_LIBRARY_PATH... It seems that while building (and of course also when running) all the tools, we still need the tools directory in the LD_LIBRARY_PATH... On the other hand, when compiling/linking, the LD_LIBRARY_PATH pathes should be ignored to prevent linking to libraries in tools/ ... Hmm, to be honest, I have no real idea of the correct way to handle this! Have you tried installing libtool-ltdl-devel (or whatever this Fedora package is called on Ubuntu) system-wide? Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git patch won't apply
Carl D. Sorensen a écrit : fatal: git apply: bad git-diff - expected /dev/null on line 46 Patch failed at 0001. When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". Any other ideas? Are "diff --git a/... b/..." lines broken in the patch you actually tried to apply? They should not be broken, I guess. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Git patch won't apply
Carl D. Sorensen a écrit : Are "diff --git a/... b/..." lines broken in the patch you actually tried to apply? They should not be broken, I guess. No, they're not broken. It's one line. Ugh, I'm almost short of ideas; which OS do you use to work with Git? Could a non-Linux system be confused by /dev/null? Is your Git working tree clean? John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Documentation/devel/
Reinhold Kainhofer a écrit : Am Samstag, 10. Januar 2009 18:49:40 schrieb John Mandereau: Have you tried installing libtool-ltdl-devel (or whatever this Fedora package is called on Ubuntu) system-wide? Yes, it is installed: lilyp...@server:~$ locate libltdl.so /usr/lib/libltdl.so /usr/lib/libltdl.so.7 /usr/lib/libltdl.so.7.1.2 This tells libtool-ltdl is installed, but it tells you nothing about libtool-ltdl-dev; is /usr/include/ltdl.h present on your system? Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make all' fails
Patrick McCarty a écrit : `make all' fails on current master. Is this because the new directory, Documentation/es/topdocs/, doesn't have a makefile yet? It had the makefile on my working tree, but I forgot adding it to Git :-/ make[3]: Entering directory `/home/pnorcks/git/lilypond/Documentation/es/topdocs' make[3]: *** No rule to make target `all'. Stop. Fixed. Thanks, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch for my bit of Frogs Task 1
Ian Hulin a écrit : (Apolgoes to the list for this coming late, I'm sorting out my subscription via gmane) Hi Carl, Here's a patch for ny bit of the first Frogs Task, but I've got some questions. Hi Ian, I wouldn't have applied your patch as this is up to Carl, but could you resend it either without line breaks or as an attachment? The patch you sent won't apply because of extra line breaks. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] my contribution: barCheckNumber to endSpanners
Carl D. Sorensen a écrit :
I've only used @code{} because I saw it in the docs before I started.
I think @var{} makes more sense.
Anybody on -devel have a definitive answer to this question?
The purpose of @var is marking variables (but not names of predefined
variables), so let's use it as suggested by the C. Guide. If we want
variables in a fixed-width font though, it's certainly possible to tweak
HTML output.
Cheers,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Japanese translation of Learning Manual
Hello Yoshiki, Thanks for your quick work on the Learning Manual. Sawada, Yoshiki wrote: My patches look dirty because I changed something on scripts directries to do "make web" completely. It looks like you reverted some changes to get the documentation to compile. I've certainly left the history with some Git revisions that don't compile, but reverting changes on your tree is only a resonable solution when you (or anybody) have already reported the error on this list and nobody has fixed it quickly; in this case, you probably did "git commit -a", which included in the first commit a lot of changes not concerning Japanese documentation. I think my patch should show only changes on "python/langdefs.py", and addition of "Documentation/ja/" and its files. I removed changes regarding all files except Documentation/ja before applying, and I couldn't find any diff for python/langdefs.py, so even though I applied your work on lilypond/translation, its compilation will be not be enabled before I apply a patch from you for langdefs.py (I don't know how to write "Japanese" in Japanese :-) How do I get neat patch? Don't put changes you make to fix compilation and changes for the documentation in the same commit; for example use "git commit Documentation/ja", and for more details do "git commit --help". Don't worry about using Git, after some time you will surely get comfortable with it. For now I only have one comments on your work: could you write your name as @c Translators: Yoshiki Sawada in the Texinfo sources, as the comma is used as a separator between different translators (yes, several French translators are often needed to complete translation of one file :-)? Thanks in advance! Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FW: Artificial harmonics with sounding pitch in parenthesis
Carl D. Sorensen a écrit : Graham and Trevor, This mail below, from -user, shows why I think NR 5 and NR 6 should be combined into one chapter, something like Extending LilyPond. I rather agree with Trevor that these chapters should remain separate (in thread Learning Manual TOC missing subsubsubsections), see below my suggestion. But because it's tucked away in NR6 "Interfaces for Programmers (HARD!)", people never see it. IMO, it's lots more gentle to just put it all in one chapter, and let the reader decide what tasks are more challenging than he/she wants to undertake. Just some food for thought, What about simply renaming NR6 "Interfaces for programmers" to "Extending LilyPond"? This would imply that all complex tweaks that extend LilyPond, e.g. using functions as overrides, should be in NR6 and not NR5. Extending LilyPond implies programming, but hiding the term "programming" in the title would scare less users away as you point out. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: No apparent makefile dependency for make web on ly/music-functions-init.ly
Carl D. Sorensen a écrit : When I make changes to ly/music-functions-init.ly (which will affect Appendix B.14 of the Notation Reference), then run the documentation is not updated to reflect the changes in ly/music-functions-init.ly. Should I post this to bug? No, issues with makefiles should be discussed on this list and fixed as soon as possible after a decision is made. In this case, would you like compilation of "lilypond-internals" (which is a dependency of "lilypond" manual) depend on ly/*.ly and scm/*.scm? This will retrigger compilation much more often, but this would be more consistent than current setup. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: No apparent makefile dependency for make web on ly/music-functions-init.ly
Carl D. Sorensen a écrit : This sounds good to me. I'd much rather trigger recompilation more often than miss a change. Done: lilypond-book will be called if at least one file in ly/*.ly or scm/*.scm is newer than .texi output, which is enough to regenerate the Internals Reference and other automatically generated Texinfo documentation, but not enough to regenerate all @lilypond(file)s snippets, because the decision of rebuilding @lilypond(file)s is taken by lilypond-book, not by make. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: website compilation
Hi Matthieu, Matthieu Jacquot a écrit : File "../../scripts/lilypond-book.py", line 43, in import lilylib as ly ImportError: No module named lilylib make: *** [web-1] Error 2 ma...@gentoo ~/site/lilydoc $ Maybe I missed something, here's what I've done : I only pulled the translation branch in my new directory ~/site/lilydoc, autogen.sh doesn't comply, What do you mean? If autogen.sh/configure says you have all dependencies installed, you should build LilyPond with "make" before building the documentation. make web, I had to add a symbolic link in /out/bin for the lilypond binary, make web again it seemed to work better but it fails with this message. Am I doing something wrong? If you can't build LilyPond itself easily (e.g. because it's diffcult or you don't want to install all dependencies), see http://lilypond.org/doc/v2.12/Documentation/user/lilypond-program/Building-documentation#Building-documentation-without-compiling-LilyPond Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Distribution updates and documentation woes
Hi Jan, Jan Nieuwenhuizen a écrit : After 2.12 I decided to do my small round checking of distributions again Super; I think it's a good idea to go on mentioning distros that provide latest stable on the download page, so I've added links for Fedora and Slackware. (should we add something like this to release tasks?). Yes, probably. Fedora is a special case, it uses our prebuilt documentation ball, so no simple patch can be provided. I think we need to fix this, other distributions may also go this way of using our pre-built doco. How to fix images in Info docs for Fedora? - distribute lilypond-info-man.tar.bz2 alongside documentation ball? - roll info (and man?) docs into documentation ball + How? docbal currently is rooted at ./Documentation, info would need to be moved to/unpacked at ../../info . This will be the simplest solution for Fedora packagers if we include info docs and re-root the documentation ball as you suggest below. - suggest make web, make web-install + adding of symlink This is the standard way to go but it's more involved for the packager; IIRC lilypond-doc Fedora package has not always used this to package the docs, it used to be a bit messy, it included stuff from out/ directories. See http://ftp.nluug.nl/pub/os/Linux/distr/fedora/linux/development/source/SRPMS/lilypond-doc-2.12.1-1.fc11.src.rpm IWBN if a fedora user would file the wishlist/bug once we settle on a fix. I can do it next week. And last but not least: what about our own documentation builds? Info docs are missing here altogether! Should we include info docs and re-root the documentation ball to look like share/doc/lilypond/Documentation/* share/info/dir share/info/* I'm for this too. Unless somebody wants to it right now, I'll have time to do it next Wednesday. and/or provide a shar archive to extract the documentation into a proper place? I'd suggest to go on distributing the docs as a bzipped tarball, and add in the shar containing the binary a command line option and/or prompt to download (if not present in current directory) and untar the documentation and install Info docs. I'm sorry I'm so busy with studies that I'll be idle on LilyPond until next week. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please fix: japanese doc compilation
Hi Han-Wen, Han-Wen Nienhuys a écrit : someone added a japanese translation of the docs, but after enabling it (so it is distributed), I get error (see below). Can someone fix this, or disable the translation? This is a blocking issue for releasing 2.12.2. I suggest not to enable it or revert the commit, and I'll deal with this on Wednesday; I'm completely unavailable today and tomorrow. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please fix: japanese doc compilation
Hello Yoshiki, I'm sorry for the delay, and unfortunately I am still quite busy. Sawada a écrit : Hello everyone, ./lilypond-learning.pdftexi:58: Paragraph ended before \documentlanguagetrywith outunderscore was complete. \par I always get the messages like above while I am doing "make web". It will fail. But, I do "make web" twice or three times, then it will work well. Repeating "make web" until it succeeds hides the fact it's currently not possible to build the Texinfo manuals in Japanese as Werner pointed out; I'll make it possible to enable building Japanese documentation in HTML only this week-end, so that "make web" goes on working. Of course, it is up to you to judge whether the translation is in a good shape for inclusion in the official documentation; I generally think making translations available earliest makes proofreading them by other people easier and speeds it up (except I couldn't reply as quickly as I'd like lately). Best, John Mandereau ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please fix: japanese doc compilation
Sawada a écrit :
I'm sure. Perhaps, we should not include Japanese translation in the source
codes until Texinfo supports Japanese. However, I want to make my translation
available in the web.
As it's possible to distribute Japanese translation at least in one compiled
format, namely Texi2HTML. However, it is reasonable to enable the
compilation of the Japanese docs only after you have provided a patch (or a
patch set) that address these points:
- remove "@c -- SKELETON FILE --" lines in .itely files where you have
translated at least a paragraph;
- provide Texinfo macros like @untranslated and the like, see e.g.
Documentation/fr/user/macros.itexi to see what macros should be defined;
- provide translation of the tutorial (which you have already translated on
http://irjb.s346.xrea.com/wiki/LilyPond+Learning+Manual.html so even if this
this a huge work you already did most of it :-)
- provide Documentation/ja/{translations-template,index}.html.in and
Documentation/po/ja.po (you needn't translate all PO entry, just figure out
which ones are needed for translation of the Learning Manual, from the file
names in which they appear).
- provide all (even Texinfo skeleton) files that would have been created by
"make new-lang", e.g.
cd Documentation/
mv ja ja.orig
make ISOLANG=ja new-lang
then copy back files from ja.orig to ja and delete ja.orig.
I believe my translation will help Japanese users to
understand LilyPond more easily and is needed as the material for proofreading
as you think.
Certainly, and integrating it in the official sources and documentation will
hopefully help for this.
Best,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please fix: japanese doc compilation
Han-Wen Nienhuys a écrit : Can you make it so doc and web take a different set of languages? For the tarball distribution, I still want to build the PDFs. I'm not sure I understand what you mean with 'doc' and 'web', I assume PDF and HTML, respectively. Japanese docs compilation will remain disabled until it is complete enough anyway, but I've already pushed a patch to disable Texi2pdf call for Japanese docs. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Remarks about the building process
Han-Wen Nienhuys a écrit : I can't remember the status of this change, but LGTM Thanks, applied. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please fix: japanese doc compilation
Sawada a écrit : It is good that Texi2HTML can handle Japanese even if Texi2DVI cannot handle it. I think we should turn off texi2dvi for Japanese Documentation. Yes, this is what I did in the makefiles. I provided all files which were created by "make ISOLANG=ja new-lang". The command produced files only for Learning Manual. Do you mean I need to provide other files (i.e., for "Program Usage", "Notation Reference" and so on) ? If you can give me those files or tell me how to create them, it is better. But I can create them by copying and editing them from "Documentation/user", if I need to do so. Sorry for the confusion I made, lilypond-learning.tely doesn't include dedication.itely, you needn't create skeleton files for Application Usage and the Notation Reference; so you should remove all files which are not included in lilypond-learning.tely. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Japanese documentation templates
Yoshiki Sawada wrote: The second patch in it is the new patch. Try it, please. If there are something to fix or do more, tell me. I should have replied earlier to other messages... I applied all changes that didn't add files related to the Notation Reference or Application Usage, and made a small fix to get the documentation to compile successfully. Your translation is now in the sources and it is enabled (only for HTML output), so it will be included in the next release (2.12.3). I will keep translating advanced. Excellent. I'm going to make comments on minor formatting details on your patches, but first I'd like to finish including translation isntructions and tips in the Contributors' Guide, which will be eaiser and more comfortable to read than the text file TRANSLATION. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG texi2html command
Hi Graham, Graham Percival a écrit : How hard would it be to compile the CG with --split=sections instead of the current setting? I have the following in my compilation log on Jan 24th: make[3]: Entering directory `/home/lilydev/git/lily/master/Documentation/devel' cp -f contrib-guide.texi out-www/contrib-guide.texi /home/lilydev/git/lily/master/scripts/build/out/extract_texi_filenames -o /home/lilydev/git/lily/master/out/xref-maps out-www/contrib-guide.texi extract_texi_filenames.py: Processing out-www/contrib-guide.texi mkdir -p out-www/contrib-guide/ texi2html -I /home/lilydev/git/lily/master/Documentation/user --I=/home/lilydev/git/lily/master/out/xref-maps --I=. --I=./out-www --output=out-www/contrib-guide/ --prefix=index --split=section --init-file=/home/lilydev/git/lily/master/lilypond-texi2html.init out-www/contrib-guide.texi I guess "--split=section" is ignored by our custom init file, so we should reenable Texi2HTML defaults there if this option is caught. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: starting 2.13 soon
Graham Percival a écrit : Has anything urgent happened since 2.12.2 was released? I can't think of anything. Unless anybody complains within the next 48 hours, we'll switch to 2.13 and get started with all the major changes. What major changes are expected? Are there already significant changes that deserve switching to 2.13 very soon? Minor syntax changes are not worthwhile IMHO. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: starting 2.13 soon
Sorry for double posting, I hit the key for sending too early. Graham Percival a écrit : Has anything urgent happened since 2.12.2 was released? Yes, the Japanese translation. I think it deserves a 2.12.3. I can't think of anything. What about posting an announcement on info-lilypond and a news item on lilypond.org? Please correct me if this is not your job. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: starting 2.13 soon
Yes, the Japanese translation. I think it deserves a 2.12.3. Good point. OK, we'll wait a week or so. That's perfect. Yes, that's totally my job. Umm... do you mean about 2.12.2, or about 2.13 when that happens? Talking from my little experience in announcing releases, it may be too late for posting to info-lilypond more than two days after the release is out, but I think an even late new item on lilypond.org is appropriate. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG texi2html command
Hi Reinhold, Reinhold Kainhofer a écrit : Do I understand it correctly, that for the CG, you want e.g. all subsections of "1.1 Gettin the source code" in the same html file, all subsections of "1.2 Updating the source code" in another html file, etc.? Yes. The quick and dirty fix would be to add a check for the manual name in the if clause quoted above. However, I'd like to keep the .init file rather clean and not add such special cases... Agreed. However, the other part of our splitting algorithm is implemented in the extract_texi_filenames.py script (which generates the file names for the output html files), we might find a solution by tweaking that script, so it places all subsections into the same html file... Let's got for hacking extract_texi_filenames.py; unless you prefer to do it, I plan to do it before Wednesday. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: starting 2.13 soon
Graham Percival a écrit : IIRC there were already two patches that are waiting to be applied that were put off until 2.13. Trevor was talking about reshuffling the text crescendo commands. OK, this is probably enough to start 2.13 in one week. I just finished unpacking today (yeah, 3.5 weeks after I arrived :) This not so exaggerated in case you had to start studies just after you arrived :-) I suck at the CG, I'll strive to do something an evening after midnight, I have no other free time next week (including next week-end). Most of all, the stability rule about 2.12 was imposed too quickly and came as a shock to most developers. We'll have a much longer stable 2.14, but I think it's better to move to 2.13 sooner rather than later. About a month ago, I said that we'd move to 2.13 at the beginning of Feb. Oh yes, time has flown so quickly... Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Good luck, Valentin
Jonathan Kulp a écrit : Francisco Vila wrote: Cross fingers, today is the premiere of Valentin's "the LilyPond Opera" in Montpellier. Success! The name is "Affaire étrangère"; how would you translate it, Valentin? :-) All right! Can't wait to hear how it goes. Good luck! IIRC it should have started at 15.00 CET, so the premiere is most probably finished. I hope this was a great success and the two other will go well too. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: many texi2html warnings for lilypond-snippets.texi
Hi Werner, Werner LEMBERG a écrit : Compiling the documentation in current git with `make web', texi2html (CVS version from 2009-01-09) produces zillion warnings like this: *** Duplicate node found: Adding beams (in out-www/expressive-marks.texi l. 13 in @lydoctitle) *** Duplicate node found: Changing text and spanner styles for text dynamics (in out-www/expressive-marks.texi l. 407 in @lydoctitle) *** Duplicate node found: Printing metronome and rehearsal marks below the staff (in out-www/expressive-marks.texi l. 1635 in @lydoctitle) ... ** node_next `slurs' for `Adding beams' not found ** node_prev `ties etc. when using tuplet and non-tuplet rythms.' for `Adding beams' not found ** No node following `Adding ambitus per voice' in menu, but `Ambitus with multiple voices' follows in sectionning This was the simplest way I found to make TOC links for individual snippets effective, and I guess "makeinfo --html" won't return non-zero status with this. A cleaner solution would be generating menus and @nodes in makelsr.py and/or lystotely.py. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
Hi Jan,
Jan Nieuwenhuizen a écrit :
So, apart from not updating libtool here, I've now also fixed the target
architecture, platform etc when building tools; makes much more sense.
Oh, I've push a whole slew of fixes that will trigger a grand rebuild...
I tried building GUB again yesterday. The fix for libjpeg works for me,
but I get the error in the attached log.
I made
make -f lilypond.make bootstrap
on a Fedora 9 x86_64 box (I used to simply "make -f lilypond.make", but
it looked like it didn't build all dependencies for building
LilyPond itself a few weeks ago.)
Best,
John
invoking tar -C /home/lilydev/git/newgub/target/freebsd-x86/root -p -x -z -f /home/lilydev/git/newgub/target/freebsd-x86/packages/cross/gcc-c++-runtime-4.3.2.freebsd-x86.gup
installing package: cross/gcc-runtime
untarring: /home/lilydev/git/newgub/target/freebsd-x86/packages/cross/gcc-runtime-4.3.2.freebsd-x86.gup
Running read_pipe
('tar -t -z -f "/home/lilydev/git/newgub/target/freebsd-x86/packages/cross/gcc-runtime-4.3.2.freebsd-x86.gup"',)
{}
invoking tar -C /home/lilydev/git/newgub/target/freebsd-x86/root -p -x -z -f /home/lilydev/git/newgub/target/freebsd-x86/packages/cross/gcc-runtime-4.3.2.freebsd-x86.gup
Running file_sub
([('^libdir=.*', "libdir='/home/lilydev/git/newgub/target/freebsd-x86/root/usr/lib'")], '/home/lilydev/git/newgub/target/freebsd-x86/root/usr/lib/libgomp.la')
{'must_succeed': True}
Running file_sub
([('^libdir=.*', "libdir='/home/lilydev/git/newgub/target/freebsd-x86/root/usr/lib'")], '/home/lilydev/git/newgub/target/freebsd-x86/root/usr/lib/libsupc++.la')
{'must_succeed': True}
Running file_sub
([('^libdir=.*', "libdir='/home/lilydev/git/newgub/target/freebsd-x86/root/usr/lib'")], '/home/lilydev/git/newgub/target/freebsd-x86/root/usr/lib/libssp_nonshared.la')
{'must_succeed': True}
Running file_sub
([('^libdir=.*', "libdir='/home/lilydev/git/newgub/target/freebsd-x86/root/usr/lib'")], '/home/lilydev/git/newgub/target/freebsd-x86/root/usr/lib/libmudflap.la')
{'must_succeed': True}
Running file_sub
([('^libdir=.*', "libdir='/home/lilydev/git/newgub/target/freebsd-x86/root/usr/lib'")], '/home/lilydev/git/newgub/target/freebsd-x86/root/usr/lib/libssp.la')
{'must_succeed': True}
Running file_sub
([('^libdir=.*', "libdir='/home/lilydev/git/newgub/target/freebsd-x86/root/usr/lib'")], '/home/lilydev/git/newgub/target/freebsd-x86/root/usr/lib/libmudflapth.la')
{'must_succeed': True}
installing package: cross/gcc
untarring: /home/lilydev/git/newgub/target/freebsd-x86/packages/cross/gcc-4.3.2.freebsd-x86.gup
Running read_pipe
('tar -t -z -f "/home/lilydev/git/newgub/target/freebsd-x86/packages/cross/gcc-4.3.2.freebsd-x86.gup"',)
{}
already have file ./usr/cross/lib64/libiberty.a: cross/binutils
Tail of target/freebsd-x86/log/build.log
*** Failed target: freebsd-x86::cross/gcc
Traceback (most recent call last):
File "bin/gub", line 323, in
main ()
File "bin/gub", line 319, in main
logged_build (settings, options, files)
File "bin/gub", line 289, in logged_build
sys.exit (exceptional_build (settings, options, files, logger))
File "bin/gub", line 268, in exceptional_build
build (settings, options, files)
File "bin/gub", line 264, in build
b.build_source_packages (names)
File "bin/../gub/buildrunner.py", line 265, in build_source_packages
self.spec_build (spec_name)
File "bin/../gub/buildrunner.py", line 223, in spec_build
self.spec_install (spec)
File "bin/../gub/buildrunner.py", line 183, in spec_install
self.pkg_install (spec, pkg)
File "bin/../gub/buildrunner.py", line 179, in pkg_install
manager.install_package (install_candidate.name ())
File "bin/../gub/gup.py", line 322, in install_package
self.install_tarball (ball, name, d['prefix_dir'])
File "bin/../gub/gup.py", line 111, in install_tarball
raise Exception ('abort')
Exception: abort
make: *** [cross-compilers] Erreur 1
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch for ja doc and two Questions
Hello Yoshiki, Sawada wrote: Please use "0001-ja-doc.patch.org.gz" instead of "0001-ja-doc.patch.gz" in: http://irjb.s346.xrea.com/wiki/Patches+for+LilyPond+Document.html And change access modes from 755 to 644 following the instruction written in the page. How did you set the execution bit? Have you used a Windows machine or some non-Unix filesystem? I am really sorry for wasting your time. That's not a problem, I'm sorry I didn't comment your patch earlier. I'm doing it in another reply. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
Jan Nieuwenhuizen a écrit :
I finally cooked-up a patch for that, it took a bit more work than
I imagined. With latest GUB3 you can do
LIBRESTRICT=open:stat bin/gub mingw::guile # or mingw::lilypond
This will disallow libtool to read from or stat in /, so this should
(from target/mingw/log/build.log) give us a clue why libtool reads
from /usr/lib on your machine.
Oh, this will trigger a full rebuild ;-)
I have a (proably simple) problem with current HEAD for building
librestrict, which may be trivial
but which I couldn't fix quickly myself:
Tail of target/tools/log/build.log
* Starting build: Sat Feb 14 00:02:49 2009
root: /home/lilydev/git/newgub/target/tools/root
platform: tools
calculating dependencies
reading spec: gub/specs/make.py
LOOKING FOR: Make__tools
module name: tools
reading spec: gub/specs/librestrict.py
LOOKING FOR: Librestrict__tools
making spec: librestrict-open
no source specified in class:librestrict-open
Tail of target/tools/log/build.log
Traceback (most recent call last):
File "bin/gub", line 323, in
main ()
File "bin/gub", line 319, in main
logged_build (settings, options, files)
File "bin/gub", line 289, in logged_build
sys.exit (exceptional_build (settings, options, files, logger))
File "bin/gub", line 268, in exceptional_build
build (settings, options, files)
File "bin/gub", line 196, in build
(names, specs) = gup.get_source_packages (settings, files)
File "bin/../gub/gup.py", line 529, in get_source_packages
topologically_sorted (todo, {}, name_to_dependencies_broker)
File "bin/../gub/gup.py", line 395, in topologically_sorted
recurse_stop_predicate)
File "bin/../gub/gup.py", line 375, in topologically_sorted_one
deps = dependency_getter (todo)
File "bin/../gub/gup.py", line 517, in name_to_dependencies_broker
name_to_dependencies_via_gub) (url)
File "bin/../gub/gup.py", line 462, in name_to_dependencies_via_gub
spec = dependency.Dependency (sets[platform], name, url).build ()
File "bin/../gub/dependency.py", line 128, in build
b = self._create_build ()
File "bin/../gub/dependency.py", line 88, in _create_build
source = self.url ()
File "bin/../gub/dependency.py", line 114, in url
raise Exception ('No URL for:' + self._name)
Exception: No URL for:librestrict-open
Best,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch for ja doc and two Questions
Sawada wrote: 1. Release of the new patch for ja doc I put it in the following page: http://irjb.s346.xrea.com/wiki/Patches+for+LilyPond+Document.html Please do not remove *.itely files for AU and Japanese messages catalog (i.e. Documentation/ja/user/i18n/ja). OK, I applied your patch, but made further fixes in the source, and made comments at the end of this email. 2. About .po file Some words in .po files (i.e. "msgid"s) are used as both words in text and variable names (or context IDs) in LilyPond inputs. I want to translate words in text, but not variable names. The reason is because I can use multi-byte characters in text, but not in codes for LilyPond (and programming languages) . For example, "dynamics" and "ossia" are used as words in *.itely files and variable names in *.ly files. I want to translate "dynamics" as a word to "強弱記号 (dynamics)", but not to translate "dynamics" as a variable name. How do I do this? The simplest way I can see is to disable translation of variable names in Japanese documentation, which I just did in lilypond-book and langdefs. Please check if it works. 3. About "Building documentation without compiling LilyPond" of "1.2.4 Building documentation", Application Usage In that sub subsection, there is a command as following: nice make LILYPOND_EXTERNAL_BINARY=/path/to/bin/lilypond web I wonder "nice" is not needed, though it is harmless. "nice" is not needed, that's a Grahamism, but I think it's not a problem if it remains there, I'd expect people who run this command with no knoweledge of nice comand to do "man nice" :-) There are other variations of this command (e.g. using -j make flag)... it's not possible to list all possibilities in the compilation documentation. @untranslated in Documentation/ja/user/converters.itely are right, but this file shouldn't contain the English translation, so I removed it. Also, the Japanese texidoc in input/lsr/piano-template-simple.ly is missing in input/texidocs, and you may want to translate snippet titles as well, writing them in doctitleja header fields. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
Jan Nieuwenhuizen a écrit : Tried a couple of things but could not reproduce this. What's the command you issued? Can you try removing the root and any librestrict/make packages: I get the error I reported when running rm -rf target make -f lilypond.make bootstrap Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
Jan Nieuwenhuizen a écrit : Interesting, that works for me. What's your python version? 2.5.1. I hope it's easy to install a newer Python in $HOME if it's needed to build GUB. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building GUB3
Jan Nieuwenhuizen a écrit :
Does the attached patch help?
It doesn't, I get exactly the same error :-(
I hope the attached full output from the terminal may give a hint. What
I don't get is that during first GUB invocation
("python bin/gub --platform=tools git"), a lot of packages in tools are
built, then a new invocation
(python bin/gub --platform=tools ...") explictly calls building of
librestrict-open, make and a lot of other packages.
Why not doing only one GUB invocation from the makefile?
Cheers,
John
$ make -f lilypond.make bootstrap
python bin/gub --platform=tools git
calculating dependencies
must rebuild[tools]: make librestrict-open tar bzip2 m4 autoconf patch zlib libtool curl expat git
building package: tools::make
*** Stage: download (make, tools)
*** Stage: untar (make, tools)
*** Stage: patch (make, tools)
*** Stage: autoupdate (make, tools)
*** Stage: configure (make, tools)
*** Stage: compile (make, tools)
*** Stage: install (make, tools)
*** Stage: package (make, tools)
*** Stage: clean (make, tools)
*** Stage: pkg_install (make, tools)
building package: tools::librestrict-open
*** Stage: download (librestrict-open, tools)
*** Stage: untar (librestrict-open, tools)
*** Stage: patch (librestrict-open, tools)
*** Stage: shadow (librestrict-open, tools)
*** Stage: compile (librestrict-open, tools)
*** Stage: install (librestrict-open, tools)
*** Stage: package (librestrict-open, tools)
*** Stage: clean (librestrict-open, tools)
*** Stage: pkg_install (librestrict-open, tools)
building package: tools::tar
*** Stage: download (tar, tools)
*** Stage: untar (tar, tools)
*** Stage: patch (tar, tools)
*** Stage: autoupdate (tar, tools)
*** Stage: configure (tar, tools)
*** Stage: compile (tar, tools)
*** Stage: install (tar, tools)
*** Stage: package (tar, tools)
*** Stage: clean (tar, tools)
*** Stage: pkg_install (tar, tools)
building package: tools::bzip2
*** Stage: download (bzip2, tools)
*** Stage: untar (bzip2, tools)
*** Stage: patch (bzip2, tools)
*** Stage: shadow (bzip2, tools)
*** Stage: compile (bzip2, tools)
*** Stage: install (bzip2, tools)
*** Stage: package (bzip2, tools)
*** Stage: clean (bzip2, tools)
*** Stage: pkg_install (bzip2, tools)
building package: tools::m4
*** Stage: download (m4, tools)
*** Stage: untar (m4, tools)
*** Stage: patch (m4, tools)
*** Stage: autoupdate (m4, tools)
*** Stage: configure (m4, tools)
*** Stage: compile (m4, tools)
*** Stage: install (m4, tools)
*** Stage: package (m4, tools)
*** Stage: clean (m4, tools)
*** Stage: pkg_install (m4, tools)
building package: tools::autoconf
*** Stage: download (autoconf, tools)
*** Stage: untar (autoconf, tools)
*** Stage: patch (autoconf, tools)
*** Stage: autoupdate (autoconf, tools)
*** Stage: configure (autoconf, tools)
*** Stage: compile (autoconf, tools)
*** Stage: install (autoconf, tools)
*** Stage: package (autoconf, tools)
*** Stage: clean (autoconf, tools)
*** Stage: pkg_install (autoconf, tools)
building package: tools::patch
*** Stage: download (patch, tools)
*** Stage: untar (patch, tools)
*** Stage: patch (patch, tools)
*** Stage: autoupdate (patch, tools)
*** Stage: configure (patch, tools)
*** Stage: compile (patch, tools)
*** Stage: install (patch, tools)
*** Stage: package (patch, tools)
*** Stage: clean (patch, tools)
*** Stage: pkg_install (patch, tools)
building package: tools::zlib
*** Stage: download (zlib, tools)
*** Stage: untar (zlib, tools)
*** Stage: patch (zlib, tools)
*** Stage: autoupdate (zlib, tools)
*** Stage: configure (zlib, tools)
*** Stage: compile (zlib, tools)
*** Stage: install (zlib, tools)
*** Stage: package (zlib, tools)
*** Stage: clean (zlib, tools)
*** Stage: pkg_install (zlib, tools)
building package: tools::libtool
*** Stage: download (libtool, tools)
*** Stage: untar (libtool, tools)
*** Stage: patch (libtool, tools)
*** Stage: autoupdate (libtool, tools)
*** Stage: configure (libtool, tools)
*** Stage: compile (libtool, tools)
*** Stage: install (libtool, tools)
*** Stage: package (libtool, tools)
*** Stage: clean (libtool, tools)
*** Stage: pkg_install (libtool, tools)
building package: tools::curl
*** Stage: download (curl, tools)
*** Stage: untar (curl, tools)
*** Stage: patch (curl, tools)
*** Stage: autoupdate (curl, tools)
*** Stage: configure (curl, tools)
*** Stage: compile (curl, tools)
*** Stage: install (curl, tools)
*** Stage: package (curl, tools)
*** Stage: clean (curl, tools)
*** Stage: pkg_install (curl, tools)
building package: tools::expat
*** Stage: download (expat, tools)
*** Stage: untar (expat, tools)
*** Stage: patch (expat, tools)
*** Stage: autoupdate (expat, tools)
*** Stage: configure (expat, tools)
*** Stage: compile (expat, tools)
*** Stage: install (expat, tools)
*** Stage: package (expat, tools)
*** Stage: clean (expat, tools)
*** Stage: pkg_install (expat, tools)
building package: tools::git
*** Stage
Re: Patch for ja doc and two Questions
Sawada a écrit : It does not work. But I fixed Lilypond-book.py as following: (line 939) if not langdefs.LANGDICT[document_language].enable_ly_identifier_l10n: ^^^ I guess the property name "enable_ly_identifier_l10n" should be changed to "disable_ly_identifier_l10n". I prefer to avoid double negations, but I fixed it anyway. Sorry for the confusion, I wrote this code too late at night :-) I am sure. I have one question about this. Should I include untranslated texinfo files into patches? For example, I am translating Learning Manual, but do not start to translate "rhythms.itely" yet. Should I include "rhythms.itely" into "Documentation/ja/user/" for patches? In fact, I can do "make web" only with "lilypond.tely", "notation.itely" and "pitches.itely". "Skeleton" .itely files (i.e. files which don't contain any translation) should be added only if you have already translated some portion in the same manual. As you probably haven't translated anything in the Notation Reference (NR, lilypond.tely) yet, you needn't add any .itely file that belongs to the NR. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Re: Building GUB3
Hi Jan,
Jan Nieuwenhuizen a écrit :
Ah, you reported something like this before... A fixlet for this is in
HEAD (full rebuild ahead).
I needed the attached patch (error log attached too) to succesfully
complete "make -f lilypond.make bootstrap".
John
>From ad674166ea290a28a6865d576088fcdcc44ae47f Mon Sep 17 00:00:00 2001
From: John Mandereau
Date: Wed, 18 Feb 2009 10:54:10 +0100
Subject: [PATCH] Remove more duplicate libiberty.a files generated by binutils and gcc
This fix completes a previous similar fix in commit
fdfe393e51f670b97afe945bb920bd5b525e129d
---
gub/specs/cross/binutils.py|2 ++
gub/specs/darwin/cross/binutils.py |6 ++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/gub/specs/cross/binutils.py b/gub/specs/cross/binutils.py
index 38a6a82..778cd34 100644
--- a/gub/specs/cross/binutils.py
+++ b/gub/specs/cross/binutils.py
@@ -44,6 +44,8 @@ cd %(install_prefix)s%(cross_dir)s/%(target_architecture)s/bin && ln strip gstri
'''
self.system ('rm %(install_prefix)s%(cross_dir)s/lib/libiberty.a',
ignore_errors=True)
+self.system ('rm %(install_prefix)s%(cross_dir)s/lib64/libiberty.a',
+ ignore_errors=True)
class Binutils__linux__ppc (Binutils):
patches = Binutils.patches + ['binutils-2.18-werror-ppc.patch']
diff --git a/gub/specs/darwin/cross/binutils.py b/gub/specs/darwin/cross/binutils.py
index 5b0b3df..717ea4f 100644
--- a/gub/specs/darwin/cross/binutils.py
+++ b/gub/specs/darwin/cross/binutils.py
@@ -13,4 +13,10 @@ class Binutils__darwin (binutils.Binutils):
#return (binutils.Binutils._get_build_dependencies (self)
#+ ['odcctools'])
def install (self):
+'''
+On some systems [Fedora9], libiberty.a is provided by binutils
+*and* by gcc; see gub/specs/binutils.py for more details.
+'''
cross.AutoBuild.install (self)
+self.system ('rm %(install_prefix)s%(cross_dir)s/lib64/libiberty.a',
+ ignore_errors=True)
--
1.5.6.6
building package: freebsd-x86::cross/gcc
*** Stage: download (cross/gcc, freebsd-x86)
*** Stage: untar (cross/gcc, freebsd-x86)
*** Stage: patch (cross/gcc, freebsd-x86)
*** Stage: autoupdate (cross/gcc, freebsd-x86)
*** Stage: configure (cross/gcc, freebsd-x86)
*** Stage: compile (cross/gcc, freebsd-x86)
*** Stage: install (cross/gcc, freebsd-x86)
*** Stage: package (cross/gcc, freebsd-x86)
*** Stage: clean (cross/gcc, freebsd-x86)
*** Stage: pkg_install (cross/gcc, freebsd-x86)
already have file ./usr/cross/lib64/libiberty.a: cross/binutils
Tail of target/freebsd-x86/log/build.log >>>>>>>>
meq4U\tgcc-4.3.2q5\x86q6U\x04bitsq7U\x0232q8\x86q9U\x06branchq:U\x00q;\x86q\x86q?u\nbuild_bi...@u\x0264qa\x86qbu\tbuild_cpuqcu\x06x86_64qd\x86qeu\x19build_dependencies_stringqfuncross/binutils;freebsd-x86::freebsd-runtime;tools::bzip2;tools::librestrict;tools::make;tools::mpfr;tools::tarqG\x86qHU\x13build_hardware_bitsqIhA\x86qJU\x08build_osqKU\x05linuxqL\x86qMU\x0ebuild_platformqNU\x08linux-64qO\x86qPU\x08builddirqQUA/home/lilydev/git/newgub/target/freebsd-x86/build/cross/gcc-4.3.2qR\x86qSU\ncache_fileqTUN/home/lilydev/git/newgub/target/freebsd-x86/build/cross/gcc-4.3.2/config.cacheqU\x86qVU\x08categoryqWh;\x86qXU\rchecksum_fileqYUG/home/lilydev/git/newgub/target/freebsd-x86/packages/cross/gcc.checksumqZ\x86q[U\x0fcompile_commandq\\U\x0bmake -j2 q]\x86q^U\x10configure_binaryq_UI/home/lilydev/git/newgub/target/freebsd-x86/src/cross/gcc-4.3.2/configureq`\x86qaU\x11configure_commandqbT\xd1\x02\x00\x00/home/lilydev/git/newgub/target/freebsd-x86/src/cross/gcc-4.3.2/configure --prefix=/home/lilydev/git/newgub/target/freebsd-x86/install/cross/gcc-4.3.2-root/usr --program-prefix=i686-freebsd4- --prefix=/home/lilydev/git/newgub/target/freebsd-x86/root/usr/cross --target=i686-freebsd4 --with-sysroot=/home/lilydev/git/newgub/target/freebsd-x86/root --disable-multilib --with-as=/home/lilydev/git/newgub/target/freebsd-x86/root/usr/cross/bin/i686-freebsd4-as --with-ld=/home/lilydev/git/newgub/target/freebsd-x86/root/usr/cross/bin/i686-freebsd4-ld --with-nm=/home/lilydev/git/newgub/target/freebsd-x86/root/usr/cross/bin/i686-freebsd4-nm --enable-static --enable-shared --enable-languages=c,c++ --enable-libstdcxx-debug qc\x86qdU\x10conflicts_stringqeU\x01;qf\x86qgU\x0bcore_prefixqhU?/home/lilydev/git/newgub/target/freebsd-x86/root/usr/cross/coreqi\x86qjU\x03cpuqkU\x04i686ql\x86qmU\rcpu_count_strqnU\x012qo\x86qpU\x0fcross_allsrcdirqqU5/home/lilydev/git/newgub/target/freebsd-x86/src/crossqr\x86qsU\tcross_dirqtU\x06/crossqu\x86qvU\x0ecross_packagesqwU:/home/lilydev/git/newgub/target/freebsd-x86/packages/crossqx\x86qyU\x0ccross_prefixqzU:/home/lilydev/git/newgub/target/freebsd-x86/root/usr/crossq{\x86q|U\x0fcross_statusdirq}U8/home/lilydev/git
[GUB3] How should Guile and Flex be built?
After a successful bootstraping stage, I tried "make -f lilypond.make" and "make -f lilypond.make installers"; both failed with the attached log. In bootstraping, Flex and Guile are built for target "tools", which I find strange, whereas they are not built for each target platform. I also miss Python building. What are the recommended commands to build these three depencdencies before attempting at building Lily binaries? Best, John *** Stage: configure (lily, mingw) Command barfed: cd /home/lilydev/git/newgub/target/mingw/build/lily-localhost--home-lilydev-git-lily-master && chmod +x /home/lilydev/git/newgub/target/mingw/src/lily-localhost--home-lilydev-git-lily-master/configure && /home/lilydev/git/newgub/target/mingw/src/lily-localhost--home-lilydev-git-lily-master/configure --config-cache --enable-shared --disable-static --build=x86_64-linux --host=i686-mingw32 --target=i686-mingw32 --prefix=/usr --sysconfdir=/usr/etc --includedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib Tail of target/linux-64/log/build.log checking for libguile.h... no checking for scm_boot_guile in -lguile... no checking for scm_boot_guile... no checking GUILE rational bugfix... Must have patched GUILE rational support. See INSTALL.txt checking for python-config... python-config /home/lilydev/bin/python2.6: error while loading shared libraries: libpython2.6.so.1.0: cannot open shared object file: No such file or directory /home/lilydev/bin/python2.6: error while loading shared libraries: libpython2.6.so.1.0: cannot open shared object file: No such file or directory checking Python.h usability... no checking Python.h presence... no checking for Python.h... no checking for gs... gs checking for gs... /usr/bin/gs checking /usr/bin/gs version... 8.63 checking for fontforge... fontforge checking for fontforge... /home/lilydev/git/newgub/target/tools/root/usr/bin/fontforge checking /home/lilydev/git/newgub/target/tools/root/usr/bin/fontforge version... 20080927 checking for t1asm... t1asm checking for t1asm... /home/lilydev/git/newgub/target/tools/root/usr/bin/t1asm checking assert.h usability... yes checking assert.h presence... yes checking for assert.h... yes checking grp.h usability... no checking grp.h presence... no checking for grp.h... no checking libio.h usability... no checking libio.h presence... no checking for libio.h... no checking pwd.h usability... no checking pwd.h presence... no checking for pwd.h... no checking for sys/stat.h... (cached) yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking fpu_control.h usability... no checking fpu_control.h presence... no checking for fpu_control.h... no checking sstream usability... yes checking sstream presence... yes checking for sstream... yes checking boost/lambda/lambda.hpp usability... no checking boost/lambda/lambda.hpp presence... no checking for boost/lambda/lambda.hpp... no checking whether stat file-mode macros are broken... no checking for working memcmp... (cached) yes checking for vprintf... yes checking for _doprnt... no checking for chroot... no checking for fopencookie... no checking for funopen... no checking for gettext... (cached) yes checking for isinf... no checking for mbrtowc... yes checking for memmem... no checking for snprintf... yes checking for vsnprintf... yes checking for wcrtomb... yes checking utf8/wchar.h usability... no checking utf8/wchar.h presence... no checking for utf8/wchar.h... no checking for library containing mbrtowc... none required checking for pkg-config... pkg-config --define-variable prefix=/home/lilydev/git/newgub/target/mingw/root/usr --define-variable includedir=/home/lilydev/git/newgub/target/mingw/root/usr/include --define-variable libdir=/home/lilydev/git/newgub/target/mingw/root/usr/lib checking pkg-config --define-variable prefix=/home/lilydev/git/newgub/target/mingw/root/usr --define-variable includedir=/home/lilydev/git/newgub/target/mingw/root/usr/include --define-variable libdir=/home/lilydev/git/newgub/target/mingw/root/usr/lib version... 0.20 checking whether to enable dynamic relocation... no checking for rpath linkage... no checking for pangoft2 >= 1.6.0... Package pangoft2 was not found in the pkg-config search path. Perhaps you should add the directory containing `pangoft2.pc' to the PKG_CONFIG_PATH environment variable No package 'pangoft2' found checking for fontconfig >= 2.2.0... Package fontconfig was not found in the pkg-config search path. Perhaps you should add the directory containing `fontconfig.pc' to the PKG_CONFIG_PATH environment variable No package 'fontconfig' found checking for freetype2 >= 2.1.10... yes checking FREETYPE2_CFLAGS... -I/home/lilydev/git/newgub/target/mingw/root/usr/include/freetype2 checking FREETYPE2_LIBS... -L/home/lilydev/git/newgub/target/mingw/root/usr/lib -lfreetype -lz checking host system type... (cached) i686-pc-mingw32 checking host system type... (cached)
Re: starting 2.13 soon
Hi guys, Trevor Daniels a écrit : I'd go along with going straight to 2.13 too. AFAIK there are no serious outstanding issues with 2.12.2 that must be fixed, and I feel a little uncomfortable with some of the doc changes which will appear in the next release. I'd rather they went into 2.13. There should be a 2.12.3 for Japanese translation, but this doesn't prevent us to start 2.13 on master branch right now: we else can branch out from master a branch named stable/2.12 and use it to release 2.12.3 as soon as GUB is ready for this. I'm sorry to annouce I'll be very few available this week because of exams from Tuesday to Thursday; then my crazy 6-months courses sessions will be over and I'll be a more available for LilyPond than in the last two months. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] Fwd: Strange output from convert-ly
Hi Francisco, Francisco Vila a écrit : I forward this to -devel, if there is no inconvenient and nobody does it before, I could apply it next Tue or Wed. Right. The attached patch removes the debug print command. Could you remove the "print" command completely by pushing to Git directly? If was of any interest to keep it, the print statement should have been replaced with a stderr call, but it's not the case here. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: starting 2.13 soon
Trevor Daniels a écrit : No, it's OK. Just a mild preference. Not worth any trouble. I'd added a new section or two which caused a renumbering. It's not really a problem. Agreed; FWIW I backported a lot of doc changes in early 2.12 versions and IIRC nobody complained about renumbering. Oh yes, I remember instructions from Graham, but it's not a problem for only one ore two sections. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updates to the LM
Reinhold Kainhofer a écrit : Okay, but I think the snippets in input/lsr/ need to be updated to include this new file from input/new/, too. Otherwise lilypond-book will not be able to find it. Unfortunately, I have no idea how to re-generate input/lsr/ from input/new/, though... Use makelsr.py Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Please fix: release show stopppers
Han-Wen Nienhuys a écrit : [+John who has been working on the japanese translation] On Thu, Feb 26, 2009 at 10:35 PM, Han-Wen Nienhuys wrote: Dist error: file from VC not distributed: lilypond-2.13.0/Documentation/ja/user/i18n/ja Oops, this file should be added to Texi2html; I removed it from LilyPond sources. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Updates to the LM
Graham Percival a écrit : On Wed, Feb 25, 2009 at 11:18:32AM -, Trevor Daniels wrote: I think I've muddled through this and updated input/lsr with my new snippet. As this was the first time I've used makelsr.py there were lots of mysterious warnings, but it seems to have converted and copied the one file I needed successfully, so I selected this one file and placed it in input/lsr. As a general note, I would encourage people NOT to use makelsr.py unless they are very familiar with it. All it takes is one inexperienced (in this area) developer trying to fix a "simple" bug at the wrong time, and could result in many of us losing our entire personal data due to a rm -rf ~ system call within a snippet. This potential issue is important, but from now you can just say "Wanna know how to run makelsr.py? Please carefully read the fine CG!" ;-) Yeah, of course we all use an encrypted incremental backup system like tarsnap.com, and we all have separate user accounts for lilypond development so that any malicious snippet can't touch our personal files... Yes, we should; I almost do, except that I use two USB sticks and an USB disk for backup, and incremental often means using Git for me, even if it's not identical. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Re: patch for bug 729
Hi Carl, Carl D. Sorensen a écrit : So, just for the record, I guess that the appropriate way to handle this would be to: 1. Search through input/lsr for relevant files. 2. Fix the snippet to make sure it compiles properly. 3. Copy the snippet to input/new 4. Delete the snippet from input/lsr Is that right? Yes, except you shouldn't do 4, and don't forget some snippets eventually come from LSR, not from input/new. Plus, I guess that something like these needs to go into the CG, so that we never have to have this conversation on -devel again. And the frogs don't have to search the frogs archive either. I added the fixing procedure you mentioned above, plus other LSR-related stuff in the CG. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond.pdf size?
Hi guys, Valentin Villenave a écrit : 2009/3/3 Han-Wen Nienhuys : We have received some complaints about bandwidth usage at lilypond.org; in particular, the lilypond.pdf with its 13mb is causing a lot of bandwidth use. Could the doc frogs/meisters/gdpers look into a solution for this? John and I are about to launch our new dedicated web-platform; I already have web storage available if you need some. I'm not sure the hoster of this new web platform would have reasonably enough bandwith for massive downloading of 13 MB lilypond.pdf; however, I guess it is OK to use download.linuxaudio.org. Any taker for adding a hook in postprocess_html.py for 'online' web target? Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: AJAX-search field in the docs (Proof-of-concept)
Reinhold Kainhofer a écrit : A few days ago, I decided it's finally time to learn what all that hype about AJAX is about. What would be a better guinea pig than trying to implement a seach box in our docs??? Well -- it turned out incredibly easy. Here it is: http://kainhofer.com/~lilypond/ajax/Documentation/user/lilypond-learning/index.html (or any other manual there, like the NR or so) Excellent! If JavaScript is disabled (so that AJAX won't work, either) or the files are viewed as static files on your harddisk (i.e. not over http, so the AJAX call would fail for sure), no search box is shown. It's certainly possible to enable the search for local docs by replacing AJAX calls with loading files locally. The other problem is that the www-post script doesn't seem to install the *.de.idx, *.ja.idx, *.fr.idx and *.es.idx files, while the *.en.idx files are properly installed to Documentation/user/... So for now the search only works in the English docs. The "culprit" is not www_post.py, it's the command that links translated doc files to Documentation/user in make/doc-i18n-user-targets.make. These search boxes are for now meant as a proof-of-concept implementation mainly. I haven't done any work on the corresponding CSS styling to make the results look nicer. I'm sure you'll push the implementation further to add it in our documentation :-) Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clarifying and requests for documentation
Dear Yoshiki, Sawada a écrit : Request 1. NR 1.1.3 Displaying pitches -> Clef In "See also", the reference to Internals Reference: "Clef" is translated to "音部記号" by ja.po file. But it should not be translated because it is a object name. There is no way to fix it right now, but it will be possible when I have modified the build scripts so node names and sections titles are no longer translated after compilation by texi2html, but are translated directly in the source file. Now I have merged TRANSLATION into the Contributors' Guide (by the way, if you can afford enough time, could you please proofread it?), I'm putting a high priority on working on the doc translation infrastructure (along with going back to GUB compilation front). Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Clarifying and requests for documentation
Sawada a écrit : NR is very long to translate, especially 1.1 Pitches and 1.2 Rhythms. Therefore, my translation does not look like progressing so much. It will take a while to release the next patch. Quoting the Contribuors' Guide, section "3.6.2 Documentation translation details": "Files marked with priority 3, 4 or 5 may be submitted individually." So in your next patch, you may just submit a complete translation of Pitches and lilypond.tely, plus all other "skeleton" files. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: AJAX-search field in the docs (Proof-of-concept)
Reinhold Kainhofer a écrit : Ah, so all I have to do is to add '*.idx' to the arguments of find and mass- link them, too. Sure. Hehe, I was hoping that someone would jump up enthusiastically and say "Sure, I'll take on the polishing" ;) Lol! I already have a bunch of work for the documentation translations and the website, so you can't count on me for the next months, sorry. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GUB3] How should Guile and Flex be built?
Hi Jan,
Jan Nieuwenhuizen a écrit :
On wo, 2009-02-18 at 14:55 +0100, Jan Nieuwenhuizen wrote:
Hi John,
How hard is it for you to install another python and try that?
I compiled Python 2.6.1 and installed it in my home, setting
LD_LIBRARY_PATH to /home/lilydev.
Does fedora carry python2.4 or python2.6 (or even python3) packages
that you can install alongside your 2.5.1, for example.
Nope, and Python 3 may not be a resonable option right now, as this
probably needs some work. Well, if everything
else fails, I might fall back to porting GUB to Python 3 without having
it working with older Python first :-P
Just to be sure we're not chasing ghosts, can you (in gub)
rm -f $(find gub -name '*pyc')
I did, and a clean build failed on odcctools. Log tail attached.
Best,
John
building package: darwin-ppc::odcctools
*** Stage: download (odcctools, darwin-ppc)
*** Stage: untar (odcctools, darwin-ppc)
*** Stage: patch (odcctools, darwin-ppc)
*** Stage: autoupdate (odcctools, darwin-ppc)
*** Stage: configure (odcctools, darwin-ppc)
Command barfed: cd /home/lilydev/git/newgub/target/darwin-ppc/build/odcctools-odcctools-278 && /home/lilydev/git/newgub/target/darwin-ppc/src/odcctools-odcctools-278/configure --prefix=/home/lilydev/git/newgub/target/darwin-ppc/install/odcctools-odcctools-278-root/usr --program-prefix=powerpc-apple-darwin7- --prefix=/home/lilydev/git/newgub/target/darwin-ppc/root/usr/cross --target=powerpc-apple-darwin7 --with-sysroot=/home/lilydev/git/newgub/target/darwin-ppc/root --disable-multilib
Tail of target/darwin-ppc/log/build.log
+fakeroot=fakeroot -i -s
+fakeroot_cache=
+file_name=svn
+full_version=odcctools-278
+gtk_version=2.8
+gubdir=/home/lilydev/git/newgub
+install_command=make DESTDIR=/home/lilydev/git/newgub/target/darwin-ppc/install/odcctools-odcctools-278-root prefix=/usr/cross install
+install_prefix=/home/lilydev/git/newgub/target/darwin-ppc/install/odcctools-odcctools-278-root/usr
+install_root=/home/lilydev/git/newgub/target/darwin-ppc/install/odcctools-odcctools-278-root
+installdir=/home/lilydev/git/newgub/target/darwin-ppc/install
+logdir=/home/lilydev/git/newgub/target/darwin-ppc/log
+makeflags=
+name=odcctools
+name_version=odcctools-odcctools-278
+native_compile_command=make -j2
+nsisdir=/home/lilydev/git/newgub/nsis
+os=darwin
+package_arch=powerpc
+packages=/home/lilydev/git/newgub/target/darwin-ppc/packages
+packaging_suffix_dir=
+patchdir=/home/lilydev/git/newgub/patches
+platform=darwin-ppc
+platform_uploads=/home/lilydev/git/newgub/uploads/darwin-ppc
+prefix_dir=/usr
+pretty_name=Odcctools
+root_dir=/root
+rpath=
+so_version=1
+source_checksum=278
+source_name=odcctools
+sourcefiledir=/home/lilydev/git/newgub/sourcefiles
+specdir=/home/lilydev/git/newgub/gub/specs
+split_ball=/home/lilydev/git/newgub/target/darwin-ppc/packages/odcctools-odcctools-278.darwin-ppc.gup
+split_hdr=/home/lilydev/git/newgub/target/darwin-ppc/packages/odcctools.darwin-ppc.hdr
+split_name=odcctools
+src_package_ball=/home/lilydev/git/newgub/target/darwin-ppc/packages/odcctools-odcctools-278-src.darwin-ppc.tar.gz
+src_package_uploads=/home/lilydev/git/newgub/target/darwin-ppc/packages
+srcdir=/home/lilydev/git/newgub/target/darwin-ppc/src/odcctools-odcctools-278
+stamp_file=/home/lilydev/git/newgub/target/darwin-ppc/status/odcctools-odcctools-278-278
+statusdir=/home/lilydev/git/newgub/target/darwin-ppc/status
+sub_name=
+system_prefix=/home/lilydev/git/newgub/target/darwin-ppc/root/usr
+system_root=/home/lilydev/git/newgub/target/darwin-ppc/root
+target_architecture=powerpc-apple-darwin7
+target_bits=32
+target_cpu=powerpc
+target_gcc_flags=-D__ppc__
+target_os=darwin
+target_platform=darwin-ppc
+targetdir=/home/lilydev/git/newgub/target/darwin-ppc
+toolchain_prefix=powerpc-apple-darwin7-
+tools_prefix=/home/lilydev/git/newgub/target/tools/root/usr
+tools_root=/home/lilydev/git/newgub/target/tools/root
+uploads=/home/lilydev/git/newgub/uploads
+vc_branch=
+vc_branch_suffix=
+version=odcctools-278
+workdir=/home/lilydev/git/newgub
+rm -rf /home/lilydev/git/newgub/target/darwin-ppc/install/odcctools-odcctools-278-root
+Dump
+/home/lilydev/git/newgub/target/darwin-ppc/status/odcctools-odcctools-278-278
+package
+rm -rf /home/lilydev/git/newgub/target/darwin-ppc/status/odcctools-odcctools-278-278 /home/lilydev/git/newgub/target/darwin-ppc/install/odcctools-odcctools-278-root
+rm -rf /home/lilydev/git/newgub/target/darwin-ppc/src/odcctools-odcctools-278 /home/lilydev/git/newgub/target/darwin-ppc/build/odcctools-odcctools-278
downloaded version: odcctools-278
building package: darwin-ppc::odcctools
*** Stage: download (odcctools, darwin-ppc)
Running dump_file
('download', '/home/lilydev/git/newgub/target/darwin-ppc/status/odcctools-odcctools-278-278', 'w')
{'permissions': 420}
*** Stage: untar (odcctools, darwin-ppc)
invoking rm -rf /home/lilydev/git/newgub/target/darwin-ppc/src/odcctools-odcctools-278 /home/lilydev/git/newgub/target/darwin
Re: Clarifying and requests for documentation
Hello Yoshiki,
Sawada a écrit :
Do you mean that you will make node names and section titles translated only by
manual
(that is, they are translated in the source files, but not by the po file)?
Yes, that's it.
If it is correct, I want new commands as following rather than it:
@rinternalsnamed-untranslated{TEXT,DISPLAY}
where, DISPLAY is not translated.
Is this possible?
There is no need for such a macro: in case TEXT will be a context or
grob name, it shouldn't be translated,
so you write e.g. @rinternals{Clef} in the Texinfo sources, and when I
have junked the gettext trickery for HTML
output this issue will die.
For the moment, the points which I noticed are as following:
1. Files to be translated
In addition to "index.html.in", "translations.template.html.in" should be
translated.
Thanks, fixed.
2. Translating the Learning Manual and other Texinfo documentation
It says that arguments of reference commands such as @ref and @rglos should not
be translated. But there are more reference commands: @rglosnamed, @rlearning,
@rlearningnamed and so on -- see "macros.itexi".
You are right, but some time later all commands will have to be translated;
as I don't have a reliable estimate of "some time later", I fixed them
anyway.
Thanks,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why is it _still_ so freaking hard to get info with images?
2009/3/9 David Kastrup : make prefix=/usr/local/lilypond install-info-WWW make --no-builtin-rules -C Documentation/user install-info make[1]: Entering directory `/lisa/lilypond/Documentation/user' export LILYPOND_DATADIR= export PYTHONPATH=/lisa/lilypond/python/out:../../python/auxiliar:/lisa/lilypond/python/out:./python/auxiliar: /usr/bin/python /lisa/lilypond/stepmake/bin/install.py -c -d /usr/local/lilypond/share/info *** Please add or update the LilyPond direntries, do install-info --info-dir=/usr/local/lilypond/share/info out/lilypond.info For images in the INFO docs to work, do make out=www install-info and read the extra instructions. /usr/bin/python /lisa/lilypond/stepmake/bin/install.py -c -d /usr/local/lilypond/share/info ; make INSTALLATION_OUT_DIR=/usr/local/lilypond/share/info depth=../.. INSTALLATION_OUT_FILES="./out/lilypond.info ./out/lilypond.info-1 ./out/lilypond.info-2 ./out/lilypond.info-3 ./out/lilypond.info-4 ./out/lilypond.info-5 ./out/lilypond-internals.info ./out/lilypond-internals.info-1 ./out/lilypond-internals.info-2 ./out/lilypond-internals.info-3 ./out/lilypond-internals.info-4 ./out/music-glossary.info ./out/lilypond-program.info ./out/lilypond-learning.info ./out/lilypond-learning.info-1 ./out/lilypond-learning.info-2" -f /lisa/lilypond/stepmake/stepmake/install-out.sub.make local-install What command did you run exactly? If it is "make prefix=/usr/local/lilypond install-info-WWW", this is all wrong: *WWW* targets must be called with out=www; these targets are purposely undocumented and not listed in "make help" because they are reserved for internal use or hacking. And sure enough: the installed tree contains no info files with images. What point is there in complaining that Linux distributions tend to omit the images when there is no working Makefile target that would get them there, make web && make web-install should compile Info docs with images, and install them is prefix is standard (/user or /usr/local); if prefix is non-standard, the commands to be issued are printed by the makefile. However, there has been a bug for at least two months that prevented the images to show in Info docs, and I agree with Jan that the printed instructions were not very clear. and when the instructions that the Makefile gives out don't even work? What command did you run exactly? "make web-install" is the recommended one by Application Usage, section Building documentation. I just added "make info-install", as suggested by Jan. Please let me know if there are still issues to address after the changes I just committed. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why is it _still_ so freaking hard to get info with images?
Jan Nieuwenhuizen a écrit : Good points, everything should be fixed. Improvements could be * add toplevel info and install-info targets that redirect to Documentation/user ..and input/lsr too. I added toplevel info and intall-info target. * make info with images automagically (using these targets) when doing a toplevel make web [there is really no point in *not* making info docs without images when the images are already built for the web docs. the only reason for supporting info without images, is for 'install-info' to work when web-doc tools are not installed/available] This is already what is done, except that the relative symlink from prefix/share/info was wrong ;-) [better not:* fix the documentation command to suggest -C Doc../user] In addition to replacing the suggested commands, I added a pointer to Application Usage, section Building documentation. Next thing is that I wrote patches[1,2] for yelp to display images in info docs, but yelp seems to be dead[3] (or at least not very eager to take them). Oh, I didn't know yelp could display images, the Info readers capable of this I knew were Emacs and Konqueror. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why is it _still_ so freaking hard to get info with images?
John Mandereau a écrit : *WWW* targets must be called with out=www; these targets are purposely undocumented and not listed in "make help" because they are reserved for internal use or hacking. BTW we probably should enclose all WWW targets in ifeq($(out),www) blocks. Any thoughts on this before I go ahead? Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compile.itely placement
Trevor Daniels a écrit : Re your recent commits: shouldn't compile.itely and introduction.itely be in /devel rather than /user? I don't understand why you suggest to place introduction.itely in devel/. As for compile.itely, it's easier to put it in user/, because compilation of Texinfo docs in devel/ already includes files in user/, whereas devel/ isn't included in compilation of docs in user/; anyway I think it's of little importance, as this file is used in manuals in both directories with equal importance. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why is it _still_ so freaking hard to get info with images?
David Kastrup a écrit : John Mandereau writes: ..and input/lsr too. I added toplevel info and intall-info target. No, you didn't. Oops, I meant info-install. At least a freshly fetched lilypond copy has only (according to bash programmable completion) the targets install-help2man install-info-WWW install-WWW LilyPond makefiles are too smart for bash completion in its current state. Even if we disable targets only for out!=www, bash completion will still show these targets. That's why we provide "make help", mentioned among other places at the end of configure output. make help offers infobuild Info documentation with images info-install install Info documentation with images This is what you are looking for. 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 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$ 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. The same applies to "make web"/"make install"; however, info-install target rebuild Info docs if needed. I really have no idea how people supposedly cope with that sort of thing. Read section "Compiling from source" in "Application usage", or one of the INSTALL* files (this is the same contents). 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. and/or are hidden away into some subdirectory make targets one cannot fathom and/or require running some other unnoticeable dependencies first. That's why there is an INSTALL file in distributed tarballs, 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. 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 (mayb
Re: compile.itely placement
Graham Percival a écrit : I'm not clear about this, either. Actually, if anything introduction.itely is going to die entirely (as part of the web-gop stuff). All right. I can't work on GOP in the 4 coming weeks: I must work on translaed documentation compilation by translating node names in source files because the current system has too many bugs; this alone is already a big task. And I'm still playing with GUB3 (trying to build it with Python 3 now...). compile.itely is slated to be removed from AU 1, so in the long term I think it should be moved to devel/. However, in the short term I really can't spend the effort requried to make everything work, so I recommend waiting 1 or 2 months. OK, in the meantime we at least don't have to worry about compilation instructions duplicated in the sources. Do you like the idea of separating compilation instructions for self-builders and packagers (that must go in INSTALL too) from instructions for Lily developers? Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GUB3] How should Guile and Flex be built?
Jan Nieuwenhuizen a écrit : Op donderdag 12-03-2009 om 10:43 uur [tijdzone +0100], schreef John Mandereau: I compiled Python 2.6.1 and installed it in my home, setting LD_LIBRARY_PATH to /home/lilydev. So, does that help? Not at all: I set PLATFORMS=linux-64 to avoid choking on odcctools compilation, and dependencies fail for both Python versions I have tested (2.5 shipped with Fedora 9, and self-compiled 2.6.1). A clean build (after "rm -rf target" and "find gub -name '*.pyc' |xargs rm -f") with Python 3 is currently running, it's not in good shape: flex and bison are built in tools, which I find snaky. I did, and a clean build failed on odcctools. Log tail attached. So, what does config.log say, why can't gcc make executables? I copied the head and the tail of config.log below. Having /home/lilydev/git/newgub/target/linux-x86/root/usr/cross/i686-linux/bin and other directories for linux-x86 xcompile look wrong to me. Best, John """ config.log """ This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by odcctools configure 622.3od16, which was generated by GNU Autoconf 2.59. Invocation command line was $ /home/lilydev/git/newgub/target/darwin-ppc/src/odcctools-odcctools-278/configure --prefix=/home/lilydev/git/newgub/target/darwin-ppc/install/odcctools-odcctools-278-root/usr --program-prefix=powerpc-apple-darwin7- --prefix=/home/lilydev/git/newgub/target/darwin-ppc/root/usr/cross --target=powerpc-apple-darwin7 --with-sysroot=/home/lilydev/git/newgub/target/darwin-ppc/root --disable-multilib ## - ## ## Platform. ## ## - ## hostname = freemousse uname -m = x86_64 uname -r = 2.6.27.19-78.2.30.fc9.x86_64 uname -s = Linux uname -v = #1 SMP Tue Feb 24 19:44:45 EST 2009 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = x86_64 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /home/lilydev/git/newgub/target/linux-x86/root/usr/cross/i686-linux/bin PATH: /home/lilydev/git/newgub/target/linux-x86/root/usr/cross/bin PATH: /home/lilydev/git/newgub/target/linux-x86/root/usr/cross/i686-linux/bin PATH: /home/lilydev/git/newgub/target/tools/root/usr/bin PATH: /home/lilydev/bin PATH: /home/john/bin PATH: /home/john/bin PATH: /usr/lib64/qt-3.3/bin PATH: /usr/kerberos/bin PATH: /usr/lib64/ccache PATH: /usr/local/sbin PATH: /usr/sbin PATH: /sbin PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /home/john/src/vc/svn/abjad/trunk/abjad/scr/ PATH: /home/john/src/vc/svn/abjad/trunk/abjad/scr/ ## --- ## ## Core tests. ## ## --- ## configure:1373: checking build system type configure:1391: result: x86_64-unknown-linux-gnu configure:1399: checking host system type configure:1413: result: x86_64-unknown-linux-gnu configure:1421: checking target system type configure:1435: result: powerpc-apple-darwin7 configure:1509: checking for gcc configure:1535: result: /home/lilydev/git/newgub/target/linux-x86/root/usr/cross/i686-linux/bin/gcc configure:1779: checking for C compiler version configure:1782: /home/lilydev/git/newgub/target/linux-x86/root/usr/cross/i686-linux/bin/gcc --version &5 gcc (GCC) 4.1.2 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:1785: $? = 0 configure:1787: /home/lilydev/git/newgub/target/linux-x86/root/usr/cross/i686-linux/bin/gcc -v &5 Using built-in specs. Target: i686-linux Configured with: /home/lilydev/git/newgub/target/linux-x86/src/cross/gcc-4.1.2/configure --prefix=/home/lilydev/git/newgub/target/linux-x86/install/cross/gcc-4.1.2-root/usr --program-prefix=i686-linux- --prefix=/home/lilydev/git/newgub/target/linux-x86/root/usr/cross --target=i686-linux --with-sysroot=/home/lilydev/git/newgub/target/linux-x86/root --disable-multilib --with-as=/home/lilydev/git/newgub/target/linux-x86/root/usr/cross/bin/i686-linux-as --with-ld=/home/lilydev/git/newgub/target/linux-x86/root/usr/cross/bin/i686-linux-ld --with-nm=/home/lilydev/git/newgub/target/linux-x86/root/usr/cross/bin/i686-linux-nm --enable-static --enable-shared --enable-languages=c,c++ --enable-libstdcxx-debug --with-local-prefix=/home/lilydev/git/newgub/target/linux-x86/root/usr --disable-multilib --disable-nls --enable-threads=posix --enable-__cxa_atexit --enable-symvers=gnu --enable-c99 --enable-clocale=gnu --enable-long-long Thread model: posix gcc version 4.1.2 configure:1790: $? = 0 configure:1792: /home/lilydev/git/newgub/target/linux-x86/root/usr/cross/i686-linux/bin/gcc -V &5 gcc: '-V' option must have
Re: Why is it _still_ so freaking hard to get info with images?
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 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
Re: Why is it _still_ so freaking hard to get info with images?
David Kastrup a écrit : John Mandereau writes: What does "grep NCSB config.make" (at top of the build tree) does say? NCSB_SOURCE_FILES = /usr/share/fonts/type1/gsfonts/c059036l.pfb /usr/share/fonts/type1/gsfonts/c059013l.pfb Your system probably misses two of the New Century Schoolbook PFB font files, probably italic and bold italic series. It looks like fontconfig substitutes italic with regular when the fonts are queried in configure script, but the installation makefile is not that tolerant. I'm for fixing the configure script, so it checks for the 4 PFB files presence. I have no time to reply about other points right now, but I'll do it as soon as possible. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Why is it _still_ so freaking hard to get info with images?
[forgot to CC to list] - Forwarded message -- From: John Mandereau Date: 2009/3/16 Subject: Re: Why is it _still_ so freaking hard to get info with images? To: Jan Nieuwenhuizen Hi Jan, 2009/3/16 Jan Nieuwenhuizen : > Your point about README/INSTALL is more difficult to tackle. While > I agree it would be nice to have those file available at toplevel-- > just as they are in the distributed tarballs--it is a pain (not to > say stupid) to have generated files in GIT. It should be simple to trigger "make do-top-doc" and link generated INSTALL and README to the root at the end of autogen.sh; having these generated files is not a pain if we add them in .gitignore. I'll get a look as soon as I can bring my laptop to work... > The problems with fixing a build system is that it is a major time sink > without any obvious benefits, very hard to get right (for a big project > like lilypond) and with a number of conflicting constraints (speed vs > correctness, etc.) and it's a very personal thing, everyone wants > something else, wants to use the build system they already know > very well (from work or wherever), doesn't care so much about speed, > or correctness, or cross-building or using yet another undocumented > language or out of tree builds or building in other ide's or... Unless > maybe you use the full standard autotools suite, which *everyone* hates > to work with. >From the little experience I got by hacking LilyPond parts of the build system dedicated to documentation and looking a little in autoconf stuff, I just fully second this. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Re: Why is it _still_ so freaking hard to get info with images?
David Kastrup wrote: So it would appear to be a problem that fc-match first finds the true type fonts installed by Canorus, and then this first match is subsequently thrown away by grep -v. So I think you need to figure out how to tell fc-match to prefer Type1 over TrueType, or how to make it list all matches rather than a single one. Weeding out the Truetype when it has been listed _instead_ rather than in addition to the Type1 fonts will not do the trick. I haven't investigated far enough to be able to force Fontconfig to prefer TTF over Type 1, so I can't reproduce the problem you describe. Does the attached patch help on your system? At least it doesn't break font selection on my Fedora 9 system. Best, John diff --git a/configure.in b/configure.in index d8f1199..e27d828 100644 --- a/configure.in +++ b/configure.in @@ -73,7 +73,7 @@ if test "$NCSB_DIR" != "" ; then else if test "$FCMATCH" != ""; then for style in Roman Italic "Bold Italic" Bold; do - NCSB_FILE=`$FCMATCH --verbose "Century Schoolbook L:style=$style" | grep 'file:' | grep -v "\.ttf"` + NCSB_FILE=`$FCMATCH --verbose "Century Schoolbook L:style=$style:fontformat=Type 1" | grep 'file:' | grep -v "\.ttf"` NCSB_FILE=`echo $NCSB_FILE | sed 's/^.*"\(.*\)".*$/\1/g'` NCSB_FILE=`$PYTHON "$srcdir/scripts/auxiliar/readlink.py" $NCSB_FILE` ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Why is it _still_ so freaking hard to get info with images?
David Kastrup a écrit : Ok, so the bad news: canorus was not in the package repository. So reinstallation is not trivial: I have to dig it up and then install it. And then it is likely that the version I'll be able to find will be quite different from what I had installed previously (and which would never have been updated after that). Probably not something I'll be able to do before the weekend. You mean trying packages from https://developer.berlios.de/project/showfiles.php?group_id=6144 ? I just compiled and installed Canorus from source, and couldn't get TTF fonts to be selected vs. Type 1. If you can reproduce this issue on your system and my patch fixes it, then we'll consider applying it. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Why is it _still_ so freaking hard to get info with images?
2009/3/18 David Kastrup : > Werner LEMBERG writes: >> I don't think so. AFAIK, we want *exactly* the URW versions, so this >> looks like a good alternative. > > When I wrote the above, my rationale was that the URW fonts are Century > Schoolbook font clones with identical font metrics. If someone would be > to install the original Century Schoolbook fonts, he'd likely disable > the URW fonts in the process (or at least put them later in the search > order). Do we really want to use these particular clones in case there > are supposedly metrically identical fonts installed in a preferred > setting? > > Namely: do we actually need the URW fonts and nothing else, or do we > need something that the system installation is prepared to call "Century > Schoolbook"? > > If for some reason, only the URW version of those fonts is acceptable, > the foundry=urw variant obviously is the way to go. Maybe another solution is requiring other fonts, IIRC Werner proposed TexGyre Schola a while ago. It looks like a good idea to append foundry=urw in fc-match call in configure, but this fix will break when the foundry field of TTFs shipped with Canorus changes from "unknown" to "urw" -- or maybe this won't happen because TTF files will never provide "urw" as foundry? I rely on advice from a fonts guru here. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: good news for my PhD
Hi Valentin, Valentin Villenave a écrit : Josh is right, this sentence doesn't really make sense. We recently had a discussion about this very subject with John, who 's in the same situation as you are, and is merely forced to contribute to proprietary music software :-) If I'd like to develop some musical applications of the math topics (homometry, phase retrieval) I'm studying and researching, it will be for one piece of software that their authors would like to distribute under LGPL but that the IRCAM direction and Forum (that's responsible for distributing IRCAM software) want to distribute with a proprietary license, which in the case of OpenMusic is made very easy just by choosing proprietary Lisp compilers. No working binaries from LGPL sources have been made available (because it's a pain to get it working on one particular GNU/Linux operating system), so in the current state all my contributions will be distributed as proprietary software; to make my soul more quiet, I'd like to make it working again on GNU/Linux, but I'm not sure I'm able to do it within the 3 months left to me at the IRCAM. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: good news for my PhD
Hi Graham, Graham Percival a écrit : I've been offered a scholarship to do my PhD at the University of Glasgow, which I'm of course eagerly accepting. I'll be starting in Sep or Oct. Congatulations! 2) I might organize European vacations around other lilypond contributors, starting with a weekend in Paris. (not because I particularly want to see Paris -- I spent four days there about 10 years ago, so I figure that I've seen everything worth seeing :P. But I thought it would be neat to argue with Valentin face-to-face. :) I've been living near Paris (and studying in Paris) for 7 months, and I'll not leave before the beginning of July, so you will have the possibility to argue with me too, even if it may be less grandiose than with Valentin :-) Speaking of good news, could you take some time to make 2.13 release finally publicly available? Chris Snyder already gave a hint on this list more than two weeks ago. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Why is it _still_ so freaking hard to get info with images?
Werner LEMBERG a écrit : Sorry, I don't understand the problem. Why will this lilypond fix break something in Canorus or vice versa? Canorus installs Truetype versions of some of those fonts, system-wide. The Lilypond configure command finds some of those truetype fonts via fc-match in preference of the usual Type1 versions coming with GhostScript. This causes compilation of Lilypond to fail. This part I have understood. But I don't see a problem if we make lilypond find the Type 1 versions of the URW fonts. lf I understand correctly, the point of this subthread is figuring out how to check presence of all Type 1 URW fonts to convert them to OTF in the build process and install these OTFs, which is for example needed for reading SVG output. This checking is done via configure script, so IMHO it's a different issue from font selection by lilypond itself. May I apply the patch below? Best, John ## diff --git a/configure.in b/configure.in index d8f1199..d45c4c0 100644 --- a/configure.in +++ b/configure.in @@ -73,7 +73,7 @@ if test "$NCSB_DIR" != "" ; then else if test "$FCMATCH" != ""; then for style in Roman Italic "Bold Italic" Bold; do - NCSB_FILE=`$FCMATCH --verbose "Century Schoolbook L:style=$style" | grep 'file:' | grep -v "\.ttf"` + NCSB_FILE=`$FCMATCH --verbose "Century Schoolbook L:style=$style:foundry=urw" | grep 'file:' | grep -v "\.ttf"` NCSB_FILE=`echo $NCSB_FILE | sed 's/^.*"\(.*\)".*$/\1/g'` NCSB_FILE=`$PYTHON "$srcdir/scripts/auxiliar/readlink.py" $NCSB_FILE` ## ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: Why is it _still_ so freaking hard to get info with images?
Werner LEMBERG a écrit : Looks good to me (if you use proper indentation :-). Applied. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: install-2.13.html ?
Hi Graham, Graham Percival a écrit : I just realized that I probably should have modified the download page, but I can't see any install-2.11.html or the like. What do we normally do for development versions? Patrick gave you the hint: just create a new download included page install-2.13.html. Good luck, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an LM update
James E. Bailey a écrit : Incidentally, although the instructions in the Contributor's Guide are generally simple enough for even me to follow, apparently they're missing something because the git-format-patch HEAD doesn't work. If you have a recent Git, it should probably be git format-patch instead (with blank space instead of a hyphen). HTH, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an LM update
Hi James, James E. Bailey a écrit : Leave it to me to take something easy and make it difficult. So, I had a conflict. I thought I resolved it, but now tutorial.itely looks funny. I don't know how to get back to just having the normal files without any changes that I've made, and I don't know if the conflict is resolved properly, but here's my next attempt. Please take half an hour to read sections "HOW CONFLICTS ARE PRESENTED" and "HOW TO RESOLVE CONFLICTS" in "git merge" documentation (the man page if you're on Linux, or in HTML on Git web site anyway), as suggested in the CG. I know you've already been making significant effort to get used to Git and Texinfo, but that's really worth it: after this, you'll never be scared by conflicts any more. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: odd configure error
James E. Bailey a écrit : I'm having a configure error, and I don't know how to solve it. I get this: ERROR: Please install required programs: /Users/lilydev/bin/fontforge >= 20050624 (installed: .fontforge 20080927) What does 'which fontforge' and '`which fontforge` --version' say? Could you quote the relevant part of config.log about fontforge check? There might be some problem with library path too. Cheers, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: an LM update
Graham Percival a écrit : Ick. Do we really need to ask casual contributors to spend 30 minutes reading how to use git? I think so, see below. Isn't there any faster way to give the instructions? Like - copy the conflicted file to a backup name - delete the file - do "git reset --hard" - do "git pull origin" - compare the conflicted file and the new version, and make whatever changes to the new version that you want. ? Certainly. If you want to perform the merge but are sure to prefer the revision of some CONFLICTING_FILE from origin/BRANCH, you can resolve this with git checkout origin/BRANCH CONFLICTING_FILE before committing everything to finalize the merge. However, you should not do this without making sure you didn't make any valuable local changes not merged upstream, so I still recommand spending the required bloody 30 minutes or so. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
