Programming

19033 readers

186 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

[email protected]

Remote c++ development suggestions. (programming.dev)

submitted 1 week ago by [email protected] to c/[email protected]

22 comments fedilink hide all child comments

I just started a new job where I have to ssh into a remote linux vm to work on a qt driven c++ project. I don’t really have a lot of leeway on what can be added to the remote environment, and I don’t think local development is possible. The vm has vim and qtcreator.

I’m from a Java background and I’m learning c++ for this role, while I’m comfortable in vim, I’d really like to have a tool that can give me autocomplete, jump to definition and linting. I know these things can be set up in neovim, but I asked about having that put on the box and was not given a good reaction.

I also know tools like vscode and possibly clion can be set up to do remote work via ssh. Does anyone have experience with this and suggestion on a good setup?

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 6 points 1 week ago (1 children)

I’m interested to know why it’s done like that. It seems awful. Do you have some SCM like git? Do you have restrictions like working for the army? So many questions.

I’m asking because I’ve seen that a lot in the past and it was always due to bad practices that no one wanted or could change.

[–] [email protected] 3 points 1 week ago

We have a similar setup where I work (enough different to think they don't work with me, but who knows). It was done like that in our case because we ship embedded linux. Because we are building on linux and targeting linux we kept running into problems with people linking local system libraries that were not compatible with the target even though they had the same name. We eventfully wrote out own package management tool which locked things down so you can't make that mistake - the same month we hit 1.0 conan did their first public release, if canan has been 2 years sooner we would have just contributed to that instead and saved a ton of effort, but now we have too many sunk costs in our current tools and so it isn't worth changing to a new one.