Re: debian packages of 7.6.112

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