Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

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

27 Jan '04

pike -x module is a new build system. Let's generate aclocal.m4 from pike, then you would not complain about that file, right? Then we put the information in the current dynamic_module_makefile in lib/modules/Tools.pmod/Build.pmod or somthing similar. Would that be better? Note that nothing would really be differnt. But anal debian maintainers would probably be happier. Personally I think it would be pointless to do all this work for nothing, though. / Per Hedbor () 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 >

6 8

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

27 Jan '04

>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 >

1 0

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

26 Jan '04

>Let me remind you that the >proposition was to put the pike's aclocal.m4 under a different name in the >system-wide .m4 directory. Does that change your assessment? I'm not sure which system-wide .m4 directory you mean. I didn't get one with the installation of either m4 or autoconf, as far as I'm aware. share/autoconf/*/*.m4 is autoconf internal files. share/aclocal is for files intended to be picked up by aclocal, and you can't even rely on it's existance unless you make pike depend on automake, which I think would be unnecessary and unfortunate. Neither is the right place for pike's aclocal.m4. >It does *not* mean the external Pike modules written in C _cannot_ use >automake, am I right? Or is it forbidden because Pike itself doesn't use it? You can use automake, but then you will not use pike -x module. And it makes no sense to have aclocal pick up the aclocal.m4 which is intended for use with pike -x. I don't know for sure that it doesn't work to do that (as I haven't tried), no matter if it ever works it's an utterly unsupported way to use that file. It's on par with including files from pike/lib/include/ into C programs. >> 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. >Of course it isn't. My point is that debian automake policy should be applied only to the installation of files which are intended to be used with automake, or are in some other way closely related to automake. The pike package does not contain a single file that is intended to be used with automake; therefore automake policy is not relevant to the pike interpreter package. / Niels Möller (vässar rödpennan) Previous text: >2004-01-26 22:18: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 09:45:04PM +0100, Niels Möller (vässar rödpennan) @ Pike (-) developers forum scribbled: >> >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. >Believe or not, but I'm quite aware of that. Let me remind you that the >proposition was to put the pike's aclocal.m4 under a different name in the >system-wide .m4 directory. Does that change your assessment? > >> 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. >Again, I'm quite aware of the fact. > >> The aclocal proram is a later invention that constructs an aclocal.m4 >> file from various fragments stored somewhere under share. >You haven't surprised me here, either. > >> 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. >It does *not* mean the external Pike modules written in C _cannot_ use >automake, am I right? Or is it forbidden because Pike itself doesn't use it? > >> 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. >Of course it isn't. But it might be relevant to external Pike modules. But >you're determined to ignore them, right? > >marek > > > > / Brevbäraren >

2 2

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

Jump to page:

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