Eclipse Europa Needs Some

 
 
By Justin Vandegrift  |  Posted 2007-08-30 Email Print this article Print
 
 
 
 
 
 
 


Polishing"> The Eclipse project has matured as a solid IDE, but the latest version—Europa Release 3.3—is a bit rough around the edges. By now, you have probably heard of Eclipse, and if you havent used it for yourself, you are likely to know someone who has. IBMs Object Technology International group released Eclipse as open source in 2001, and it has since matured into a premier development environment that is the IDE of choice for many professional software developers. While in most engineering offices the dominant platform continues to be Microsofts Windows, and the dominant development tool Microsofts Visual Studio, Eclipse has incrementally edged its way into the mainstream. It is now quite common to find Eclipse users interspersed among the coding masses.
The Eclipse community consists of more than 60 distinct projects, many of which are plug-ins that extend the capabilities of the platform. Updates from these projects are organized as yearly "simultaneous releases," for which packages are bundled into separate tool kits. This years release, Europa, consists of five separate tool kits: Java, Java EE, C/C++, RCP and Eclipse Classic. The tool kits can be downloaded for free from the Eclipse Foundations Web site.
What I Reviewed As a C/C++ developer with a Windows background, I primarily write embedded code for mobile platforms. So when selecting a package appropriate for my needs, I naturally reached for the C/C++ IDE from the Eclipse Web site and then installed it on an x86 computer running Windows XP.
After downloading, installing and building a few simple console applications, I used the Software Updates feature from the Eclipse Help menu to install the Ruby Developers Toolkit, or RDT. This essentially equipped me with all that I needed to develop, compile and test my production C code and to edit the library of Ruby scripts that I use for analyzing and formatting test data. Installation As is often my experience with open-source software, the "environment" did not work immediately after the initial installation—that is, it would not compile a simple C program. Eclipse is based on the GCC (GNU Compiler Collection) compiler, and the Windows version of the installer does not include the compiler in the standard package. This is an annoyance but is not insurmountable. The recommended GCC installations for Windows are MinGW (Minimalist GNU for Windows) and Cygwin. I opted for MinGW. After downloading and installing it—then manually setting up some environment variables, then rebooting, then selecting the "internal builder" for "builder type" in the project properties—I finally had Eclipse running and compiling code. Even smart IT people do stupid things. Check them out here. Needless to say, the installation procedure was rather unpolished, involving far more manual installation and configuration steps than a professional-grade application installer should require. There really is no reason why the installer on the Eclipse Foundations Web site shouldnt include all dependent packages (GCC) or why the default project options shouldnt be set in a way that will compile code (Internal/External Builder Type). Nothing leaves a more sour taste in a Windows users mouth than an application not working properly, or requiring additional manual configurations, after clicking finish on the installation wizards final panel. Framework Particulars If you have a Visual Studio background, one of the first things that takes some getting used to in Eclipse is the work space model. In Eclipse, the work space is closely coupled with the systems directory structure. In fact, a work space is defined by specifying a top-level directory that houses all its contents. Every subdirectory and file contained therein is, by default, part of the work space. A work space can contain multiple projects, but the files associated with these projects must be organized into different subfolders. This constraint is somewhat annoying, as it dictates how you must organize the location of your source. For example, files shared among the projects must be kept in a folder that is included in every project, which may break some natural associations that those shared files have with other project-specific items. Comparing this with a Visual Studio paradigm, in which source files can exist wherever you want them to, any constraint imposed on your organizational method feels unnecessarily restrictive. Page 2: Eclipse Europa Needs Some Polishing



 
 
 
 
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel