As I blogged a few days ago, I've started working on a game engine using open source bits. Part of it is just to satisfy my hunger to learn more about game development, but the more practical benefit of this effort is to better understand the plight of the C/C++ developer using the CDT on a real and fairly sizable project.
And I have my first lesson. It came about thanks to git. I have the source checked into a git repository out on github. Now, since the root of the game engine is open source libraries, I was working in the command line to extract them into the git repository. As a result I got used to using git from the command line, including adding a .gitignore so that git wouldn't check in my Eclipse .metadata directory and any directories containing build output.
I then started setting up the projects as CDT projects and started working in Eclipse. And I gave the Helios egit plug-ins a try. Unfortunately, they currently don't support .gitignore and as a result I got weird results that caused me to lose trust in egit, like ?'s on the folders I have listed in my .gitignore. Or did I forget to add them there? Not sure. I have to go back to the command line to look. At any rate, I ended up staying there and now I just use git from the command line. At least until egit 0.9 comes out with .gitignore support and I'll try again.
But this article isn't about egit. It's about Eclipse and how developers who do C/C++, especially experienced ones, work. The command line and command line tools are still a very important part of the development cycle and Eclipse and the CDT need to deal with that.
I see a lot of functionality in Eclipse assuming that projects are the root of your life. Well, it's not in my case. I have a git repo which contains directories that contain projects and there are some that do not. There's even a README file at the root and some files to help me build for Android using CMake.
I think there's a concept missing in Eclipse. We can equate the root of my git repo as a workspace. But then there are things in that workspace, files and folders, that aren't projects. I would like to be able to browse them, and maybe even edit the files, without having to go to the file explorer. Essentially I need a file navigator rooted at the workspace. I'm not sure whether we need a separate view for that, or to just allow Workspace roots to have IFiles and IFolders and make them navigable in the project navigator.
I'd like to hear other people's experiences, especially those who try to mix Eclipse with command line development. Is this something that would be useful? Are there other things?
The 'Navigator' view shows all files rooted at the workspace.
ReplyDeleteAt work I'm using the Git command line with my project, and I'm constantly frustrated at having to manually refresh my workspace root. Surely, having a background thread do this isn't THAT big of a performance hit.
Doug,
ReplyDeleteYou should be able to do this as of Eclipse 3.6 with the exclusion filters feature added to the resources layer in that release (originally part of e4 project). Just setup another simple project (no natures) that points to whatever is your source tree root and tell it to exclude the locations that map to other projects.
Not related to Git, but definitely related to CDT and Eclipse:
ReplyDeleteI think it's absolutely vital that CDT gets real support for pkg-config. It's the way most applications in the GNU sphere resolve their dependencies, and it's very confusing when a build works from the command line, but importing it into Eclipse results in hundreds of "unresolved include" warnings (and the lack of indexing that comes with that).
Even worse, even experienced developers who *know* what the problem is still have no recourse except for running pkg-config on the command line, identifying which of the 30 or so results are relevant to the particular code at hand, and manually adding them to the "Paths and Symbols" page. And then do this for every dependency that uses pkg-config! At this point most people will just give up.
Cheers,
Adrian
Yes! This is one of the first impedance issues I hit when I first started using Eclipse. I have since gotten used to the lack of this feature, but reading your post made me look back and realize how much I have had to retrain myself to do things the Eclipse way. It'd be nice if Eclipse was better at supporting the way I work.
ReplyDeleteWe use scons as our build system and we have a very dense directory/file structure that rarely maps to separate projects (and there are lots of them). My Eclipse configuration looks as follows:
ReplyDelete- I have only one CDT project, located in the root of the directory tree. Thus in the project view physical directory structure is nicely represented and I can browse every file just like in the file manager. I also get great code completion, because every file stays in one project.
- in that project I have a couple of build configurations which are only responsible for calling external scons command with appropriate target and parameters.
- I also have several debug/run configurations.
- build/debug/run configuration map directly into 'buildable' applications.
- for some tasks I still use command line.
I am very happy with that kind of environment setup. I only add or modify anything when I actually need it. It is only local to my machine, we do not store any IDE configuration in the repository, that way everyone can use whatever they like to write/edit/debug code. So for me, current Eclipse/CDT possibilities are more than enough.
The most important flaw of eclipse when it comes to manage big C++ projects is the workspace management that is so annoying.
ReplyDeleteI have several c++ projects, each one depends to one or another. I cannot share the workspace with my fellow coworkers. Each developer has to checkout each project, import each project, reconfigure with its own setting. The run/debug/execute external tools are also lost, which means lot of work to do again and again and again. That's a huge mess, source for error, and too much trouble.
That also means I have to maintain a "classic workspace", and when I work one several branches at the same time, I have to apply each change I do one all workspace. Of course there is the "export preference", but things like "key mapping" should never change between workspace, so they need to be
The solution would be... a "solution", like (sorry for the comparison) what does Visual Studio. I checkout the "solution" which will in turn include all inter-project settings (all c++ projects included in the solution + debug/run configuration, ...).
All "workspace dependent" settings (key mapping, view/perspectives,...) would remain at the discretion of the developer, but factoring a concept larger than the project but smaller than the workspace among all involved developers would be so useful! ("factoring" means "something I could checkin in my CVS/SVN/GIT".
And yes, a true GIT plugin would be soooo cool.
The shared workspace preferences is one thing that bugs me too. I use emacs keys and add a couple of bindings to it for build. I have to recreate that for every workspace.
ReplyDeleteEclipse dumped the "solution" idea way back in the beginning (I believe the even had it at one point). But I agree with you, that was a mistake. Comparing with Visual Studio is very valid at this point. They're still the usability kings.
This makes for a good post on it's own.
i use eclipse to develop a multiplatform project i use different targets for each platform but the end users usually use only one of them even when i import the projects in a new workspace it tries to compile the wrong architecture
ReplyDeletehaving something like platform detection is not that hard, it can even be configurable, in case i'm compiling for a target platform different that the host one.
also dependencies between targets instead of projects will be super useful if i'm compiling my debug target i want the debug version of the dependent libraries to be compiled not the selected ones.
and dependencies with individual files, if i recompile some library and then try to compile a dependent project it doesn't detect that the library has changed and i need to modify any cpp so the project re-links again
+1 for the solutions idea btw :)
Hi Doug, I just commented on your earlier post about this (I missed this post when I came here). Please read that first, as it addresses my biggest complaint, having attempted to convert a large Visual Studio project to Eclipse.
ReplyDeleteBut regarding your newer post... yes, 100% absolutely correct. You do need a proper workspace solution. The biggest argument I can make for it is the headless builder that we use. It gets the newest version of the code from source control every time there's a checkin and builds it via the command line. In Eclipse/CDT, this was done via the very dodgy headless-builder, but it worked. The first step of that was to recursively search for Eclipse projects, which I think is just wrong. If for no better reason than avoiding the import project step, there really needs to be a Master Project File that can simply be imported into Eclipse.
Another thing I would really like (personally, outside of work), is the ability to mix languages in a single project. At home, I use Ogre/OpenAL/Bullet/Lua to develop my own games. It would be ideal for me to be able to have my CDT project be Lua aware, so that I could have syntax highlighting and source browsing between lua and C++. I've actually been considering writing my own plugin based on CDT's, to accomplish exactly this. Debugging would be the icing on the cake though. But perhaps there needs to be an interface layer between different language plugins to share source bindings? Food for thought.
But honestly, all this is trumped by the problems with the build system. If you want to see them for yourself, start compiling ALL your code in Eclipse (this includes Ogre, Bullet, and OpenAL). Make modifications to Ogre or Bullet. You'll see the build system fall to pieces very quickly. As a simple test, try unifying the math between Bullet and Ogre as a single library. Hopefully you won't get very far before discovering the problems I mentioned.
Thanks, David. That's great feedback. The whole purpose of this exercise is to see where CDT is strong and not and fix where it is not.
ReplyDeleteWe know there are build issues, many caused by the Eclipse Platform build system which still struggles with non-Java/Web builds. I need to get a good feel for the changes we need. Hopefully we can figure that out for the next Eclipse release.
That would be excellent. Really, I love CDT. It just falls apart in big projects, and it's really uplifting for me to see you trying to do exactly that. It would be fantastic to have a real cross platform alternative to Visual Studio.
ReplyDeleteThere is a style of development particularly in the Embedded (Microcontroller) world where people either checkout or have my other means a set of source files somewhere in their file system. Then they have different project that use different subsets (sometimes overlapping) of these source files. CDT lets you have 'Linked files' but this becomes very cumbersome very quickly.
ReplyDeleteWhat is needed is for CDT to show and manipulate these external files as part of the projects transparently without having to make copies of them.