Re: Old build environments
Am 17.10.2020 um 10:08 schrieb Jonas Hahnfeld: Am Freitag, den 16.10.2020, 14:30 -0600 schrieb Carl Sorensen: On Fri, Oct 16, 2020 at 1:02 PM Michael Käppler wrote: Hi all, a few days ago I wanted to try how some functionality in LilyPond worked, when it was added long time ago. (about 15 years ago, around 2.7.x or 2.8.x) Not very surprisingly I could not even get the code to compile with my current build setup. That made we wonder if it would be a good idea to store a build environment that is proven to work with the code base every, say, minor version bump. I actually think that is the motivation for GUB. You could checkout the GUB repository for the appropriate date, and the LilyPond code should build under GUB. It might help, but keep in mind that all "packages" in tools:: must be built by the system compiler. Running Arch Linux, I've had problems with that far too often so you might hit similar issues with versions of GUB from that time. And the version range sounds like the very beginning of GUB... Sorry for the late reply. Speaking from my experience, building GUB is very time-consuming and error-prone. My intention was to propose that we store a representation (Docker, qemu-Image, whatever) of a build environment proven to work for every minor version. Maybe it is not worth the effort, I'm interested to hear what you think. Cheers, Michael
Re: Old build environments
Am Freitag, den 16.10.2020, 14:30 -0600 schrieb Carl Sorensen: > On Fri, Oct 16, 2020 at 1:02 PM Michael Käppler wrote: > > Hi all, > > a few days ago I wanted to try how some functionality in LilyPond > > worked, when it was added long > > time ago. (about 15 years ago, around 2.7.x or 2.8.x) > > Not very surprisingly I could not even get the code to compile with my > > current build setup. > > > > That made we wonder if it would be a good idea to store a build > > environment that is proven to work > > with the code base every, say, minor version bump. > > > > I actually think that is the motivation for GUB. You could checkout the > GUB repository for the appropriate date, and the LilyPond code should build > under GUB. It might help, but keep in mind that all "packages" in tools:: must be built by the system compiler. Running Arch Linux, I've had problems with that far too often so you might hit similar issues with versions of GUB from that time. And the version range sounds like the very beginning of GUB... Instead, how about using the oldest available binary release (2.8.8)? Jonas signature.asc Description: This is a digitally signed message part
Re: Old build environments
On Fri, Oct 16, 2020 at 1:02 PM Michael Käppler wrote: > Hi all, > a few days ago I wanted to try how some functionality in LilyPond > worked, when it was added long > time ago. (about 15 years ago, around 2.7.x or 2.8.x) > Not very surprisingly I could not even get the code to compile with my > current build setup. > > That made we wonder if it would be a good idea to store a build > environment that is proven to work > with the code base every, say, minor version bump. > I actually think that is the motivation for GUB. You could checkout the GUB repository for the appropriate date, and the LilyPond code should build under GUB. Have you tried that? Carl > >
Old build environments
Hi all, a few days ago I wanted to try how some functionality in LilyPond worked, when it was added long time ago. (about 15 years ago, around 2.7.x or 2.8.x) Not very surprisingly I could not even get the code to compile with my current build setup. That made we wonder if it would be a good idea to store a build environment that is proven to work with the code base every, say, minor version bump. This could be a container (Docker? QEMU?) or an ISO image that can be run inside a VM. If the container formats are changing as quickly as the build environments, this does not make sense, however. But surely there are concepts out there for long-term archivation (or better, long-term reproducibility) of software. What do you think? Michael
