Pike-devel January 2004

pike-devel@lists.lysator.liu.se

11 participants
77 discussions

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

26 Jan '04

Because pike -x module use it to avoid duplicating conveninent macros in the module configure files. Please note that automake is not used in this case, so having a automake-aware pike.m4 would not help. Again, a perl-like method (with the relevant files in module files (and, yes, perl does this partly to avoid discussion) instead of as separate 'misc' files) would apparantly be better, since that would avoid all this discussion about nothing. Note that perlmod* is written in perl, and thus require perl. Not all that unlike pike -x module. The same seems to be true for python, you need it to build modules (same goes for gimp, really). There is actually a good reason for this: It's the only way to be certain that the module is compiled for the correct version of the scripting language, with exactly the same options. Do you really think python and perl should also change their module compilation methods? Example python module makefile: | from distutils.core import setup, Extension | | module1 = Extension('demo', | sources = ['demo.c']) | | setup (name = 'PackageName', | version = '1.0', | description = 'This is a demo package', | ext_modules = [module1]) We could do something very similar for pike (and that would probably be rather nice for the ones writing the modules, actually) I failed to find any simple perl modules, their makefiles tend to be very large (and written in perl, to boot), and there does not seem to be any easy-to-find documentation on their site. / Per Hedbor () Previous text: >2004-01-26 22:21: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 09:50:07PM +0100, Per Hedbor () @ Pike (-) developers forum scribbled: >> The point is that the contents really are _not_ the same. aclocal.m4 >> is a pike local file with macros for pike compilation, and does thus >> not belong in the directory with .m4 macros for automake and aclocal, >> which only contain settings for things, really. >If it is a pike local file for pike compilation, then why is it required to >be installed along with the include files etc. in the first place? > >marek > > > > / Brevbäraren >

1 0

pike -x testing
by Niels M�ller (v�ssar r�dpennan) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

In general, if any pike -x foo works in a standard "./configure && make && make install" installation of pike, but not in the debian/redhat/gentoo/whatever package, then it's a bug in the debian/redhat/gentoo/whatever packaging (which of course might also indicate a problem in pike itself). Talking about pike -x, two feature requests: There should be some way to get pike to list available "tools", and that way should be listed by either pike --help or pike -x (it seems pike --help doesn't mention -x at all. I'm using Pike v7.4 release 20 when testing this). For example, instead of $ pike -x Pike: -x specified without tool name. I'd like to see $ pike -x Pike: You must provide the name of a tool. Available tools: module Build a standalone pike module. pv Image viewer bench Pike benchmark It would be nice to have the testsuite exersize all supported tools, and have pike -x testsuite run the testsuite. Then pike -x testsuite on an installed system is an easy way to test if the installation workd properly. Maintainers for various pike packaging could be encouraged to use pike -x testsuite to test their packages after installation. Providing a testsuite is a precise way of saying that an appearantly obscure feature like pike -x module is actually both supported and expected to work. / Niels Möller (vässar rödpennan) Previous text: >2004-01-26 21:51: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 09:35:08PM +0100, Per Hedbor () @ Pike (-) developers forum scribbled: >> Well, debian is way less flexible. And you seem to be intentionally >The difference is that it's pike one installs in Debian and not Debian in >Pike. > >> minsunderstandning things in texts we write. >yep, as always. You should have gotten used to that. > >> >> Pike modules are internal to the pike build process. >How is that relevant to the discussion? Show me a single place where the >pexts, php4 or caudium C Pike modules need the Pike interpreter to compile >and link. > >marek > > > > / Brevbäraren >

1 0

optimizer failure
by Bill Welliver 26 Jan '04

26 Jan '04

I get the following error in a pike module I'm writing: Warning: Optimizer failure in replace(). The code that fails is: v = replace(v, ({"," "+", "\"", "\\", "<", ">", ";"}), ({"\\,", "\\+", "\\\"", "\\\\", "\\<", "\\>", "\\;"}) ); It also seems to throw an error when I try to perform the replace. Any ideas ( or am i blind to a typo )? Bill

4 4

Re: Pike @ Debian
by Niels M�ller (v�ssar r�dpennan) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

>How is that relevant to the discussion? Show me a single place where the >pexts, php4 or caudium C Pike modules need the Pike interpreter to compile >and link. There's more than one way to do it. pike -x module is one way, used by some pike modules, and it is one way that is recommended by the pike developers. It is expected to work on all pike installations, and it works fine when installing pike with the standard ./configure && make && make install. Marcus complained that pike -x module was broken in the current debian package. That's what the discussion is about, as far as I can tell. If you can build some modules without using pike -x module, that's fine too, but not really relevant to modules that do use pike -x module. / Niels Möller (vässar rödpennan) Previous text: >2004-01-26 21:51: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 09:35:08PM +0100, Per Hedbor () @ Pike (-) developers forum scribbled: >> Well, debian is way less flexible. And you seem to be intentionally >The difference is that it's pike one installs in Debian and not Debian in >Pike. > >> minsunderstandning things in texts we write. >yep, as always. You should have gotten used to that. > >> >> Pike modules are internal to the pike build process. >How is that relevant to the discussion? Show me a single place where the >pexts, php4 or caudium C Pike modules need the Pike interpreter to compile >and link. > >marek > > > > / Brevbäraren >

1 0

Re: Pike @ Debian
by Martin Nilsson (saturator) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

Couldn't we just call the files something different and hope that the debian packet maintainer doesn't notice that the contents are the same? / Martin Nilsson (saturator) Previous text: >2004-01-26 21:38: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 09:10:03PM +0100, Per Hedbor () @ Pike (-) developers forum scribbled: >> Perhaps it would be better to stop using autoconf entirely. Nobody >> seems to complain about Make.pl files, so perhaps that's the way to >> go. >I would be more than happy. There's pmk and numerous other systems of >configuring software. pmk is maturing, so it might be an option in the near >feature. But then, who will convert the current build system to a new >standard? I would just hope that no pike would be necessary to generate the >makefiles > >marek > > > > / Brevbäraren >

2 3

Re: Pike @ Debian
by Martin Nilsson (saturator) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

That they won't work properly under Pike 7.5? By the way, why is a module.pmod required nowdays? / Martin Nilsson (saturator) Previous text: >2004-01-26 21:41: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 09:35:07PM +0100, Per Hedbor () @ Pike (-) developers forum scribbled: >> Even pure C-modules generate .pmod files nowdays. Which is what I >> wrote, I think. >None of the pexts, caudium or php4 modules do. What's your point? > >marek > > > > / Brevbäraren >

1 0

Re: Pike @ Debian
by Niels M�ller (v�ssar r�dpennan) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

>Alas, it wouldn't... If some Pike C module runs aclocal it could pull in >both the pike's aclocal.m4 and other files with, possibly, macros that are >already defined in the pike's aclocal.m4 file. I doubt autoconf is smart >enough to cope with it ;) I think you're confusing several things here. Autoconf, automake, the aclocal program (more or less a part of automake), and the aclocal.m4 file are not all used together and are not using the same conventions. aclocal.m4 existed long before automake, and it plays the same role that acinclude.m4 plays in automakeified projects. It's a *handwritten* file included by autoconf, specific to the project being built. The aclocal proram is a later invention that constructs an aclocal.m4 file from various fragments stored somewhere under share. Pike uses autoconf, and uses aclocal.m4 the the way it was intended when autoconf was first written. It does *not* use automake, and it does *not* use the aclocal program. It's aclocal.m4 is *not* intended to ever be picked up by the aclocal program. So the main poitn here is that any debian policy that has to do with automake and the aclocal program is totally irrelevant to pike. (The only excuse for automake and the aclocal program to start to use the good old aclocal.m4 file in a new way is that autoconf was unmaintained for so many years). /Niels / Niels Möller (vässar rödpennan) Previous text: >2004-01-26 21:27: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 08:55:02PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled: >> >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. >Alas, it wouldn't... If some Pike C module runs aclocal it could pull in >both the pike's aclocal.m4 and other files with, possibly, macros that are >already defined in the pike's aclocal.m4 file. I doubt autoconf is smart >enough to cope with it ;) > >> > 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. >Then putting it in a system-wide location is not justified. And its sole >existence outside the pike interpreter build process seems to be >questionable in that light... > >> 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. >First of all, they aren't mine. Second of all, they serve the purpose of >keeping the stuff where it belongs and where anyone can find it knowing only >the type of the resource they're looking for (e.g. autoconf macros -> >/usr/share/aclocal, C header files -> /usr/include/*, application specific >shareable stuff -> /usr/share/applicationname/*). It's in the Unix >spirit, according to LSB and done that way to faciliate sharing >architecture-independent stuff between machines on the LAN or WAN. All the >architecture-independent stuff goes in /usr/share which can be shared via >NFS accross the machines on your LAN. Anything that is not >architecture-independent must NOT go in /usr/share, obviously (so the Pike >.o files can't, for instance). > >> >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. >Why didn't I expect a different conclusion? > >marek > > > > / Brevbäraren >

1 0

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

26 Jan '04

Well, debian is way less flexible. And you seem to be intentionally minsunderstandning things in texts we write. Pike modules are internal to the pike build process. / Per Hedbor () Previous text: >2004-01-26 21:27: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 08:55:02PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled: >> >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. >Alas, it wouldn't... If some Pike C module runs aclocal it could pull in >both the pike's aclocal.m4 and other files with, possibly, macros that are >already defined in the pike's aclocal.m4 file. I doubt autoconf is smart >enough to cope with it ;) > >> > 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. >Then putting it in a system-wide location is not justified. And its sole >existence outside the pike interpreter build process seems to be >questionable in that light... > >> 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. >First of all, they aren't mine. Second of all, they serve the purpose of >keeping the stuff where it belongs and where anyone can find it knowing only >the type of the resource they're looking for (e.g. autoconf macros -> >/usr/share/aclocal, C header files -> /usr/include/*, application specific >shareable stuff -> /usr/share/applicationname/*). It's in the Unix >spirit, according to LSB and done that way to faciliate sharing >architecture-independent stuff between machines on the LAN or WAN. All the >architecture-independent stuff goes in /usr/share which can be shared via >NFS accross the machines on your LAN. Anything that is not >architecture-independent must NOT go in /usr/share, obviously (so the Pike >.o files can't, for instance). > >> >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. >Why didn't I expect a different conclusion? > >marek > > > > / Brevbäraren >

1 0

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

26 Jan '04

Even pure C-modules generate .pmod files nowdays. Which is what I wrote, I think. / Per Hedbor () Previous text: >2004-01-26 21:21: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 08:55:01PM +0100, Per Hedbor () @ Pike (-) developers forum scribbled: >> How can it save space? You really _do_ need pike to compile >The autobuilders work by keeping a minimum bootstrap filesystem in a chroot >or UML. When a package is requested for autobuild, the build daemon >downloads all the build-time dependencies for the package. Pike pulls in >quite a lot of stuff, if you install everything, around 100MB. The pike core >pulls around 40MB. > >> 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). >Neither caudium nor php4 need to dump anything. All they have is pure C code >that needs nothing else but the pike C header files. In that light, >downloading the whole interpreter just isn't necessary. Besides, I could >never figure out how to (correctly) dump pike .pmod and .pike files outside >the pike install process... So it's academical... > >marek > > > > / Brevbäraren >

1 0

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

26 Jan '04

What's the point of a .m4-file with support for multiple pike versions (which would require an elaborate system to add macros, and support for having the same macro in different versions) instead of multiple files? One could of course have a pike.m4 along with a AC_PIKE_INIT() or so with only 'include(/usr/include/pike/VERSION/aclocal.m4)' as it's body. Where version is taken from the arguments, and some code in the beginning to select a suitable one (as in, the one that is called when running pike --version) as default. That's not very meaningful, though. / Per Hedbor () Previous text: >2004-01-26 21:02: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 08:50:03PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum scribbled: >> You only have a single version of pike installed?? >No, but I can tell without big problems which pikes are available in Debian >and set pike.m4 for them. I can also use, say, > >/etc/pike/versions > >and source it in pike.m4 > >marek > > > > / Brevbäraren >

1 1

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