I made some changes to the autoconf macro that is used to find a pike. It seems to work a little bit better, though it has one shortcoming I'd like to fix: if you specify a pike that's actually a symlink to another, it won't follow the symlink to determine what the actual filename is. This creates a problem when you install a new version of pike (which is a relatively common occurrence), and things stop working because the version has changed:
/usr/local/bin/pike is actually /usr/local/pike/ver/bin/pike.
Any thoughts about this?
-- Specifically, I made some portability changes and added the ability to check for minimum and maximum pike versions. This macro makes it easier to get pike modules set up, as it sets a number of autoconf substitutions.
Example in a configure.in/ac when this file is stored as aclocal.m4 in your project directory:
AP_CHECK_PIKE(7.4.1, 7.4.999)
to check for a version of pike that's between 7.4.1 and 7.4.999, and make sure it has a C include directory (where the headers and compile tools live).
It sets the following variables/substitutions:
PIKE - path to pike PIKE_VERSION - version of pike found (ie 7.4.10) PIKE_INCLUDE_DIRS - string to includes (ie -I /usr/local/pike/7.4.10/include/pike) PIKE_MODULE_DIR - path to pike modules directory (ie /usr/local/pike/7.4.10/lib/modules)0
I'd like to get some feedback on this, along with other suggestions for easing the creation of pike modules and applications. Thanks again!
Bill -- H. William Welliver / Fairchild Semiconductor Mountain Top Systems email: bill.welliver@fairchildsemi.com / phone: 570.474.6761 x4445 cell: 570.262.7151
Hi Bill,
I made some changes to the autoconf macro that is used to find a pike. It seems to work a little bit better, though it has one shortcoming I'd like to fix: if you specify a pike that's actually a symlink to another, it won't follow the symlink to determine what the actual filename is. This creates a problem when you install a new version of pike (which is a relatively common occurrence), and things stop working because the version has changed:
/usr/local/bin/pike is actually /usr/local/pike/ver/bin/pike.
Any thoughts about this?
Maybe parsing the output of file on the symbolic link ?
Specifically, I made some portability changes and added the ability to check for minimum and maximum pike versions. This macro makes it easier to get pike modules set up, as it sets a number of autoconf substitutions.
Example in a configure.in/ac when this file is stored as aclocal.m4 in your project directory:
AP_CHECK_PIKE(7.4.1, 7.4.999)
Great :)
to check for a version of pike that's between 7.4.1 and 7.4.999, and make sure it has a C include directory (where the headers and compile tools live).
It sets the following variables/substitutions:
PIKE - path to pike PIKE_VERSION - version of pike found (ie 7.4.10) PIKE_INCLUDE_DIRS - string to includes (ie -I /usr/local/pike/7.4.10/include/pike)
PIKE_MODULE_DIR - path to pike modules directory (ie /usr/local/pike/7.4.10/lib/modules)0
Why not using pike -e 'write("%s\n", master()->pike_module_path * "\n"); to get the module paths and pike -e 'write("%s\n", master()->pike_include_path * "\n");' for include paths ? I think it's the best way to be sure to get the paths used by the given Pike binary if you have several of the them. Also it reduces the code needed to perform the guess.
I'd like to get some feedback on this, along with other suggestions for easing the creation of pike modules and applications. Thanks again!
I think there are other things we need to have especially the flags that was used during the Pike installation like -DPIKE_DEBUG or -DMALLOC_something. Indeed if you compile your Pike with dmalloc chances are you will want to debug your own modules as well. I've checked pike -x module code for that but it doesn't provide this information. Indeed I've got a Pike compiled with dmalloc and pike -x module doesn't give information about that. And if I look in $PIKE_INCLUDE_PATH/specs I don't have all the flags used in the compilation:
$ cat specs # $Id: specs.in,v 1.2 2002/09/13 01:14:26 marcus Exp $ CC=/usr/local/pike/7.4.31/include/pike/smartlink gcc CFLAGS= -g -mcpu=i686 LDFLAGS= -R/usr/local/lib -L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib CPPFLAGS= -I/usr/local/include -I/usr/X11R6/include CPP=gcc -E LDSHARED=gcc -shared configure_args=
Maybe it's a bug ?
/ David
The macros that affect compilation (mainly AUTO_BIGNUM, PIKE_SECURITY, PIKE_DEBUG, DMALLOC_DEBUG, and PROFILING) are propagated via machine.h in the include directory.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-24 10:40: Subject: Re: autoconf macros for pike
Hi Bill,
I made some changes to the autoconf macro that is used to find a pike. It seems to work a little bit better, though it has one shortcoming I'd like to fix: if you specify a pike that's actually a symlink to another, it won't follow the symlink to determine what the actual filename is. This creates a problem when you install a new version of pike (which is a relatively common occurrence), and things stop working because the version has changed:
/usr/local/bin/pike is actually /usr/local/pike/ver/bin/pike.
Any thoughts about this?
Maybe parsing the output of file on the symbolic link ?
Specifically, I made some portability changes and added the ability to check for minimum and maximum pike versions. This macro makes it easier to get pike modules set up, as it sets a number of autoconf substitutions.
Example in a configure.in/ac when this file is stored as aclocal.m4 in your project directory:
AP_CHECK_PIKE(7.4.1, 7.4.999)
Great :)
to check for a version of pike that's between 7.4.1 and 7.4.999, and make sure it has a C include directory (where the headers and compile tools live).
It sets the following variables/substitutions:
PIKE - path to pike PIKE_VERSION - version of pike found (ie 7.4.10) PIKE_INCLUDE_DIRS - string to includes (ie -I /usr/local/pike/7.4.10/include/pike)
PIKE_MODULE_DIR - path to pike modules directory (ie /usr/local/pike/7.4.10/lib/modules)0
Why not using pike -e 'write("%s\n", master()->pike_module_path * "\n"); to get the module paths and pike -e 'write("%s\n", master()->pike_include_path * "\n");' for include paths ? I think it's the best way to be sure to get the paths used by the given Pike binary if you have several of the them. Also it reduces the code needed to perform the guess.
I'd like to get some feedback on this, along with other suggestions for easing the creation of pike modules and applications. Thanks again!
I think there are other things we need to have especially the flags that was used during the Pike installation like -DPIKE_DEBUG or -DMALLOC_something. Indeed if you compile your Pike with dmalloc chances are you will want to debug your own modules as well. I've checked pike -x module code for that but it doesn't provide this information. Indeed I've got a Pike compiled with dmalloc and pike -x module doesn't give information about that. And if I look in $PIKE_INCLUDE_PATH/specs I don't have all the flags used in the compilation:
$ cat specs # $Id: specs.in,v 1.2 2002/09/13 01:14:26 marcus Exp $ CC=/usr/local/pike/7.4.31/include/pike/smartlink gcc CFLAGS= -g -mcpu=i686 LDFLAGS= -R/usr/local/lib -L/usr/local/lib -R/usr/X11R6/lib -L/usr/X11R6/lib CPPFLAGS= -I/usr/local/include -I/usr/X11R6/include CPP=gcc -E LDSHARED=gcc -shared configure_args=
Maybe it's a bug ?
/ David
/ Brevbäraren
Maybe parsing the output of file on the symbolic link ?
yes, that's what I was thinking. there aren't any functions in pike that will do this, are there?
Why not using pike -e 'write("%s\n", master()->pike_module_path * "\n"); to get the module paths and pike -e 'write("%s\n", master()->pike_include_path * "\n");' for include paths ? I think it's the best way to be sure to get the paths used by the given Pike binary if you have several of the them. Also it reduces the code needed to perform the guess.
that's true, i hadn't thought of that, though I was using pike --show-paths. Also, I never intended this for use when building modules per se, as we should be using pike -x modules. It was just a side effect of working with the code.
I was thinking of this as a way to make it easier for developers to develop apps that use pike, but of course I'm willing to listen to suggestions about it.
besides, once they have this, they can include a pike -x module inside of their application's makefile, right?
Bill
Afaics it doesn't use the -x module system. It definitely should for 7.4 and later. Some examples:
> /usr/local/bin/pike -x module --query include_path /usr/local/pike/7.4.25/include/pike > /usr/local/bin/pike -x module --query src_path /usr/local/pike/7.4.25/include/pike > /usr/local/bin/pike -x module --query bin_path /usr/local/pike/7.4.25/include/pike
(src_path and bin_path might be different when running directly from the build tree.)
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-23 22:53: Subject: autoconf macros for pike
I made some changes to the autoconf macro that is used to find a pike. It seems to work a little bit better, though it has one shortcoming I'd like to fix: if you specify a pike that's actually a symlink to another, it won't follow the symlink to determine what the actual filename is. This creates a problem when you install a new version of pike (which is a relatively common occurrence), and things stop working because the version has changed:
/usr/local/bin/pike is actually /usr/local/pike/ver/bin/pike.
Any thoughts about this?
-- Specifically, I made some portability changes and added the ability to check for minimum and maximum pike versions. This macro makes it easier to get pike modules set up, as it sets a number of autoconf substitutions.
Example in a configure.in/ac when this file is stored as aclocal.m4 in your project directory:
AP_CHECK_PIKE(7.4.1, 7.4.999)
to check for a version of pike that's between 7.4.1 and 7.4.999, and make sure it has a C include directory (where the headers and compile tools live).
It sets the following variables/substitutions:
PIKE - path to pike PIKE_VERSION - version of pike found (ie 7.4.10) PIKE_INCLUDE_DIRS - string to includes (ie -I /usr/local/pike/7.4.10/include/pike) PIKE_MODULE_DIR - path to pike modules directory (ie /usr/local/pike/7.4.10/lib/modules)0
I'd like to get some feedback on this, along with other suggestions for easing the creation of pike modules and applications. Thanks again!
Bill
H. William Welliver / Fairchild Semiconductor Mountain Top Systems email: bill.welliver@fairchildsemi.com / phone: 570.474.6761 x4445 cell: 570.262.7151
/ Brevbäraren
good point. i was especially looking at this code as something to use going forward, so I wasn't specifically going to support pre-7.4 pikes, unless someone wanted to do it for me :)
bill
On Fri, 24 Oct 2003, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
Afaics it doesn't use the -x module system. It definitely should for 7.4 and later. Some examples:
> /usr/local/bin/pike -x module --query include_path /usr/local/pike/7.4.25/include/pike > /usr/local/bin/pike -x module --query src_path /usr/local/pike/7.4.25/include/pike > /usr/local/bin/pike -x module --query bin_path /usr/local/pike/7.4.25/include/pike(src_path and bin_path might be different when running directly from the build tree.)
/ Martin Stjernholm, Roxen IS
Previous text:
2003-10-23 22:53: Subject: autoconf macros for pike
I made some changes to the autoconf macro that is used to find a pike. It seems to work a little bit better, though it has one shortcoming I'd like to fix: if you specify a pike that's actually a symlink to another, it won't follow the symlink to determine what the actual filename is. This creates a problem when you install a new version of pike (which is a relatively common occurrence), and things stop working because the version has changed:
/usr/local/bin/pike is actually /usr/local/pike/ver/bin/pike.
Any thoughts about this?
-- Specifically, I made some portability changes and added the ability to check for minimum and maximum pike versions. This macro makes it easier to get pike modules set up, as it sets a number of autoconf substitutions.
Example in a configure.in/ac when this file is stored as aclocal.m4 in your project directory:
AP_CHECK_PIKE(7.4.1, 7.4.999)
to check for a version of pike that's between 7.4.1 and 7.4.999, and make sure it has a C include directory (where the headers and compile tools live).
It sets the following variables/substitutions:
PIKE - path to pike PIKE_VERSION - version of pike found (ie 7.4.10) PIKE_INCLUDE_DIRS - string to includes (ie -I /usr/local/pike/7.4.10/include/pike) PIKE_MODULE_DIR - path to pike modules directory (ie /usr/local/pike/7.4.10/lib/modules)0
I'd like to get some feedback on this, along with other suggestions for easing the creation of pike modules and applications. Thanks again!
Bill
H. William Welliver / Fairchild Semiconductor Mountain Top Systems email: bill.welliver@fairchildsemi.com / phone: 570.474.6761 x4445 cell: 570.262.7151
/ Brevb�raren
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
David Gourdelier -
Martin Stjernholm, Roxen IS ＠ Pike developers forum