Phil is a library for portability. Phil makes use of what Autoconf reports so that your C/C++ or Java app doesn't have to. The Phil docs also discuss portability issues that might be of use even without Phil.
Phil is a portability library for flavors of Unix. It includes a C library, some programs & code for portable shell programming, some tips for portable makefiles, & this documentation, which describes installing Phil, writing programs to make use of Phil, & general portability tips.
Phil is the Portable Header Interface Library. Alternatively, Phil is a C library that fills in the holes in an operating system & accompanying C library by ensuring that all the usual functions & data types of Unix & Standard C are defined.
Unpack the distribution.
If the distribution came in a file with a name of the form phil-m.n.tar.gz, you can unpack it like this: zcat phil-m.n.tar.gz |tar xf -.
If the distribution came in a file with a name of the form phil-m.n.cpio.bz2, you can unpack it like this: bzcat phil-m.n.cpio.bz2 |cpio -i.6.1
Either way, you'll end up with a directory called phil-m.n in the current directory.
# cd phil
Running ./configure with no options will setup Phil to install with default options. It's possible to override many of those options. For example, it's possible to change the directory into which Phil installs. To use those options, read the ``Options to ./configure'' section, below.
You might notice a program called make-makefile. It's a wrapper around ./configure, & it's for Phil's developers to use. While running make-makefile as a user will probably work just fine, it's not guarranteed. Still, users who need to supply lots of options to ./configure because of their operating system or compiler system might fine some useful templates, hints, or starting points in make-makefile.
Remember: make-makefile is intended for Phil's developers. Users should endeavour to ignore it.
This builds the Phil library, programs, & test programs.
# make check
This runs the Phil test programs. In general, a test program prints nothing if it works. Let me restate that: If a test program succeeds, it doesn't print anything. If all the tests work, you'll see a list of the tests that ran; the list was printed by make. You won't see any other output. If a test fails, it will print a diagnostic message, & the make will fail.
I do this (make test programs print nothing if they succeed) so that you can glance at the list of tests as make runs them & easily determine whether they succeeded. After all, that's what you care about. You don't want or need to read through a long, ugly, stream of output from a bunch of test programs to determine whether the tests succeeded. Success or failure should be binary, & should be easy to determine at a glance.
There are some exceptions to this rule. Some tests will print warnings even if they succeed. I consider these bugs & intend to fix them. Seeing a ``warning'' message from a test program does not mean that all the tests failed, though it is ugly.
# make install
This will install Phil. See a section below for a discussion of what gets installed where.
Sort of an interactive final test. It should print your home directory, just like echo would.
If you see a ``program not found'' or ``no such file or directory'' message, it's possible that the directory into which Phil was installed is not in your path.
What's New in This Release:
· Phil now compiles to a shared library where appropriate.
· It does this by using 'libtool' as a wrapper for compiling, creating libraries, & linking.
· (So Phil can't take the credit for managing the shared libraries. 'libtool' should get all the credit.)