Am 23.11.18 um 00:08 schrieb Janek Warchoł:
czw., 22 lis 2018 o 00:21 Werner LEMBERG <w...@gnu.org
<mailto:w...@gnu.org>> napisał(a):
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.
Yeah, we're working on that. :)
czw., 22 lis 2018 o 00:29 Urs Liska <li...@openlilylib.org
<mailto:li...@openlilylib.org>> napisał(a):
Janek has created a set of very useful scripts.
Whoah, I almost forgot them :p
So, you're still using them?
Unfortunately not. I really used them because it's so convenient to
maintain multiple builds from different branches or commits. However,
since Guile 1.8 isn't available anymore on my systems I haven't managed
to set up a build environment anymore ...
Maybe this would be the
opportunity to adapt them so they can also be used on systems with
custom-compiled Guile 1.8.8?
Interesting, AFAIR they're just bash scripts. Is there anything to adapt?
Yes, they are just bash scripts. And probably it's trivial to change
them but still I found them pretty confusing and didn't manage to track
it down. Essentially because your scripts made it unnecessary for me to
actually learn about the invocations.
The problem is that on (most modern Linux) systems it is necessary to
use a self-compiled version of Guile (if you're not actively
investigating support for Guile 2), and that of course it's necessary to
adjust the compilation commands.
I think it would be worth updating these scripts, at least the
build-lilypond one (I never used the script to pull in all the
dependencies because I think it makes too many assumptions. Instead it's
rather easy to do that by hand). Maybe it would be a good idea to
somehow make them available in the general LilyPond developer's toolkit?
For others to comment on the latter suggestion: Janek's build script
provides an interface where you don't build LilyPond from the actual
repository. Instead it makes a lot of sanity checks (providing some
configuration), then clones the development repository to another
directory and starts the build from there. Of course this uses
significant disk space but you have a convenient and clean interface to
manage multiple builds in parallel (you then can register them as
independent LilyPond versions in Frescobaldi, for example).
Urs
Janek
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
