search

Dreadbot / Dreadbot-V

Code for the 2015 Dreadbot
2 stars 0 forks source link

Project files: On github or not? #2

Closed SteveKing closed 8 years ago

SteveKing commented 9 years ago

I was about to re-add the Eclipse project files (.project, .cproject, build.properties, build.xml) to the git repo, but before getting into a commit war I thought we could discuss whether or not they belong in the project.

The comment for the removal is "removing user-specific Eclipse and C++ project files". I'd argue that these are not user-specific files, but part of the project and should be under version control. I think it should be possible to clone the project, import it into Eclipse, and build. Without these files you need to create a new robot project in Eclipse then clone the repo over the top of it.

The one advantage of keeping these files off of github is that you could have multiple copies of the project open at once. The project name is stored in .project, and Eclipse doesn't let you have two projects with the same name in a workspace. If these files are not stored in Eclipse you can easily have different branches open as different projects simultaneously. I don't think that outweighs the ability to clone, import, and build without any other messing around.

Thoughts? Are there other advantages to treating the project files as user-specific instead part of the project itself?

C7C8 commented 9 years ago

I'd tend to argue that since problems can arise with everybody's specific configuration of Eclipse, the files should remain user-specific - we don't want one person's changes to their setup affecting anyone else's setup. For example, earlier on, when the lib folder was under the src folder, I moved my lib folder such that, in Eclipse only (I use virtually linked files) so it wasn't under src any longer - I felt it was cluttering up my src folder. Since many changes to our setup are simply personal preference, it might be better to let everyone set their project up as they prefer it.

In any case, Eclipse tries to keep all of its project files within its workspace (at least, as far as I can tell it never lets you have anything outside the workspace). I've tried getting Eclipse to import entire projects before, but so far it seems really finicky and I haven't had much success so far - it always tries to move the project to its workspace, even though it can't do that because of Git.

Personally, I just use a really easy setup consisting of virtually-linked files. I created a WPILib C++ Robot Development project from the template (which sets up everything from building to deploying when it works normally), then import all the source files, but keep them as virtually linked (it's under the "advanced" button when you do import/filesystem). That way, the project builds normally, but keeps my user settings away from the repo, and puts the entire "Debug" directory elsewhere, keeping it off the repo. It just means one additional step. Instead of "clone, import, build", it's just "create, clone, import, build".

If this was a scenario where we had some special build setup, I would agree that the files are no longer user specific. In the case that we add a third party library (like SDL2, which I'm currently looking into for the purposes of using its timing and mouse control abilities), the project files/settings should be part of the repo such that nobody has to reconfigure their copy of Eclipse to build using the new library.

johnpaulensign commented 9 years ago

Also, you can import the files into a new project. I can get the exact steps that are needed, if you'd like, but with some of the Eclipse files, it messes with the default includes if you are building on Linux, Windows, or Mac.

On Tue, Feb 3, 2015, 21:44 Sourec notifications@github.com wrote:

I'd tend to argue that since problems can arise with everybody's specific configuration of Eclipse, the files should remain user-specific - we don't want one person's changes to their setup affecting anyone else's setup. For example, earlier on, when the lib folder was under the src folder, I moved my lib folder such that, in Eclipse only (I use virtually linked files) so it wasn't under src any longer - I felt it was cluttering up my src folder. Since many changes to our setup are simply personal preference, it might be better to let everyone set their project up as they prefer it.

In any case, Eclipse tries to keep all of its project files within its workspace (at least, as far as I can tell it never lets you have anything outside the workspace). I've tried getting Eclipse to import entire projects before, but so far it seems really finicky and I haven't had much success so far - it always tries to move the project to its workspace, even though it can't do that because of Git.

Personally, I just use a really easy setup consisting of virtually-linked files. I created a WPILib C++ Robot Development project from the template (which sets up everything from building to deploying when it works normally), then import all the source files, but keep them as virtually linked (it's under the "advanced" button when you do import/filesystem). That way, the project builds normally, but keeps my user settings away from the repo, and puts the entire "Debug" directory elsewhere, keeping it off the repo. It just means one additional step. Instead of "clone, import, build", it's just "create, clone, import, build".

If this was a scenario where we had some special build setup, I would agree that the files are no longer user specific. In the case that we add a third party library (like SDL2, which I'm currently looking into for the purposes of using its timing and mouse control abilities), the project files/settings should be part of the repo such that nobody has to reconfigure their copy of Eclipse to build using the new library.

— Reply to this email directly or view it on GitHub https://github.com/Dreadbot/Dreadbot-V/issues/2#issuecomment-72780470.

SteveKing commented 9 years ago

On 2015-02-04 14:17 , johnnyensign wrote:

Also, you can import the files into a new project. I can get the exact steps that are needed, if you'd like, but with some of the Eclipse files, it messes with the default includes if you are building on Linux, Windows, or Mac.

Okay, that would be a problem, and if that's the case it makes sense to exclude those files.

I've been thinking about it more, and my lack of experience with IDEs is hindering me here. I'm more used to situations where the editor and compiler aren't coupled. Normally I'd say that an editor config should not be part of the project. Everyone should be free to use whatever editor they prefer. BUT, build configuration (eg., Makefiles) should be part of the project. You should be able to check the project out of version control and build it with a minimum of effort. (That goes double for something like FRC, where new members aren't going to be experienced enough to really troubleshoot.)

Johnny, could you please do a quick write up of how you'd go about creating a fresh project in Eclipse and importing the the source files?
It's something we ought to post on the github wiki for future generations. If you have even more time it'd also be useful to create an Eclipse config guide -- beyond what FIRST says to install, what plugins (git, saros, etc.) are recommended for the Dreadbots?

Something else I'd like to see on the wiki is a cookbook showing a typical workflow. Here's how you make a project in Eclipse. Here's how you populate it with files from github. After you've made a change, here's how to push it back up to github. Here's how to merge changes others have made into your local repo. When you have something stable, here's how to tag it. Here's how to work on a branch, and merge it back into the master. My git-fu is very weak and certainly not up to the task.

(As an aside, github supports accessing the repos with svn as well as git. I've been using svn with the Dreadbots repos just as if they were hosted by a subversion server. I could easily write an svn addendum to the cookbook.)

Steve King steve@narbat.com mailto:steve@narbat.com