01_master.in.dpatch put the extra add_include_path() and add_module_path() calls in normalize_path(). WTF?? Moved to a sensible place.
I assume the new place is create()?
You assume correctly.
I forgot to mention that you can browse the Debian packaging files at http://svn.kibibyte.se/pike7.6/trunk/debian
03_language.yacc_bison_fix.dpatch disables the following #define in language.c:
[...]
Foo?
Some versions of Bison had problems with that code. Makefile.in nowadays has a proper workaround, so there should be no need for the patch anymore.
OK, I'll delete it then.
04_make_variables_fpic.dpatch adds -fPIC to OTHERFLAGS and NOOPTFLAGS in src/make_variables.in. Isn't Pike's build system competent enough to use -fPIC as needed?
It should be. If it isn't, it's a bug and should be reported.
OK, we'll investigate that further then. Too bad debian/changelog doesn't say anything about it.
05_install.pike.dpatch was merged with 06_src_makefile.in.dpatch. It should have been the other way around, since patching install.pike is no longer necessary with --traditional. However, patching src/Makefile.in is still necessary to allow INSTALLARGS and include_prefix to be passed from the top Makefile. (debian/rules now calls the top Makefile only, since I suppose that's what you're supposed to do.)
07_dynamic_module_makefile.in-libgcc.dpatch sets LIBGCC=$(shell gcc -print-libgcc-file-name) in dynamic_module_makefile.in. I suppose it's practical if modules can be built with some other version of gcc that the one Pike was built with.
Sounds reasonable.
Shall I open a bug report about the makefiles being inflexible wrt INSTALLARGS and such?
debian/rules creates a file /usr/include/pike/7.6.112/specs containing various build parameters, such as CPPFLAGS and configure_args. I don't know if any other package uses it.
That file is (supposed to be) used by pike -x module.
Oh, now I see. I'll take a closer look at the differences compared to the ordinary one.
Finally, the location of dynamic_module_makefile is adjusted, in dynamic_module_makefile, from $(MODULE_BASE) to $(PIKE_SRC_DIR), which probably makes sense if PIKE_SRC_DIR is set to the include directory and MODULE_BASE is set to the modules directory when building modules. How does it work? Is there an example of how to build a binary module somewhere?
http://pike.ida.liu.se/generated/manual/ref/chapter_18.html#2 is not very complete. And shouldn't "sinclude(../module_configuration.in)" be
Indeed.
"sinclude(../module_configure.in)"?
Where did you find this?
module_configure.in was the closest match I could find with a cursory search. There is no file called module_configuration.in AFAICS.