Menu
▾
▴
naviserver-devel
|
From: Zoran V. <zv...@ar...> - 2005-10-21 15:27:06
|
Hi!
I do not know how to resolve those...
Normally, I have a Tcl module (built with TEA) and would like
to link it together with NS. It complains about PACKAGE and
VERSION already being defined in nsconfig.h... Bad thing is
that I use those things in my C-code so whenever I load
nsconfig.h, it re-defines them :-(
Using TEA, you get all those things defined on the command line:
gcc -pipe -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -
D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -
DHAVE_PTHREAD_ATFORK=1 -DHAVE_READDIR_R=1 -
DHAVE_THREE_ARG_READDIR_R=1 -DHAVE_LIBKERN_OSATOMIC_H=1 -
DHAVE_OSSPINLOCKLOCK=1 -DMAC_OSX_TCL=1 -DUSE_VFORK=1 -
DTCL_DEFAULT_ENCODING=\"utf-8\" -DTCL_LOAD_FROM_MEMORY=1 -
DTCL_WIDE_INT_TYPE=long\ long -DWORDS_BIGENDIAN=1 -DHAVE_GETCWD=1 -
DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_STRTOLL=1 -
DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DNO_VALUES_H=1 -
DHAVE_LIMITS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -
DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -
DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -
DHAVE_TM_GMTOFF=1 -DHAVE_ST_BLKSIZE=1 -DSTDC_HEADERS=1 -
DHAVE_SIGNED_CHAR=1 -DHAVE_PUTENV_THAT_COPIES=1 -DHAVE_LANGINFO=1 -
DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_FILIO_H=1 -DTCL_WIDE_INT_TYPE=long\
long -DNO_VALUES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DVERSION=
\"0.2\" -DPACKAGE=\"archdev\" -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 -
D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_READDIR_R=1
-DTCL_THREADS=1 -DUSE_TCL_STUBS=1 -DNS_AOLSERVER=1 -arch ppc -pipe -
I"/usr/local/include" -DNO_CONST -I../generic -I/Users/zoran/dev/
libmacbinary/generic -I/Users/zoran/dev/libarchdev/generic -I/Users/
zoran/dev/findutils-4.1/find -g -fno-common -g -fno-common -I/usr/
local/aolserver/include -c `echo tclp_bg.c` -o tclp_bg.o
-DVERSION=\"0.2\"
-DPACKAGE=\"archdev\"
Now, as I understand, those symbols are defined by autoconf
automatically.
Does anybody have any idea how to get out of this blues?
At the moment, I have to edit the nsconfig.h and remove
lines definig PACKAGE and VERSION but I assume this is
not the most elegant and fail-safe way...
Another blues: the new TEA (3.3) uses PACKAGE_NAME and
PACKAGE_VERSION (obviously because of the above reason)
but NS uses them AS WELL since it also uses TEA!
My god, what a mess...
Zoran
|
|
From: Vlad S. <vl...@cr...> - 2005-10-21 15:40:47
|
Can we use NS_VERSION and NS_PACKAGE instead in nsconfig.h? Zoran Vasiljevic wrote: > Hi! > > I do not know how to resolve those... > > Normally, I have a Tcl module (built with TEA) and would like > to link it together with NS. It complains about PACKAGE and > VERSION already being defined in nsconfig.h... Bad thing is > that I use those things in my C-code so whenever I load > nsconfig.h, it re-defines them :-( > > Using TEA, you get all those things defined on the command line: > > gcc -pipe -DTCL_THREADS=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 - > D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 - > DHAVE_PTHREAD_ATFORK=1 -DHAVE_READDIR_R=1 - DHAVE_THREE_ARG_READDIR_R=1 > -DHAVE_LIBKERN_OSATOMIC_H=1 - DHAVE_OSSPINLOCKLOCK=1 -DMAC_OSX_TCL=1 > -DUSE_VFORK=1 - DTCL_DEFAULT_ENCODING=\"utf-8\" -DTCL_LOAD_FROM_MEMORY=1 > - DTCL_WIDE_INT_TYPE=long\ long -DWORDS_BIGENDIAN=1 -DHAVE_GETCWD=1 - > DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_STRTOLL=1 - > DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DNO_VALUES_H=1 - > DHAVE_LIMITS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 - DUSE_TERMIOS=1 > -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 - DHAVE_TM_ZONE=1 > -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 - DHAVE_TM_GMTOFF=1 > -DHAVE_ST_BLKSIZE=1 -DSTDC_HEADERS=1 - DHAVE_SIGNED_CHAR=1 > -DHAVE_PUTENV_THAT_COPIES=1 -DHAVE_LANGINFO=1 - DHAVE_SYS_IOCTL_H=1 > -DHAVE_SYS_FILIO_H=1 -DTCL_WIDE_INT_TYPE=long\ long -DNO_VALUES_H=1 > -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DVERSION= \"0.2\" > -DPACKAGE=\"archdev\" -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1 - > D_THREAD_SAFE=1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=1 -DHAVE_READDIR_R=1 > -DTCL_THREADS=1 -DUSE_TCL_STUBS=1 -DNS_AOLSERVER=1 -arch ppc -pipe - > I"/usr/local/include" -DNO_CONST -I../generic -I/Users/zoran/dev/ > libmacbinary/generic -I/Users/zoran/dev/libarchdev/generic -I/Users/ > zoran/dev/findutils-4.1/find -g -fno-common -g -fno-common -I/usr/ > local/aolserver/include -c `echo tclp_bg.c` -o tclp_bg.o > > -DVERSION=\"0.2\" > -DPACKAGE=\"archdev\" > > Now, as I understand, those symbols are defined by autoconf > automatically. > > Does anybody have any idea how to get out of this blues? > At the moment, I have to edit the nsconfig.h and remove > lines definig PACKAGE and VERSION but I assume this is > not the most elegant and fail-safe way... > > Another blues: the new TEA (3.3) uses PACKAGE_NAME and > PACKAGE_VERSION (obviously because of the above reason) > but NS uses them AS WELL since it also uses TEA! > My god, what a mess... > > Zoran > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2005-10-21 15:54:15
|
Am 21.10.2005 um 17:42 schrieb Vlad Seryakov: > Can we use NS_VERSION and NS_PACKAGE instead in nsconfig.h? > Well I think not that easy: (configure.in) AC_INIT(NaviServer, 4.99.1, nav...@li...) AC_CONFIG_SRCDIR(include/ns.h) AC_CONFIG_HEADER(include/nsconfig.h) AC_PREREQ(2.50) AC_REVISION($Revision: 1.15 $) AM_INIT_AUTOMAKE (aclocal.m4) # AM_INIT_AUTOMAKE(PACKAGE, VERSION, [NO-DEFINE]) # AM_INIT_AUTOMAKE([OPTIONS]) # ----------------------------------------------- # The call with PACKAGE and VERSION arguments is the old style # call (pre autoconf-2.50), which is being phased out. PACKAGE # and VERSION should now be passed to AC_INIT and removed from # the call to AM_INIT_AUTOMAKE. # We support both call styles for the transition. After # the next Automake release, Autoconf can make the AC_INIT # arguments mandatory, and then we can depend on a new Autoconf # release and drop the old call support. I believe autoconf defines those automatically when you call AC_INIT. The way we now generate headers (autoheader), it gets included in the nsconfig.h automatically... I do not know the autoconf machinery enough, unfortunately. Zoran |
|
From: Stephen D. <sd...@gm...> - 2005-10-22 13:27:40
|
On 10/21/05, Zoran Vasiljevic <zv...@ar...> wrote: > Hi! > > I do not know how to resolve those... > > Normally, I have a Tcl module (built with TEA) and would like > to link it together with NS. It complains about PACKAGE and > VERSION already being defined in nsconfig.h... Bad thing is > that I use those things in my C-code so whenever I load > nsconfig.h, it re-defines them :-( > > Using TEA, you get all those things defined on the command line: > > gcc -pipe -DTCL_THREADS=3D1 -DUSE_THREAD_ALLOC=3D1 -D_REENTRANT=3D1 - > D_THREAD_SAFE=3D1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=3D1 - > DHAVE_PTHREAD_ATFORK=3D1 -DHAVE_READDIR_R=3D1 - > DHAVE_THREE_ARG_READDIR_R=3D1 -DHAVE_LIBKERN_OSATOMIC_H=3D1 - > DHAVE_OSSPINLOCKLOCK=3D1 -DMAC_OSX_TCL=3D1 -DUSE_VFORK=3D1 - > DTCL_DEFAULT_ENCODING=3D\"utf-8\" -DTCL_LOAD_FROM_MEMORY=3D1 - > DTCL_WIDE_INT_TYPE=3Dlong\ long -DWORDS_BIGENDIAN=3D1 -DHAVE_GETCWD=3D1 - > DHAVE_OPENDIR=3D1 -DHAVE_STRSTR=3D1 -DHAVE_STRTOL=3D1 -DHAVE_STRTOLL=3D1 = - > DHAVE_STRTOULL=3D1 -DHAVE_TMPNAM=3D1 -DHAVE_WAITPID=3D1 -DNO_VALUES_H=3D1= - > DHAVE_LIMITS_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_SYS_PARAM_H=3D1 - > DUSE_TERMIOS=3D1 -DHAVE_SYS_TIME_H=3D1 -DTIME_WITH_SYS_TIME=3D1 - > DHAVE_TM_ZONE=3D1 -DHAVE_GMTIME_R=3D1 -DHAVE_LOCALTIME_R=3D1 - > DHAVE_TM_GMTOFF=3D1 -DHAVE_ST_BLKSIZE=3D1 -DSTDC_HEADERS=3D1 - > DHAVE_SIGNED_CHAR=3D1 -DHAVE_PUTENV_THAT_COPIES=3D1 -DHAVE_LANGINFO=3D1 - > DHAVE_SYS_IOCTL_H=3D1 -DHAVE_SYS_FILIO_H=3D1 -DTCL_WIDE_INT_TYPE=3Dlong\ > long -DNO_VALUES_H=3D1 -DHAVE_UNISTD_H=3D1 -DHAVE_SYS_PARAM_H=3D1 -DVERSI= ON=3D > \"0.2\" -DPACKAGE=3D\"archdev\" -DUSE_THREAD_ALLOC=3D1 -D_REENTRANT=3D1 - > D_THREAD_SAFE=3D1 -DHAVE_PTHREAD_ATTR_SETSTACKSIZE=3D1 -DHAVE_READDIR_R= =3D1 > -DTCL_THREADS=3D1 -DUSE_TCL_STUBS=3D1 -DNS_AOLSERVER=3D1 -arch ppc -pip= e - > I"/usr/local/include" -DNO_CONST -I../generic -I/Users/zoran/dev/ > libmacbinary/generic -I/Users/zoran/dev/libarchdev/generic -I/Users/ > zoran/dev/findutils-4.1/find -g -fno-common -g -fno-common -I/usr/ > local/aolserver/include -c `echo tclp_bg.c` -o tclp_bg.o > > -DVERSION=3D\"0.2\" > -DPACKAGE=3D\"archdev\" > > Now, as I understand, those symbols are defined by autoconf > automatically. > > Does anybody have any idea how to get out of this blues? > At the moment, I have to edit the nsconfig.h and remove > lines definig PACKAGE and VERSION but I assume this is > not the most elegant and fail-safe way... > > Another blues: the new TEA (3.3) uses PACKAGE_NAME and > PACKAGE_VERSION (obviously because of the above reason) > but NS uses them AS WELL since it also uses TEA! > My god, what a mess... How about this: Rename nsconfig.h -> config.h and don't install it. Include it explicitly where it's needed, not via ns.h. Create nsversion.h to hold version info, install it. This would mean that the results of configuration probing are not available to modules, but I'd like to move towards having modules run their own configure scripts, a bit like TEA. Is anyone depending on this? Generating nsversion.h feels better to me than running ns.h through configu= re. |
|
From: Zoran V. <zv...@ar...> - 2005-10-22 13:38:36
|
Am 22.10.2005 um 15:20 schrieb Stephen Deasey: > > How about this: > > Rename nsconfig.h -> config.h and don't install it. > Include it explicitly where it's needed, not via ns.h. > Create nsversion.h to hold version info, install it. Yes. This stops the blues. > > This would mean that the results of configuration probing are not > available to modules, but I'd like to move towards having modules run > their own configure scripts, a bit like TEA. Is anyone depending on > this? Yes. Modules should do somethig similar Tcl modules are doing. This is well-known and (well) tested and understood. This way the module writer may/should/must perform his own specific configure step. Cheers Zoran |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X