Perhaps I can provide a bit more background. Caudium, and by extension pexts were written before pike -x module came about. They're designed to compile with older versions of pike, and as such can't currently use the build system in place. They use a bunch of "homebrewed" techniques, including automake, i believe.
My understanding of the problem (which could be incorrect), is that pike makes an assumption about the c include files (in particular) being in a location that is relative to the pike installation root, which in the case of debian isn't necessarily the case. Marek's modules do, from what I can determine.
I guess the root of the problems that he'd like a way to be able to gather the location of said includes without having to resort to starting pike, for purposes of using the debian autobuild systems, hence the suggestion of pike-config --cflags.
Getting away from the whole religious wars about what philosophy is correct, I guess the real question is, can we make it so that the include files (and other such sets of data) can be installed in arbitrary locations rather than in a subdirectory under pike's exclusive control?
To this point, I have an autoconf macro (submitted to the pike list a while back) that can be used to gather most of this information, however, it relies on the presence of a working pike.
It worked something like:
AP_HAVE_PIKE(7.2.308 7.4.20) <== require a pike between 7.2.308 and 7.4.20
which would provide the command line argument --with-pike= and set a bunch of variables for file locations and such. I realize that it's not the recommended method for developing modules, but it is useful for other things, like developing programs that rely on pike. Some of the pext automake/autoconf stuff uses similar code.
sheesh, I've lost track of what I was going to say in the first place. this problem seems to be contagious...
Bill
From what I have tried to puzzle together from small scraps and pieces
over the past days (and I may be off by a mile here), the current set of Caudium/PExt modules (ab)use some or other pike aclocal.m4 macros in an aclocal/automake context, somehow leading to the uncomfortable situation with the debian packages' redistribution of those internals to an overly exposed location.