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

I want to include an extra .c file when building a .xs module. My Makefile.PM currently uses ExtUtils::MakeMaker, but if I have to switch to Module::Build to accomplish the purpose, that's OK. I would like to contribute the module to CPAN in the future.

The reason for the separate .c file is that I copied several source functions out of a standard library package written in C, made some small modifications to them, renamed them, and want to include them in the .so file with my module. The mods were to comment out lock and unlock operations so that the locking can be done at a higher/outer level in my .xs module.

It doesn't seem like a good idea to '#include' the resulting .c file in my .xs file, because the code from the other library wants to be compiled with the same .h file as is in my .xs, but with the '#include' preceded by a '#define private' statement as in the file from which I copied them.

man/perldoc ExtUtils::MakeMaker mentions a 'C' => [array of c files] option. If the list includes the .c file produced from my .xs file, the build proceeds as if the option is omitted from the MakeMaking, otherwise nothing at all is compiled. Including the name of the other .c file in this array doesn't cause it to be compiled.

What's the best way to set up building this module?
cmac
www.animalhead.com

Replies are listed 'Best First'.
Re: extra .c file in .xs module building
by syphilis (Archbishop) on Jan 18, 2009 at 02:55 UTC
    Does specifying the object file in 'OBJECT' have the desired effect ? 
    OBJECT => 'module_name.$(OBJ_EXT) extra.$(OBJ_EXT)',

    [download]
    Update: The 2 stops (.) are wrong and it's probably better expressed as: 
    OBJECT => '$(BASEEXT)$(OBJ_EXT) extra$(OBJ_EXT)',

    [download]
    I gather that if you specify one object file, then you need to specify *all* object files that are going to be built. (And I don't know whether that's all that's required to get it to work.)

    Cheers,
    Rob
[reply]
[d/l]
[select]
      That did the trick. Many thanks!!

      Now I don't seem to have "memclr" in my library paths. The "helper" program that's used in Makefile.PM outputs "-L/usr/local/lib" which goes into the LIBS array.

      Do you (or anyone) know if memclr is deprecated in favor of memset? With an eye toward CPAN, I wouldn't want to use a library function that people don't have in standard libraries...

      Many thanks,
      cmac
      www.animalhead.com
[reply]
        Do you (or anyone) know if memclr is deprecated in favor of memset?

        I don't have memclr available on my Ubuntu system, while memset is part of the C89 and C99 standards.

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom