Re: Fatal error compiling large project (Win10/2.19.82)

[Aaron Hill]

On 2018-12-19 3:43 am, Urs Liska wrote:
> Am 19. Dezember 2018 11:53:26 MEZ schrieb Aaron Hill 
> <address@hidden>:
> > But if Frescobaldi needs to have a path to the LilyPond installation,
> > then it can never be made to work with WSL.  There is no* path to the
> > WSL file system that a Windows program can access.  Instead, it is the
> > Windows file system that is mounted so that Linux programs can
> > read/write to it from the WSL environment.  This is the only supported
> > method for data transfer.
>
> How does one launch Linux programs then? Is that some specific "WSL
> Shell" that you start and then have a bash or something? And this does
> mean theWSL can only be used to do stuff on the Linux command line, no
> way to use Linux commands triggered from Windows applications?

The Windows program "wsl.exe" is the interop program that ties things 
together.  You can call it and pass it a command to be executed within 
the WSL environment.

So, while I can simply say "lilypond" in a WSL shell, under a Windows 
shell I need to say "wsl lilypond" to have the same effect.  Note then 
that I am technically running "wsl.exe", not "lilypond"; but "lilypond" 
will end up a child process of "wsl.exe" with standard input/output 
properly routed.

(Related to this, you can run any Windows binary from a WSL shell 
directly without needing any interop program.  So "wsl.exe" is just for 
executing Linux binaries from Windows.)

> Is there something like a $PATH to look for Linux commands? Then it
> might be possible to create an invocation from Frescobaldi. I wasn't
> clear about it: the default in Frescobaldi is to simply call
> "lilypond" if no specific path is given, and we can of course do
> anything that can be done in the given set-up.

Running "wsl echo $PATH" should return that value from the WSL 
environment.  Be aware that WSL will automatically forward the current 
Windows environment path to the Linux environment, so that "wsl echo 
$PATH" will include entries from the Windows side of life.  These are 
appropriately converted from the Windows path format to something that 
is valid in WSL:

    D:\path\to\folder -> /mnt/d/path/to/folder

In theory, all we should need is for Frescobaldi to spawn a process like 
this:

    wsl.exe /path/to/lilypond file.ly

(Of course, /path/to/lilypond is only needed if it is not already in the 
path.  For instance, I installed LilyPond globally using sudo so it 
created entries in /usr/local/bin for me.)

One challenge, though, is that Frescobaldi will invariably pass as 
arguments paths to files that are in Windows format, since it is after 
all running on Windows.  These paths will need to be converted.  
"wslpath" is a command in the WSL environment for this exact purpose.

I never hit this issue in my own use as I only ever run…

    wsl lilypond file.ly

…for a file in the current directory.  But I could not, for instance, 
say…

    wsl lilypond "D:\path\to\file.ly"

…which would be rejected by Linux lilypond as an invalid path.  I could, 
however, say…

    wsl lilypond `wslpath "D:\path\to\file.ly"`

…which is rather wordy, but would get the job done.  For Frescobaldi, 
however, we'd would likely need an intermediate script that translates 
file paths.  But this is probably non-trivial, as there are a few cases 
where paths could show up and need conversion (e.g. 
"-dinclude-settings=" would need to be handled).

(Side note: I mainly use Bash on Windows, which follows the "proper" way 
to work with paths.  This helps greatly, as it means I can do relative 
paths on Windows and have the slashes pointing the right direction 
automatically.  I had tried using PowerShell for a long time but gave up 
after continually fighting issues like pathing, ultimately determining 
that PS is not intended to be an interactive shell.  Great for 
scripting, but that's about it.)

To Michael's point about running Linux in a VM, I would also agree that 
it is more likely the sensible option if you are going to go as far as 
set up a desktop environment and try to get Frescobaldi running in WSL.  
Aside from the fact that it is not really an intended use case for WSL, 
virtualization makes some things much easier.

And to reply to Saul: I would probably look at WSL LilyPond as a CLI 
approach only.  Think of it as the final build tool.  While iterating on 
your score, continue to use Frescobaldi on Windows with the Windows 
build of LilyPond.  Despite the 32-bit constraint, hopefully no single 
part of a score is so big as to run out of memory.  And then when you 
need to do the complete build, that is when you'd shell out to WSL and 
let 64-bit Linux LilyPond do the work.  With this strategy, it is no 
longer important that Frescobaldi be able to directly work with WSL.


-- Aaron Hill