The whole point of the excersice is to get rid of the dynamic_module_makefile, since it invariably does not work if you change your system in any way.

The example is as compact as it is because the CHANGES file is not really intended to be 10000 lines long..

You are, as is stated in the entry, free to use configure.in with friends. But please do avoid using the dynamic_module_makefile and similar things. A set of useful configure-macros might be good to have to shorten your configure.in (but really, it's not really all that needed, the only thing you need to find out is the location of whatever library your module use, if any, and how to compile shared library code, which is trivial on most systems nowdays, and there already exist finished macros for that kind of things)

It's not really nessesary to compile your module with the exact same flags that were used when pike was compiled, and it tends to break things (libgcc moved? Broken. Gcc updated, thus a different version on libgcc? Broken. New library installed? You won't find it if pike checked for it at compile time, etc)

There are basically only two things you need to know from pike, and one of them is rather optional:

1: Where is the pike include files, and any special defines needed? pike -x cflags

2: Where should the module be installed to? pike --show-paths or use pike -x module ('new' style)

The idea with the minimal example is to show that if you want to write a small module for your own use, you don't really need 100 lines of configure.in and the mess that is dynamic_module_makefile.

I think though, that you're over-simplifying the situation. For simple modules that you don't intend to distribute, it's possible that this new system will work just fine. However, there are a large number of useful targets in dynamic_module_makefile that allow external modules to be distributed and built in a consistent manner.

Most of the Makefiles I write using dynamic_module_makefile are less than 10 lines long, as are the configuration scripts. I don't see how throwing all of that away makes life better; perhaps some things are better, but many others certainly won't be.

To be sure, it's a pain that there are cflags embedded in the installation, and it's a pain to update them when things change (which frankly doesn't happen that often for me). I always include checks for any libraries potentially required in modules I write, I'd guess that it's a better practice to do that rather than asssume that Pike will have found them previously.

Again, I think the "definitiveness" of the statements made regarding this new system should be altered appropriately, otherwise there is a very real risk of destroying the delicate balance of the external module world.

The idea with the minimal example is to show that if you want to write a small module for your own use, you don't really need 100 lines of configure.in and the mess that is dynamic_module_makefile.

Indeed. I've yet to see the split of machine.h into ABI relevant parts (e.g. INT_TYPE, PIKE_DEBUG) and nonrelevant parts (defines like HAVE_FOOBAR_H and most others). The first ones are vital to have, and the latter can easily get in the way.