Re: Re: Multiprocessor (SMP) system detection

This comment is actually more of a question.

It seems to me that even though ANSI C may be widely available, any solution that involves calling a C function is inherently non-portable.

I say that because in order to call a C function one would need to compile a call to the function. And even if ANSI C were widely available the mechanics of compiling C would differ. So no portable Makefile.PL could be created. Hence, non-portability.

Comment on Re: Re: Multiprocessor (SMP) system detection

Replies are listed 'Best First'.
Re: Multiprocessor (SMP) system detection by Abigail (Deacon) on Jun 25, 2001 at 19:19 UTC
Well, if no portable Makefile.PL could be generated, Perl wouldn't be half as popular as it's today. Lots of modules on CPAN use C, including very popular ones like DBD::* and Date::Calc. All with a portable Makefile.PL That's what XS and the ExtUtils are for! And nowadays, the Inline family even gives us easy access to XS. -- Abigail	[reply]
Re: Re: Re: Multiprocessor (SMP) system detection by bikeNomad (Priest) on Jun 25, 2001 at 19:07 UTC
Actually, the Inline module makes it possible to have C code that is compiled without changing your Makefile.PL on a number of systems. Now, whether the C code itself is portable depends on what it calls (for instance, there is no portable way to determine the number of processors). But it can be possible to make portable C routines that compile across platforms. Here's an example from the Inline::C::Cookbook : `use Inline C => <<'END_C'; void greet() { printf("Hello, world\n"); } END_C greet;` [download]	[reply] [d/l]