Folks,
Carl wrote to me privately:
> OK, so now I have a failure:
>
> I did
>
> ```
> rm -rf build
> mkdir build
> cd build
> ../autogen.sh --currdir
> ../configure &> configure.log
> make -j10 CPU_COUNT=10 all
> make doc LANGS="
> I can confirm that I get the proper HTML pages, compiling with -j10
> on both make bytecode and make doc.
Great!
> It was delightful to see the proper lilypond website on my local
> file system! Thank you so much for fixing this!
Glad that I could help. I will now p
On Mon, Feb 12, 2024 at 9:22 AM Werner LEMBERG wrote:
>
> v2.25.13-8-gbe52228a70
>
> Please test again! Theoretically, you should now get proper HTML
> pages.
>
I can confirm that I get the proper HTML pages, compiling with -j10 on both
make bytecode and make doc.
It was
On Sat, Feb 10, 2024 at 7:20 AM Werner LEMBERG wrote:
>
> >> systems like macOS that neither have or use '/bin/bash'.
> >
> > Apple changed the default shell for new users to zsh about 5 years
> > ago, but bash is still there. I don't oppose making the build
> > scripts more portable, but let's
>> systems like macOS that neither have or use '/bin/bash'.
>
> Apple changed the default shell for new users to zsh about 5 years
> ago, but bash is still there. I don't oppose making the build
> scripts more portable, but let's not misunderstand the situation.
OK, thanks – let's see whether
On 2024-02-10 07:52, Werner LEMBERG wrote:
systems like macOS that neither have or use '/bin/bash'.
Apple changed the default shell for new users to zsh about 5 years ago,
but bash is still there. I don't oppose making the build scripts more
portable, but let's not misunderstand the
cOS that neither have or use '/bin/bash'.
Carl, please do another run of the following commands based on the
updated 'dev/wl/build-fixes' branch, then create and upload a tarball
of your `build` directory as before and send me a link to it.
```
./configure
make bytecode -j10 LANGS="en"
make do
> If I click on the Notation link from that page, I get to:
>
> out-www/offline-root/Documentation/web/notation.html
>
> which has no css, but has lots of links.
This shouldn't happen, and it means that your documentation build is
still not correct.
> I'm happy to send a tar file of my
> "/Users/carl/Development/lilypond/build/out/lybook-db/
> snippet-names-c5b165525229969dd268a5b19f9f64fd.ly"' returned
> non-zero exit status 1.
Please try to find out which of the snippet files mentioned in the
above file failed. `*.log` files should be in directory
`out/lybook-db`, too, and
p and
find.
I still got errors if I tried make doc with -j12. But without -j12 it
succeeded.
There are some minor issues with either the way the documentation is built
or the way I am using it.
IIRC, in the past, I could use Documentation/out-www/index.html as a
beginning place for documentation
n to your requested steps:
>
> Ah, my steps were not intended to be used additionally but instead :-)
>
Ah, so I tried that.
```
../configure
make bytecode -j12
```
Ran without error.
```
carl@carls-mbp-2 build % make doc -j12 CPU_COUNT=12 LANGS="en"
Making input/regression/out-ww
>> > I omitted the '-l' option in the cp calls in the patch.
>> >
>> > 'make doc' succeeded without any errors, so I thought I had success. But
>> > it turns out that
>> >
>> > a) I appear not to have the .css files copied (at least the o
[Carl sent me the file listing off-list, thanks! I will analyze it in
due course.]
> [...] and make test with a single job (to avoid race conditions that
> have given me trouble in the past):
Interesting. When is the 'past'? This shouldn't happen today, and it
would be great if you could
oblem with `cp -l` on your macOS. It's
> still hard to believe.
>
Yes, and apparently it's a new bug (older versions of the OS didn't have
it, IIUC).
>
> BTW, which macOS version are you using?
>
Sonoma 14.2.1 (23C71)
>
> > I omitted the '-l' option in the cp calls in
ing?
> I omitted the '-l' option in the cp calls in the patch.
>
> 'make doc' succeeded without any errors, so I thought I had success. But
> it turns out that
>
> a) I appear not to have the .css files copied (at least the output
>showed no css -- just basic white screen)
`cp` calls in my patch.
>
I checked -- the results of the problem were different for me than for the
bug report. I got the error message, but the hard link was never copied
(there were not two files with the same inode -- only the original file.
I omitted the '-l' option in the cp calls in the p
> 'make doc' failed.
>
> It appears that under some conditions, we end up with a path
> including '//'.
Multiple slashes in succession are completely harmless; they are
simply equivalent to `/`.
Doing a bit of an internet search it seems this is a bug in the `cp`
implementat
you've encountered.
>
It seems to work, but not perfectly. 'make all' and 'make test' work.
'make doc' failed.
It appears that under some conditions, we end up with a path including '//'.
Log file attached.
Thanks,
Carl
make.doc.log.gz
Description: GNU Zip compressed data
> I've attached three compressed log files. [...]
Thanks a lot, very helpful. Please apply the attached patch to the
top-level `GNUmakefile.in` file, then retry from scratch (including
the `configure` step); it should catch all of the three problems
you've encountered.
The `-maxdepth` and
ils. What problems did you experience with `cp`
> and `find`? Did this happen during a call to `make ...` for LilyPond?
>
All errors happened during 'make doc'. They appeared to happen after all
of the lilypond processing was done, while creating the html documentation
pages.
I've attached three
; I then get to a problem with perl: [...]
Interesting. I wasn't aware that we ever call `perl` with a long list
of arguments during `make doc`.
Please repeat this with saying
```
make doc VERBOSE=1 &> make.doc.log
```
so that we can more information in the log file. Usually, such errors
can eas
Still trying to get 'make doc' to complete successfully.
At this point, I think I'm through all the lilypond stuff, and now I'm
stuck in shell script errors.
I already had to install (via homebrew) gnu coreutils and gnu findutils,
since the MacOS 'cp' and 'find' commands don't work the same
>> Aah, this looks like a bug in `typography-demo.ly`. Please try the
>> following line in `typography-demo.ly` instead of the three
>> original font lines.
>>
>> ```
>> property-defaults.fonts.serif = "Linux Libertine O, Noto Serif CJK JP, Noto
>> Serif JP, serif"
>> ```
>
> I can confirm
On Wed, Jan 24, 2024 at 11:49 PM Werner LEMBERG wrote:
>
> >> I installed Noto Serif JP, and added it to the fontcofig cache.
> >> That got me through the previous file error. But then I got
> >> stopped on another Japanese font (I suppose this might be a Linux
> >> Libertine font, but my
>> I installed Noto Serif JP, and added it to the fontcofig cache.
>> That got me through the previous file error. But then I got
>> stopped on another Japanese font (I suppose this might be a Linux
>> Libertine font, but my fc-list command shows that I have them
>> installed):
Interesting.
On Tue, Jan 23, 2024 at 4:54 AM Carl Sorensen
wrote:
>
>
> On Mon, Jan 22, 2024 at 8:37 PM Carl Sorensen
> wrote:
>
>>
>>
>> On Mon, Jan 22, 2024 at 5:58 PM Jean Abou Samra
>> wrote:
>>
>>> Le lundi 22 janvier 2024 à 16:38 -0700, Carl Sorensen a écrit :
>>> > > Looks like no error:
>>> > >
>>>
> carl@Carls-MBP-2 lilypond % tidy --version
>
> HTML Tidy for Mac OS X released on 31 October 2006 - Apple Inc. build 6141
This explains the failure, thanks: Your `tidy` version doesn't support
HTML 5. I've submitted an MR to catch this.
On Mon, Jan 22, 2024 at 8:37 PM Carl Sorensen
wrote:
>
>
> On Mon, Jan 22, 2024 at 5:58 PM Jean Abou Samra
> wrote:
>
>> Le lundi 22 janvier 2024 à 16:38 -0700, Carl Sorensen a écrit :
>> > > Looks like no error:
>> > >
>> > > carl@Carls-MBP-2 lilypond % build/out/bin/lilypond input/regression/
>> Can someone remind me why the build system sets the C locale in the
>> first place?
>
> Answering my own question: I guess it is because we can't assume the
> system has an en_US.UTF-8 locale or a C.UTF-8 locale?
Exactly. Some time ago (see
On Mon, Jan 22, 2024 at 5:58 PM Jean Abou Samra wrote:
> Le lundi 22 janvier 2024 à 16:38 -0700, Carl Sorensen a écrit :
> > > Looks like no error:
> > >
> > > carl@Carls-MBP-2 lilypond % build/out/bin/lilypond input/regression/
> pdf-copy-paste.ly
> > > GNU LilyPond 2.25.13 (running Guile 3.0)
> Can someone remind me why the build system sets the C locale
> in the first place?
Answering my own question: I guess it is because we can't assume the
system has an en_US.UTF-8 locale or a C.UTF-8 locale?
Maybe we ought to set only LC_MESSAGES to C? It should prevent overriding
the system
Ah, but, wait.
$ touch àéù.txt
$ guile3.0
scheme@(guile-user)> (open-file "àéù.txt" "r")
$1 = #
~/tmp $ LC_ALL=C guile3.0
scheme@(guile-user)> (open-file "àéù.txt" "r")
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure open-file: No such file or directory: "??.txt"
Le lundi 22 janvier 2024 à 18:00 -0700, Carl Sorensen a écrit :
> So I ran the file in this log message:
>
>
> carl@carls-mbp-2 build % out/bin/lilypond out/share/lilypond/current/ly/
> init.ly
>
> GNU LilyPond 2.25.13 (running Guile 3.0)
>
> Processing `out/share/lilypond/current/ly/init.ly'
Le mardi 23 janvier 2024 à 01:58 +0100, Jean Abou Samra a écrit :
> The latter is basically that this regtest (pdf-copy-paste.ly)
> has Japanese text, specifying the Noto Serif JP font, but since
> you apparently don't have that font installed, Fontconfig falls
> back to some system font, and
uld actually try that
>> >> before running `make doc`...
>> >>
>> >
>> > Interesting -- the CG has make doc show up before make test. But I
>> > appreciate the suggestion, so I decided to restart
>> >
>> > So I did a make clean,
Le lundi 22 janvier 2024 à 16:38 -0700, Carl Sorensen a écrit :
> > Looks like no error:
> >
> > carl@Carls-MBP-2 lilypond % build/out/bin/lilypond
> > input/regression/pdf-copy-paste.ly
> > GNU LilyPond 2.25.13 (running Guile 3.0)
> > Processing `input/regression/pdf-copy-paste.ly'
> >
On Mon, Jan 22, 2024 at 3:58 PM Jean Abou Samra wrote:
> Le lundi 22 janvier 2024 à 21:10 +, Werner LEMBERG a écrit :
> > > >
> > OK, thanks. This means that there is apparently a macOS-specific
> > problem with either Guile or LilyPond. For testing purposes I renamed
> > one of my local
On Sun, Jan 21, 2024 at 12:33 AM Werner LEMBERG wrote:
>
> >> You have to check the log files in `lybook-db` to find the problematic
> >> `.ly` file(s). Does `make test` succeed? You should actually try that
> >> before running `make doc`...
> >>
> >
Le lundi 22 janvier 2024 à 21:10 +, Werner LEMBERG a écrit :
> > >
> OK, thanks. This means that there is apparently a macOS-specific
> problem with either Guile or LilyPond. For testing purposes I renamed
> one of my local fonts to something containing Katakana, and my
> self-compiled
>> > In procedure open-file: No such file or directory:
>> > "/System/Library/Fonts/??? W4.ttc" [...]
>> >
>> > SO it looks to me like there's a problem with not getting UTF characters
>> > into the proper file name in the Scheme procedure. Any ideas for what to
>> > do next?
>>
>> What
On Sun, Jan 21, 2024 at 11:05 PM Werner LEMBERG wrote:
> > In procedure open-file: No such file or directory:
> > "/System/Library/Fonts/??? W4.ttc"
> >
> > I checked out the /System/Library/Fonts directory, and found these fonts
> > listed:
> >
> > ヒラギノ角ゴシック W3.ttc
> >
> > ヒラギノ角ゴシック
> In procedure open-file: No such file or directory:
> "/System/Library/Fonts/??? W4.ttc"
>
> I checked out the /System/Library/Fonts directory, and found these fonts
> listed:
>
> ヒラギノ角ゴシック W3.ttc
>
> ヒラギノ角ゴシック W4.ttc
>
> SO it looks to me like there's a problem with not getting UTF
Thanks for the hint, Dan!
I got to a new log file that gave me what I believe is a helpful error
message:
carl@carls-mbp-2 build % cat out/lybook-testdb/0f/lily-acefd898.log
Processing `0f/lily-acefd898.ly'
Parsing...
Renaming input to: `/Users/carl/Development/lilypond/input/regression/
>> You have to check the log files in `lybook-db` to find the problematic
>> `.ly` file(s). Does `make test` succeed? You should actually try that
>> before running `make doc`...
>>
>
> Interesting -- the CG has make doc show up before make test. But I
>
On 2024-01-20 20:55, Carl Sorensen wrote:
File
"/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/subprocess.py",
line 524, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['/usr/bin/tidy', '-o',
'/dev/null', '-q',
ybook-db` to find the problematic
> `.ly` file(s). Does `make test` succeed? You should actually try that
> before running `make doc`...
>
Interesting -- the CG has make doc show up before make test. But I
appreciate the suggestion, so I decided to restart
So I did a make clean, and the
lly try that
before running `make doc`...
BTW, if you execute `make test`, you are greeted with the following
advice:
```
To begin investigating regression-test crashes, try this:
grep -L systems.texi out/lybook-testdb/*/*log | sed s/log/ly/g | xargs grep
-H sourcefilename
Matching lines m
I've successfully compiled master on my MacBook with M1. I can
successfully compile some simple lilypond files.
I tried to compile the documentation using make doc.
I got this result:
carl@Carls-MBP-2 build % make doc
Making input/regression/out-www/collated-files.list < 1888 files
Mak
On Sat, 2023-07-08 at 10:20 +, Werner LEMBERG wrote:
> Currently, `make bytecode && make doc` is broken:
https://lists.gnu.org/archive/html/lilypond-devel/2023-07/msg8.html
(it's not like there are hundreds of messages every day, a duplicate
thread doesn't se
> Le 8 juil. 2023 à 12:21, Werner LEMBERG a écrit :
>
> ...display-lily-tests.ly:252:8: fatal error:
> Guile signaled an error for the expression beginning here
> \test #
> #[ \key e \minor #]
> ```
That sounds like the same problem as
[b30a94a7f8da18a8b08d3c4f11bb95c278a83c57]
Currently, `make bytecode && make doc` is broken:
```
Command '/home/wl/build-lilypond/out/bin/lilypond [...] \
".../out/lybook-db/snippet-names-c727b9067d4d978254fae040dfb82c3e.ly"'
returned non-zero exit status 1
Due to
https://bugs.ghostscript.com/show_bug.cgi?id=706552
which was fixed today it is necessary to use the forthcoming gs
version 10.02 for successful LilyPond documentation builds (using
`extractpdfmark`) with the new PDF engine of GhostScript. Without
this patch, many text accents in
ils for you on a completely fresh build, i.e.,
>
> git reset --hard
> git pull
>
> ?
>
>
> Werner
Doing all from scratch again, it works fine for master now.
I likely forgot `make doc-clean`
The glitch in my upcoming patch is corrected as well.
To check and inspect c
>> At the beginning of `internals.texi2pdf.log`:
>>
>> {finger
>>
>> /home/hermann/lilypond-git/build/Documentation/out-www/en/internals.texi:1659:
>> Paragraph ended before @var was complete.
>>
>> @par
>> l.1659
>>
>> I guess you missed a `@`...
>>
>>
>>
Am So., 29. Nov. 2020 um 19:15 Uhr schrieb Werner LEMBERG :
>
>
> > while preparing a patch, I couldn't build the docs on my local branch
> > for unknown reasons.
>
> At the beginning of `internals.texi2pdf.log`:
>
> {finger
>
>
> while preparing a patch, I couldn't build the docs on my local branch
> for unknown reasons.
At the beginning of `internals.texi2pdf.log`:
{finger
/home/hermann/lilypond-git/build/Documentation/out-www/en/internals.texi:1659:
Paragraph ended before @var was complete.
20 lines:
Underfull \hbox (badness 1) in paragraph at lines 57331--57339
@texttt . 123) (class . foo) (data-whatever . \bar"))[] @textrm will pro-duce
@texttt
It's you.
:)
I can make doc with no issues (and I am using Xetex it seems)
Also:
texi2dvi --version
texi2dvi (GNU Tex
Il giorno lun 14 set 2020 alle 13:44, Han-Wen Nienhuys
ha scritto:
On Mon, Sep 14, 2020 at 12:21 PM Michael Käppler
wrote:
Hi Jean,
Am 12.09.2020 um 13:28 schrieb Jean Abou Samra:
> Hi,
>
> Towards the end of the process, `make doc` outputs warnings coming
> from fi
Am 14.09.2020 um 13:44 schrieb Han-Wen Nienhuys:
On Mon, Sep 14, 2020 at 12:21 PM Michael Käppler wrote:
Hi Jean,
Am 12.09.2020 um 13:28 schrieb Jean Abou Samra:
Hi,
Towards the end of the process, `make doc` outputs warnings coming
from fix-docsize.sh. This occurs in CI too. Any ideas
Michael Käppler writes:
> Hi Jean,
>
> Am 12.09.2020 um 13:28 schrieb Jean Abou Samra:
>> Hi,
>>
>> Towards the end of the process, `make doc` outputs warnings coming
>> from fix-docsize.sh. This occurs in CI too. Any ideas?
>>
>> Best,
&g
On Mon, Sep 14, 2020 at 12:21 PM Michael Käppler wrote:
>
> Hi Jean,
>
> Am 12.09.2020 um 13:28 schrieb Jean Abou Samra:
> > Hi,
> >
> > Towards the end of the process, `make doc` outputs warnings coming
> > from fix-docsize.sh. This occurs in CI too. Any id
Hi Jean,
Am 12.09.2020 um 13:28 schrieb Jean Abou Samra:
Hi,
Towards the end of the process, `make doc` outputs warnings coming
from fix-docsize.sh. This occurs in CI too. Any ideas?
Best,
Jean
IIUC this is simply due to the fact that the mentioned manuals are not
translated and therefore
Le 12/09/2020 à 13:28, Jean Abou Samra a écrit :
Hi,
Towards the end of the process, `make doc` outputs warnings coming
from fix-docsize.sh. This occurs in CI too. Any ideas?
Best,
Jean
fix-docsize.sh: changes.ca.pdf not accessible from
/builds/lilypond/lilypond/build/out-www/offline-root
Hi,
Towards the end of the process, `make doc` outputs warnings coming from
fix-docsize.sh. This occurs in CI too. Any ideas?
Best,
Jean
fix-docsize.sh: changes.ca.pdf not accessible from
/builds/lilypond/lilypond/build/out-www/offline-root/Documentation/web-big-page.ca.html
|
fix
>> I get zillions of warnings from gs, all of them in the form
>>
>> Can't find (or can't open) font file
>> /usr/share/ghostscript/9.52/Resource/Font//usr/share/gh.
>>
>> All such lines are immediately followed by
>>
>> Loading Emmentaler-XX font from
>>
Am Freitag, den 14.08.2020, 19:01 +0200 schrieb Werner LEMBERG:
> Compiling the documentation (using commit 1a64f012b from today) with
>
> make doc VERBOSE=1
>
> I get zillions of warnings from gs, all of them in the form
>
> Can't find (or can't open) font file
>
> Compiling the documentation (using commit 1a64f012b from today) with
>
> make doc VERBOSE=1
>
> I get zillions of warnings from gs, all of them in the form
>
> Can't find (or can't open) font file
> /usr/share/ghostscript/9.52/Resource/Font//usr/share/gh.
Compiling the documentation (using commit 1a64f012b from today) with
make doc VERBOSE=1
I get zillions of warnings from gs, all of them in the form
Can't find (or can't open) font file
/usr/share/ghostscript/9.52/Resource/Font//usr/share/gh.
All such lines are immediately followed
On 31/07/2020 22:04, Daniel Benjamin Miller wrote:
It's actually quite fine. It's basically saying it can't find Gyre or
Emmentaler in GhostScript's bundled fonts. Which it shouldn't, since
they're not included with GS. It finds it instead in the LilyPond
build directory, where it well should
Hello,
I thought I'd do a full make/make doc since the last set of merges about
5 mins ago (just because I have time) using verbose logging and I
noticed a slew of these
--snip--
...
GPL Ghostscript 9.50 (2019-10-15)
Copyright (C) 2019 Artifex Software, Inc. All rights reserved
On 6/17/20, Valentin Villenave wrote:
> Thanks for giving me hope, even for a minute :-)
I spoke too soon; running doc-clean and _then_ “make doc” indeed fixes
the problem. (And Jonas has just merged it onto master so that
problem is fixed.)
Thanks!
Cheers,
-- V.
On 6/17/20, Michael Käppler wrote:
> Do you have
> https://gitlab.com/lilypond/lilypond/-/merge_requests/148/diffs?commit_id=c002d5e8c2e737cefbafa84f4b66e4b3bbc6d111
> in your repo? Otherwise that may well be the problem. Jonas wanted to
> push this one yesterday,
> but it seems that did not
Am Mittwoch, den 17.06.2020, 10:59 +0200 schrieb Michael Käppler:
> Am 17.06.2020 um 10:52 schrieb Valentin Villenave:
> > Greetings everyone,
> > I’ve noticed a recent regression with `make doc’: when it reaches
> > Documentation/ly-examples, gs fails on a bunch of files w
Am 17.06.2020 um 10:52 schrieb Valentin Villenave:
Greetings everyone,
I’ve noticed a recent regression with `make doc’: when it reaches
Documentation/ly-examples, gs fails on a bunch of files with the
following error message:
Command: /home/work/lilypond/out/bin/lilypond -dpreview
-dresolution
Greetings everyone,
I’ve noticed a recent regression with `make doc’: when it reaches
Documentation/ly-examples, gs fails on a bunch of files with the
following error message:
Command: /home/work/lilypond/out/bin/lilypond -dpreview
-dresolution=150 -o ./out-www sesto-violin.ly
Changing working
Hello,
While doing some sanity tests this morning building doc (making sure
everything works for me for testing with new infrastructure) I spent
more time looking at the terminal window than I usually do.
During the make doc part where the 'page numbers' all whiz by I noticed
occasionally
On 4/23/20, Federico Bruni wrote:
> I confirm it's a stale dependency file.
> I had the same problem while testing my patch before pushing and IIRC
> removing Documentation/it/out-www/web.texi fixed it.
OK, thanks! I should have thought about doc-clean.
Cheers,
- V.
Il giorno gio 23 apr 2020 alle 16:01, Jonas Hahnfeld via Discussions on
LilyPond development ha scritto:
Am Donnerstag, den 23.04.2020, 13:37 + schrieb Valentin Villenave:
Hey everybody,
For the past few days, I’ve been unable to make doc because of the
following error
Am Donnerstag, den 23.04.2020, 13:37 + schrieb Valentin Villenave:
> Hey everybody,
> For the past few days, I’ve been unable to make doc because of the
> following error:
>
> *** No rule to make target
> '/home/work/lilypond/Documentation/it/web/news-headlines.itexi',
&g
Hey everybody,
For the past few days, I’ve been unable to make doc because of the
following error:
*** No rule to make target
'/home/work/lilypond/Documentation/it/web/news-headlines.itexi',
needed by 'out-www/web.texi'. Stop.
Federico, do you know anything about it?
Cheers,
V.
ve python3 by default since months, so I'm sure.
After I got this error I used a temporary alias to switch python to
python2, just to see if the error disappeared. But it did not.
Anyway, 'make distclean' solved the problem, as usual.
I was reluctant to clean everything because 'make doc' t
Am Samstag, den 11.04.2020, 14:33 +0200 schrieb Federico Bruni:
> Fedora 31. /usr/bin/python points to version 3.7.6.
> I'm running `make doc` in the translation branch and I get this error:
>
> $ make -j3 doc
> GNUmakefile:30: warning: overriding recipe for target 'po-update'
&
Fedora 31. /usr/bin/python points to version 3.7.6.
I'm running `make doc` in the translation branch and I get this error:
$ make -j3 doc
GNUmakefile:30: warning: overriding recipe for target 'po-update'
/home/fede/src/lilypond-translation/stepmake/stepmake/podir-targets.make:14:
warning
On Mon, Feb 24, 2020 at 10:44 PM David Kastrup wrote:
> > The result is 25 minutes of purely CPU bound grinding (this is with
> > Guile 2.2). Then building the remaining docs takes about 15 minutes.
> > In this last phase, there is some inefficiency: we process the
> > documents per language
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> I tried what happens if one concats all texi/tely files together, and
>> runs lp-book on them.
>>
>> The result is 25 minutes of purely CPU bound grinding (this is with
>> Guile 2.2). Then building the remaining docs takes about 15 minutes.
Han-Wen Nienhuys writes:
> I tried what happens if one concats all texi/tely files together, and
> runs lp-book on them.
>
> The result is 25 minutes of purely CPU bound grinding (this is with
> Guile 2.2). Then building the remaining docs takes about 15 minutes.
> In this last phase, there is
I tried what happens if one concats all texi/tely files together, and
runs lp-book on them.
The result is 25 minutes of purely CPU bound grinding (this is with
Guile 2.2). Then building the remaining docs takes about 15 minutes.
In this last phase, there is some inefficiency: we process the
Dan Eble writes:
> On Jan 30, 2020, at 14:57, David Kastrup wrote:
>>
>> os.symlink ("../../../out-baseline/share",
>> "out-www/offline-root/input/regression/out-test-baseline/share")
>>
>> What has the test baseline to do with make d
On Jan 30, 2020, at 14:57, David Kastrup wrote:
>
> os.symlink ("../../../out-baseline/share",
> "out-www/offline-root/input/regression/out-test-baseline/share")
>
> What has the test baseline to do with make doc ?
Try cherry-picking this:
commit dbe42
e out where stuff goes wrong with my
>> system? One thing I could do is check with current master.
>
> How about editing www_post to print the values of p and dest so we can
> see for which file os.symlink is failing?
Oh wow.
os.symlink ("../../../out-baseline/share",
"out-www/offline-root/input/regression/out-test-baseline/share")
What has the test baseline to do with make doc ?
--
David Kastrup
Dan Eble writes:
> On Jan 30, 2020, at 13:39, David Kastrup wrote:
>>
>>> I just had a successful mage -j5 doc as of commit
>>> 8a05312fd8d2a56ec724a793b313949db0cfe729
>>
>> Current stable/2.20 which failed on my system.
>
> I also am not able to reproduce the problem in a clean workspace;
On Jan 30, 2020, at 13:39, David Kastrup wrote:
>
>> I just had a successful mage -j5 doc as of commit
>> 8a05312fd8d2a56ec724a793b313949db0cfe729
>
> Current stable/2.20 which failed on my system.
I also am not able to reproduce the problem in a clean workspace; but I have
verified that I
Jean-Charles Malahieude writes:
> Le 30/01/2020 à 19:46, David Kastrup a écrit :
>> Oops.
>> dak@lola:/usr/local/tmp/lilypond$ git checkout origin
>> error: The following untracked working tree files would be overwritten by
>> checkout:
>>
Le 30/01/2020 à 19:46, David Kastrup a écrit :
Oops.
dak@lola:/usr/local/tmp/lilypond$ git checkout origin
error: The following untracked working tree files would be overwritten by
checkout:
Documentation/snippets/non-traditional.snippet-list
Please move or remove them before you
gt; Compilation of CPU_COUNT=9 make -j9 doc ends with
>>>>>
>>>>> […]
>>>> Thanks. It is sort of annoying that it occurs right at the end of
>>>> the
>>>> (comparatively expensive) doc build, but at least then it is reproduced
>>
;>> […]
>>> Thanks. It is sort of annoying that it occurs right at the end of
>>> the
>>> (comparatively expensive) doc build, but at least then it is reproduced
>>> with another "make doc" within several seconds. So ther
g that it occurs right at the end of
>> the
>> (comparatively expensive) doc build, but at least then it is reproduced
>> with another "make doc" within several seconds. So there may be a way
>> of getting an extensive log just for that final phase of mass-linking
>> the offsit
s sort of annoying that it occurs right at the end of the
(comparatively expensive) doc build, but at least then it is reproduced
with another "make doc" within several seconds. So there may be a way
of getting an extensive log just for that final phase of mass-linking
the offsite-root .
--
David Kastrup
On Jan 30, 2020, at 11:39, David Kastrup wrote:
> That's not a new development, so there is no point in me to refrain from
> cherry-picking further material: the last version of the branch I
> checked was from early December and it failed in the same manner.
> Compilation of CPU_COUNT=9 make -j9
That's not a new development, so there is no point in me to refrain from
cherry-picking further material: the last version of the branch I
checked was from early December and it failed in the same manner.
Compilation of CPU_COUNT=9 make -j9 doc ends with
find ./out-www/web -name '*.html' |
1 - 100 of 672 matches
Mail list logo
