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.
This is not correct. The location is an absolute path. The assumptions made are:
A) That all the needed files by the build system are in this same location
B) That the master knows the location
At least assumption B), but possibly also A), I haven't checked too closely, is broken by the Debian packaging.
Fixing B) is simple, since the location is dumped in from a variable when the master is generated from master.pike.in. Just make the variable point to the right location, and it doesn't matter exactly where this location is.
Fixing A) (if it needs fixing) means either rearranging the files so that they _are_ in the same location, or reworking the code in Tools.Standalone.module so that the variables "srcdir" and "include_path" are used a little less indiscriminately. This of course requires that all the relevant locations can be found somehow. Using the specs file could be a workable solution, as long as the specs file itself can be found using the information obtained from the master.
Personally I don't see a need for splitting the stuff up, but if other people feel otherwise, I'm not going to try to stop them from adding this to Tools.Standalone.module. However, should anyone take such a project upon themselves, please watch out for regressions. The current system can build modules using
* A pike built from a pike.ida.liu.se distribution or from CVS, and installed using "make install" * An _uninstalled_ pike built from a pike.ida.liu.se distribution or from CVS
Care should be taken that both these cases keep working.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-01-27 21:14: Subject: Re: Pike @ Debian
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.
/ Brevbäraren