- Reading the Documentation
- Running the Software
- Building Software
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Building Software
Even if you've been able to run the code successfully, you're still going to have to learn how to compile it yourself for any of your changes to take effect.
Developers use a variety of tools to build their software, and your best hope for getting a project compiled today (as opposed to next week) is to use the same tools as the original developer(s). These tools all leave configuration files, and when you find those files you can use them to build the software. Which tools you need depends on what files you find. Here's a short table listing some of the more popular tools and their associated filenames:
|
Filename |
Product |
|
*.jbx, *.jbr |
JBuilder |
|
build.xml |
Ant |
|
*.prj |
VisualCafé |
|
*.dsw |
Microsoft Developer Studio |
|
*.make |
UNIX make |
|
.project |
Eclipse |
|
.ptl |
Rational Rose |
Rational Rose is a source-code generator rather than a compiler. Your source won't always consist of just .java, .c, and .cpp files. JBuilder and VisualCafé are also source-code generators; they generate Java source code from a graphical GUI builder. The source code isn't always easy to read, since it was designed to be read by a compiler, not by hand.
Sometimes you'll just encounter a bunch of source files, in which case you'll have to build from scratch, without any outside assistance at all. Actually, I consider that a good thing. It means that you don't have to learn (and possibly purchase) some development environment. If you're taking over a maintenance project, the development environment will likely be available to you already, since you're probably working for the original owner of the code, but not necessarily.
In addition, all programmers have favorite environments to which they become addicted; they operate less effectively without it. If you've been using JBuilder for the past four years, and you suddenly assume the maintenance of a project developed using VisualCafé, you've got a significant learning curve just for the environment, in addition to the software you're actually maintaining.
For that reason, I like to work "naked." I always want to be able to re-create functioning software using just a bare-bones, freely available environment. In the case of Java, that's the relevant Java Development Kit from Sun. For C programs in any UNIX environment, it's gcc, which is installed on nearly every UNIX computer (Solaris, Linux, or other). If you don't have it, you can readily get it on the Internet, at a cost only of your time to figure out how to get and install it—and the time can be significant, unfortunately.
Building from Java Source
When you have no other build support, the first thing to do is to just compile everything. Java source files are most commonly arranged in one of two ways. Sometimes the source files are arranged by packages in subdirectories. For example, on the Thorn project, the source files are found in src/thorn, src/thorn/parser, and so on, which mimics the packages thorn, thorn.parser, etc. (Sun would like for you to name your packages beginning with your domain name, such as Piccolo's edu.umd.cs.piccolo, but I find that this custom is followed intermittently.)
When the source files are organized that way, they can be easily compiled with this line:
javac *.java
You set your CLASSPATH environment variable to refer to the root directory (in Thorn's case, the src directory). You'll also have to look around for any .jar files included in the project (most often located in a lib subdirectory off of the root). You may have to compile several directories:
javac thorn\*.java thorn\parser\*.java thorn\parser\java\*.java ...
The command line gets pretty lengthy, which is why project-management tools are created.
Some projects lump all of the Java source files into a single directory, no matter what package they're in. The Java compiler has a special mode for this:
javac –d classes *.java
Set classes to whatever directory you want. I like this option, since it means you don't have to separate the Java source files later, when it's time to deliver.
The more complicated the build procedure, the more likely it was that the last maintainers were using some sort of tool to assist them. Sometimes those are in the form of .bat or .sh files, containing hand-crafted commands. They might also have been using something like Apache Ant.
Building with Ant
For open source Java projects, Ant is increasingly common, so sooner or later you'll probably encounter it. It's usually overkill for simple projects where all you have to do is compile a single library; but when you have multiple products (such as the main code, examples, Javadoc, and various distributions), it's more cross-platform than the various idiosyncratic versions of make.
The "magic incantation" for Ant is as follows:
java -classpath %JAVA_HOME%\lib\tools.jar;lib/ant.jar org.apache.tools.ant.Main target
where target is the thing you want built. For starters, try leaving it blank, which will get you the default. The default is usually either the thing you want, or a message explaining what the targets are. What I gave above is the Windows version; replace %JAVA_HOME% with $JAVA_HOME on UNIX. The above also assumes that they provided ant.jar in the lib directory, which I've found many projects do, since it's free to redistribute. If it's not there, then it's easy enough to find it on the web.