Am 21.12.18 um 09:06 schrieb Urs Liska:
Hi Lukas,
thanks for putting this together. Indeed since installing a distro
that doesn't Guile 1.8 anymore I hadn't been able to compile LilyPond
anymore. Once I managed to compile Guile 1.8 and do a build but for
some reason I lost this option. I think the point was that after
compiling Guile I had to actually change the way LilyPond's make was
handled - which of course isn't sustainable.
I'm also running Linux Mint 19.1, and followed your command list (and
the previous instructions from the CG). Except that I already had some
of the dependencies installed everything worked flawlessly, and I
could run a make to compile LilyPond, register that in Frescobaldi and
compile a .ly file with it. A warning about missing URW fonts was the
only issue I encountered. make doc took the expected ages but worked
without errors too!
So I can confirm that the steps work on Linux Mint 19.
Janek WachoĊ has written a few scripts to help managing multiple
LilyPond builds, which I really appreciated when I had them working.
Basically they provide a configuration layer around the compilation,
then create a local clone of the main code repository and build from
that copy. That makes it possible to have multiple different builds
from different branches (or even states of a branch) in parallel. I
will see if I can integrate that with compiling through a
self-compiled Guile and report back. Maybe these scripts are of use
for others as well.
I have looked again into these scripts and found that they (still) work
well.
The script that I suggest looking into is located at
https://github.com/jan-warchol/cli-tools/blob/master/lilypond/build-lily.sh
However, when it is considered of general use I'll ask Janek to extract
the script from his scripts collection.
In order to use the script two environment variables have to be exported
(presumably from .bashrc):
LILYPOND_GIT=/path/to/lilypond/source/repository
LILYPOND_BUILD_DIR=/path/to/root/of/lilypond-builds
When invoked without arguments the script will clone the source
repository in its current state to the "current" subdirectory of
LILYPOND_BUILD_DIR and build it from there.
Settings to build other branches (or combinations of branches) to other
target directories are described at the beginning of the script.
Does this look interesting to anybody?
Urs
Best
Urs
Am 20.12.18 um 12:21 schrieb Lukas-Fabian Moser:
Folks,
this is mostly to give a reference to those who might hit the same
problems that I had:
I decided to switch from my ancient Linux Mint 17.3 to Linux Mint
19.1 yesterday. In order to set up a working build environment, I had
to provide a working Guile 1.8 which seems not to be in the
repositories any more.
So in addition to following the instructions given in
http://lilypond.org/doc/v2.19/Documentation/contributor/requirements-for-compiling-lilypond#linux-mint
I also followed the most recent one of the various variations of
steps for compiling Guile 1.8 that Federico Bruni gave in October
2017
(http://lilypond.1069038.n5.nabble.com/compiling-lilypond-in-debian-stretch-with-self-compiled-guile-1-8-td206683.html)
git clone https://git.savannah.gnu.org/git/guile.git
cd guile
git checkout branch_release-1-8
./autogen.sh
./configure --disable-error-on-warning --prefix=/usr/local
make
sudo make install
sudo ldconfig
echo "GUILE_CONFIG=/usr/local/bin/guile-config" >> ~/.bashrc
Then, after restarting Bash, I could proceed to
http://lilypond.org/doc/v2.19/Documentation/contributor/configuring-make
and successfully compile current Master.
(On my system, the echo [...] >> ~/.bashrc command added the given
line without any new-line or whitespace, so I had to insert a newline
in an editor.)
Probably these instructions would need some more
testing/polishing/adjusting to other distributions before they could
reasonably be added to the Contributor's Guide, so I just thought it
might be helpful to collect them once more here. (In fact I did run
into a bit of trouble tonight, but this seems to have been because I
wanted to re-use my old lilypond git directory which had been used
for compiling on my old system, so it wasn't really a clean start.
This might also mean my procedure can't be guaranteed to work on a
really fresh Lilypond git folder, but I think they should - I removed
the old build/ folder before the first succesful compile, so there
shouldn't have been any remnants of earlier successful compilations.)
Or would there have been a much easier way to success?
(The upside for me: Now I have the necessary Python/Qt/Lilypond
bindings to also run current Frescobaldi from the git repository
following Urs's excellent instructions on
https://github.com/wbsoft/frescobaldi/wiki/Run-Frescobaldi-3-on-Linux.)
Best
Lukas
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user