Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

ethan (3163)

  reversethis-{ed. ... rap.nov.olissat}

Being a 25-year old chap living in the western-most town of Germany. Stuying communication and information science and being a huge fan of XS-related things.

Journal of ethan (3163)

Tuesday July 22, 2003
03:09 AM

Having fun with h2xs

[ #13608 ]

Some weeks ago on the perl5-porters list, someone (Ken Williams?) mentioned re-writing, re-factorizing, modularizing etc. h2xs in the same way he did it with xsubpp by creating ExtUtils::ParseXS.

I thought, well, why not. Can't be that hard. It should be benificial for those times when Module::Build finally replaces ExtUtils::MakeMaker as the preferred way of creating CPAN modules.

And so I started with ExtUtils::H2XS. That was eight days ago. Right now I am not too far away from regretting this decision deeply. The code of h2xs is disgusting to an almost criminal extent. It uses about (and this is no exaggeration) 50 global variables (named in an as obfascated way as possible) to gather all the information it needs to create a module skeleton. I have already spotted around 10 variables that are only assigned to but never read from. It uses for-loops where there can clearly be only one iteration, passes arguments to the few functions it has that are discarded inside these functions.

Furthermore, the code differs greatly from what the documentation says. It has switches that are useless (-f for instance) and it offers features that aren't mentioned in the docs (the mysterious ext/ directory).

The real problem is that no one on the porters list can provide some help with h2xs' internals. That's not because they wouldn't want to, it's because they don't understand it either. No one does.

This surely has historical reasons. Over the years, h2xs has been patched to can easily tell that different parts of it have been written by different people. The only thing they had in common was that they never looked at the seemingly unrelated other parts of the code (which results in so many useless and duplicate variables used) and that they never commented any of their additions. Ideally, patches and changes would have an author-tag so that later the authors can be asked what their code does in case of emergencies (such as this case). But they haven't. (Admittedly: my enum-patch for h2xs to be found in perl5.8.1 was no exception from the above).

And one final rant: Who was responsible for adding the -x/--autogen-xsubs switch? This whole C::Scan business is causing me a major headache. It's by far the hardest part (and at the same time the part that almost never works in practice). Once I am done with implementing a functional duplicate of the current h2xs, I'll create a subclass of ExtUtils::H2XS::XSUBS (the package that encapsulates all the work of C::Scan) that uses ExtUtils::XSBuilder to create XSUB accessors. Unlike C::Scan, this module actually works and uses a proper C-grammar instead of these silly heuristics of C::Scan.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • This sounds like the code I work on every day.
    You certainly have my sympathy...
  • Why don't you look into the Changes file, search for h2xs.PL and look at the corresponding patches using the Perl Repository Browser []?

    I think the C::Scan stuff can be attributed to Ilya. :)

    • Why don't you look into the Changes file, search for h2xs.PL and look at the corresponding patches using the Perl Repository Browser?

      You are right, I should make more use of that. The blamelog is useful in this case (I see that I can be blamed for 81 and 83). Too bad that there isn't a mapping from the numbers to the respective authors.

      I think the C::Scan stuff can be attributed to Ilya. :)

      Tsss. I can't remember him raising his hands when I brought this topic up on p5p. Perhaps too ashamed. :-)
  • Yeesh, ExtUtils:: was supposed to be for code that _interfaced_ with external utilities (like make or gcc or whatever). But for some reason a whole bunch of random crap related to modules has ended up in there. For example, Geoff Avery's ExtUtils::ModuleMaker. Nice handy tool, but it doesn't interface with anything else. It _is_ a utility. Call it Module::Maker!

    So for your tool, how about something like Module::SkeletonFromHeaders or something like that? At the very least, it belongs in the Module:: namespace, which is where module generator/install tools belong.
    • Ah, I didn't actually know that the ExtUtils:: namespace was for interfacing with other things. I guess I never thought about the meaning of ExtUtils.

      Fortunately, I didn't yet register any namespace or so (I first want to make sure that I ever finish my work). Module::Maker sounds sane, or perhaps Module::H2XS. I might ask the porters when I am done.

      But thanks that you mention it! Sometimes I overlook such small things.