Compiling and Installing Flick

This chapter is adapted from the INSTALL file located in the root of the Flick distribution source tree and from the README file located in the test directory.

Flick 2.1 has been successfully built and tested on the following platforms:
 
Operating System
Host/Processor
Compiler



FreeBSD 3.0-CURRENT
Intel Pentium II
gcc/g++ 2.95.1
FreeBSD 3.0-CURRENT
Intel Pentium II
gcc/g++ 2.7.2.1
Linux 2.2.12
Intel Pentium II
egcs 1.1.2
SunOS 5.7 (Solaris)
Sun 4u SPARC
gcc/g++ 2.8.0
SunOS 5.7 (Solaris)
Sun 4u SPARC
Sun WorkShop C/C++ 5.0
SunOS 5.7 (Solaris)
Sun 4u SPARC
Sun WorkShop C/C++ 4.2
4.3+ BSD
HP 9000/J210XC PA-RISC 1.1
gcc/g++ 2.7.2
IRIX64 6.5
SGI Origin 2000
MIPSpro 64-bit C/C++ 7.30
Windows 95
Intel Pentium II
egcs 1.1
with Cygnus' Cygwin library b20.1
Windows NT 4.0
Intel Pentium Pro
egcs 1.1
with Cygnus' Cygwin library b20.1



FreeBSD is the current Flick development platform. Flick-generated stubs have also been tested on Mach/Lites and our Fluke OS. If you build Flick on a platform other than the ones listed above, the Flick developers would love to know about it. Of course, if the build fails, they would like to know about that, too. Send build reports, bug reports, praise and damnation to flick-bugs@cs.utah.edu.

2.1 Building the Flick Programs

In order to build Flick you will need:

An ANSI C compiler
gcc 2.7.2.1 is our usual compiler. Flick has previously been built with gcc 2.6.3 and 2.5.8.1
An ANSI C++ compiler
g++ 2.7.2.1 is our usual compiler. Again, Flick has worked with g++ 2.6.3 / 2.5.8 in the past.
GNU make
Versions 3.69, 3.74, 3.75, and 3.77 have been tested.
flex or lex
flex versions 2.4.6, 2.5.2, and 2.5.4 have been tested. Vendor-provided versions of lex should work, but this has not been extensively tested.
bison or yacc
bison version 1.25 has been tested; version 1.22 is known not to work. Vendor-provided versions of yacc should work, but have not been extensively tested.
Disk space
You will need ~140MB of free disk space for a fully debuggable Flick object tree, and an additional 100-200MB in order to run the Flick tests.

Once you have those tools, you must unpack the Flick distribution tar file and create a build tree to contain the object files. If you create a build directory called obj, your directory setup would look as follows:

~/flick-2.1
The Flick source tree, unpacked from flick-2.1.tar.gz.
~/obj
The Flick object tree, which you will use to build Flick.

In that configuration, you would type the following commands in order to first configure Flick for your operating system and then compile all of the Flick tools:2
         cd ~/obj
         ../flick-2.1/configure
         make

If all goes well, links to the suite of Flick programs will be installed in ~/obj/bin. Section 2.3 below explains how to install the Flick tools in a place outside of the Flick object tree. Section 2.4 explains how to test Flick against the set of included sample IDL inputs and driver programs.

2.2 Building the Flick Runtime Libraries

Flick's configure script automatically determines which of Flick's runtime libraries should be built and installed for your system. In general, the IIOP and ONC/TCP runtimes (for CORBA C language stubs and ONC RPC C language stubs, respectively) are always built. The other, more special-purpose runtime libraries are built only when configure detects that special header files are available on your system.

In particular, Flick's configure script looks for the following header files in order to decide which runtime libraries will be compiled on your system:

<sys/socket.h>
If this file is found, the IIOP and ONC/TCP runtimes will be built.
<mach/mach_types.h>
If this file exists, the Mach 3 runtime will be built.
<tpz_api.h>
If this file is found, the Trapeze runtime will be built. configure will look in $(TPZ_HOME)/include for this header.
<gm.h>
If this file exists, the Khazana runtime will be built. configure will look in $(KHAZANA_ROOT)/src for this file.

Flick's C++ CORBA stub generator creates stubs that work with TAO, the real-time ORB from Washington University in St. Louis. You will need a copy of TAO version 1.0 (from http://www.cs.wustl.edu/~schmidt/TAO.html or ftp://ace.cs.wustl.edu/pub/ACE/) in order to make use of Flick's optimized C++ CORBA stubs. TAO provides all the required runtime support for Flick-generated C++ stubs, and therefore, there is no library in Flick's runtime directory for C++ CORBA stubs.

2.3 Installing Flick

You can install the Flick binaries, libraries, and header files in a "standard" place on your system by typing the following command in the root directory of the Flick object tree (~/obj in our example configuration):
         make install

By default, the root installation directory is /usr/local. You can change this default by specifying the --prefix option to configure, e.g.:
         ../flick-2.1/configure --prefix=/usr/local/flick
 
         make            # to build Flick
         make install    # to install Flick under `/usr/local/flick'

It is not necessary to "install" Flick in order to run the provided tests (as described in the next section) or to build your own stubs.

2.4 Testing Flick

Flick comes with a set of test IDL inputs and example programs; these are located in the test subdirectory of the distribution source tree. A make in the root of the Flick object tree will not run the Flick tools against these test inputs. However, running your newly compiled tools against the provided tests is easy. In a sentence: Go to the test subdirectory of your Flick object tree and type make.

2.4.1 Running Flick

You will need ~100MB of free disk space in order to run Flick against all of the provided test IDL inputs, and an additional ~100MB if you want to run regression tests. To run regression tests you must acquire the "known good" output files from ftp://flux.cs.utah.edu/flux/flick/2.1/flick-2.1-tests.tar.gz. Download that file and unpack it on top of your Flick source tree. For example, if the root of your Flick source tree is ~/flick-2.1, you would install the regression test files by typing:
         cd ~
         tar xf flick-2.1-tests.tar      # Adds to `~/flick-2.1'

Once you have found enough disk space and (optionally) installed the files for regression testing, go into the test directory of your Flick object tree (~/obj/test in our running example) and type one of the following commands:

make
. . . if you simply want to run all of the Flick compiler components. The generated `.c'/`.cc' and `.h' files will be output into the pbe/* subdirectories of test. If everything runs smoothly, Flick is most likely working correctly. (You should ignore warnings from the Trapeze back end about maximum message sizes, array sizes, and unsupported features.)
make verify
. . . if you want to run all of the Flick compiler components and compare their outputs to "known good archetype" copies of the output files (i.e., do regression testing).3

2.4.2 Compiling and Running the Test Programs

The above commands will produce the stub source code files, but will not attempt to compile that code or link it with client or server application code.

The test programs in test/programs/* illustrate how client and server code can use Flick's IIOP, ONC/TCP, Mach 3, and Trapeze runtime libraries in conjunction with Flick-generated stubs. To compile and link the programs in one of these directories, you must first compile the corresponding runtime library and then create the stubs that will be compiled and linked to create the various client and server programs. Once those steps are complete, you can navigate to the test directory and make the directory that you want to compile, e.g.:
         make programs/iiop

That command will compile and link the programs that exercise the IIOP stubs. You may navigate into the programs/iiop directory in order to run the newly compiled test programs. Refer to Chapter 4 for lists of the available command line options.

2.4.3 Additional Tests and Test Programs

The README file in Flick's test source directory contains additional, more detailed instructions for compiling the various test IDL inputs and programs.

The test/examples/phone directory contains the source code for the example application programs developed in Chapter 5. All of the other example application programs in test/examples, however, are out of date and may not compile at all.