Shared objects should be installed to the usual location

1 view
Skip to first unread message

Sisyphus

unread,
Sep 17, 2008, 4:19:53 AM9/17/08
to gsl-dev
Hi,
(The view expressed in the subject line is just an opinion - though I would
think it's an opinion shared by many.)

Currently, all of the Math::GSL shared objects are being installed into
$Config{installsitearch}. This is unusual, to say the least. It means that I
have nearly 50 shared objects sitting together in the same folder, and
alongside various .pm and .pod files.

One would normally expect that each of these shared objects would be
installed in separate directories - ie that we would have:

$Config{installsitearch}/auto/Math/GSL/BLAS/BLAS.so
$Config{installsitearch}/auto/Math/GSL/BSpline/BSpline.so
$Config{installsitearch}/auto/Math/GSL/CBLAS/CBLAS.so
.
etc.

Everything works ok as it stands ... it's just very unorthodox, and rather
untidy (imo).

Math::GSL doesn't have exclusive rights to the $Config{installsitearch}
directory. Bit::Vector, eg, could at some stage in the future also decide
that it's going to install its Vector shared object into
$Config{installsitearch} ... whereupon we have the same folder
($Config{installsitearch}) having to provide 2 instances of Vector.so ...
one Vector.so for Bit::Vector and another Vector.so for Math::GSL::Vector.
This would not work well at all :-)

With this patch to inc/GSLBuilder.pm, the shared objects get installed into
the locations that one normally expects:

-------------------------------------------------
--- GSLBuilder.pm_orig Wed Sep 17 16:31:42 2008
+++ GSLBuilder.pm Wed Sep 17 17:11:53 2008
@@ -2,6 +2,7 @@
use Config;
use File::Copy;
use File::Spec::Functions qw/:ALL/;
+use File::Path;
use base 'Module::Build';

sub process_swig_files {
@@ -35,11 +36,8 @@

# The .so files don't go in blib/lib/, they go in blib/arch/auto/.
# Unfortunately we have to pre-compute the whole path.
- my $archdir;
- {
- my @dirs = splitdir($file_base);
- $archdir = catdir($self->blib,'arch', @dirs[1..$#dirs]);
- }
+ my $archdir = catdir($self->blib,'arch','auto','Math','GSL',
$file_base);
+ File::Path::mkpath($archdir) unless -d $archdir;

# .o -> .so
$self->link_c($archdir, $file_base, $obj_file);

-------------------------------------------------

I've tested that on Windows, but not on linux - where I expect it will work
equally well. Perhaps there's a better way of achieving the same result. (I
don't know.)

In the original GSLBuilder.pm code I couldn't see what is supposed to be
achieved by @dirs:

-------------------------------------------------
my @dirs = splitdir($file_base);
$archdir = catdir($self->blib,'arch', @dirs[1..$#dirs]);
-------------------------------------------------

Afaict @dirs contains just the one element ($file_base) and @dirs[1..$#dirs]
doesn't exist. Sorry if I've overlooked something important there.

File::Path is core (and has been for a long time), so there's no problem
with the inclusion of that module.

Obviously, even with that patch, the shared objects that, with a previous
build, were installed into $Config{installsitearch} are still going to be
there. That's not a problem - the newer shared objects installed into
$Config{installsitearch}/auto/Math/GSL/whatever will be found (and loaded)
first.

Thanks guys !!

Cheers,
Rob


Jonathan Leto

unread,
Sep 24, 2008, 6:04:19 AM9/24/08
to math-g...@googlegroups.com
Hola,

This looks sane and reasonable, I will apply it as soon as I get back
in the states (sometime tomorrow). I have been attending a friends
wedding in the south of france, which is why I have been
incommunicado.

Cheers,

--
[---------------------]
Jonathan Leto
jal...@gmail.com

Jonathan Leto

unread,
Sep 27, 2008, 9:38:46 AM9/27/08
to math-g...@googlegroups.com
Howdy,

> In the original GSLBuilder.pm code I couldn't see what is supposed to be
> achieved by @dirs:
>
> -------------------------------------------------
> my @dirs = splitdir($file_base);
> $archdir = catdir($self->blib,'arch', @dirs[1..$#dirs]);
> -------------------------------------------------
>
> Afaict @dirs contains just the one element ($file_base) and @dirs[1..$#dirs]
> doesn't exist. Sorry if I've overlooked something important there.

This was inherited spaghetti code, thanks for cutting it out. Your
patch is now in the latest bleed.

Cheers,

Reply all
Reply to author
Forward
0 new messages