Docker dev environment #28
Conversation
The intention is to provide a standardized development environment.
This is necessary when cross-compiling from arm to x86.
It is used to standardize the VsCode settings.
| [target.x86_64-unknown-linux-gnu] | ||
| linker = "x86_64-linux-gnu-gcc" |
There was a problem hiding this comment.
I don't get it. You're specifying linker for x86 target, how is that relevant to arm cross built? 🤔
There was a problem hiding this comment.
x86 is the target for the cross compilation. arm is the host.
There was a problem hiding this comment.
ah ok. Thing is that this will be used on normal native builds too and that would not be good. E.g I use mold linker for faster linking and AFAICT, this would override that.
|
|
||
| // Features to add to the dev container. More info: https://containers.dev/features. | ||
| // "features": {}, | ||
|
|
||
| // Use 'forwardPorts' to make a list of ports inside the container available locally. | ||
| // "forwardPorts": [], | ||
|
|
||
| // Uncomment the next line to run commands after the container is created. | ||
| // "postCreateCommand": "cat /etc/os-release", | ||
|
|
||
| // Configure tool-specific properties. | ||
| // "customizations": {}, | ||
|
|
||
| // Uncomment to connect as an existing user other than the container default. More info: https://aka.ms/dev-containers-non-root. | ||
| // "remoteUser": "devcontainer" |
There was a problem hiding this comment.
We don't need these. If people need to add them, they can consult the docs you point to above and add them themselves.
There was a problem hiding this comment.
I would prefer other way but no problem. I can add .devcaontainer folder to .gitignore.
There was a problem hiding this comment.
You misunderstand. I was referring to the commented out settings, not the file itself.
| @@ -0,0 +1,4 @@ | |||
| FROM rust | |||
|
|
|||
| RUN cargo install cargo-watch cargo-deb | |||
There was a problem hiding this comment.
I wouldn't provide any distro-specific stuff.
There was a problem hiding this comment.
cargo-deb is necessary to build the deb packages, which might be good to have it accessible.
There was a problem hiding this comment.
Yeah I know what it would be for but it's distro-specific and hence not something I'd want here.
Is building deb natively harder?
There was a problem hiding this comment.
What do you mean with natively? Without using cargo-deb?
There was a problem hiding this comment.
I mean w/o using docker or any containers, like I normal develop. :)
|
Initially, I would like to use it just with VsCode. No other purposes. When you open a project with a Docker file, VsCode prompts the option for opening the project in the container and then builds and prepares the container env. |
Nice! However, given that this project is quite small and has very few deps (which are fetched by cargo for you) and I don't expect a lot of developers to get involved, I'd only want this nice workflow added if it can be done in a very non-intrusive (e.g no changes to default linker on x86 Linux) manner. With #27, I was more thinking of users, not developers. |
|
Ok, I am closing this PR as I don't have enough energy to continue the discussion. :) |
Fair enough. I hope no hard feelings though and that you understand me disagreeing doesn't meant that I do not appreciate your contributions (even ones that don't get merged). |
|
Not at all. Apparently you don't need much help here and can move faster alone. Please don't hesitate to contact me when you need help. |
This will provide a standardized development environment as well as the necessary infrastructure for the debian package management.