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
I should note that I'm not at all against an automake pike.m4 or what not, but rather I'm arguing that if "pike -x module" is broken, it should be fixed.
/ David Hedbor
Previous text:
2004-01-27 16:54: Subject: Re: Pike @ Debian
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
I must say I really like your concise approach. :-) Not only because I happen to agree, even though it probably helps.
Perhaps I can provide a bit more background. Caudium, and by extension pexts were written before pike -x module came about. They're designed to compile with older versions of pike, and as such can't currently use the build system in place. They use a bunch of "homebrewed" techniques, including automake, i believe.
My understanding of the problem (which could be incorrect), is that pike makes an assumption about the c include files (in particular) being in a location that is relative to the pike installation root, which in the case of debian isn't necessarily the case. Marek's modules do, from what I can determine.
I guess the root of the problems that he'd like a way to be able to gather the location of said includes without having to resort to starting pike, for purposes of using the debian autobuild systems, hence the suggestion of pike-config --cflags.
Getting away from the whole religious wars about what philosophy is correct, I guess the real question is, can we make it so that the include files (and other such sets of data) can be installed in arbitrary locations rather than in a subdirectory under pike's exclusive control?
To this point, I have an autoconf macro (submitted to the pike list a while back) that can be used to gather most of this information, however, it relies on the presence of a working pike.
It worked something like:
AP_HAVE_PIKE(7.2.308 7.4.20) <== require a pike between 7.2.308 and 7.4.20
which would provide the command line argument --with-pike= and set a bunch of variables for file locations and such. I realize that it's not the recommended method for developing modules, but it is useful for other things, like developing programs that rely on pike. Some of the pext automake/autoconf stuff uses similar code.
sheesh, I've lost track of what I was going to say in the first place. this problem seems to be contagious...
Bill
From what I have tried to puzzle together from small scraps and pieces
over the past days (and I may be off by a mile here), the current set of Caudium/PExt modules (ab)use some or other pike aclocal.m4 macros in an aclocal/automake context, somehow leading to the uncomfortable situation with the debian packages' redistribution of those internals to an overly exposed location.
Where are include files installed if pike is configured for a --traditional install?
/ Niels Möller (vässar rödpennan)
Previous text:
2004-01-27 21:14: Subject: Re: Pike @ Debian
Perhaps I can provide a bit more background. Caudium, and by extension pexts were written before pike -x module came about. They're designed to compile with older versions of pike, and as such can't currently use the build system in place. They use a bunch of "homebrewed" techniques, including automake, i believe.
My understanding of the problem (which could be incorrect), is that pike makes an assumption about the c include files (in particular) being in a location that is relative to the pike installation root, which in the case of debian isn't necessarily the case. Marek's modules do, from what I can determine.
I guess the root of the problems that he'd like a way to be able to gather the location of said includes without having to resort to starting pike, for purposes of using the debian autobuild systems, hence the suggestion of pike-config --cflags.
Getting away from the whole religious wars about what philosophy is correct, I guess the real question is, can we make it so that the include files (and other such sets of data) can be installed in arbitrary locations rather than in a subdirectory under pike's exclusive control?
To this point, I have an autoconf macro (submitted to the pike list a while back) that can be used to gather most of this information, however, it relies on the presence of a working pike.
It worked something like:
AP_HAVE_PIKE(7.2.308 7.4.20) <== require a pike between 7.2.308 and 7.4.20
which would provide the command line argument --with-pike= and set a bunch of variables for file locations and such. I realize that it's not the recommended method for developing modules, but it is useful for other things, like developing programs that rely on pike. Some of the pext automake/autoconf stuff uses similar code.
sheesh, I've lost track of what I was going to say in the first place. this problem seems to be contagious...
Bill
From what I have tried to puzzle together from small scraps and pieces
over the past days (and I may be off by a mile here), the current set of Caudium/PExt modules (ab)use some or other pike aclocal.m4 macros in an aclocal/automake context, somehow leading to the uncomfortable situation with the debian packages' redistribution of those internals to an overly exposed location.
/ Brevbäraren
My understanding of the problem (which could be incorrect), is that pike makes an assumption about the c include files (in particular) being in a location that is relative to the pike installation root, which in the case of debian isn't necessarily the case.
This is not correct. The location is an absolute path. The assumptions made are:
A) That all the needed files by the build system are in this same location
B) That the master knows the location
At least assumption B), but possibly also A), I haven't checked too closely, is broken by the Debian packaging.
Fixing B) is simple, since the location is dumped in from a variable when the master is generated from master.pike.in. Just make the variable point to the right location, and it doesn't matter exactly where this location is.
Fixing A) (if it needs fixing) means either rearranging the files so that they _are_ in the same location, or reworking the code in Tools.Standalone.module so that the variables "srcdir" and "include_path" are used a little less indiscriminately. This of course requires that all the relevant locations can be found somehow. Using the specs file could be a workable solution, as long as the specs file itself can be found using the information obtained from the master.
Personally I don't see a need for splitting the stuff up, but if other people feel otherwise, I'm not going to try to stop them from adding this to Tools.Standalone.module. However, should anyone take such a project upon themselves, please watch out for regressions. The current system can build modules using
* A pike built from a pike.ida.liu.se distribution or from CVS, and installed using "make install" * An _uninstalled_ pike built from a pike.ida.liu.se distribution or from CVS
Care should be taken that both these cases keep working.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-01-27 21:14: Subject: Re: Pike @ Debian
Perhaps I can provide a bit more background. Caudium, and by extension pexts were written before pike -x module came about. They're designed to compile with older versions of pike, and as such can't currently use the build system in place. They use a bunch of "homebrewed" techniques, including automake, i believe.
My understanding of the problem (which could be incorrect), is that pike makes an assumption about the c include files (in particular) being in a location that is relative to the pike installation root, which in the case of debian isn't necessarily the case. Marek's modules do, from what I can determine.
I guess the root of the problems that he'd like a way to be able to gather the location of said includes without having to resort to starting pike, for purposes of using the debian autobuild systems, hence the suggestion of pike-config --cflags.
Getting away from the whole religious wars about what philosophy is correct, I guess the real question is, can we make it so that the include files (and other such sets of data) can be installed in arbitrary locations rather than in a subdirectory under pike's exclusive control?
To this point, I have an autoconf macro (submitted to the pike list a while back) that can be used to gather most of this information, however, it relies on the presence of a working pike.
It worked something like:
AP_HAVE_PIKE(7.2.308 7.4.20) <== require a pike between 7.2.308 and 7.4.20
which would provide the command line argument --with-pike= and set a bunch of variables for file locations and such. I realize that it's not the recommended method for developing modules, but it is useful for other things, like developing programs that rely on pike. Some of the pext automake/autoconf stuff uses similar code.
sheesh, I've lost track of what I was going to say in the first place. this problem seems to be contagious...
Bill
From what I have tried to puzzle together from small scraps and pieces
over the past days (and I may be off by a mile here), the current set of Caudium/PExt modules (ab)use some or other pike aclocal.m4 macros in an aclocal/automake context, somehow leading to the uncomfortable situation with the debian packages' redistribution of those internals to an overly exposed location.
/ Brevbäraren
Uh. If it doesn't work it SHOULD BE FIXED, I meant to say.
(uppercase to emphasize missing words in the original post).
/ David Hedbor
Previous text:
2004-01-27 16:54: Subject: Re: Pike @ Debian
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
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
David Hedbor ＠ Pike developers forum -
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Niels M�ller (v�ssar r�dpennan) ＠ Pike (-) developers forum
-
Per Hedbor () ＠ Pike (-) developers forum