Re^3: Why Module::Build?

I'd be interested to listened to what specific problems you ran into on VMS. I agree the absence of evidence is not evidence of absence, but when people tell me they have problems and I ask for specifics, they don't give them. People have problems with a lot of things, and I try to find out how they are doing things and why they are having the problems. Sometimes the problem is something else.

I don't credit schwern with the success of MakeMaker I've seen because a lot of the people I have to deal with use versions he wasn't involved in, and I stick to the versions that came with a Perl (rather than the in-between releases).

I don't have a problem with you or your users using Module::Build, and if it works for you that's great. However, sentiments like "MakeMaker must die!" has nothing to do with the choice you were able to make.

--
brian d foy <brian@stonehenge.com>

Comment on Re^3: Why Module::Build?

Replies are listed 'Best First'.
Re^4: Why Module::Build? by adrianh (Chancellor) on May 20, 2005 at 21:20 UTC
I'd be interested to listened to what specific problems you ran into on VMS VMS wasn't drastically worse than the other operating systems, but problems usually showed up there later since they had a longer cycle between installs. It was some time ago but the VMS specific problems that I remember included: Continually forgetting the `nicetext` calls causing problems with colon escaping. Forgetting spaces around the separators between source and target. There was some problem with cleanup not removing all versions of a file. prefixify was ignoring some config settings. I'm pretty sure that was an EU::MM bug though. There was a bug with the version of mmk on one of the boxes. For the life of me I can't remember what, but an upgrade fixed the problem. Had to deal with mmk updating the target when the source file had the same timestamp Hopefully this gives you a feel for some of the problems I encountered. Of course they can all be overcome with effort - but I'd prefer expend my effort on writing the application rather than having to deal with N different platform/make/shell combinations that I cannot easily control. I don't credit schwern with the success of MakeMaker I've seen because a lot of the people I have to deal with use versions he wasn't involved in, and I stick to the versions that came with a Perl (rather than the in-between releases). I wasn't trying to give schwern sole credit! He was just the first name that popped into my head since he's the current maintainer. Obviously everybody who has spent time getting EU::MM to work as well as it does at the moment is owed a huge debt of gratitude. However EU::MM is, IMHO, fiendishly complicated and hard to tweak/extend. Most of the reason it's fiendishly complicated and hard to extend as far as I can see is it's reliance on various external make tools. I don't have a problem with you or your users using Module::Build, and if it works for you that's great. However, sentiments like "MakeMaker must die!" has nothing to do with the choice you were able to make. I take it that you're talking about the MakeMaker is Doomed talk? I just wish I'd read it before I spent weeks of my time messing around with EU::MM:-) Okay - I can see your point. It's ranty in places. But when extending the default Perl build system involves doing such evil things as doing s/// on make file fragments I think a little ranting is warranted.	[reply] [d/l]

Replies are listed 'Best First'.

Re^4: Why Module::Build?
by adrianh (Chancellor) on May 20, 2005 at 21:20 UTC

I'd be interested to listened to what specific problems you ran into on VMS

VMS wasn't drastically worse than the other operating systems, but problems usually showed up there later since they had a longer cycle between installs. It was some time ago but the VMS specific problems that I remember included:

Continually forgetting the nicetext calls causing problems with colon escaping.
Forgetting spaces around the separators between source and target.
There was some problem with cleanup not removing all versions of a file.
prefixify was ignoring some config settings. I'm pretty sure that was an EU::MM bug though.
There was a bug with the version of mmk on one of the boxes. For the life of me I can't remember what, but an upgrade fixed the problem.
Had to deal with mmk updating the target when the source file had the same timestamp

Hopefully this gives you a feel for some of the problems I encountered. Of course they can all be overcome with effort - but I'd prefer expend my effort on writing the application rather than having to deal with N different platform/make/shell combinations that I cannot easily control.

I don't credit schwern with the success of MakeMaker I've seen because a lot of the people I have to deal with use versions he wasn't involved in, and I stick to the versions that came with a Perl (rather than the in-between releases).

I wasn't trying to give schwern sole credit! He was just the first name that popped into my head since he's the current maintainer. Obviously everybody who has spent time getting EU::MM to work as well as it does at the moment is owed a huge debt of gratitude.

However EU::MM is, IMHO, fiendishly complicated and hard to tweak/extend. Most of the reason it's fiendishly complicated and hard to extend as far as I can see is it's reliance on various external make tools.

I don't have a problem with you or your users using Module::Build, and if it works for you that's great. However, sentiments like "MakeMaker must die!" has nothing to do with the choice you were able to make.

I take it that you're talking about the MakeMaker is Doomed talk? I just wish I'd read it before I spent weeks of my time messing around with EU::MM:-)

Okay - I can see your point. It's ranty in places. But when extending the default Perl build system involves doing such evil things as doing s/// on make file fragments I think a little ranting is warranted.

[reply]
[d/l]