The situation on Windows without lilypond-windows.exe is even worse than I thought - the option -dlog-file no longer generates the log file into the prescribed place - instead the log is splashed onto the terminal box (which then vanishes when the typesetting is finished). It means no error reporting to the unlucky Windows users of Denemo.
Please can we have lilypond-windows.exe back? It is indeed as far as I know just an extra target in the makefile with -mconsole in it, and given the size of a LilyPond installation not a enormous burden on the windows users disk space. Richard Shann On Mon, 2023-04-03 at 10:54 -0700, Aaron Hill wrote: > On 2023-04-03 10:31 am, Jean Abou Samra wrote: > > > Le 3 avr. 2023 à 12:21, Richard Shann <rich...@rshann.plus.com> a > > > écrit : > > > > > > Is there any chance the developers might re-instate the > > > lilypond-windows.exe? > > > > Maybe. Is it as easy as compiling with -mconsole ? Does that have > > other > > effects to take care of? Is there a use case where the current mode > > is > > important or could we just switch to the other mode? > > LilyPond would still need to be able to be run purely from the > terminal, > so the main target should continue to use the console subsystem. > This > importantly covers the scenarios of scripting and automation where > you > need standard I/O to be mapped properly. > > The use case for a third-party GUI application running LilyPond > behind-the-scenes is where the "windows" subsystem could be useful, > providing the application is unable to spawn the child process in a > hidden manner. > > This goes to my question of which application has the real problem. > Denemo relied on LilyPond providing two entrypoints, so it was not > really at fault. But Denemo probably should have been spawning the > worker process hidden to begin with, thus never relying on > lilypond-windows.exe in the first place. However, that would require > working around glib to use the Win32 API directly (and adding > platform-specific development overhead), or by getting the glib > developers to expose the underlying process creation flag. But for > all > I know, it might be out-of-scope for glib to support this scenario, > thus > pushing the work back to Denemo. > > It should be noted that this dual subsystem approach is very common > on > Windows. Take the Windows scripting host itself. It comes in two > flavors: wscript.exe and cscript.exe. The first is for use without > an > attached terminal, and the second is meant to be run from the > command-line. Java likewise has always shipped with two frontends: > java.exe and javaw.exe. So, LilyPond would not be doing anything > unusual by shipping two executables. > > > -- Aaron Hill
