Re: Issue 5380: Fix `make doc` with non-clean build directory (issue 355750043 by truer...@gmail.com)
Thank you for your reviewing. https://codereview.appspot.com/355750043/diff/1/scripts/build/www_post.py File scripts/build/www_post.py (right): https://codereview.appspot.com/355750043/diff/1/scripts/build/www_post.py#newcode97 scripts/build/www_post.py:97: os.link (f, strip_file_name[t] (f)) On 2018/07/13 22:54:48, Dan Eble wrote: This is not a reason to hold back the patch, but this would be easier to read and probably perform better if strip_file_name[t] (f) were called once instead of three times. Otherwise, LGTM. Done. https://codereview.appspot.com/355750043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
>>> I found a possibility that the wrong PDF is output >>> if the build directory is not clean. > > I've created the patch. > https://sourceforge.net/p/testlilyissues/issues/5380/ > https://codereview.appspot.com/355750043 Thanks a lot! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
> Masamichi Hosoda writes: > GUB worked for a long time, but we have a) an unsolved problem building the pdfs of the english documentation of stable/2.20, >>> >>> That sounds like more of a race condition to me, so it's likely >>> unrelated to GUB but may be related to building in a separate directory >>> or to cross-compilation. >> >> I found a possibility that the wrong PDF is output >> if the build directory is not clean. > > Like when a build aborted, maybe. > >> I'll create a patch which fixes this issue. > > Let's hope that this will avoid this problem in future. I've created the patch. https://sourceforge.net/p/testlilyissues/issues/5380/ https://codereview.appspot.com/355750043 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
Masamichi Hosoda writes: >>> GUB worked for a long time, but we have a) an unsolved problem >>> building the pdfs of the english documentation of stable/2.20, >> >> That sounds like more of a race condition to me, so it's likely >> unrelated to GUB but may be related to building in a separate directory >> or to cross-compilation. > > I found a possibility that the wrong PDF is output > if the build directory is not clean. Like when a build aborted, maybe. > I'll create a patch which fixes this issue. Let's hope that this will avoid this problem in future. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
>> GUB worked for a long time, but we have a) an unsolved problem
>> building the pdfs of the english documentation of stable/2.20,
>
> That sounds like more of a race condition to me, so it's likely
> unrelated to GUB but may be related to building in a separate directory
> or to cross-compilation.
I found a possibility that the wrong PDF is output
if the build directory is not clean.
This issue is unrelated to GUB.
With GUB, without GUB, it might happen in both.
You can reproduce by the following procedure without GUB.
```
$ git checkout release/2.19.82-1
$ ./autogen.sh --noconf
$ rm -fr build
$ mkdir build
$ mkdir -p out-www/offline-root/Documentation/
$ echo "wrong file" > out-www/offline-root/Documentation/notation.pdf
$ mkdir -p out-www/online-root/Documentation/
$ echo "wrong file" > out-www/online-root/Documentation/notation.pdf
$ ../configure
$ make -j 8
$ make -j 8 CPU_COUNT=8 WEB_TARGETS='offline online' LANGS='' doc
```
The result is as follows.
```
$ find . -name 'notation.pdf' -exec ls -lah {} \;
-rw-r--r-- 1 trueroad none 6.5M Jul 13 22:37
./Documentation/out-www/notation.pdf
-rw-r--r-- 1 trueroad none 11 Jul 13 21:39
./out-www/offline-root/Documentation/notation.pdf
-rw-r--r-- 1 trueroad none 11 Jul 13 21:39
./out-www/online-root/Documentation/notation.pdf
$ cat out-www/offline-root/Documentation/notation.pdf
wrong file
$ cat out-www/online-root/Documentation/notation.pdf
wrong file
$
```
I'll create a patch which fixes this issue.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
Hi David, > It's just possible that the Guix developers will refuse accepting a > Guile-1.8 development package on philosophical grounds. We Guix people have had a “guile-1.8” package since a long time and it is still used by our “lilypond” package. There are no plans to remove it. -- Ricardo ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES - Countdown for July 13th
Hello, Here is the current patch countdown list. The next countdown will be on 16th July. A quick synopsis of all patches currently in the review process can be found here: http://philholmes.net/lilypond/allura/ Push: 5375 Let \raise and \lower heed font-size - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5375 http://codereview.appspot.com/343330043 5374 Remove Grob_info::origin_contexts () - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5374 http://codereview.appspot.com/342210043 5373 website: remove fixed width in code blocks of Mac Os X page - Federico Bruni https://sourceforge.net/p/testlilyissues/issues/5373 http://codereview.appspot.com/347910043 5370 \germanChords raises accidentals too high - Malte Meyn https://sourceforge.net/p/testlilyissues/issues/5370 http://codereview.appspot.com/349750043 5369 Change highmidtom to himidtom in notation-appendices.itely - Thomas Morley https://sourceforge.net/p/testlilyissues/issues/5369 http://codereview.appspot.com/355740043 5368 Reduce allocations in Grob dimension caching - Dan Eble https://sourceforge.net/p/testlilyissues/issues/5368 http://codereview.appspot.com/359770043 Countdown: 5376 parser.yy: rename multiplied_duration to duration - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5376 http://codereview.appspot.com/367750043 5351 Spacing_spanner::prune_loose_columns: prune in-place - David Kastrup https://sourceforge.net/p/testlilyissues/issues/5351 http://codereview.appspot.com/351720043 Review: No patches in Review at this time. New: No new patches at this time. Regards James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
Thomas Morley writes: > 2018-07-09 23:33 GMT+02:00 Carl Sorensen : >> In May, when we were discussing the limitations of 32 bit MinGW, I >> asked Jan for an estimate of how much work it would be to add a >> 64-bt MinGW to GUB. >> >> His answer was that GUB is a hack, and that he wasn't interested in >> putting any more effort into fixing up GUB, although he would >> certainly provide me advice if I asked for it. >> >> His recommendation was to move to Guix[1], which is an existing and >> supporting package for maintaining appropriate package versions for >> a particular user. He said he would be willing to help with that, >> as it's making things better, not just spending more effort on a >> hack. >> >> Are there any opinions on whether we should pursue a move to Guix? >> >> Thanks, >> >> Carl >> >> 1. >> https://www.gnu.org/software/guix/manual/en/html_node/Package-Management.html > > >>From a mail by Ludovic Courtès via the guile-user-list: > "The plan is for Guix to require Guile >= 2.2 sometime soon though," > http://lists.gnu.org/archive/html/guile-user/2018-07/msg00043.html > > So ... That's not all that relevant. It's bog standard (and has been for years) for LilyPond to have all its scripts running on Guile 2.x while its internals are linked to Guile 1.8. It's just possible that the Guix developers will refuse accepting a Guile-1.8 development package on philosophical grounds. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB
2018-07-09 23:33 GMT+02:00 Carl Sorensen : > In May, when we were discussing the limitations of 32 bit MinGW, I asked Jan > for an estimate of how much work it would be to add a 64-bt MinGW to GUB. > > His answer was that GUB is a hack, and that he wasn't interested in putting > any more effort into fixing up GUB, although he would certainly provide me > advice if I asked for it. > > His recommendation was to move to Guix[1], which is an existing and > supporting package for maintaining appropriate package versions for a > particular user. He said he would be willing to help with that, as it's > making things better, not just spending more effort on a hack. > > Are there any opinions on whether we should pursue a move to Guix? > > Thanks, > > Carl > > 1. > https://www.gnu.org/software/guix/manual/en/html_node/Package-Management.html From a mail by Ludovic Courtès via the guile-user-list: "The plan is for Guix to require Guile >= 2.2 sometime soon though," http://lists.gnu.org/archive/html/guile-user/2018-07/msg00043.html So ... Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
