Let me address the points about GUB: Am Dienstag, den 20.10.2020, 11:03 +0200 schrieb Jean Abou Samra: > > > - rely only on C++, flex, bison and the extension language. > > > Eliminating the need for GUB and Python would greatly simplify > > > porting LilyPond to various environments, including web sites, > > > phones and tablets.
I don't see how eliminating GUB simplifies porting to "various environments". As others have said, it's only used to produce the official binaries distributed for user convenience. This process is complex and needs some form of automation, which is the reason why GUB was created. Now even if moving to something else, it will still only support a limited set of targets. > > GUB will be history soon, thanks to the work mainly of Jonas. Your mileage may vary, but I don't see this happening "soon", as in the next few months. Right now it's more of a proof-of-concept that native binaries for a number of architectures could be produced with a set of generic scripts. > Is this true, Jonas? I've heard of scripts you wanted to replace > GUB with, but the last time I read about them, Han-Wen was skeptical > of this idea because GUB had precisely been created to replace the > scripts that were used before and were a nightmare to maintain. I don't want to digress into this topic right now (P.S. the reply got longer than I initially anticipated), but the scripts have a much narrower focus: they mostly compile native binaries (except for Windows via mingw) instead of cross-compiling for all targets. In my experience from helping with GUB in the past year, that's the main source of complexity for usage and maintenance. Moreover, this choice also outright prevents 64-bit executables for macOS because of Apple's restrictions with regard to their toolchain. I'm open to reconsider the choice of sh-scripts, but GUB aims at doing just too much (a package manager for building arbitrary packages for various targets; where we only do LilyPond to a handful) by using a too powerful language and architecture (Python 2 with dynamic dependency resolution and generic interfaces to various build systems). I think we should learn from that and choose a design that avoids the pitfalls. But again, that's nothing I'm expecting to happen "soon". Also because an eventual transition to Guile 2 plays an important role here: I don't want to plug that into GUB, but Guile 1.x is fundamentally incompatible with 64-bit binaries for Windows. Closing words: In general, a replacement for GUB is not something to be discussed in length on -user. This must happen in a proper thread on the -devel list, and hopefully with more technical content than just the statement of "we need something better". Jonas
signature.asc
Description: This is a digitally signed message part
