The one and only way to compile Pike modules that should be endorsed and/or developed is "pike -x module". That's it. If it doesn't work it. If it requires the entirety of Pike, deal with it.
That's about all I have to say.
/ David Hedbor
Previous text:
2004-01-26 21:32: Subject: Re: Pike @ Debian
On Mon, Jan 26, 2004 at 08:55:02PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
_No_. It can _not_ be tailored to the distribution, because then the Pike modules you distribute could only be compiled with that distrubution. That would be totally useless.
Huh? pike.m4's purpose is would be to:
a) detect the presence of the Pike binaries on the system (or requested components thereof)
b) inform the application where the .h, .pmod etc. etc. files are located.
How could that prevent the code from being compiled on different operating systems??? Since when the contents of the information above matters and not the way you get the information? If you have 10 OSes and each of them keeps the .h files in a different location, but you have one pike.m4 which has a macro
PIKE_C_HEADER_FILES
which sets the PIKE_HEADERS variable to the location of the .h files on the system, then where is the problem?
You put
CC_INCLUDES=$(PIKE_HEADERS)
in your makefile and your code perfectly compiles on any OS, no matter where it keeps the files. Suspecting that you might have misunderstood the 'tailoring' part - I meant by it that the maintainer of the Pike port for a particular system can modify it and customize for his platform. I didn't mean it has to be done in the Pike core, all gods of the universe forbid! As said previously somewhere, the .m4 could just source a config file put in a well-known location. That would make it extremely configurable and flexible, not to mention simple.
marek
/ Brevbäraren