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.

Yes? In order to find the information in b) though, it need to either run the Pike binary detected in a), asking it to disclose this information (which is equivalent to the use of pike -x module today), or grope this information out in some other way. The latter solution would have to include support for all systems, packagings and installations, since the stuff from the .m4 file goes into the generated "configure" script, to be distributed together with the module. So you can't tailor the .m4 file for your own system, since the generated configure script needs to work on any system with any Pike.

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?

The problem was how to write the macro PIKE_C_HEADER_FILES so that the shellscript code it expands to works on all systems without resorting to running the Pike interpreter.

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.

I'm sorry, but I don't think it's realistic to require a "well-known location" to exist in all Pike installations. Just consider users installing pike without having global write access, or ports to operatings systems with completely different pathname conventions (win32, AmigaOS, etc). pike -x module works because it only needs to follow $PATH to find everything it needs to bootstrap. You can have the Pike installed anywhere, using any directory layout (under the current limitations of the master and the Makefiles), as long as you have the intepreter binary in your $PATH.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

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