I think I mentioned this before, but I'll repeat it just so an alternate viewpoint is heard: I guess I fail to see the upside of this "new" way of doing things. Sure, you may get the ability to recheck settings that may have changed since pike's original install, or you want to incorporate an entirely new build system. The (big, in my opinion) downside is that you lose the ability to distribute the module easily, as the "new" method doesn't come with any of the established build and install framework ready to go. It seems to me a far better solution for all modules to use the same mechanism for build/install rather than a split system.
As I think about it I'm not even sure about the benefit gained from being able to recheck things, as if you didn't have something previously, you can always recheck and add it during configure (I've got a number of modules that do that) and if you already had it and changed it, you risk introducing failures due to having different versions of "stuff" used by different parts of the code.
Yes, some have indicated that it's a pain to make a distributable module that only contains a pike file, but that's only if you don't start with a sample module source tree (which I made available 2 or 3 years ago.
http://hww3.riverweb.com/dist/pike_modules/SampleModule.tar.gz
Bill
On Aug 11, 2008, at 6:40 AM, Marcus Agehall (Roxen IS) @ Pike (-) developers forum wrote:
Currently, yes. But the old style module building framework pretty much assumed you were building a CMOD in general. If you didn't intend to do that, you still had to provide a few files which were more or less empty.
I think that was more of a design-flaw in the old-style method than anything else, but nevertheless...