Debug webserver

[qdel]

First steps of a debug webserver version.

Note that it is draft because I switched the image from your namespace to mine.

We can discuss here about what we can modify to make it non-draft.

• [ ] linux test
• [ ] windows test

[qdel]

Mainly, the python script was modified to allow serving of the mapped files from the source code of the project. This is needed to have debugging in the browser possible with source maps.

It also allows to serve files from the emsdk toolchain which the debugger could need.

Using python version from the container allows us to avoid different behavior from one PC to another.

By side, the script was using port 80. Only an admin can do this.

[forderud]

Mainly, the python script was modified to allow serving of the mapped files from the source code of the project. This is needed to have debugging in the browser possible with source maps.

Sounds useful. Could it make sense to submit some/all of these changes in a slimmed-down PR that only adds (partial) debugging support to the Python script while still running the webserver host-side?

It also allows to serve files from the emsdk toolchain which the debugger could need. Using python version from the container allows us to avoid different behavior from one PC to another.

Probably useful in some situations, but I would like to first see how far we can get while still running the webserver in the host.

By side, the script was using port 80. Only an admin can do this.

Feel free to submit a PR for changing the port to 8080 or similar.

[qdel]

Mainly, the python script was modified to allow serving of the mapped files from the source code of the project. This is needed to have debugging in the browser possible with source maps.

Sounds useful. Could it make sense to submit some/all of these changes in a slimmed-down PR that only adds (partial) debugging support to the Python script while still running the webserver host-side?

We could have a couple of solutions:

• use symlink to bind source to ../, but on windows, it would be problematic
• disable use of out of source builds
• make the same modifications on the python script, but only on a subset of the locations

It also allows to serve files from the emsdk toolchain which the debugger could need. Using python version from the container allows us to avoid different behavior from one PC to another.

Probably useful in some situations, but I would like to first see how far we can get while still running the webserver in the host.

We can get only "our" source debugging. Which I think is enough.

Moving everything container side disable the possibility to enter in these situations. If we have docker, why use it only for a part of the job ?

By side, the script was using port 80. Only an admin can do this.

Feel free to submit a PR for changing the port to 8080 or similar.

Will do.

From my point of view, it would be more efficient to have only 1 bat or sh file running the container and then having a helper script in the container where we could specify build type or if the container should "serve".

With such, we reduce the adherence on host OS and user configuration, move all to the container, reducing the human error factor.

[forderud]

Moving everything container side disable the possibility to enter in these situations. If we have docker, why use it only for a part of the job ?

I have mixed feelings about Docker myself. It's more tricky to debug processes running inside a container, compared to running directly on the host. The Docker daemon also adds complexity, since it needs to be started in advance and sometimes run out of memory. Still, Docker is still very nice for establishing a versioned and deterministic build environment, which is very useful for Qt-WASM builds. I'm therefore primarily interested in using Docker to get a deterministic build environment, and not so much for other tasks .

[qdel]

Moving everything container side disable the possibility to enter in these situations. If we have docker, why use it only for a part of the job ?

I have mixed feelings about Docker myself. It's more tricky to debug processes running inside a container, compared to running directly on the host. The Docker daemon also adds complexity, since it needs to be started in advance and sometimes run out of memory. Still, Docker is still very nice for establishing a versioned and deterministic build environment, which is very useful for Qt-WASM builds. I'm therefore primarily interested in using Docker to get a deterministic build environment, and not so much for other tasks .

Very good points, I use this a lot so I am tend to use it everywhere applicable. (Podman could be your friend if you do not like the daemon-way but it is linux-oriented).

For wasm, remember that we will not need to debug in the container. It is merely a webserver hosting our files, the debugger is our browser.

Anyway I understand your remarks and will make a push of a stripped down version to have minimal debugging support, I still believe this will be enough.