I'd like to propose some techniques that have helped me in the past
for project management.
In
> pcsc-lite-1.2.9-beta4: Ludovic Rousseau
was the following change
> 3 July 2004
> - src/libmusclecard.pc.in and src/libpcsclite.pc.in
> . includedir is now @includedir@/PCSC
I (currently) install every PCSC application into /local/pcsc and this
change moves the include files from
/local/pcsc/include
to
/local/pcsc/include/PCSC
No big deal, but I thought this was an opportunity to bring up a
technique that I have found useful. I think others might also find it
convenient.
I'd like to describe why I use the structure /local/pcsc instead of
what is normally done. I think there are several advantages. In many
team projects I have been involved in, we have multiple revisions
co-existing on the same file system. We have distributed systems with
replicated software, yet we want to allow each developer to be able to
choose which release they want to use, without affecting others, even
on the same computer.
This allows us to prepare for a demo using a new release, and if we
want to, to change to an earlier release of libraries, executables,
etc. without changing any files. Therefore we can go back to an easier
(working) release seconds before the demo. Life on the edge.
We do this with a tree organization, with the top of the tree
corresponding to the revision of the project. In this case, I use
/local/pcsc as the top of the tree, with ./bin, ./include, ./lib, and
./etc underneath. Here are some of the advantages:
*) Having all of the PCSC files in a single directory makes it
easier to backup, install and archive a complete suite of
compatible packages. This also allows having simultaneous
revisions of the software, and the ability to choose which
one to use (e.g. I can have a /local/pcsc symbolic link point
to /local/pcsc.rev6).
*) By use of environment variables, (or symbolic links) I can
at run time choose which release to use when doing
testing/development. I also use environment variables to
define subdirectories, such as the include directories,
libraries, config files, etc. By using environment variables
corresponding to the different directories, I can select and
combine any coimbination of include files, libraries, etc. as
I wish, without affecting any other developer using the same
directory structure.
*) This does not interfer or break anything that is installed
in /usr/local or /usr. I don't have to worry about installing
some package using apt/yum/up2date that over-writes a file I
have already installed.
*) I can, as a developer, have the permissions of the top
level directory different from /usr or /usr/local. Therefore
I can install files into this directory without root
permissions, or without compromising the security of the rest
of the system. If I instead install files in /usr/local, I
either have to loosen the permission to allow me to update
files from my developer's account, or I have to do a majority
of the development work as a priviledged account. Both of
these options increases the risk of someone else of the
computer from priviledge escalation.
To give an example of how it might work in practice, I have a file
that defines environment variables in a tree structure. The file -
call it "ENV" might look like this:
#!/bin/sh
# usually you source this file using "."
vset() {
# $1 is the environment variable. If it's not defined, use argument #2
eval "$1=\${$1:-$2}"
export "$1"
}
vset PCSC "/use/local/pcsc"
vset PCSC_INCLUDE "$PCSC/include"
vset PCSC_LIB "$PCSC/lib"
[ "$#" -gt 0 ] && eval $@
#------------------end
so if you do a ". ENV" you get
PCSC=/usr/local/pcsc
PCSC_INCLUDE=/usr/local/pcsc/include
PCSC_LIB=/usr/local/pcsc/lib
--------------------
however, if you execute
PCSC=/local/pcsc.NEW
export PCSC
You would get
PCSC=/local/pcsc.NEW
PCSC_INCLUDE=/local/pcsc.NEW/include
PCSC_LIB=/local/pcsc.NEW/lib
Or if you executed
PCSC_INCLUDE=/local/pcsc.OLD
export PCSC_INCLUDE
. ENV
you would get
PCSC=/local/pcsc.NEW
PCSC_INCLUDE=/local/pcsc.OLD/include
PCSC_LIB=/local/pcsc.NEW/lib
Notice how this case uses the new LIB directores, but the old INCLUDE directories.
Therefore each user is allowed to mix and match include files, libraries, etc.
This makes regression tests, demos, revision management easier, etc.
Also - by having the command
[ "$#" -gt 0 ] && eval $@
at the end of the ENV file, users can use it like this:
ENV nterm & # launch a new terminal - and shell
ENV run_demo # run the demo with a special environment
ENV bash # start a new shell with the desired environment
as well as simply
. ENV
I have found this useful in the past. Others might also find it useful.
In conclusion:
1) Archive management is easier
2) Multiple revisions can co-exist on the same file system
3) Users can personalize which revision they use without
affecting others, and select which revision to use at run
time
4) Users can mix and match revisions of libraries, include
files, executables, etc.
5) It's more secure in a development environment
Comments?
- Bruce Barnett
_______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.drizzle.com/mailman/listinfo/muscle
