Sisyphus <[EMAIL PROTECTED]> writes:
>> Two main ways:
>> A. Compute something in Makefile.PL before calling WriteMakefile
>> and adjust args passed to that so that vars end up the way you want.
>> In this case it means adding something to
>> LIBS =>
>> passed in. (This is what Tk does - it is well behaved for once.)
>>
>
>I can't get that to work - but then there's something a little unusual
>in what I'm trying to do.
>
>I'm using 'nmake' and MSVC++ 6.0, and the 'EXTRALIBS' specified are the
>usual MSVC libs. But I need to link to my MinGW libgcc.a and libg2c.a
>files.
Latter shouldn't be a problem if you link with MinGW?
>This works - if I manually add those 2 files (specifying full
>paths) to the EXTRALIBS and LDLOADLIBS in the generated makefile, then
>'nmake' runs fine. I just need to find a way to get Makefile.PL to do it
>for me. (Makefile.PL has no problems in finding the full path to those 2
>files, btw.)
>
>If I do:
>LIBS => ['-LD:/MinGW/lib -lg2c'],
>
>then that has absolutely no effect on 'EXTRALIBS', which continues to
>list the same MSVC files as in the past. Of course, even if it did have
>an effect on EXTRALIBS, it would be the wrong effect as it would add
>something like D:/MinGW/lib/libg2c.lib to the EXTRALIBS list - which is
>still not one of the files that I want.
Ah.
>
>> B. A MY::something which messes with the data structures via the
>> object passed to it as 1st arg.
>> In this case it needs to be something at or before const_loadlibs
>> so this would work.
>>
>> package MY;
>> sub const_loadlibs
>> {
>> my ($self,@args) = @_;
>> # diddle with $self - you have to poke about in real const_loadlibs
>> # do find out where things are.
>> return $self->SUPER::const_loadlibs(@args);
>> }
>>
>
>I don't really understand that - I'll take a look tomorrow when I have
>some time (especially if that's the way to fix this problem).
That can't fail to fix the problem as you can set string to
anything you like.
One way to find out where they are is:
package MY;
use Data::Dumper;
sub const_loadlibs
{
my ($self,@args) = @_;
# diddle with $self - you have to poke about in real const_loadlibs
# do find out where things are.
print Dumper($self);
return $self->SUPER::const_loadlibs(@args);
}
Another idea might be to add the MinGW .a files to OBJECT or O_FILES
as we know MS's standard MS's are not going to reference anything in there.
>
>My current fix is to have a perl file named 'makefile.fix' which
>determines the full path to the 2 '.a' files and rewrites the generated
>makefile, adding those 2 files to the EXTRALIBS and LDLOADLIBS list. So
>I run:
>
>perl Makefile.PL
>perl makefile.fix
>nmake
>
>But that seems embarrassingly deplorable - especially if there's a
>perfectly sensible way to have the Makefile.PL do the work of makefile.fix.
Not that deplorable if you hide the mess ;-)
That is you could "do" the things makefile.fix does in Makefile.PL
after WriteMakefile() returns having writen the Makefile.
Reopen it and fix it. Then exit and 'user' is none the wiser...
>
>Cheers,
>Rob
