cdarke has asked for the wisdom of the Perl Monks concerning the following question:

I am struggling to get MakeMaker to integrate an extra DLL into a build.

I have an XS module, with its associated bits & pieces generated by h2xs. All is fine, and nmake all works for the main module. However, I have another DLL, (EnvProcessDll) which does not use XS or anything perly, required to be built at the same time (this is going to be used for DLL injection). I added this to Makefile.PL:
sub MY::postamble {
    return <<'MAKE_FRAG';
    
Dll: EnvProcessDll.c
    $(CC) $(CCFLAGS) EnvProcessDll.c  /link /OUT:.\$(INST_ARCHLIB)\aut
+o\$(FULLEXT)\EnvProcessDll.$(SO) -dll
MAKE_FRAG
}

[download]
This generates a Makefile where the target, Dll, can be built using nmake Dll. How do I arrange Makefile.PL so that this target is included in nmake all?

I could just document the extra nmake, but I intend to put this on CPAN and the extra step would be missing by those reluctant to RTFM.

Replies are listed 'Best First'.
Re: MakeMaker tailoring
by randyk (Parson) on Jan 24, 2008 at 04:18 UTC
    Do you have to make and install the EnvProcessDll dll separately? If not, you might take the approach of Math::FFT; in this, there's an XS file (FFT.xs), plus a couple of pure C files (arrays.c and fft4g.c) to supply some needed functions. The associated Makefile.PL: 
    my %opts = (
            'NAME'           => 'Math::FFT',
            'VERSION_FROM'   => 'FFT.pm',
            'OBJECT'         => 'FFT.o fft4g.o arrays.o',
           );
WriteMakefile(%opts);

    [download]
    writes a Makefile to compile and link all the files needed to build the extension.
[reply]
[d/l]
      If I understand you correctly, that will compile the files as seperate relocatable objects, and link them with perl.

      The idea of my code is that the DLL is "injected" into another process, which is probably non-perl. This is done by waving a magic wand and sacrificing a goat (but not necessarily in that order). The DLL has to be a discrete executable in order for the alien process to run it.

      Thanks anyway.
[reply]
        I don't believe that the presence of the XS interface would preclude the use of the dll for injection into other processes. Just provide your normal dll interface for your other code in addition to the XS stuff. So one copy will be loaded with perl and use the XS interface, and when you inject the DLL into other processes, the other processes will use the other interface.

        Note: I'm assuming Windows here (where the above will work). I've not tried it in *NIX, though I don't know of any reason that it wouldn't work there.

        Alternatively, can't you just add your rule to build the other DLL and add it as a dependency to the XS DLL?

        ...roboticus

[reply]
        In this case, would something like the following work? 
        package main;
use strict;
use warnings;
use ExtUtils::MakeMaker qw( WriteMakefile );
my $parms = {
    NAME            => 'Module::Name',
};

WriteMakefile( %$parms );

package MY;

sub postamble {
    return <<'MAKE_FRAG';
new_target:
    $(PERL) -e "print qq{Hello from new_target\n}"

MAKE_FRAG
}

sub top_targets {
  my $inherited = shift->SUPER::top_targets(@_);
  $inherited =~ s/(\npure_all\s+::.+)/$1 new_target/;
  return $inherited;
}

1;

        [download]
        This adds a new new_target target, which is then carried out at the nmake stage, without having to specify nmake new_target explicitly.
[reply]
[d/l]

Back to Seekers of Perl Wisdom