[VS6] add Dockerfile and docker-compose to build the code

[PiecePaperCode]

Added two dockerfiles

Dockerfile & docker-compose.yml

With this two files you can locally build your copy of the source code. The binarys are dropped down on your build directory ./build/docker

No dependency needed to be installed on the development machine only docker

[tintinhamans]

I don't know how I feel about having a dependency on master branch of a repo outside of our control.

[PiecePaperCode]

can we inhouse vs6 in TheSuperHackers as a repo. Otherwise you need to hund it from an outside repo.
itsmattkc is a youtuber i follow an wich i trust to not have tempered with the distribution of vs6. Maby a trusted member can source the vs6 files and provide them in a repo.

[xezon]

No idea about the nature of VS6 redistributability. @OmniBlade @Generalcamo thoughts?

Locally I am using the VS6 SP6 package that OmniBlade has put together.

[tintinhamans]

No idea about the nature of VS6 redistributability. @OmniBlade @Generalcamo thoughts?

Locally I am using the VS6 SP6 package that OmniBlade has put together.

Perhaps we can think about making this a mandatory mount that the user provides, that way it is not redistributed inside of the image.

[Generalcamo]

Agreed with @tintinhamans, I am uncomfortable with distributing this.

[NoToComments]

Then there should be at least a link to this file with an disclaimer.
Otherwise it becomes an tedious task

[PiecePaperCode]

I have optimized the image.
The current size is now 2.8G. From 5G
The biggest culprit for the size is wine.
I generate the wineprefix on the fly.
This ads another 2G to the runtime instead inside the image

[tintinhamans]

Actually, why not expand on this entire idea and implement devcontainers?

They are supported in many IDEs: VS, VSCode and more.

[PiecePaperCode]

Actually, why not expand on this entire idea and implement devcontainers?

They are supported in many IDEs: VS, VSCode and more.

Yeah dev containers are a interesting approach but for this PR its out of scope.
Devcontainers should be in its own PR or/and a new issue.

[edbird]

My question would be why do you want to do this. Expressed another way, what is the advantage, or even purpose of, creating a temporary self-contained environment to build an executable, to then not run that executable in the same environment.

I am somewhat a Docker advocate myself, but in this context, it doesn't seem to make much sense. Typically, if you want to build an application inside a Docker container, this is becuase you want to run the application inside the same environment.

A Docker container is simply a way of reproducing the same environment across multiple physical or virtual machines. In other words, it abstracts away the complexities (configuration) of an environment, because a container image gives you not just an application to run, but also a preconfigured environment in which to run it.

Sorry for labouring the point somewhat, I'm sure many reading this will already know these things.

Let me know your thoughts.

[PiecePaperCode]

My question would be why do you want to do this. Expressed another way, what is the advantage, or even purpose of, creating a temporary self-contained environment to build an executable, to then not run that executable in the same environment.

I am somewhat a Docker advocate myself, but in this context, it doesn't seem to make much sense. Typically, if you want to build an application inside a Docker container, this is becuase you want to run the application inside the same environment.

A Docker container is simply a way of reproducing the same environment across multiple physical or virtual machines. In other words, it abstracts away the complexities (configuration) of an environment, because a container image gives you not just an application to run, but also a preconfigured environment in which to run it.

Sorry for labouring the point somewhat, I'm sure many reading this will already know these things.

Let me know your thoughts.

Its a valid point. This file is for people who just want to get started building the code without installing VC6 or VC2019 and hunting all the deps needed or setting the correct build environments vars. Its kinda a executable manual. Dev containers are an alternative but in my case out of scope for this PR. If somebody want to convert it to a dev container and use this PR as a reference i would be pleased.

Otherwise i have gone further and set up a Gpu docker environment that would run the game and you cold connect via web browser to see the game rendered wich would make it more a complete example.

[mirogajdos]

Typically, if you want to build an application inside a Docker container, this is becuase you want to run the application inside the same environment.

This is false. You typically want to standardize build env and run final app wherever you need to as your customer would have. If we don't include deployment of web services majority of use cases for docker in development is to streamline dev env setup. It's much easier to say to newcomer to install docker and run some docker compose instead of N long getting started list which can result in many inconsistencies based on your machine state.

[OmniBlade]

While I'm all for using containers to create standardised build environments, I'm not sold on the containers run command being to run the build as that gives little scope to customise the build that is run. I'd rather it gave me a prompt to run the configure myself and perhaps included wrapper scripts that encapsulated the wine commands or included a toolchain file with the appropriate wine wrapped commands.

[OmniBlade]

This won't work as it is here, you need to run the cleanup as part of the other RUN commands that perform apt operations. The results of previous run operations become baked into the image as read only layers.

[OmniBlade]

Again this needs to be part of the previous runs (one for each that downloads a zip) if the idea is to save space in the image as the result of the previous run become read only.

[NoToComments]

@OmniBlade To adress your concerns regarding the run command.

You could easily use
docker exec run -it /bin/bash

to step into the container if you should need different builds.

Therefore it should be changed to this:

 ENTRYPOINT ["/bin/sh", "-c"]  
CMD ["wineboot && wine /build/tools/cmake/bin/cmake.exe ..."]

[NoToComments]

The Cmake Configuration could be also loaded from an CMakePresets.json
https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html

Here is an example:

{
  "version": 3,
  "cmakeMinimumRequired": {
    "major": 3,
    "minor": 19,
    "patch": 0
  },
  "configurePresets": [
    {
      "name": "vc6",
      "hidden": false,
      "generator": "NMake Makefiles",
      "cacheVariables": {
        "CMAKE_SYSTEM_NAME": "Windows",
        "CMAKE_C_COMPILER": "Z:/build/tools/vs6/vc98/bin/cl.exe"
      }
    }
  ]
}

[Mauller]

Was there more work to be done on this still?

[OmniBlade]

I think you misunderstood what I was suggesting, as it stands the container is started and just does everything automatically which I would have preferred a shell in the container which you did address in your comments. The other comments are more technical related to how the different layers of the image are baked and are probably more important to address as they should help optimise it further.

[kriegster108]

My question would be why do you want to do this. Expressed another way, what is the advantage, or even purpose of, creating a temporary self-contained environment to build an executable, to then not run that executable in the same environment.

I am somewhat a Docker advocate myself, but in this context, it doesn't seem to make much sense. Typically, if you want to build an application inside a Docker container, this is becuase you want to run the application inside the same environment.

A Docker container is simply a way of reproducing the same environment across multiple physical or virtual machines. In other words, it abstracts away the complexities (configuration) of an environment, because a container image gives you not just an application to run, but also a preconfigured environment in which to run it.

Sorry for labouring the point somewhat, I'm sure many reading this will already know these things.

Let me know your thoughts.

It is totally normal practice to make containers using docker to JUST build your application. Most CI/CD pipelines use build containers to easily setup build environment w/dependencies pre-installed to build and publish build artifacts automatically.

This simplifies anyone needing to get the entire C&C dependency chain installed onto their local machine in order to build.. I dont understand the pushback on this PR.

I understand people need to get local environment setup in order to contribute which makes total sense, but people like me who just want a quick and simple solution to clone -> build -> test out the latest commit on main this would be helpful.

+1

[xezon]

So what is left to do to get this done?

[edbird]

My question would be why do you want to do this. Expressed another way, what is the advantage, or even purpose of, creating a temporary self-contained environment to build an executable, to then not run that executable in the same environment.
I am somewhat a Docker advocate myself, but in this context, it doesn't seem to make much sense. Typically, if you want to build an application inside a Docker container, this is becuase you want to run the application inside the same environment.
A Docker container is simply a way of reproducing the same environment across multiple physical or virtual machines. In other words, it abstracts away the complexities (configuration) of an environment, because a container image gives you not just an application to run, but also a preconfigured environment in which to run it.
Sorry for labouring the point somewhat, I'm sure many reading this will already know these things.
Let me know your thoughts.

It is totally normal practice to make containers using docker to JUST build your application. Most CI/CD pipelines use build containers to easily setup build environment w/dependencies pre-installed to build and publish build artifacts automatically.

This simplifies anyone needing to get the entire C&C dependency chain installed onto their local machine in order to build.. I dont understand the pushback on this PR.

I understand people need to get local environment setup in order to contribute which makes total sense, but people like me who just want a quick and simple solution to clone -> build -> test out the latest commit on main this would be helpful.

+1

Yes, but why?

How are you going to run your code? Possibly I misunderstand what you intend to do here. It might be useful to run a set of unit tests in a Docker container. Other than that I don't see any benefit or use case.

[mirogajdos]

The point why: As non C++ dev I don't want to bloat my PC with otherwise useless stuff. Just have docker, come to any commit, branch. Run the command and get the working .exe out.

[xezon]

Can it perhaps do both things? One mode where the docker just build the EXE and another mode where it builds the EXE and can also run it?

[Mauller]

The point why: As non C++ dev I don't want to bloat my PC with otherwise useless stuff. Just have docker, come to any commit, branch. Run the command and get the working .exe out.

The CI already produces build artifacts for every PR in the repo and will soon have weekly releases implemented once the PR for that is finalised.

[mirogajdos]

The pushback is incredible. Still don't get how one contradicts other. It's still also benefits beginner developers or non C++ devs like me who wants to just experiment with small changes and get the working .exe out of it with minimal effort without struggling with complicated dev setup.

[mirogajdos]

Can it perhaps do both things? One mode where the docker just build the EXE and another mode where it builds the EXE and can also run it?

I think you can do that but I would personally create some Base image which can do builds and then create other dockerfiles which are based on build image and can run .exe and do various stuff like run tests and such

[xezon]

I never used Docker. No push back from my side. But I do not know how to review this because this is not my field of expertise. We do not necessarily need to wait for PiecePaperCode to address the remaining review comments, but can have anyone else create a new revision for it too.

[Mauller]

The pushback is incredible. Still don't get how one contradicts other. It's still also benefits beginner developers or non C++ devs like me who wants to just experiment with small changes and get the working .exe out of it with minimal effort without struggling with complicated dev setup.

I don't think you got the point, i was responding to the use case you were making, which is redundant when the CI already produces artifacts.

I'm not against also having a docker setup if it can work for what people need it to do. But the point you initially made was already an invalid use of a docker container since we already have artifacts.

[mirogajdos]

I never used Docker. No push back from my side. But I do not know how to review this because this is not my field of expertise. We do not necessarily need to wait for PiecePaperCode to address the remaining review comments, but can have anyone else create a new revision for it too.

I didn't mean you personally. Actually it seems you're only one open about it 👍 I'm experienced with docker but in this case I cannot review or work on the actual content as I'm not familiar with complex C++ builds. (That's also why I need it) What matters is that I have working .exe when I run it.

What Omniblade requires is definitely doable and meant to replace dev envs for you experienced C++ devs so you can configure it really granularly. But I don't think that at this point of time you actually need it as you have your dev setups up and running. To create really granular docker dev env I think it would require much more work and is out of scope of this MR. This is just base to get .exe quickly with one command and zero deps. (other than docker)

[edbird]

The pushback is incredible.

Not pushing back against it either. Just wanted to understand what is the end goal here. As someone who uses Docker on a daily basis, I just didn't understand the intention of it here. Fine, someone wants to avoid cluttering their environment. Yes, that is an advantage. But if you can't run the game, how will you test your changes?

benefits beginner developers or non C++ devs like me who wants to just experiment with small changes

To be completely honest, this is not a good project for someone to contribute to unless that person already has considerable experience. (At least on the C++ software side.)

I'm not trying to exclude anyone from contributing. This is just reality. I have quite considerable experience with C++ but I know my limitations. I know very little about graphics, for example. I know where I can be useful, which is in converting old C++ code to newer standards, and contributing to core libraries. However I am also aware of how difficult this is likely to be. It's not a good project for someone to use to learn C++, or for someone who is learning to code.

That said, obviously go ahead to try if you are interested. But be aware, those of us who do this professionally have very little time on our hands to contribute to projects like this already.

Me personally? So busy I haven't yet had time to start reading the code. Sorry for my lack of contribution. I commented on this thread because I thought I may have some useful experience on this point about Docker specifically.

[mirogajdos]

Experimenting with the source code of your favorite childhood game and seeing the actual changes in the game locally with minimal setup is far from contributing. But it may actually inspire someone to get better and contribute in the future. But currently to see any your change in the game locally is not very accessible.

[edbird]

But currently to see any your change in the game locally is not very accessible.

I agree with you. However, this is a build config/Visual Studio tooling issue. It may have improved since I last tried to build the code, but from your comment it sounds like perhaps it hasn't.

Ideally there should be a way to build everything using GCC/clang, cmake and VS Code. At least, this is my personal preference, but I know many other people will also share this preference.

I think some people are currently working on it.

[OmniBlade]

The point why: As non C++ dev I don't want to bloat my PC with otherwise useless stuff. Just have docker, come to any commit, branch. Run the command and get the working .exe out.

On a windows PC you need to install WSL2 and Docker... is that not bloating your PC. For none windows platforms having the build environments in a container for other platforms makes more sense for cross compilation but you still need to be able to test so you'd still need a windows machine to do any real development.

[OmniBlade]

But currently to see any your change in the game locally is not very accessible.

I agree with you. However, this is a build config/Visual Studio tooling issue. It may have improved since I last tried to build the code, but from your comment it sounds like perhaps it hasn't.

Ideally there should be a way to build everything using GCC/clang, cmake and VS Code. At least, this is my personal preference, but I know many other people will also share this preference.

I think some people are currently working on it.

I don't mind building with cl.exe on windows, but I think aiming for an IDE agnostic setup using CMake which I try and push for is the best place to aim for long term.

[mirogajdos]

The point why: As non C++ dev I don't want to bloat my PC with otherwise useless stuff. Just have docker, come to any commit, branch. Run the command and get the working .exe out.

On a windows PC you need to install WSL2 and Docker... is that not bloating your PC. For none windows platforms having the build environments in a container for other platforms makes more sense for cross compilation but you still need to be able to test so you'd still need a windows machine to do any real development.

WSL2 and Docker are much more common dependencies which many developers from other areas already have. Even non developer power users tend to have it installed for selfhosting various services. Again unreasonable pushback.

[OmniBlade]

The point why: As non C++ dev I don't want to bloat my PC with otherwise useless stuff. Just have docker, come to any commit, branch. Run the command and get the working .exe out.

On a windows PC you need to install WSL2 and Docker... is that not bloating your PC. For none windows platforms having the build environments in a container for other platforms makes more sense for cross compilation but you still need to be able to test so you'd still need a windows machine to do any real development.

WSL2 and Docker are much more common dependencies which many developer from other areas already have. Even non developer power users tend to have it installed for selfhosting various services. Again unreasonable pushback.

I would note that my review is largely on technical matters and I don't object to having the docker image on principal, but the argument that dev tools bloat a machine, but that other dev tools that bloat a machine don't count as bloat is a spurious argument in my opinion.

If you are using a machine for dev you have dev tools installed and it gets messy. The tools we use for VC6 even have portable installs that you can just stick in a directory and delete when you are done. The arguments for Docker IMO are cross platform development and CI streamlining.

[mirogajdos]

The point why: As non C++ dev I don't want to bloat my PC with otherwise useless stuff. Just have docker, come to any commit, branch. Run the command and get the working .exe out.

On a windows PC you need to install WSL2 and Docker... is that not bloating your PC. For none windows platforms having the build environments in a container for other platforms makes more sense for cross compilation but you still need to be able to test so you'd still need a windows machine to do any real development.

WSL2 and Docker are much more common dependencies which many developer from other areas already have. Even non developer power users tend to have it installed for selfhosting various services. Again unreasonable pushback.

I would note that my review is largely on technical matters and I don't object to having the docker image on principal, but the argument that dev tools bloat a machine, but that other dev tools that bloat a machine don't count as bloat is a spurious argument in my opinion.

If you are using a machine for dev you have dev tools installed and it gets messy. The tools we use for VC6 even have portable installs that you can just stick in a directory and delete when you are done. The arguments for Docker IMO are cross platform development and CI streamlining.

Having one very generic tool as Docker, which is widely used for many many other use cases and running one command to get build out is very very different to try to download and manage any tooling even if portable manually. You just don't want to understand it.

[tintinhamans]

But currently to see any your change in the game locally is not very accessible.

Almost every commit already generates artifacts in GitHub CI which you can then download and test locally.

[mirogajdos]

Usecase: As developer from other area or novice I want to start experimenting with the game code:

1, I have docker and copy of the game installed
2, I clone repo
3, I make change in text editor
4, I run one command and have working .exe

I don't know why you just don't want to provide this accessibility feature for other potentional users.

[OmniBlade]

Usecase: As developer from other area or novice I want to start experimenting with the game code:

1, I have docker and copy of the game installed 2, I clone repo 3, I make change in text editor 4, I run one command and have working .exe

I don't know why you just don't want to provide this accessibility feature for other potentional users.

The venn diagram of people with docker installed who couldn't just install cmake and the portable VC6 (or install C++ tools in modern Visual Studio) but want to mess around building a local copy for the lulz is probably so tiny as to not really be worth the investment of time to support. While I agree it is a potential valid use case for Docker support, of the Docker use cases its the smallest one.

To put it another way, I don't think we have appetite to officially support that as a build process.

If you are just messing about locally you don't even need VC6 which is what this PR is to support, you can build and play with modern MSVC. Use https://github.com/mstorsjo/msvc-wine if you want to build it from a container.

[edbird]

Usecase: As developer from other area or novice I want to start experimenting with the game code:

1, I have docker and copy of the game installed 2, I clone repo 3, I make change in text editor 4, I run one command and have working .exe

I don't know why you just don't want to provide this accessibility feature for other potentional users.

I keep getting emails about this thread.

Can I try to provide some rational solution to it:

I have no objections to this workflow although it is a slightly unusual use of docker (you are creating a container aka environment to compile something but then you do not run what you have compiled in the SAME environment, which is a bit odd although it MAY work, but also might not...)

If/when the code can be built using just cmake + a compiler (gcc/clang) it should be fairly straightforward to put that cmake stuff into a container and get it working.

But I think that someone who wants this workflow has to be the one to do it, otherwise it just won't get done.

[mirogajdos]

The venn diagram of people with docker installed who couldn't just install cmake and the portable VC6 (or install C++ tools in modern Visual Studio) but want to mess around building a local copy for the lulz is probably so tiny as to not really be worth the investment of time to support. While I agree it is a potential valid use case for Docker support, of the Docker use cases its the smallest one.

I think this assumption is very wrong. I think that this attitude is unfortunate. But whatever. Do as you wish. At least as the author said keep it please open so others can use it even if it's not merged.

[mirogajdos]

I have no objections to this workflow although it is a slightly unusual use of docker (you are creating a container aka environment to compile something but then you do not run what you have compiled in the SAME environment, which is a bit odd although it MAY work, but also might not...)

I don't know on what kind of projects you have worked on but to have standardized build and then run it in on different env is very common usecase. What about cross complications and stuff.. pretty usual in many projects.

[xezon]

What would be the trouble to provide for the alleged small Docker use case? Is it complicated to implement or maintain?

[edbird]

What about cross complications and stuff.

Question for you. Do you think that most software in the world is being cross-compiled for a different platform, or is it more typical to compile on/for the same platform?

Cross compiling is definitely not the default.

Regardless, let us not go on a tangent about this. No one else reading these comments is going to care about what either of us think about this.

[PiecePaperCode]

I cannot afford the time at the moment, as my personal situation has changed. I need to hand over this work to another contributor who is willing to finish what I started. Otherwise i plan to come back in the next 6-12 months.

This PR focuses on a base image. Running graphic-intensive games in Docker is possible but difficult and, in my opinion, not recommended. It also becomes unmaintainable very quickly when installing an almost full-blown desktop environment.

[OmniBlade]

What would be the trouble to provide for the alleged small Docker use case? Is it complicated to implement or maintain?

Its largely already covered by projects like https://github.com/mstorsjo/msvc-wine as I already stated which will build a containerised build system that can then be used with cmake as documented. This would be sufficient for the tinkerer wanting a local build to mess with and someone wanting to cross compile. A VC6 solution is only needed if you need to build with an eye to committing your changes to this repo so its really only useful for the cross compiling use case where a developer is based on a none windows system and needs to check before PR that it builds against VC6. It would likely need to be more flexible than its current iteration to be useful on the CI.

I have no objections to this being merged at some point though as its a small text file, it needs some technical fixes to ensure unneeded files aren't baked into the layers of the image.

From a technical point of view the docker-compose is completely unwarranted though, docker-compose is for orchestrating several containers to provide a single service not for running a single container for a short lived task.