in reply to Re^2: How to author a module with optional XS
in thread How to author a module with optional XS

I don't know what capabilities there are to detect whether C compilation is available.

Generally, however, the user will know - and might want to skip the C compilation even when a compiler is available, for whatever reason. So my inclination would be to let the user choose, and to concentrate on providing good error messages if you can't do what they ask you to (and at most a warning if you think what they've asked for isn't the best option for them).

For what it's worth, one of my recent maths projects (written in C) is being run by a number of people on Windows, but despite several of them being programmers only one of them was prepared to actually compile the code (who then provided a binary I could distribute to the others) - even while some of them were asking for features that were already available as compile-time options. I do not pretend to understand this, but I think I can reasonably conclude that some people have a complicated relationship with the concept of a compiler.

  • Comment on Re^3: How to author a module with optional XS

Replies are listed 'Best First'.
Re^4: How to author a module with optional XS
by afoken (Chancellor) on Aug 31, 2023 at 13:57 UTC
    I don't know what capabilities there are to detect whether C compilation is available.

    Neither do I, but one should be obvious: Just try to compile something. On a sane system (for some definition of sane), creating foo.c followed by invoking make foo in the directory containing foo.c should result in a binary named foo and an exit code of 0. If anything went wrong, the exit code will be non-zero and/or foo does not exist. To see if you did not accidentally invoke a cross-compiler, you would simply try to start foo. To detect if foo.c behaves as expected, make it exit with an exit code that is unlikely to happen and/or write out a text that you test for when invoking foo.

    Something like this:

    /tmp>cat foo.c int main(void) { return 42; } /tmp>make foo cc foo.c -o foo /tmp>echo $? 0 /tmp>./foo /tmp>echo $? 42 /tmp>

    Of course, getting that to work on non-Unix systems needs a little bit more work, starting with the fact that the compiled binary will very likely be named foo.exe, not just foo, on Windows. I also completely ignored all problems of having the right libraries and headers available. And, of course, I did not write any Perl code to write foo.c and to compile it, but that's just a little bit of perlipc.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

      Well, and non-unix probably don't have 'make' in the first place (does Mac have make in the global path?). But they very well might have a compiler installed in some place that Perl toolchain knows how to find, according to some magic environment variables or something, or hard-coded paths that were stored in %Config when perl was built.

      This is why I was asking, instead of just stumbling forward with the idea.

      I almost care more whether a system is *intended* to support XS modules than whether it can be made to compile them. If the user intends to install XS then I want to try compiling and show the message to them if it fails, rather than skipping the XS support.

      "make" type programs aren't only called "make": cf Windows with gmake and dmake, VMS, etc.