> From: Ludovic Rousseau <[EMAIL PROTECTED]>
>
> Le Monday 23 August 2004 � 16:41:43, Bruce Barnett a �crit:
> > Here's the output of pcscd. Note the tokenparser error I didn't get
> > before. I think this is because the mscBundle is now in the same
> > directory I had other bundles (/local/pcsc/lib/drivers).
>
> Why did you installed the musclecard bundle in /local/pcsc/lib/drivers/
> and not in the default directory?
I've been meaning to answer this one.
And since Carl asked:
>I tried installing pcsclite and musclepkcs11 into non-standard
>locations, but they still installed some things into /usr/local/pcsc.
>Is there no way to get rid of this apparently hard-coded dependency?
I'd figure it was time for me to send my solution in.
When I try to configure the system using
configure --prefix=/local/pcsc
I get:
enable USB drop directory : /usr/local/pcsc/drivers
enable MuscleCard bundles dir : /usr/local/pcsc/services
enable confdir : /etc (default)
instead of what I expected:
enable USB drop directory : /local/pcsc/drivers
enable MuscleCard bundles dir : /local/pcsc/services
enable confdir : /local/pcsc/etc
So I have to specify nearly each and every directory to make sure
things work.
Also - this is the first time I have been exposed to bundles. It
wasn't clear to me that "bundles" functionality are defined by
location, instead of bundle contents. So at first I tried to put
the "service"-flavored bundles in
the same place as all of the other bundles. I.e. in
/local/pcsc/lib/drivers. But I spotted my error.
You know, it would be really nice if there was a single file that
could define the location of all of the directories needed. Assigning
them names in a consistent fashion would help a lot in merging
together packages from different developers, and packages such as
opensc/OCF/muscle/JCOP/etc.
For example, suppose you have a file called "env.sh" (or "ENV" as I
said before) placed in the top of the PCSC tree (normally
/usr/local/pcsc). It might look like this:
#-------------------cut here----------------
#!/bin/sh
# File env.sh
# usually you source this file using "."
define() {
# $1 is the environment variable. If it's not defined, use argument #2
eval "$1=\${$1:-$2}"
export "$1"
}
define PREFIX "/usr/local" # Top of tree - might be many projects
define PCSC "$PREFIX/pcsc" # Top of the PC/SC code tree
define USB_LIB "/usr" # Location of ./include/usb.h and
./lib/libusb.so
define PCSC_INCLUDE "$PCSC/include" # Location of all PCSC include files
define PCSC_LIB "$PCSC/lib" # Location of all PCSC libraries
define PCSC_ETC "$PCSC/etc" # Location of all PCSC config files
define PCSC_USB_BND "$PCSC_LIB/drivers" # Location of all USB bundles
define PCSC_MSC_BND "$PCSC/services" # Location of all musclecard bundles
define PCSC_RUN "$PCSC/run" # Location of PCSC runtime files
define PCSC_HOME "$PCSC" # Used by JCOP
define DESTDIR "$PCSC" # Used by muscleframework
# etc etc.
[ "$#" -gt 0 ] && eval $@
# END of file env.sh
#------------------end-of-file
As you can see, it's easy to understand, customize, and to add new names/directories.,
which are relative to previously listed directories.
If I want to change the top/PREFIX, it's just one line, and not a dozen.
And there is another benefit that if you define any of these before you source the
file,
then that value overrides the value in this file.
This makes it handy when you want to debug something new in a different directory
without making a permanent change.
For simple scripts, such as David Corcoran's
muscleframework-1.1.5/MCardPlugin/installBundle file, it's simple to replace the lines
-----------------------
if [ x$DESTDIR = "x" ]
then
DESTDIR=/usr/local/pcsc/services
fi
-----------------------
with
-----------------------
DESTDIR=${PCSC_MSC_BND:-/usr/local/pcsc/services}
-----------------------
(I had to modify this file because installBundle seems to ignored the
value of --prefix=). I wish I didn't have to modify so many of the scripts
that use different conventions, in strange places.
This line keeps backwards compatability, while adding new functionality.
And it's shorter as well. But for someone to specify an alternate
location, the env.sh file has to be sourced, or the variable has to be
set beforehand. Perhaps it might be more robust to add this piece
of code in front, to make sure:
-----------------------
if [ -f ${PCSC:-/usr/local/pcsc}/env.sh ]
then
. ${PCSC:-/usr/local/pcsc}/env.sh
fi
DESTDIR=${PCSC_MSC_BND:-/usr/local/pcsc/services}
-----------------------
So the new script is backwards compatable, yet gains new functionality in a few lines.
As for pcsc-lite, (and other programs) I have added a file called "Configure" as a
wrapper
for ./configure. It contains
#-------------start of file----------
#!/bin/sh
# My personal preferences
CUSTOM="--enable-daemon --enable-debug --enable-threadsafe --enable-debugatr"
#now add the snippet from before to set the values if they are undefined....
if [ -f ${PCSC:-/usr/local/pcsc}/env.sh ]
then
. ${PCSC:-/usr/local/pcsc}/env.sh
# then run config with the parameters set:
./configure --prefix=${PCSC} --enable-libusb=${USB_LIB}
--enable-confdir=${PCSC_ETC} \
--enable-runpid=${PCSC_RUN}/pcscd.pid --enable-usbdropdir=${PCSC_USB_BND} \
--enable-muscledropdir=${PCSC_MSC_BND} $CUSTOM
else
# Use standard locations
./configure $CUSTOM
fi
#----------end-of-file---------
This way, I can reuse my personal Configure file on upgrades. I just copy it into the
directory and reconfigure.
Yet others can use this even if their directories are in a different location.
So it's more than a localization.
I mentioned earlier about the advantages of this approach.
Some of them include:
* ability to support more than one revision of code on the same machine
* ability to select optional libraries of different revisions (like
using the USB libraries in /usr vs. /usr/local, or testing beta vs released code)
* Ability to test compatabilities between different packages without
affecting others using the same directory structure
* allowing development work minimizing working as root, and without
making /usr/local more vulnerable by allowing your main account to
write to it.
But the biggest issue is selecting names that everyone agress too.
I don't expect everyone to change to my system, but it would be very useful
if we at least agree on the NAME of the variable.
I used PCSC_* as a prefix to the name to isolate the PCSC variables from
other code trees and other projects. This is wht I don't like "DESTDIR" as a choice.
Perhaps others might find this useful
Cheers,
Bruce Barnett
_______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.drizzle.com/mailman/listinfo/muscle
