| Suggestions for setting up CDT in existing environment + CVS [message #755034] |
Mon, 07 November 2011 05:49  |
 cghill
Messages: 2
Registered: November 2011 |
Junior Member |
|
|
At my work we've decided to try out Eclipse CDT in our environment. The current environment we run is Suse Linux, and we are using CVS for change control.
I personally used Eclipse a lot in college when doing Java projects, but that was about the extent of my IDE experience - very small code baselines created from scratch. Ever since then, its been all vi and grep at work. Needless to say I'm looking forward to the features of an IDE again, but I've never had to try to integrated Eclipse into a large, existing code baseline, nor have I had to use it with CVS, so I'm looking for some suggestions from seasoned veterans for how to set up my environment so that I don't have to make some of the same mistakes that many already have.
(Note: as probably a relief to you guys, I'm not looking for a guide on "how to add files" or "how to compile" - I know how to do that stuff or can figure it out if needed. I'm just seeking wisdom here)
First of all:
At my last position we used Windriver Workbench (modified eclipse environment) with Rational Synergy. One of the biggest things that is throwing me off in this environment is how to play nice with CVS. It seems when you want to modify anything in CVS, you checkout the entire code baseline (a branch) and check it back in to integrate it with the trunk. In synergy, you would check out and modify one file at a time. Thus, the location of your projects and the metadata would never change. It seems with CVS you get an entire new directory structure every time you create a branch. How does this work with Eclipse? Do you have to import all the projects every time that you want to perform a branch? I know that Eclipse itself can play nice with CVS with its plugins - is that the trick?
The other main question I have is:
Is there a general philosophy on how to separate your code into "projects" within Eclipse. Technically all the code we have is for the same engine, so should it all be under one project? Should we have multiple projects - 1 for each logical piece of the engine "probably at 7-8 in total? Can you have a main project with multiple sub-projects? Our code is separated quite cleanly into "include" and "source", then within source we have "libraries" and "executables" - should it be broken up that way? I'm sure a lot of this is personal preference, but any benefits/drawbacks I could hear from you guys may help.
Thanks for the help everyone, and sorry for the long post.
|
|
|
| Re: Suggestions for setting up CDT in existing environment + CVS [message #755478 is a reply to message #755034] |
Tue, 08 November 2011 15:52  |
cghill
Messages: 2
Registered: November 2011 |
Junior Member |
|
|
Almost 2400 views and no comment?
Oh well - I'll update with the progress I have so far:
I've kind of resolved to the fact that I will set up a "generic" environment, and check it into CVS. Then, in the future, when someone creates a branch, they will simply need to import that project(s) into their workspace and be able to get going. I still am looking for suggestions on the best way to set up the project structure. I have some ideas - I'm hoping some of you guys can speak to what will likely be the best.
Our current directory structure is roughly like this:
source/
__include/
____includeA/
____includeB/
__libs/
____libA/
____libB/
____libC/
__app/
____appA/
____appB/
(sorry for the underscores, but it removed my spaces for indenting)
I currently have the workspace pointing to source, and it being the root (and only) project. This is nice in that when I click "Build" it builds the whole code base, and it becomes very easy and clean to import everything when you create a new branch - only 1 project to import and you are ready to start coding. However, I'm wondering if it would be cleaner to have multiple projects at the 2nd level (like an app project and a lib project), or even go all the way down to the lowest level (libA, libB, libC, appA, appB projects). While it would be a real pain to import all these when you create a branch, it would be nice to be able to build them all individually. Any thoughts?
Some other questions:
1) Should workspace be in a personal directory, completely outside of this location? As far as I remember, workspace and project locations aren't required to be together.
2) We are using our own Makefiles - one in each directory listed above with a nested calling structure that starts from the top level (source). The code builds just fine right now, but I noticed that the Eclipse editor doesn't seem to parse the Makefiles to know what external libraries were included - it was having issues in some files saying that they couldn't find references to functions or variables declared in the libraries (even though the file built just fine with make). Is there a way to get Eclipse to parse the Makefiles to determine included libraries, or do I have to set this all up on my own?
3) As a follow up to the question above, right now all I can do is build the entire code base. I can't build individual directories, even though they all have their own Makefile. I've heard people mention "Make targets", and I played with them a bit, but I'm wondering if that is the only solution to this problem. Additionally - if I have to manually specify external libraries for the editor (as talked about in question 2) is that something that can be done on a "per-folder" basis? Each folder's makefile specifies its own libraries to include - would I just have to include them all at the top project level, or can you specify them in Make targets?
Thanks
[Updated on: Tue, 08 November 2011 15:55] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.03146 seconds
] 
Search
Help
Register
Login
Home
