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
>