I've been playing around with external module building under Pike 7.7, and I think that most of the difficulty involves propagated_variables. There's a propagated_variables file that gets installed in include/pike, but it seems that the macro that actually reads this file only looks for it in the current directory. I think I understand that rationale when compiling within the source tree, but think there needs to be a behavior that checks for the file in the installed headers directory too. The question for those more knowledgeable in this magic is: does it seem reasonable to check in the installed headers directory first (most likely $BUILD_BASE, I think), then in the current directory for all situations or would that have an undesirable effect when compiling within the Pike source tree?
While traveling home from the pike conference, I forced mast to have a look at the problem. He concluded that the propagated_variables file should be copied into the module directory when building external modules.
I think the easiest fix, with the least side-effects, is to just have the pike -x module command copy the file into the module directory if it doesn't already exist.
/.../ The question for those more knowledgeable in this magic is: does it seem reasonable to check in the installed headers directory first (most likely $BUILD_BASE, I think), then in the current directory for all situations or would that have an undesirable effect when compiling within the Pike source tree?
If you reverse the order so that it checks the current directory first then it's fine with me. At the end of the configure run, that file is rewritten with the current variable settings. One intended use with this is to be able to rerun configure locally in a module (external or not) and conveniently retain the previous settings.
pike-devel@lists.lysator.liu.se