Apologies in advance for being a newbie.
We are using Jetson TX2 and I’ve been able to do some remote debugging on it, using Nsight from a separate Ubuntu 16.04 host machine (actually in a VM hosted in Windows). That’s OK just for me.
However, I want to set up a project that other engineers can share in git in a sensible production environment. Any engineer should be able to check out the project, build the code, and debug it, without any local tinkering, and commit/push useful changes back to the source code repository for other engineers to pick up.
If we were to just use a makefile, that would be easy. Similarly if it was a Visual Studio project under Windows, we could share the same solution and project files, which use relative paths nicely. But Nsight/Eclipse seems to create a whole raft of hidden setup/configuration files (.cproject, .project, .settings/* etc). And importing a sample project (say) seems to copy everything locally to a workspace folder by default. Some settings will inevitably be engineer-specific (e.g. target Jetson board name/IP address).
I do want to work within Nsight, so that we can use the graphical debugging and profiling in what will become a very complex application. Yet I want to sensibly share the build amongst a collaborating development team without tripping over machine-specific settings or paths, if at all possible. I don’t want my build to work for me, but not a colleague. Should I just commit all of the hidden setup files? Is there some other well-known way? I’ve searched quite a bit, and not really found any consensus on handling Eclipse projects collaboratively in general, yet it’s used so much I feel there must be some sensible approach.
Thanks in advance for any tips or pointers!