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...
