Thanks to the very handy Inline::C2XS module, I have finally converted AI::NeuralNet::Simple from Inline::C to XS. This has not only removed a dependency, it has sped up the test suite from 14 seconds to 2 seconds (most of the 14 seconds was spent converting the Inline::C to XS, of course). In the process, I used Perl::MinimumVersion to verify that I could lower the version number of the module to 5.005 from the 5.008 it erroneously had.
Also, after peeking at David Rolsky's XS code for Params::Validate, I found a neat trick to pass the -Wall flag to my compiler if it detects a .svn file, thus ensuring that I get full warnings when compiling the C code. This led me to remove several unused variables. All in all, a productive day. Now let's hope the module actually works for other people.
I wanted to use Module::Build, but not only could I not figure out how to pass extra flags to the C compiler, I kept getting "Can't locate loadable object for module AI::NeuralNet::Simple in @INC" errors in my tests. I finally gave up and stuck with Makefile.PL, though I should rectify this at some point.
Why?I wanted to use Module::Build,
Re:M::B
Ovid on 2006-11-18T17:11:01
This has been beaten to death in many forums, to be honest. Module::Build is easier to extend and doesn't depend on whatever strange OS or make program you on your system. The main thing which keeps EMM going is inertia and the fact that MB has lacked some of the thing which EMM provides. Those who've had to do deep work with EMM have at times simply given up on adding requested features because it's so hard to do. I'm sure that what I want to do is available, but there are so many examples of EMM out there that I gave into inertia.
Re:M::B
educated_foo on 2006-11-18T18:04:33
Okay, I looked at the Makefile.PL for AI::NeuralNet::Simple, and it did nothing fancy. I don't have a problem with M::B, except when it's used gratuitously. When you try to do something that's painful with EU::MM, it makes perfect sense to switch over to M::B. But for stuff that EU::MM handles easily, M::B just adds another pointless point of failure. Why do this when it costs you nothing to avoid it?Re:M::B
Ovid on 2006-11-18T19:56:46
For the simple reason that, in the long run, we're trying to encourage people to stop using EMM when they can. Trying to debug a Makefile problem on an OS you don't have access to -- particularly when it's an uncommon make program they're using -- is a nightmare. Since I've encouraged people to make the switch, it looks awfully bad when I'm not using it myself.
Re:M::B
educated_foo on 2006-11-18T20:38:47
That's an essentially political point, and we happen to be on opposite sides. Module authors who have no particular build tool ideology, but want to have their modules install most painlessly on the most platforms, would do best using EU::MM. Those who think EU::MM is a drain on both their own and their users' time would best force their users to install the latest-greatest M::B. Just please, *please* don't use M::B because it's the cool kids' replacement for make.Re:M::B
Ovid on 2006-11-18T20:48:41
Without wanting to debate this to death, I'll just say that I do provide a compatible Makefile.PL. If someone doesn't have MB installed, it's not a problem.
Re:M::B
educated_foo on 2006-11-18T21:08:00
Sweet -- this exactly how I prefer people use M::B. I just wish more module authors did this.Re:M::B
Alias on 2006-11-19T15:57:32
Without getting too much into the standard arguments, I just note it makes little point to move people on from EU:MM when the replacements both have major issues.
When the bug count for either MB or MI falls, or we finally solve the upgrade problem, then maybe we should be spruiking a solution. My concern has always been that it's happening prematurely, not that it shouldn't happen at all.
Re:M::B
Aristotle on 2006-11-19T17:25:48
Of course, EU::MM is not solid either, so for some people, the choice is between multiple evils.
Re:M::B
Ovid on 2006-11-19T18:21:17
And yet, the problem space is so large that if people were unwilling to try M::B, it would have taken far longer to get it to its current state of being an acceptable alternative. Some people have to be early adopters for any new technology to take off.
Did you see the extra_compiler_flags key to the Module::Builder constructor? That's always worked for me.
With regard to the loadable object problem, make sure you have blib/lib in @INC in your test files.
(I'm sure you've checked these, so I suggest both ideas for anyone else who stumbles across this journal in the future with a similar problem.
Re:Extra Compiler Flags
Ovid on 2006-11-18T20:52:32
Actually, I hadn't checked those. I scanned the docs, but I missed the extra_compiler_flags mainly because I was being careless.
