What is the "correct" way to provide the C include path(s) to C/XS modules

[adamk]

I'm building a Perl distribution, and having some trouble with building Perl modules that link to C libraries.

Different modules seem to use a variety of different methods to build/define the include path that will ultimately be provided to gcc.

For example "$ENV{INCLUDE}", "perl Makefile.PL INC=-I..." and "$Config{libpth}". And some Makefile.PL do their own stuff to locate include paths beyond these.

Unfortunately, many of them use one method and ignore the others, some overwrite one with the other, and I can't find one way of providing the include path to the modules in a way that all modules can handle correctly.

Now, I'm ok with talking to authors or taking over modules and converting them to support the correct way, but I have no idea what that is.

What is the "correct" way to provide the include paths via CPAN.pm such that all modules in a recursive install will receive and understand the include path to use for finding libs?

[tye]

That should be taken from a Config.pm setting. I'd expect it to be in a CCFLAGS or something similar because expecting every single C compiler in the world to support -I just seems a bit optimistic so you should specify the whole command-line argument not just the path string.

I see $Config{incpath} but I expect that to be used for searching for *.h files from Perl code, not for constructing command-line flags to be passed to the compiler to tell it where to find include files.

Updates: Note that supporting $ENV{INCLUDE} or "... Makefile.PL INC=-I..." or other such things to augment CCFLAGS is just fine.

It sounds like you've found code that has some "-I" string hard coded and appends $Config{incpath} to that. To be clear, I don't consider such portable (in at least two ways).

[Anonymous Monk]

ExtUtils::Liblist/ExtUtils::Embed might help

[Anonymous Monk]

Do you have an example?

[eserte]

For setting on a per-distribution basis, you can use the distroprefs system of CPAN.pm.

[syphilis]

Hi adamk,

It's an interesting question (on a number of points). I speculate (untested) that if the Makefile.PL simply does something like:

WriteMakefile(
 NAME => 'whatever',
 VERSION_FROM => 'whatever.pm',
);

then the perl Makefile.PL INC="-I...." LIBS="-L... -l..." would always work fine. It has always worked fine for me. Faik, however, there may be ways of writing a Makefile.PL that break that method.

What is the "correct" way to provide the include paths via CPAN.pm

The "correct" way to install any software is to download the source and follow the instructions in the README file (or should that be the INSTALL file ?). Of course CPAN.pm totally ignores what's written in the README/INSTALL, thereby committing a fundamental sin - to the extent that I therefore wonder if the term "correct" is even applicable in the context of CPAN.pm.

However, that's probably not a very helpful observation/opinion. I don't use CPAN.pm, but I can well imagine that if I did try to use it to install something like Net::SSH::Perl (without having already installed Math::GMP) then there would be a problem because my GMP library is not in a standard location (ie it won't be found by default). So, I would need to be able to provide a switch to the CPAN command that tells the compiler to look in that non-standard location. (But then, how would I necessarily know in advance that I needed to provide that switch ?) Is that what you're getting at ... how to universally avoid the hiccup I would encounter if I were to try to build Net::SSH::Perl under those circumstances ?

(Needless to say I don't use Net::SSH::Perl, either :-).

Cheers,
Rob

[adamk]

The "correct" way to install any software is to download the source and follow the instructions in the README file (or should that be the INSTALL file ?). Of course CPAN.pm totally ignores what's written in the README/INSTALL, thereby committing a fundamental sin - to the extent that I therefore wonder if the term "correct" is even applicable in the context of CPAN.pm.

I would posit it is a far greater sin to add a critical install time dependency on a non-linear naive unreliable non-expert organic neural net encased in a meat sack.

Software, ESPECIALLY libraries and components that will only ever be consumed directly by machines, should always be installable by machines as well.