Pike-devel January 2004

pike-devel@lists.lysator.liu.se

11 participants
77 discussions

Re: Pike @ Debian
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

>dynamic_module_makefile+specs, aclocal.m4, precompile* and the headers must >_all_ go in separate directories. It doesn't seem there is a simple hack to >work around it. aclocal.m4 (as Martin already said) would have to be a) >cleaned up from the non-pike cruft, b) put in /usr/share/misc - Would it help it it was called something other than "aclocal.m4"? It's an internal file to the pike build system, so it's frankly only Pikes business what it contains. > autoconf would find it there. autoconf is not _supposed_ to find it, except when pointed to it by the build system. The rules are internal and not useful in a stand-alone configure script. Can you give some kind of motivation at to what benefit your "rules" bring to the user? They seem pretty pointless and anal to me. >No, the system is nowhere near flexible. It would be so much easier to >simply provide a pike.m4 file... I'd say Debian is much less flexible than the build system is. / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2004-01-26 20:45: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 08:31:05PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled: >> If master()->include_prefix points to the directory where the include >> files, dynamic_module_makefile, aclocal.m4 file, precompile.{pike,sh} >> files and specs file are, pike -x module should work yes. This is >> exactly what include_prefix is there for, and the only thing it is >> used for. >OK, so it won't work for Debian. It's not flexible enough. >dynamic_module_makefile+specs, aclocal.m4, precompile* and the headers must >_all_ go in separate directories. It doesn't seem there is a simple hack to >work around it. aclocal.m4 (as Martin already said) would have to be a) >cleaned up from the non-pike cruft, b) put in /usr/share/misc - autoconf >would find it there. The precompile scripts should either go in /usr/bin >(they would have to be renamed to pike-precompile* then) or in >/usr/lib/pike/PIKEVER/bin, the dynamic_module_makefile and the specs file >should most probably go in /usr/share/pike/PIKEVER/include >No, the system is nowhere near flexible. It would be so much easier to >simply provide a pike.m4 file... > >marek > > > > / Brevbäraren >

1 0

Re: Pike @ Debian
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

_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. / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2004-01-26 20:48: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 08:40:02PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled: >> Besides, even if you did a pike.m4, it would have to invoke pike with >> --show-paths or similar in order to find the files, since J Random >> disribution might have moved them to god-knows-where. ;-) So you'd >> need to launch the pike interpreter anyway. >Nope, I disagree. The pike.m4 can be statically tailored to fit the >distribution scheme. No need for dynamic configruation since you are dealing >with a distribution that has its standards and locations set. > >marek > > > > / Brevbäraren >

1 0

Re: Pike @ Debian
by Per Hedbor () ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

How can it save space? You really _do_ need pike to compile pikemodules. Anything else is highly volatile, it's _extremely_ tough (although theoreticall possible) to dump .pmod files to .pmod.o without pike, but I would not attempt it (a pike module is always a .so and a .pmod nowdays, and the .pmod needs to be dumped). / Per Hedbor () Previous text: >2004-01-26 20:47: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 08:35:02PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled: >> The main reason is that you can have several pikes installed or >> semi-installed. The -x module systems lets you start up any pike of >> your choice with any additional flags you might need, and get the >> module compiled for that exact environment. >PIKE_MACRO(7.4.123) > >would do the trick just fine. You can pass the version on the configure >command line > >> And if you have .cmod:s, you do need pike to build the module. >Sure, but they are not needed to build e.g. Caudium or PHP4 modules - and in >Debian it saves over 40MB in dload size for the autobuilders. Not something >to be ignored. > >marek > > > > / Brevbäraren >

1 0

Re: Pike @ Debian
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

You only have a single version of pike installed?? / Henrik Grubbström (Lysator) Previous text: >2004-01-26 20:48: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 08:40:02PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled: >> Besides, even if you did a pike.m4, it would have to invoke pike with >> --show-paths or similar in order to find the files, since J Random >> disribution might have moved them to god-knows-where. ;-) So you'd >> need to launch the pike interpreter anyway. >Nope, I disagree. The pike.m4 can be statically tailored to fit the >distribution scheme. No need for dynamic configruation since you are dealing >with a distribution that has its standards and locations set. > >marek > > > > / Brevbäraren >

1 0

Re: Pike @ Debian
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

Besides, even if you did a pike.m4, it would have to invoke pike with --show-paths or similar in order to find the files, since J Random disribution might have moved them to god-knows-where. ;-) So you'd need to launch the pike interpreter anyway.

1 0

Re: Pike @ Debian
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

The main reason is that you can have several pikes installed or semi-installed. The -x module systems lets you start up any pike of your choice with any additional flags you might need, and get the module compiled for that exact environment. And if you have .cmod:s, you do need pike to build the module. / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2004-01-26 20:25: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 08:15:02PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled: >> I don't think the build system needs to change. That it can't work if >> you put the files at place A but _tell the build system they are at >> place B_ isn't really a bug. There might be a point in allowing finer >If the build system was documented, then I wouldn't have to wait for >somebody to stumble upon the problem. If you confirm what I asked about in >the other posting and repeated below, then I'll fix it in no time. > >> granularity in the path specifications, so that certain files can be >> in one place and others in another, but that's not the problem here. >> Debian keeps all the files needed by the build system in one place, it >> just lies to said build system about what that place is. >If include_prefix is the only change that is _really_ needed, then it's >trivial. OTOH, why does the build system have to be a build system at all? >Why not just provide a simple pike.m4 file to be included in you module's >aclocal.m4? It seems to me to be a bit overdone to have to install and >launch the whole pike interpreter and the library in order to get a few >strings for the compilation process - especially that you don't need pike to >link your modules, all you need is the C headers. > >marek > > > > / Brevbäraren >

1 0

Re: Pike @ Debian
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

If master()->include_prefix points to the directory where the include files, dynamic_module_makefile, aclocal.m4 file, precompile.{pike,sh} files and specs file are, pike -x module should work yes. This is exactly what include_prefix is there for, and the only thing it is used for. / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2004-01-26 20:20: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 08:10:02PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled: >> It's not inflexible, but you have to inform it that it should flex. >> Like I said, it can't be clairvoyant. include_prefix must be set to >> where the include files are (the Pike build system does this when you >> build Pike normally). >And is this the only thing that needs to be done in order for it to work? > >marek > > > > / Brevbäraren >

1 0

Re: Pike @ Debian
by Per Hedbor () ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

One solution is to discontinue the debian port. / Per Hedbor () Previous text: >2004-01-26 18:40: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 06:25:01PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled: >> pike -x module is _my_ friend, and it works everywhere except in >> Debian. >Well, your friend is inflexible then. If it has to be hacked to work in a >different environment, then something is wrong with it. Where is the build >system documentation? I'll be happy to hack it if I don't have to spend a >day or two learning it. > >thanks, > >marek > > > > / Brevbäraren >

3 3

Re: Pike @ Debian
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

It's not inflexible, but you have to inform it that it should flex. Like I said, it can't be clairvoyant. include_prefix must be set to where the include files are (the Pike build system does this when you build Pike normally). / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2004-01-26 18:40: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 06:25:01PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled: >> pike -x module is _my_ friend, and it works everywhere except in >> Debian. >Well, your friend is inflexible then. If it has to be hacked to work in a >different environment, then something is wrong with it. Where is the build >system documentation? I'll be happy to hack it if I don't have to spend a >day or two learning it. > >thanks, > >marek > > > > / Brevbäraren >

1 0

Re: Pike @ Debian
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

${include_prefix} is the C include path. ${share_path}/include is the Pike include path. They are not the same in a normal installation. / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2004-01-26 18:38: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 06:20:02PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled: >> It is told, by the master. The path is passed through the variable >> master()->include_prefix, which is initialized to the value of >> ¤include_prefix¤ when master.pike is generated from master.pike.in. >> So as you can see, it's fully configurable. >So you say it can encompass a separate pike .h files path and a separate C >.h path? How? > >marek > > > > / Brevbäraren >

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel January 2004