![]() |
|
The design of VIDE has been somewhat evolutionary, but you should find that it is not that much different than other IDEs you may have used. Because VIDE is a free, open source program, it probably lacks some of the polish of commercial IDEs. However, it is still quite functional, and it is really easier to develop programs with it than it is to use a command line interface.
Generally, any application you write will consist of various source files (with associated header files for C/C++), and required data files. These files are generally dependent on each other. By defining a VIDE Project for your application, all the file dependencies are automatically handled. The standard tool make is used for C/C++ files, while the JDK Java compiler automatically handles dependencies.
Using VIDE, the normal work cycle goes:
The main C/C++ compiler VIDE is designed to work with is the GNU Compiler Collection (gcc), either on a Unix-like system, or on MS-Windows with the GNU GCC compiler. (VIDE will work with either the MinGW version of GCC, or the Cygnus version. Try the latest merged GCC 2.95.2!) Functionality of VIDE for gcc is based on standard GNU makefiles. VIDE uses a standard GNU make Makefile to build your project. Thus, you must have a Makefile defined. This Makefile can be one created automatically by VIDE itself from your Project file, one generated by the vgen V application generator, or even one you've written yourself. If you have your own Makefile, then you probably won't need to use a VIDE Project.
VIDE assumes you have your gcc/g++ compiler already installed on your system and the PATH correctly set. For Unix/Linux systems, this is a given. If you are using a MS-Windows version (MingGW or Cygnus), then you must follow the instructions provided with their distributions. You might find it helpful to copy the VIDE executables to the /bin directory that has your g++ compiler. VIDE requires GNU make (it is not compatible with some other versions of make), the GNU C/C++ compiler (preferably the latest GCC 2.95) and associated utilities, and the GNU gdb debugger. You also may want the V utilities vgen and viconed.
Beginning with version 1.07, VIDE has added support for the free Borland compiler. This support includes support for running Borland's Turbo Debugger. More complete information about using VIDE with the Borland compiler is found in the VIDE Borland reference guide. It is essential that you read the information in that reference to get a properly working version of VIDE with Borland BCC32.
Functionality of VIDE for BCC32 is based on the non-standard Borland MAKE program. VIDE uses a Borland make Makefile to build your project. Thus, you must have a Makefile defined. This Makefile can be one created automatically by VIDE itself from your Project file, or one you've written yourself. If you have your own Makefile, then you probably won't need to use a VIDE Project.
VIDE assumes you have your Borland compiler already installed on your system and the PATH correctly set. When working with the Borland compiler, VIDE requires the Borland make.
Once you start VIDE, you will see a blank window labelled "No Makefile, Project, or .java file Specified." This opening window is the message window, and is used to output the results of your make. A typical first step after starting VIDE is to open a VIDE Project or select an existing Makefile.
Once you've opened a project or specified a Makefile, you can build your project with the Build:Make C++ menu command, or click on the Make button on the tool bar. This runs the make utility with the default target (often "all"). VIDE first runs the Makefile in dry run mode. It uses that output to then run the commands generated. It intercepts the error messages for g++ and put them in the message window. You can then right-click the error line, and VIDE will open up the file in question, and put the cursor on the offending line. This all assumes that the source and makefile are in the same directory. VIDE also assumes all your files have unique names (i.e., you don't have files in your project with the same name but in different directories). After you correct the problem, rerun make.
You can also make a specific target in your makefile by using the Make menu: Make:Make <target>. If you include a "clean" target in your Makefile, Make:Make Clean will run make clean. (The Makefile generated by VIDE from a Project has a "clean" target.)
The tools menu allows you to run your program. If you are using a VIDE Project, then Tools:Run project will run the project you just built. If you are using your own Makefile, then Tools:Run project will prompt you for the file to run.
When you are first creating a new project (or moving an existing program to VIDE), click on the Project:New C++ Project menu. After you select a name for your project, a "wizard" dialog will open that will let you begin defining a project. The first thing to fill in is the name of the program you are building (Target name). If you are building an application, this will be something like "foo.exe" on Windows, or simply "foo" on Linux or Unix systems. Libraries end with a ".a" extension: "foo.a" on both platforms, or a ".lib" for Borland.
Next, select the type of project you want to build. A Console Application runs in a shell or console window, and does not use any GUI components. A GUI application uses a graphical interface. On Windows, this will be the standard WIN32 API, while on X systems, you will have a choice of Athena, Motif, or gtk. You can also use the V GUI. You will be given a choice between using the static V library or a dynamically loaded library. If you are using OpenGL or Mesa, check that box.
You can also build a static library. Static libraries are usually easy to build. Both Windows and Linux support dynamic libraries (called DLLs on Windows and shared libraries on Linux). However, the rules for defining and getting a shared library (especially DLLs) is somewhat beyond the scope of VIDE. The VIDE project file can support DLLs and shared libraries, but you have to just how to put a dynamic library together first. See the later section on Advanced options for a few more details of building a DLL.
You can also select which you are building, a release version, or simply a debugging version of your project. These options simply determine some switches to the compiler. VIDE does not support both a release and a debug build within the same session. The easiest work around for this is to first build one version, then use File->Save As to save the alternate version.
The Windows version also lets you select which compiler you are using - MingGW, Cygnus, or Borland. Setting the "-mno-cygwin" option will build an application under Cygwin without using the Cygwin DLL.
Once the initial project attributes have been selected, You will get the project editor dialog box with various tabbed items. Most of the fields will be filled in according to the values you set in the opening dialog. The main thing you will probably want to do is add source files using the Files tab. You can set defines as needed in the other tabs. Once you have added the files needed and click "Done," VIDE will create a Makefile suitable to compile your project with gcc or Borland BCC32.
Each of the project editor tabs are described in more detail in the following sections. (These screen shots were taken from the project file that builds VIDE itself using the V GUI library.)
This pane lets you set the target name for the executable or library. You can also change the name of the generated Makefile. Usually, you will use g++ as the compiler. The Borland compiler is BCC32. The The target name determines what kind of final target is built. A ".exe" extension on Windows, or no extension on Linux, causes an executable to be built. If the target name ends in ".a" (or ".lib" for Borland), then a static library will be built. It is important to get these extensions right to generate the correct kind of target.
Compiler Flags line lets you pass switches to the compiler, such as -O for optimize, or whatever. The linker flags are passed to the linker, and usually consist of a set of library references. The new project wizard will usually fill these fields in as needed for console, GUI, and V apps. The HOMEV value is required for programs that use the V library if the V GUI system has not been installed in the same places as other libraries and include files on your system.
You may have to change some of the default switches for your specific compiler or operating system. You should only have to do this once for a project. If you will be creating other projects, you can save a template project in a file of your choice, and then use it as a starting point for new projects.
The Borland guide gives some specific details for the Borland version.
This lets you add the names of the source files included in the project. Clicking ADD brings up a file selection dialog. When you select a file, the file is added without any path name. To delete the selected entry, use the Del button. Until V adds multi-line selection (someday soon), you have to add files one at a time.
On Windows, the source file can be a ".rc" resource file as well. If you include a ".rc" file, VIDE will automatically add the dependency to the Makefile, and use the appropriate resource compiler (WINDRES for gcc or BRCC32 for Borland) to compile a ".o" file for gcc or a ".res" file for Borland.
Note: Adding relative file paths
The current mechanism for adding files does not support
adding relative or absolute paths in front of a file name
using the file selection dialog. Normally, VIDE assumes that
you will have your source files in the directory specified
in the source directory path. Thus it strips any leading path.
However, you can add relative paths.
If you need to add a relative (or absolute) path, first
add the file using the file selection dialog. Then, select
the file from the list file, and click Edit to hand edit the entry.
Then add the relative path to the file.
Note: Multiple source directories
Sometimes you may want to keep files in multiple directories.
With GNU make, this is not a problem. Simply use relative paths.
Borland Make has some problems, and doesn't seem to handle
embedded relative paths. So, you can specify an exact path
if you wish. Simply edit the file, give the full path, but
put a leading = (equal sign) in front of the file
name. When generating the Makefile, VIDE will then copy the
file name literally, and not append the standard "$(Src)"
symbol.
(Note: using the file selection dialog can leave the current directory set to something other than the default source directory, and when you exit the project editor, the generation of the Makefile may fail because things get started in the wrong directory. This problem is a bit hard to fix, and only happens when you use the file dialog box to select a file from a different directory. Just edit the project again, and the Makefile will be generated correctly. Someday I may fix this, but I have higher priorities for now. Sorry.)
This lets you specify the directory for the source files, the directory where you want object files to be generated, and the directory where the binary should be written to. It is best to use relative paths for these whenever possible. You can also list paths for include and library directories. These are passed to g++ as the appropriate switches.
It is often helpful to provide compile time defines for C and C++ programs. This tab lets you add compile time defines. The left list shows a a pool of definitions that you might want to use. To have them included at compile time add them to the Active Definitions list using the ">" button between the lists. The pool will stay constant, while the Active side can be a bit more dynamic as you work with your project. Note that you have to supply the full g++ definition switch: -DFOO or -UNOTFOO.
The first field of the Advanced pane lets you define a project specific argument for the ctags program. For example, the entry "-c-types=+p * ../includew/v/*.h" does several things. First, it adds extra information about function prototypes. Then it includes the V library headers in the tags file for easy lookup of functions used from the library. Check the ctags documentation for other switches you might want to use.
The second advanced field lets you specify startup switches for the debugger. (Not shown in this screen capture.) For example, when used with gdb, "-nw" is provided by default to start gdb in non-windows mode.
The other advanced panels let you add lines to the Makefile in one of two places. You will have to have a pretty good understanding of Makefile in order to make effective use of these options.
Anything you add to the "User Makefile Options" list will be written to the generated Makefile immediately after the standard definitions. You could use it to define your own symbols, or whatever.
The "User Targets" list lets you add new targets other than the defaults to make. You can use these to define specific values you want to add to your Makefile. The Borland support uses these to define the default runtime libraries.
If you want to build something other than an executable or a library, there is one important feature provided by the user targets list. If the first entry has "#all" in the it, then VIDE will not generate an "all" target (usually the same name as the target name) for the make file. It assumes you are providing the all target here instead.
Note that when you need a leading tab for the makefile, enter a '\t' into the project. It will be automatically converted to a real tab in the final makefile.
A VIDE .vpj project files is in fact regular text file. It is laid out in clearly labeled sections. While you can add entries to any section using the Project Editor, advanced users may find it easier to edit the V project file directly to add definitions and targets that aren't generated automatically. Using these two mechanisms (defines and targets), you can build complicated makefiles which will be automatically generated from the project file. It is possible to define practically anything you might need to include in a makefile. For example, all the options needed to generate the Windows DLL version of V are included in a VIDE project file.
I'm not going to explain every detail of the project file format here. Any programmer reasonably familiar with makefiles will be able to see some of the potential of the VIDE project file. For example, VIDE uses a set of standard variable names such as "oDir" and "EXOBJS". The standard make targets are defined using symbols, too. It is easy to define entries in the user defined symbol section that use the makefile "+=" operator to modify and add to the standard symbols. You can add very complicated targets to the user target section, especially when you override the "all" target with the "#all" convention. Perhaps the best thing to do is look as a VIDE Project File, and study the VIDE and VGUI project files for examples of some of the things you can do. The main advantage of using a project file is the automatic generation of dependencies and other features that will be eventually included in VIDE.
VIDE now includes a Help menu. Most of the help is supplied in a separate distribution file, and is in HTML format. V Help uses your default Web Browser to show the help files.
I have attempted to collect the most useful documentation I could find for the various GNU C++ tools. If you download and install the Help files, you should have a very complete and useful set of documents for C, C++, and Java programming at your finger tips. See Installing VIDE for more instructions on how to install VIDE help.
If there are other HTML based documents you would like added to the VIDE distribution, please let me know.
VIDE supports the standard GNU gdb and Sun jdb debuggers. The VIDE interface to the debuggers makes it far easier to debug your code, but is of minimalist design. The goal is to make using the native debuggers as easy as possible for casual users, while maintaining the full power of the debugger for experienced users. VIDE accomplishes this by showing a command window interface to the debugger. You can enter any native debugger command in this window, and thus have full access to all debugger features.
VIDE makes using the debugger easier by providing a popup dialog with the most often used commands. And most importantly, VIDE will open the source file in an editor window and highlight the current execution line on breakpoints or steps. It is very easy to trace program execution by setting breakpoints, and clicking on the Step over or Step into dialog buttons. VIDE also allows you to inspect variable values by highlighting the variable in the source and right clicking the mouse.
A description of debug dialog commands is provided in the VIDE Command Reference section.
To debug C/C++ programs with gdb, you must first compile the program with debugging information. This is accomplished with the -g switch on the compile line. The current version of VIDE does not provide automatic generation of debug or release makefiles. The easiest way to define VIDE projects for both debug and release versions is to use the Project:Save Project as... command. First, define a release version of the project. Then, using that project as a template, change the switches as needed for your debug version, and save the project under a different name.
The full power of gdb is available in the debugger command window. You may enter any standard gdb command after the "(gdb)" prompt. In fact, there really is limited interaction between VIDE and gdb, mostly handling breakpoints. VIDE starts gdb using the "-f" switch, which causes gdb to send a special output sequence after each break, which VIDE then uses to open and display the highlighted break line.
VIDE maintains its own list of breakpoints, which it keeps even if you start and stop the debugger. It is important that you use VIDE commands to set and delete breakpoints. If you enter breakpoints directly into the gdb command window, VIDE won't know about them, and won't highlight them in your source code.
At the present time (June, 2000), gdb Version 5.0 has been released for Windows. At this time, the only ready to run version is supplied with the Cygwin gcc distribution. Since gdb 4.18 supplied with MinGW still seems to have problems debugging large Win apps, I've made a stripped down version of the Cygwin gdb version available on the ObjectCentral web site. There are actually two versions. One is the full Cygwin version with the tk/tcl windowed interface, and the other only works in console mode (and must be started with the -nw switch). The stripped down version works great with VIDE for both Cygwin and MinGW code. In fact, I can finally actually debug VIDE itself using this version of gdb!
This program is provided on an "as is" basis, without warranty of any kind. The entire risk as to the quality and performance of the program is borne by you.
Bruce E. Wampler, Ph.D.
bruce@objectcentral.com
www.objectcentral.com