On Monday, Nov 18, 2002, at 08:43 US/Pacific, John Adams wrote:
I've been happily using Fink to install some of my software, and I'mthere are several basic arguments here that need to be addressed.
considering whether I'd be better off putting Perl in /sw/bin instead of
/usr/bin.
Any thoughts, pro or con?
martin has pointed towards a 'name space solution' by having
your PATH environmental set to include the three basic sets
/usr/local/bin:/sw/bin:/usr/bin
which addresses a part of keeping the three possiblely different
'perl executables' - and their associated 'configurations' in three
different name spaces. This strategy forgets that PATH is a first
come first served solution. So if your scripts/code call out a
specific perl
#!/usr/bin/perl
#!/usr/local/bin/perl
#!/sw/bin
you are mostly sorta safe, since they will pick 'the right one'
for you - sorta, kinda.... Remember that it is not only the 'perl
executable' itself that gets delivered, there are things like 'perldoc'
and other applications that have a 'sense of presence'. Nothing more
fun that typing
perldoc <something>
and finding that the version of perldoc in /usr/local/bin is not
the same as in /sw/bin from /usr/bin ... Which allows one to see
things related to the 'perl' that was built in each...
The most aggressive solution I have seen in this space has been to
expressly define which perl you REALLY MEANT.
#!/usr/bin/perl5.6.0
#!/usr/perl/perl5.8.0
since /usr/bin/perl and /usr/local/bin/perl are really only links
to the 'executable' /usr/bin/perl.<vers> - At one time I had
implementations of perl back to perl4.<???> - since when you
build a new perl - it installs the new 'numbered' version and
then links to it as /usr/.../perl
All of this avoids the problem of where did you actually go and
stuff which sets of libraries for what....
To understand a part of why the Fink Folks have gone to /sw as
their name space - it helps to understand the 'build time linkage problem'.
{ WARNING: this gets a bit technical for those accustom to pure perl modules,
but bear with me... }
The reason that there is an 'architecture dependent' section of the @INC
is for those modules that have 'bundles' { aka: dynamically loadable libraries,
shared objects, etc... } created from non-perl code ( C, C++, assembler, ... )
that is actually compiled into a run time linkable library that the pure
perl section knows how to access . ( cf perldoc perlxs, et al )
This is simple enough when you build your 'dynamically loadable library'
with everything that it needs already resolved internally. But gets to
be more complex IF your code expects that some of it will be resolved
at run time from other 'dynamically loadable libraries'. Allow me
to illustrate: my Dtk::Happy perl module will rest on top of some
c-code that has open symbols since it expects to find lib_dtk_smile.$EXT
and lib_dtk_mania.$EXT at run time.
EITHER
a) I have to contaminate the system LD_LIBRARY_PATH so
that all dynamically loadable modules will get to see my
two libraries as well.
b) put my libraries some place special
b1: oblige the user to update their LD_LIBRARY_PATH/LD_RUN_PATH
environmental variables to find that happy place
b2: build my perl module with the '-R' flag that inserts that
it will search say "/sw/lib/dtk" as the first place
at run time.
It's this 'b2' option that makes things "simpler" since the installer
now just WHACKS in the two external bundles into /sw/lib/dtk and
the Happy.bundle down in
/Library/System/darwin/Dtk
or say:
/sw/lib/perl5/darwin/Dtk
will be content to resolve all open symbols at run time...
This way I can ship out the actually compiled stuff for folks,
and they can get it put into place where it will all belong and
work and play well. The end user does not have to actually install
a compiler on their machine from the Developer Toolkit, and all
is wonderful with the world.
{ except of course that I have to have the source code for
lib_dtk_smile.$EXT and lib_dtk_mania.$EXT with all of the fun
filled
#ifdef _MAC_OS_STUFF
.....
#....
#endif
for all the bits and bobs uniq to each OS... but I need only
maintain the dynamically loadable library and NOT have to change
any of the 'perl code'.... }
I take us down this side of the 'software maintenance side' of the
problem - since if folks understand this part of the problem - they
will perchance better understand why it may be simpler to 'rebuild
their perl' to include the /sw perl sections as a default part of
the @INC ... or not...
So the 'correct' answer is
how much time do you have to do which types of maintenance?
ciao
drieux
---
