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