Re: MakeMaker and Library filename extensions

[syphilis]

I don't get it, The values in $Config{} should be easily adjustable per build

They are, if you take the ExtUtils::FakeConfig approach:

use Config;
use warnings;
use strict;

print $Config{cc}, "\n";

my $obj = tied %Config::Config;
$obj->{cc} = 'garbage';

print $Config{cc}, "\n";

__END__

Outputs:
gcc
garbage

Do the assigning of the alternate value(s) in a module (say, Config_alt.pm) and load that module before you run the Makefile.PL:

perl -MConfig_alt Makefile.PL

Or, if you want Config_alt.pm to be automatically loaded every time perl is run, just set the PERL5OPT environment variable to -MConfig_alt

Cheers,
Rob

[Anonymous Monk]

Rob, Thank you ... Finally an answer with a technique.

However, A few minutes ago I decided to try ExtUtils::MakeMaker::Config, I figured (because of the wonderful documentation) it was just a local copy of the readonly Config::Config{}, I tried it, it's not readonly, It provides an easily modifiable $Config, A couple of quick tests later shows it does the job smack on ...
Wow, Exactly what is needed!

Of course that leaves me wondering why this is "FOR INTERNAL USE ONLY"

It's construction is initialized from Config::Config.
It's avaliable in Makefile.PL et al.

So now I beg to know what the issue is with it's use and why it's not a documented capability.
One I consider a must have feature!

Off to do more testing with it ...

Thanks

[syphilis]

it was just a local copy of the readonly Config::Config{}

Yes, you can overwrite its values.
That won't alter %Config::Config at all, but as long as the values are taken from this local %Config then you can perhaps make use of it.

However, my preference would still be to overwrite %Config::Config itself as that is cleaner and simpler (IMO).
Also, there might be something in the .pm file or the test suite that looks specifically at %Config::Config rather than this local copy that EU::MM uses.

Cheers,
Rob

[Anonymous Monk]

That won't alter %Config::Config at all, but as long as the values are taken from this local %Config then you can perhaps make use of it.

I've been through the EU code, for the most part it refers to it's local %Config, though there are the following:

In Base.pm: $Config::Config{perlpath})
In Install.pm: $Config::Config{make}
In MakeMaker.pm: $Config::Config{eunicefix}
In MM_Os2.pm: $Config::Config{lib_ext}
In Mkbootstrap.pm: @Config::Config{qw(osname dlsrc)}
In Mksymlists.pm: $Config::Config{archname}
In Mksymlists.pm: $Config::Config{version}
In Mksymlists.pm: $Config::Config{'cc'}
In Mksymlists.pm: $Config::Config{d_vms_case_sensitive_symbols}


Love the consistency ...


So as I see it as long as you don't want to muck with the above listed values one should be good to go using ExtUtils::MakeMaker::Config in ones Makefile.PL.
Obliviously this is only going to work within the scope of the current Makefile.PL.

However, my preference would still be to overwrite %Config::Config itself as that is cleaner and simpler (IMO).

I agree, However it appears big brother does not ...

I still find this does not serve my needs.
For my needs the real issue is, on *nix, ExtUtils::Liblist::Kid will not allow fully qualified library names.

The standard technique for including a Static library over a Shared library is to use the fully qualified filename without the '-l' library tag. As in:
-L/usr/local/lib /usr/local/lib/libmylib.a
This tells the make tool chain to blindly use it, where '-lmylib' says search for libmylib.so (or versions of it) if found use it, if not look for libmylib.a (or versions of it).

ExtUtils::Liblist::Kid ignores and tosses out anything that doesn't have either a '-L' or '-l' tag.

My words for ExtUtils-MakeMaker: If you don't understand it, pass it on ... Don't toss it!
Someone may be smarter then you and know what to do with it!

And I don't mean a human ... I mean the make tool chain.

Peace out.