What is here?
This project consists of libraries and utilities that I developed over
time and which I found very useful, of which a "property manager" is
one small part. It is extremely misnamed, but so be it.
Here-in you can find the following:
| nssilib |
This is a library containing useful routines for:
parsing
ftp
daemonizing
tagged logging
argument vector management
string management
timer queue
property management
NSLink client API for querying and updating properties stored in NSLinkd
|
| hotmon |
A hotfolder daemon configurable via the property manager.
This can monitor any directory or set of directories, watch for
changes to files, look for files matching regular expressions, etc. and
perform some action or set of actions on those files.
Note:
This was originally developed to work with FTM, a "File Transfer
Monitor" daemon and would send files about the network using the FTP
protocol. Unfortunately I cannot offer FTM in this package as I
developed it for a client and they now own it. Perhaps one day I
will write something similar as a replacement.
|
| NSLinkd |
A daemon that manages properties, connects to other NSLinkd
daemons through the network, and replicates properties to ensure
"nearness" to the clients. |
| nslcmd |
A command line interface to NSLinkd |
| pmu |
The Property Manager Utility. This command line utility
is useful for debugging complex property files. It can pretend to
be any application that uses the property manager and provide traces as
to how a property is resolved. |
 t_* |
A collection of simple test utilities |
Documentation:
Getting the source from CVS
On your local machine open a shell window and "cd" to the directory
where you'd like the source code deposited. Then enter the
following commands:
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/propmgr login
If you are prompted for a password just hit the ENTER key. You may get an error about no .cvspass file .. ignore it.
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/propmgr co -P common
The above will check out common files such as project headers, make file definitions, etc.
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/propmgr co -P propmgr
This gets you the meat of the source code.
Building
Prerequisites
You will need the following tools:
| banner |
This is a little program that, given a string, displays it in
large letters across the screen. It is not necessary to build
this project but is fun to have. With it your "make" process will
show you each component that it is working on. Without it you
will just get harmless error messages that it cannot find "banner".
Your linux distribution may include this as "sysvbanner".
If you google for "sysbanner" I am sure that you can find the
sources. Built it and rename it to "banner" in some directory in
your $PATH. |
| cproto |
Builds prototype statements from C
source code files. The propmgr system dynamically builds
prototypes and puts them into "*.ph" files in the "proto/" directory
beneath each component..
Note:
Unfortunately cproto is stalled at version 4.6 and has not been
updated since October, 2000. You will need at least version 4.6c
(the CVS version) as there is a bug in it that has been corrected in
the CVS repository. Please follow the directions on the project
home page and build a copy from CVS. Then make sure that this is
the copy that appears first in your PATH.
I find that the following sequence works pretty well:
mkdir src
cd src
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/cproto login
<ENTER to the password prompt>
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/cproto co -P cproto
cd cproto/
./configure
make
cp cproto /usr/local/bin/
|
| Gnu make |
This comes with any modern linux distribution. |
| bash |
The shell scripts, particularly those
kicked off by the make process, are written for bash. Once upon a
time they were compatible with ksh and they may still be, but no
guarantees. |
Environment
There is a script in the common/scripts directory named "project" which
is very useful for switching from project to project and setting up
your environment for you. Copy this to an area in your path and
source it either directly from the shell or by way of your .bashrc or
.bash_profile. The "project" script looks for an ASCII text file
in your home area named ".projects". The format is simple: a name
followed by white space and then a directory.
Sourcing the "project" file (for example via ". /usr/local/bin/project"
assuming that you put it in the /usr/local/bin directory) will add a
couple of commands to your shell (via aliases):
| project name |
The name
field is looked up in your $HOME/.projects file, either as a direct
match or as the best abbreviation of it. If found then the script
will:
- Change to the directory associated with that name
- Remove all directories of your previous project from CDPATH
- Source a hidden ".project" directory if one exists in that directory
- Add all subdirectories from the new project to your CDPATH.
This lets you simply "cd component" to quickly change to any
component directory within the project.
|
| project |
When given by itself (with no argument)
the "project" command will change to the top directory of the existing
project. If no project has yet been set then an error message is
displayed. |
project ?
projects |
These two commands are equivalent, they both will list out the projects that you have defined in your $HOME/.projects file. |
You will need to create a .projects file in your home directory.
Assuming that you've put the CVS sources into $HOME/src then you
might create the file to look like this:
| common |
~/src/common |
| propmgr |
~/src/propmgr |
Once you have done this you can then simply type "project common" to
quickly go to the root of your "common" area or "project propmgr" to go
to the root of the property manager area. In addition your
.project files from each area will be sourced and thus your environment
setup. Btw you may want to look at the default .project files in
the root of both areas to ensure that they are setup correctly.
Build the common area
The common area must be built first as this contains project wide
definitions and a header file generated for your specific system
(typedefs.h). Build this using the following commands:
project common
make
Note that the above assumes that you've named the common area "common"
in your .projects file. Substitute the appropriate name if you
chose something different.
Upon completion of the make (which will be very fast) you should see something similar to the following:
> ls bin
BumpBuild cc_intr.sgi
> ls include
defines.h p_acc.h p_icc.h project.h p_sgi.h typedefs.h
nstypes.h p_gcc.h platform.h projend.h p_sunpro.h
The "lib/" directory will be empty as there are no libraries produced.
Build the property manager
This is equally simple and requires the following commands:
project propmgr
make
At the conclusion you should be able to do the following:
> ls bin
hostent hotmon.property nslcmd.property NSLinkd.property NSLsr Updater
hotmon
nslcmd
NSLinkd
nslog
pmu
> ls include
argv.h
daetach.ph memlib.h
nslog.ph objmgr.h
proclib.ph symbol.h
argv.ph
ftplib.h memlib.ph
nsplog.h objmgr.ph
property.h symbol.ph
attribute.h
ftplib.ph msgtag.h
nsplog.ph path.h
property.ph timemgr.h
attribute.ph
hash.h msgtag.ph
nsregexp.h path.ph
siglib.h timemgr.ph
crc32.h
hash.ph nslapi.h
nsregexp.ph pidfile.h siglib.ph
crc32.ph
help.h nslapi.ph
nssocklib.h pidfile.ph strlib.h
daetach.h
help.ph nslog.h
nssocklib.ph proclib.h strlib.ph
> ls lib
nssilib.a
About the process
The top level make for each project (common and propmgr) builds all of
the components beneath it and creates areas (such as "bin/", "include",
"lib") into which each component exports its product. Thus the
"bin/" directory receives executables, the "include/" receives include
files, and the "lib/" receives libraries.
Components may also separately be built. You can "cd
~/src/propmgr/nssilib" and then "make" to build just that library
component.
A top level build is done in multiple passes. During the first
pass the source code is scanned for functions and ".ph" files are
produced, each containing the prototype definitions for the
corresponding source file. To reduce clutter these are deposited
into a "proto/" subdirectory within the component area. Prototype
files that are important to external components (for example if this
component is a library) are exported to the project's include/ area.
Dependency files are also built during this pass and similarly
deposted to a separate "depend/" subdirectory within the component area.
The second pass is used to allow each component to post intermediate
files to the top-level project directories. Thus libraries may
export their include and prototype files so that other components can
access them.
The third pass is where the actual build of each component occurs.
All object files are accumulated into "obj/" subdirectories.
The product file is then built and left in the top level
component area.
The last pass allows each component to "post" what it produced into the project's "bin/", "/include/", or "lib/" area.
Note that the top level Makefile has a special rule called
"CheckProducts" If you do a "make CheckProducts" this will
descend the build area and check that each product was actually built
and successfully posted to its respective area.