Dev Containers for faster setup

[carsakiller]

Hey @sumneko,

I have been looking at getting a dev container set up for the language server. It should allow anyone to get set up for development quick and easy, as the container would come with all the build tools and dependencies.

So far, I have been able to get a Ubuntu container running that installs build-essentials (gcc, g++, make) as well as ninja. I can then build the language server and run it in the container 🎉.

The goal is that I can build the server in the container, and, because its filesystem is mounted to my local OS, I can then use misc.executablePath to use the new binary as my language server in the VS Code client. However, my local OS is Windows 11, meaning I cannot run the built binary on my machine.

Is it possible to cross-compile the language server on Ubuntu for Windows? I noticed the GitHub action builds the Windows binary on Windows, so I would assume no? I have basically no experience with C++ and so I am pretty lost, especially when it comes to luamake compiling the code – I'm surprised I made it this far 😄.

So far I have tried running 3rd/luamake/luamake -platform win32-x64, which responds with unknown platform. So I think I need to add a case to the detect_platform.lua if statement for win32-x64 that specifies the lm.cc to be a compiler that can compile for Windows... but again I have pretty much no idea what I am talking about. Your guidance would be greatly appreciated 🙂.

[sumneko]

@actboy168 help me doraemon!

[carsakiller]

I just found that you added the --socket CLI command 😲. The port can be forwarded so that instead the client can communicate with the server in the container on the socket. However, I am encountering an error:

$ ./bin/lua-language-server --socket=5050

/workspaces/lua-language-server/script/brave/work.lua:65: socket closed!
stack traceback:
        [C]: in function 'error'
        /workspaces/lua-language-server/script/brave/work.lua:65: in function </workspaces/lua-language-server/script/brave/work.lua:16>
        [C]: in function 'xpcall'
        /workspaces/lua-language-server/script/brave/brave.lua:57: in function 'brave.brave.start'
        /workspaces/lua-language-server/script/brave/brave.lua:23: in function 'brave.brave.register'
        [string "package.path  = "/workspaces/lua-language-ser..."]:13: in main chunk
        [C]: in ?

[actboy168]

Unlike Linux/macos, Windows has very strong binary compatibility. You can directly use the compiled binary without compiling it yourself.

[actboy168]

For Windows users, there is no need to compile, just download the binary compiled by Github Action.

[carsakiller]

This is for developers wanting to modify the language server, built it, and test it. The GitHub action artifacts contain the latest changes made to master. The dev container is so users can modify the source code, build it locally in the container, and test it with their client on their OS (the one hosting Docker and the dev container).

flowchart LR

    subgraph "Local OS (Windows 11)"
        direction LR

        subgraph fs[Filesystem]
            direction TB

            source[(LLS Source Code)]
            binary{{"Binary (exe)"}}
        end

        subgraph docker ["Docker Container (Ubuntu)"]
            direction TB
            dep["Dependencies (Ninja, g++, etc.)"]

            subgraph mount[Mounted Filesystem]
                direction TB

                mount_source[(LLS Source Code)]
                mount_binary{{"Binary (exe)"}}
            end
        end

        subgraph vsc[Visual Studio Code]
            direction LR
            vsc-lua["vscode-lua (Client)"]
        end

        dep <-- Build --> mount_binary
        mount <-- "Mounted Volume (mirror)" --> fs
        source ~~~ mount_source
        binary ~~~ mount_binary
        binary <-. Launch Server .-> vsc-lua
    end

Loading

[carsakiller]

The other option is to run the binary in the container and communciate using a socket:

flowchart LR

    subgraph "Local OS (Windows 11)"
        direction LR

        subgraph fs[Filesystem]
            direction LR

            source[(LLS Source Code)]
            binary{{"Binary (Linux)"}}
        end

        subgraph vsc[Visual Studio Code]
            direction LR

            vsc-lua["vscode-lua (Client)"]
        end

        subgraph docker ["Docker Container (Ubuntu)"]
            direction LR

            subgraph mount[Mounted Filesystem]
                direction LR

                mount_source[(LLS Source Code)]
                mount_binary{{"Binary (Linux)"}}
            end

            dep["Dependencies (Ninja, g++, etc.)"] -- Build --> mount_binary
        end

        mount <-- "Mounted Volume (mirror)" --> fs
        mount_binary <-. Communicate through socket .-> vsc-lua
    end

Loading

[actboy168]

In Windows, I don't know anyone who needs to modify the source code of the luals binary and need to cross compile it. In fact compiling on windows is very simple. If he can't even compile, I don't think he has the ability to modify the source.

I think what should be more concerned about is how a novice using luals on Linux can obtain the binary of luals.

[carsakiller]

The primary goal is to have a standard development environment that can be used by someone on Windows, Linux, or MacOS due to it being in a container. The developer then only needs docker to have the same exact development setup as everyone else. The user needs to somehow build and test the language server. Doing it in the container makes the most sense as it removes the need for the user to install anything on their OS or mess with OS-specific requirements.

I would prefer it then simply build in the container on Linux and communicate using a socket to the client on the local OS, however, that does not seem to work and cross-compiling is theoretically another option.