Re: compilation with clang

> And answers are trickling in; see thread starting with > > http://lists.llvm.org/pipermail/cfe-users/2018-November/001417.html Is the work-around shown in https://godbolt.org/z/cTq06R usable for lilypond? Werner ___ lilypond-devel mailing

Re: compilation with clang

>> No. It's not C++08 syntax, and LilyPond actually makes use of the >> overloading resolution (which of the templates is called depends on >> where in the hierarchy the function that the function pointer >> refers to is defined) as part of the macro framework used here and >> thus it's not poss

Re: compilation with clang

> And answers are trickling in; see thread starting with > > http://lists.llvm.org/pipermail/cfe-users/2018-November/001417.html And here's the definite answer from a clang developer: The rule for determining when a base class function declaration introduced by a using-declaration is hid

Re: compilation with clang

>> The rule for determining when a base class function declaration >> introduced by a using-declaration is hidden by a derived class >> function declaration does not take the template parameter list >> into account: >> http://eel.is/c++draft/namespace.udecl#15.sentence-1 > > Huh? This

Re: compilation with clang

And another follow-up. > Isn’t it template-parameter-list that is different rather than > parameter-type-list? > > http://eel.is/c++draft/dcl.fct#def:parameter-type-list > http://eel.is/c++draft/temp#nt:template-parameter-list Yes. The pieces are these: template // template-p

Re: Long time no see :-)

> does anyone remember me? :-) Looks like I'm going to meddle a tiny > bit in the Pond affairs again. Welcome back! > What you've been up to in the last 4 years? What's the current > situation? The main news: David K. tries to cut a 2.20 release; he cleaned up the syntax handling a lot. Just

Re: 2.20 plans.

>> I've just set up a new user on my build machine and tried to build >> GUB. [...] >> >> /home/gubd/GubDir/gub/target/tools/build/guile-1.8.7 && export guile 1.8.7? What about updating to guile 1.8.8? Werner ___ lilypond-devel mailing list lily

what happened with janneke/gub on github?

It seems that http://github.com/janneke/gub is no longer available. Jan, is this intentional? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: what happened with janneke/gub on github?

>> It seems that >>http://github.com/janneke/gub >> is no longer available. > > Most activity for GUB development is now at Graham Percival's > repository, isn't it? > > Yes, but our documentation still talks about Jan's repository, which seemed to be avai

Re: what happened with janneke/gub on github?

>> http://github.com/janneke/gub >> >> is no longer available. Jan, is this intentional? > > Yes, sorry. > > After I found that github is non-free software and the FSF advised > agains using it, I moved activity to gitlab. After Microsoft bought > github I removed all my repositories. OK,

Re: New LilyPond contributor: Basia Mroczek

> Please give her a warm welcome! Warm welcome :-) I suggest to start with setting up a build environment (on GNU/Linux box or in a virtual GNU/Linux machine) so that changes to C++ code, Scheme code, and documentation can be easily done. Werner __

nasty `ar' crash while building guile with gub

My attempts to build lilypond (or rather guile) with gub are stopped in the `tools' stage since a few days due to a nasty crash in `ar' in combination with its `LLVMgold.so' plugin on openSuSE 42.3, cf. https://bugzilla.opensuse.org/show_bug.cgi?id=1117239 Does anybody else experience this is

lilypond 2.19.82 now in macports

Folks, lilypond 2.19.82, the last released development version, is now available in macports. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GSoC Proposal - SVG Export

> I’m Étienne Beaulé and I’ve been making some changes to LilyPond. I > am also the maintainer of the MediaWiki Score extension which allows > embedded LilyPond on Wikipedia. I’m currently a bachelor student at > the Université de Montréal studying computer science and > mathematics, and Google

Re: lilypond 2.19.82 now in macports

>> lilypond 2.19.82, the last released development version, is now >> available in macports. > > Just curious - why should one use the macports version instead of > the binary provided by lilypond.org? There are at least two reasons. * It seamlessly integrates into macports, which means it can

Re: Lilypond Python upgrade

>> It was over two and a half years ago I was about to launch into >> starting off the upgrade of lilypond to use Python 3. [...] > > That would be great. Upgrade to python3 only? Or python2 + python3? Definitely the latter! However, I think we should first upgrade gub to contain Python 2.6 as

Re: GUB lilypond build fails

>I think you have the same issue me and others had. You don't see >it in the tail below, but if you open the lilypond.log file >you'll see a python command failing to generate a file because >GUB python is 2.4 while lilypond python code uses if statements. >It's discussed in

Re: GUB lilypond build fails

> lilypond should now build with gub as soon as this commit goes to > `master'. To be more precise: I can build lilypond with gub on my openSuSE Leap 42.3 GNU/Linux box.[*] I use the attached patches for gub (relative to HEAD), which are based on https://github.com/gperciva/gub/pull/7 plus s

Re: GUB lilypond build fails

> So it would be really _urgent_ to get GUB advanced to a recent > version of Python 2 in all supported platforms Yes. > (and I think we can delist the PPC platform support by now): What's exactly the reason for this? > But at least PPC seems reasonably safe to retire, and possibly > FreeBSD if

write access for gperciva/gub

Phil, Federico, et al. I would like to have write access to the gub git repository. Right now I've successfully built gub for all OS flavours on my openSuSE Leap 42.3 box. The next step is to make gub's `lilypond-test' target succeed. Currently it fails because in 2015 `pngtopam' was introdu

fundamental problem with gub's regtest tarball

Folks, we have an unfortunate dependency on the private directory layout of the guy who has created lilypond-2.19.82-1.test-output.tar.bz2 (this file is needed for completing a gub build of lilypond). For example, on my openSuSE box ghostscript aborts with Error: /undefinedfilename in

Re: fundamental problem with gub's regtest tarball

>> For example, on my openSuSE box ghostscript aborts with >> >>Error: /undefinedfilename in --file-- >>Operand stack: >> (/home/gub/NewGub/gub/target/linux-x86/.../otf/emmentaler-20.otf) (r) >> >>[...] >>Last OS error: No such file or directory > >

Re: fundamental problem with gub's regtest tarball

> Hopefully the latest fixes by Werner will work.. I'm now testing his > branch on LilyDev 0.3, recently released. FYI, he means my pull request at https://github.com/gperciva/gub/pull/51 Werner ___ lilypond-devel mailing list lilypond-devel@

Re: fundamental problem with gub's regtest tarball

>>> Hopefully the latest fixes by Werner will work.. I'm now testing his >>> branch on LilyDev 0.3, recently released. >> FYI, he means my pull request at >> https://github.com/gperciva/gub/pull/51 >>Werner > > Now merged Thanks! Werner ___

Re: fundamental problem with gub's regtest tarball

>  On openSUSE Tumbleweed (VERSION_ID="20181218") and ubuntu 18.04 > "make lilypond" still fails with current gub master. Will have a look soon. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/li

Re: GUB lilypond build fails

> Almost completed a GUB build today, building against > release/unstable. Unfortunately it eventually failed with the errors > below. Can anyone suggest what ids going wrong? > > invoking gs -sDEVICE=png16m \ > -dGraphicsAlphaBits=4 \ > -dTextAlphaBits=4 \ >

Re: GUB lilypond build fails

>> This command seems to fail. Can you run it manually (with proper >> values for $PATH, $GS_FONTPATH, and $GS_LIB) so that we can see its >> output? Information about the environment variables should be >> available in `lilypond-test.log'. > > Any idea of what would be the proper values for t

Re: GUB lilypond build fails

> Now done and I get this: > > Error: /undefinedfilename in (v2.19.64-1/merge-rests-engraver.eps) > > [...] > > Which is true. The file doesn't exist. It should have come from > the test-output-distance.py, I think, but have no clue as to why > it's not there. How many processes do run in pa

Re: GUB lilypond build fails

> It may be of note that an earlier (i.e. 6 months' earlier) > successful run doesn't have the "invoking GS" line in its output. What does locate merge-rests-engraver say? Are files containing this name actually present for the old version? And what about newer version? Maybe a log file w

Re: fundamental problem with gub's regtest tarball

> We have to update fontconfig in gub to a more recent version (at > least 2.12.2) – Masamichi-san's collection of patches doesn't fix > this glitch. I've just submitted a pull request that updates FreeType to 2.9.1 and fontconfig to 2.12.6. https://github.com/gperciva/gub/pull/52 Werner

Re: fundamental problem with gub's regtest tarball

> 'git clean -dfx; make lilypond' succeeded on ubuntu 16.04.4 after I > installed the gperf fontconfig-2.12.6  depends on. That means we > also need a tools::gperf. Thanks for testing. I've just added gperf to https://github.com/gperciva/gub/pull/52 Werner __

Re: GUB lilypond build fails

> It now fails with a different file not found, but essentially still > the same: [...] OK. > If I try to locate the file we get: [...] Are these files displayable? You could try gv -nosafedir -nosafer foo.eps > A curious other problem which I'd not remarked on before is that a > little hig

Re: GUB lilypond build fails

>> cherry-picking 915799cad7118c39c89f564430093c0ad021dd9e from master >> fixes that. > > Of course (change to Python 2.4 syntax). Done. Please cherry-pick 8067320145662554d85e59e6b9e6df3770f9e4a3 also; I'm going to submit fontconfig changes to gub that rely on the availability of this feature

ulimits for `lilypond-test' in gub

Folks, running `lilypond-test' in gub uses the following ulimit values for creating the regression EPS files: ulimit -m 524288 ulimit -d 524288 ulimit -v 2097152 Interestingly, this is not sufficient on my 64bit openSuSE 42.3 GNU/Linux box with my forthcoming changes to restrict fontconf

Re: GUB lilypond build fails

>> Please cherry-pick 8067320145662554d85e59e6b9e6df3770f9e4a3 also; >> I'm going to submit fontconfig changes to gub that rely on the >> availability of this feature. > > Well, I am not happy with such fresh changes in the stable-2.20 > branch but a 2.20 that we don't manage to get through GUB

gub: I can now completely build lilypond

Folks, using gub pull requests https://github.com/gperciva/gub/pull/53 https://github.com/gperciva/gub/pull/54 together with https://sourceforge.net/p/testlilyissues/issues/5456/ allows me to successfully run gub's `make lilypond' on my machine, including regression tests and documenta

Re: gub: I can now completely build lilypond

>> This means that a lilypond build is no longer bound to a certain >> architecture > > Thanks for your work, but that part of the sentence seems a bit > optimistic to me ... :-) > bin/gub on plain openSuSE Tumbleweed still is unable to build > xxx::guile (xxx is anything but 'tools') and *::p

gub's `make bootstrap' is useless

As far as I can see, running gub's make bootstrap target is completely useless. If you call make lilypond (which is equivalent to `make -f lilypond.make', BTW), all necessary packages are rebuilt – even the stuff from `tools', which doesn't make any sense. Looking into the `*.checksum' f

speeding up issue #5456

I've just updated the patch for issue #5456; a complete gub build from scratch unveiled that it didn't work as expected. http://codereview.appspot.com/349090043 To continue my work on gub I would like to push this ASAP, skipping the review process so that I don't have to wait another week...

Re: gub: I can now completely build lilypond

> Version 2 of the patch to fix building xxx::guile with gub. > >rm -rf target/*/packages/*guile* >bin/gub tools::guile freebsd-64::guile linux-ppc::guile >darwin-x86::guile darwin-ppc::guile mingw::guile freebsd-x86::guile >linux-x86::guile linux-64::guile > > now succeeds on ub

Re: speeding up issue #5456

>> To continue my work on gub I would like to push this ASAP, skipping >> the review process so that I don't have to wait another week... Is >> this OK? > > If the other devs are OK with this then fine. OK, now pushed. `make test' succeeded on my computer. > I'll do a full patch test run any

Re: gub: I can now completely build lilypond

Regarding Knut's compilation problems on gub with guile: >> In file included from >> >> /home/gub/NewGub/gub/target/darwin-x86/src/guile-1.8.7/libguile/strings.h:25:0, >> from /usr/include/string.h:431, >> from >> >> /home/gub/NewGub/gub/target/darwin-x86/src/guile-1.8.7/libguile/gen-s

Re: gub: I can now completely build lilypond

> because you wrote "no longer bound to a certain architecture", I gave > it a try on my 64-bit Ubuntu 18.04. [...] > > [...] > building package: darwin-ppc::odcctools > *** Stage: download (odcctools, darwin-ppc) > *** Stage: untar (odcctools, darwin-ppc) > *** Stage: patch (odcctools, darwi

Re: gub: I can now completely build lilypond

now, what about your Python issue? Do you still have the same problem? Have you ever tried a Python debugger? Werner PS: A minor correction: please replace Version 3, based on an analysis of Werner Lemberg. with Version 3,

Re: gub: I can now completely build lilypond

>> Given that the installation of guile seems to work now, what about >> your Python issue? Do you still have the same problem? Have you >> ever tried a Python debugger? > > Still broken. I'll have a look at the python build system later. > > 'bin/gub tools::python' segfaults during compile sta

Re: gub: I can now completely build lilypond

>> ./python: error while loading shared libraries: >>libdb-4.7.so: cannot open shared object file: >>No such file or directory > > Looks like it's `strace' time again... I suspect wrong linker > options that hard-link the DLL locations. s/hard-link/hard-code/ Werner __

Re: gub: I can now completely build lilypond

> FWIW, I did a successful complete run of 'make lilypond' in LilyDev > 4(?), based on debian-8, 32 bit (only thing I had to install was > missing 'unzip') Excellent! > gub was amended with pull-requests 53, 54, 55, 56 I think these four pull requests should be now merged into the repository.

Re: gub: I can now completely build lilypond

> [ continued analysis of tools::python build problem on openSuSE > Tumbleweed] Thanks a lot! It's a tedious job to check all those strace files... > [...] Should this be an incompatibility of gcc 8.* and python 2.4.5? It seems so. > Results: Building of all *::lilypond targets succeed. Goo

patches for python in gub

Jan, we are in the process of updating gub to contain a more recent python version since the current version segfaults with gcc 8 on some platforms. All python versions supported in gub are accompanied with a bunch of patch files. What did you use as the source for those patches, and what were

Re: gub: I can now completely build lilypond

> [ continued analysis of tools::python build problem on openSuSE > Tumbleweed] Thanks a lot! It's a tedious job to check all those strace files... > [...] Should this be an incompatibility of gcc 8.* and python 2.4.5? It seems so. > Results: Building of all *::lilypond targets succeed. Goo

patches for python in gub

Jan, we are in the process of updating gub to contain a more recent python version since the current version segfaults with gcc 8 on some platforms. All python versions supported in gub are accompanied with a bunch of patch files. What did you use as the source for those patches, and what were

patches for python in gub

[gnu.org rejected mail for a few hours, thus resending.] Jan, we are in the process of updating gub to contain a more recent python version since the current version segfaults with gcc 8 on some platforms. All python versions supported in gub are accompanied with a bunch of patch files. What

Re: patches for python in gub

>> All python versions supported in gub are accompanied with a bunch >> of patch files. What did you use as the source for those patches, >> and what were the reasons to use them? > > IIRC, Han-Wen and I created patches to cross-build python. Both of > us tried at length to get them upstream.

Re: patches for python in gub

> There's another feature we added in the patches: dynamic/runtime > relocation of the install prefix. You may have to keep that bit. I seem to be blind since I can't find that feature in the patches. Could you please give a link to a relevant spot in the gub patch files for, say, python 2.4.5?

Re: [GUB] libc.so.6: undefined reference

Federico, regarding: /home/dev/gub/target/linux-x86/root/lib/libc.so.6: undefined reference to `_dl_out_of_memory@GLIBC_PRIVATE' This doesn't look like a problem with guile – at least I can't see a problem in the log file. I rather believe it is a problem with compilation of `ldtl', wh

Re: gub: I can now completely build lilypond

>> Obviously another linking path issue: While executing the external >> TeX binaries, DLL stuff from `target/...' must not be used. > > I think the easiest solution is a simple etex wrapper script in > tools/root that clears LD_LIBRARY_PATH and then executes the > system's etex. Excellent solu

Re: patches for python in gub

>>> There's another feature we added in the patches: dynamic/runtime >>> relocation of the install prefix. You may have to keep that bit. >> >> I seem to be blind since I can't find that feature in the patches. >> Could you please give a link to a relevant spot in the gub patch >> files for, say,

Re: gub: I can now completely build lilypond

> If you and Werner managed to build the installers, why don't you get > in touch with Phil to make a new release? I could build current lilypond git within gub and upload the created packages so that other people can play with it. However, I have not the experience to cut a new release...

Re: patches for python in gub

>> OK, thanks for letting us know. Fortunately, the situation seems >> to have become better, so perhaps adding support for the most >> recent python version is trivial now. > > Do you mean that there are hints that let you say patches for > cross-compiling would be likely accepted upstream? > >

Re: gub: I can now completely build lilypond

> Here's the tail of target/tools/log/m4.log > > [...] > /home/dev/gub/target/tools/src/m4-1.4.12/lib/freadahead.c: > In function 'freadahead': > /home/dev/gub/target/tools/src/m4-1.4.12/lib/freadahead.c:77:3: >error: [...] > #error "Please port gnulib freadahead.c to your platform! >

Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

> I've been struggling today to 'make check' as part of the normal set > of commands I use to patch test. > > I've gone back, one by one, and this is the commit that 'breaks' my > patch testing > > Issue 5450: relocate.cc: Introduce new command `set?' > commit 8067320145662554d85e59e6b9e6df37

Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

> I did from scratch: > > rm -fr build/ > sh autogen.sh --noconfigure > mkdir -p build/ > cd build/ > ../configure > gitk > git status > make -j3 CPU_COUNT=3 > make -j3 CPU_COUNT=3 test-baseline > make -j3 CPU_COUNT=3 check > > > Failed with: > > Error: /undefinedfilename in --file-- > Operand s

Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

>> > Failed with: >> > >> > Error: /undefinedfilename in --file-- >> > Operand stack: >> > >> > (input/regression/out-test-baseline/share/lilypond/current/fonts/otf/emmentaler-20.otf) >> >> I can't reproduce that. I followed exactly your recipe (but >> omitting `-j3 CPU_COUNT=3'), and it works

Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

>> Can you repeat the whole thing without any options for parallel >> computing and show us the output of >> >> make check &> make.check.log & >> >> please? I could then compare it directly with my log file. > > I downgraded ghostscript to 9.26, still failing. So likely not a > gs-problem. > > A

Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

>> -> I suspect that stable/2.20 fails because patch >> 2c7277e0014b8d1d22ef5a1caa69a2f86bcfb964 is missing ... > > Patch does not apply (upon cherry-pick) so I guess that this builds on > some previous patch. Would we be needing both then? Yes, 430fcf895a49d8159413f194488b8474d4ae6be6 is also n

Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

>> Yes, 430fcf895a49d8159413f194488b8474d4ae6be6 is also needed. > > Doesn't apply either. OK, so please add 61d42c83db9abf567da0dcabec50df71d56d2bf9, too. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mail

Re: I cannot run make check since Issue 5450: relocate.cc: Introduce new command `set?'

> The gs interpreter should not be 9.26. What files are opened during > the gs run? [...] Can you show the environment for this gs run? It seems as if `.../target/linux-64/root/usr/lib' is missing from LD_LIBRARY_PATH... > -> We either need to change lilypond's code in a way that PATH is >

grand copyright replacement

I'm going to run `scripts/build/grand-replace' to update all copyright years. However, my test run shows that there are a bunch of files that aren't covered, for example `lily/part-combine-part-iterator.cc', which has the following copyright notice: Copyright (C) 2015 Daniel Eble Shall this

Re: grand copyright replacement

>> I'm going to run `scripts/build/grand-replace' to update all >> copyright years. However, my test run shows that there are a bunch >> of files that aren't covered, for example >> `lily/part-combine-part-iterator.cc', which has the following >> copyright notice: >> >> Copyright (C) 2015 Daniel

Re: grand copyright replacement

>> Assuming we are running `grand-replace' next year again this would >> be (in almost all cases) a one-time job. > > Would there be a way to automate it so the first build run in a new > year updates all the copyrights? Well, the *proper* way IMHO would be to use gnulib's `update-copyright' scr

Re: Emacs lilypond mode

> David's suggestion, the GNU Emacs SMIE Simple Minded Indentation > Engine looks like a good place to start. For this I need the BNF > grammar for Lilypond. Where does one find that? See Appendix A in the contributor's guide. Werner ___ lilypo

Re: Emacs lilypond mode

>> David's suggestion, the GNU Emacs SMIE Simple Minded Indentation >> Engine looks like a good place to start. For this I need the BNF >> grammar for Lilypond. Where does one find that? > > See Appendix A in the contributor's guide. Uh, oh, the output is severely broken. Attached is the bare

Re: Emacs lilypond mode

>> PS: I'll fix the `yyout2grammar' script. Done, see https://sourceforge.net/p/testlilyissues/issues/5468/ > You might want to check whether Bison now offers some output option > that is more dependable than its debug output. I haven't seen related to this in the last version announcements

Re: Emacs lilypond mode

> PS: I'll fix the `yyout2grammar' script. >>> >>> Done, see >>> >>>https://sourceforge.net/p/testlilyissues/issues/5468/ >> >> So what is >> >> >> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=385ed0864c1be511ce16eb21751cec7fb68dd978 >> >> all about Formatting only. N

Re: Emacs lilypond mode

PS: I'll fix the `yyout2grammar' script. > > http://lists.gnu.org/archive/html/bug-lilypond/2018-01/msg00010.html Ah, I have missed this completely, and/or couldn't remember your work. Thanks for the link! Unfortunately, `lists.gnu.org' distorts stuff in text attachments that contain `@' i

Re: Emacs lilypond mode

>> Formatting only. No change in behaviour. > > And grammar and wording changes in the comments and changes from ## > comments to # comments (which does not appear to make a difference > to Emacs though as opposed to comments in some other languages). Yes. `#' and `##' were mixed up without a

Re: Please test gub

>> The overall end doesn't report a failure, but the last "rule" shows >> some problems, > > I should have mentioned this was the "nsis rule" If you reach this point you can be rather sure that everything was fine – at least for your build system, since it was used to run lilypond's tests to gen

Re: Please test gub

>> If we get more success reports, the resulting packages should be >> uploaded so that other people not running gub can test them. >> Developers can then have a look how to add support for 64bit >> binaries on MacOS and Windows. Especially the former is rather >> urgent... > > I can upload my st

Re: Emacs lilypond mode

>> What I want to know, however, is the `significance threshold' such >> courtesy messages should have. > > Pretty much any commit you are about to push to staging. It's as > simple as that. OK, deal. Werner ___ lilypond-devel mailing list lil

Re: Please test gub

> The resulting installers all have SHA256 checksums different than the > ones from Urs Liska's Nextcloud share. Are you sure that the build refers to exactly the same lilypond git commit as Urs's installers? HEAD is continuously updated... > I don't know what's expected with that. It would b

Re: Please test gub

>> Apart from that minor buzz, `make lilypond` does a good chunk of work, >> but fails building tools::guile; log attached. > > I see. libtools segfauls. >../libtool: line 950: 23645 Segmentation fault  (core dumped) >ar cru .libs/libguile.a [...] This is probably the same bug I've

Re: Please test gub

>>../libtool: line 950: 23645 Segmentation fault  (core dumped) >>ar cru .libs/libguile.a [...] > > This is probably the same bug I've encountered on my openSUSE box. > Try to remove the file (or link) `/usr/lib/bfd-plugins/LLVMgold.so' > and replace it with the gcc variant `liblto_plu

Re: Please test gub

> On my system, the symlink for liblto_plugin.so already exists, so I > only had to remove (rename wasn't enough) LLVMgold.so. > > Building tools::guile succeeds after that modification; [...] OK! BTW, It took me some weeks to identify this very problem... > # pacman -Qo /usr/lib/bfd-plugins/

Re: Please test gub

> That leaves the two problems of > > - LLVMgold.so in /usr/lib/bfd-plugins shadowing liblto_plugin.so > (I rm'ed LLVMgold.so there for the purpose of the above gub run.) This is definitely *not* a gub issue. It's strange that only the compilation of guile is affected by the problem, but I c

Re: PATCHES - Countdown for Feb 7th

> New: No new patches at this time. Please put https://sourceforge.net/p/testlilyissues/issues/5468/ into the loop – it contains a new, improved patch, and it seems that I've reset the tags to wrong values so that it slipped your attention. Werner ___

debugging problem

Folks, while trying to find out why https://sourceforge.net/p/testlilyissues/issues/5472/ doesn't work as expected, I stumbled across a problem that I'm not able to locate since hours. Consider this call (with the patch from issue #5472 applied), where lilypond gets configured and compiled

Re: debugging problem

> Where is the output name constructed for the MIDI file? To be more > precise, where is the string > > > /home/wl/git/lilypond/input/regression/midi/crescendo-gap-compatible-target.ly > > converted to the basename of the MIDI file? Right now, in function > `write-performance-midis' (file

Re: Please test gub

> - addition of texinfo/txi-pt.tex from Texinfo sources, as Portuguese > translation has been added and I don't have Texinfo installed in GUB > host system; ??? What exactly needs Portuguese? Lilypond doesn't, AFAICS. > - update of texinfo.tex (not necessary, but I did it together with > tx

Re: Please test gub

>> @Werner: Didn't you write something about updating python in gub? Well, someone (I forgot his name) offered to work on updating python to the latest 2.7.x version, which should make it easier to eventually migrate to python 3.x... > I assume you're referring to the situation that (e.g.) 2.19

Relocation

Folks, attached are two images that show my planned documentation of lilypond's binary relocation. What I'm interested in are comments to the relocation algorithm. If we can find an agreement, I'm going to fix lilypond to follow it.[*] Right now, lilypond's behaviour is quite erratic and has s

Re: Relocation

>> What I'm interested in are comments to the relocation algorithm. >> If we can find an agreement, I'm going to fix lilypond to follow >> it.[*] > > Is there a good reason for looking for $INSTALLER_PREFIX > subdirectories (#2) before examining whether LILYPOND_DATADIR and > LILYPOND_LOCALEDIR

Re: Relocation

>> I'd rather do this in the opposite order and put #4 and #5 (as "Use >> VAR_FOODIR as LilyPond FOO directory) just after #1, and execute #2 >> only if LILYPOND_DATADIR environment variable is unset. > > Good idea, thanks. Here's an updated version of the algorithm, which is now pretty simple a

Re: 64-bit version of Lilypond?

>> I don't have access to a mac, I don't think that I know anybody who >> uses one within a 20 miles radius, and my knowledge of MacOS is >> almost limited to the single information that it does exist. >> Therefore I definitely will not work on 64-bit mac support in gub. I just want to remark th

Re: Please test gub

>> ??? What exactly needs Portuguese? Lilypond doesn't, AFAICS. > > In stable/2.20 here's a translation of the website in this language, > and a PDF of the website is built and even shipped in the > documentation tarball and the website, e.g. look at the end of the > file list on http://lilypond

Re: Please test gub

> After getting everything downloaded, `time make lilypond` ran for > just under 3h30m. [...] Excellent! > Also, I have been exploring adding 64-bit macOS (Darwin) targets and > I am planning on sharing my findings thus far as soon as I have > finished writing them up. Great news, and thanks

Re: Please test gub

>>> In stable/2.20 here's a translation of the website in this >>> language, and a PDF of the website is built and even shipped in >>> the documentation tarball and the website, e.g. look at the end of >>> the file list on http://lilypond.org/doc/v2.19/Documentation/ >> >> Thanks, but uh, oh – how

Re: Update of texinfo.tex, and cherry-picks in stable/2.20

> As suggested by Werner on February 8th in "Please test GUB" thread, > we should update tex/texinfo.tex in our sources from Texinfo git > repo. Is there any objection to applying this change on both > staging and stable/2.20 branches without the usual review process? Obviously, I don't have ob

GUB progress?

Folks, we had some good progress with GUB. However, in the last few weeks the development stalled, which is not good. I thus propose the following. * The pull requests as described in https://lists.gnu.org/archive/html/lilypond-devel/2019-01/msg00221.html should finally be applied. I

Re: GUB progress?

> Please could you confirm which ones can happily be applied - is it > all from #53 (fontconfig: Avoid access...) to #62 (Enable ... on > macOS) or a subset? John already took action, and Knut will certainly comment soon :-) Werner ___ lilypond-

Re: GUB progress?

> I got no reply from my last comment on #59, so I went for closing > it. I merged all others from #53 to #62. I'm not as certain for #61 > and #62 as for others, but I observed no regression with them and > nobody else commented. Thanks! > There are also old open pull requests left, do you ha

<    3   4   5   6   7   8   9   10   11   12   >