-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hey there,
i want to patch & build openccs under fedora. So I have to do the autoconf/automake chain. No problem at all, but one special thing makes me wanne cry:
I see the following line in configure.in (yes its an relatively old tarball):
GLOB_INCLUDE="-I${srcdir} -I${srcdir}/include" AC_SUBST(GLOB_INCLUDE)
This means I have config headers in the include subdirectory, where I actually build the package.
But my autoconf adds the following lines to the ./configure script:
# When building in place, set srcdir=. if test "$ac_abs_confdir" = "$ac_pwd"; then srcdir=. fi
How can I fix that?
thank you
christoph
On Mon, Jan 07, 2008 at 02:07:59PM +0100, Christoph Höger wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hey there,
i want to patch & build openccs under fedora. So I have to do the autoconf/automake chain. No problem at all, but one special thing makes me wanne cry:
I see the following line in configure.in (yes its an relatively old tarball):
Are you using the same autoconf version that was used to generate th eupsteram tarball (and same automake)? There are older versions kept in fedora exactly for such issues.
-- Pat
Hi,
it was originally built with autoconf-2.59, which is not available for fedora as I see in 'yum search autoconf' output.
Am Montag, den 07.01.2008, 15:05 +0100 schrieb Patrice Dumas:
On Mon, Jan 07, 2008 at 02:07:59PM +0100, Christoph Höger wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hey there,
i want to patch & build openccs under fedora. So I have to do the autoconf/automake chain. No problem at all, but one special thing makes me wanne cry:
I see the following line in configure.in (yes its an relatively old tarball):
Are you using the same autoconf version that was used to generate th eupsteram tarball (and same automake)? There are older versions kept in fedora exactly for such issues.
-- Pat
On Mon, Jan 07, 2008 at 04:37:23PM +0100, Christoph Höger wrote:
Hi,
it was originally built with autoconf-2.59, which is not available for fedora as I see in 'yum search autoconf' output.
Indeed. The idea is that 2.61 is compatible with 2.59, though it doesn't seems like it is true in your case...
-- Pat
Christoph Höger choeger@cs.tu-berlin.de writes:
I see the following line in configure.in (yes its an relatively old tarball):
GLOB_INCLUDE="-I${srcdir} -I${srcdir}/include"
GLOB_INCLUDE='-I${top_srcdir} -I${top_srcdir}/include'
(note the ' instead of ") should do what you want.
Enrico
Hi
Thanks, I will give it a try, but does that stop the configure script from setting srcdir to . ?
Am Montag, den 07.01.2008, 15:18 +0100 schrieb Enrico Scholz:
Christoph Höger choeger@cs.tu-berlin.de writes:
I see the following line in configure.in (yes its an relatively old tarball):
GLOB_INCLUDE="-I${srcdir} -I${srcdir}/include"
GLOB_INCLUDE='-I${top_srcdir} -I${top_srcdir}/include'
(note the ' instead of ") should do what you want.
Enrico
Hello,
On Mon, Jan 07, 2008 at 02:07:59PM +0100, Christoph Höger wrote:
GLOB_INCLUDE="-I${srcdir} -I${srcdir}/include" AC_SUBST(GLOB_INCLUDE)
variables like srcdir, top_srcdir, top_builddir, and such are not available for the shell code in the configure.ac. The manual does not mention them. (Yes, there is something about having the available in AC_CONFIG_* macros, but that's not the case here.)
These variables are available in the file _created_ by configure, specifically in the makefiles.
So, formally speaking, the observed problem with backward compatibility of 2.61 is caused by relying on undocumented features in the autoconfigury of openccs.
Let me outline the way to fix this. src/make.rules should use $(top_srcdir) and such like this:
GLOB_INCLUDE = \ -I$(top_srcdir) \ -I$(top_srcdir)/include TOOLS_INCLUDE = \ -I$(top_srcdir)/shared/rte \ -I$(top_builddir)/shared/comm \ -I$(top_srcdir)/shared/comm \ -I$(top_srcdir)/shared/filterIdent \ -I$(top_srcdir)/shared/tools
AM_CPPFLAGS = $(GLOB_DEFINES) $(GLOB_INCLUDE) $(TOOLS_INCLUDE)
Note: - the two lines quoted in the top of this mail should go away from configure.in, GLOB_INCLUDE in defined directly in make.rules - likewise, TOOLS_INCLUDE shall not be AC_SUBSTed - some Makefile.am contain INCLUDE = @GLOB_INCLUDE@ and such; these are redundant and should go away - $(GLOB_DEFINES) works even though it is not spelled as @...@; thats because all AC_SUBSTed variables are inherited in makefiles
Hope this explanation will drag you back to the sane world. ;-)
Have a nice day, Stepan Kasal
Am Montag, den 07.01.2008, 20:01 +0100 schrieb Stepan Kasal:
Hello,
On Mon, Jan 07, 2008 at 02:07:59PM +0100, Christoph Höger wrote:
GLOB_INCLUDE="-I${srcdir} -I${srcdir}/include" AC_SUBST(GLOB_INCLUDE)
variables like srcdir, top_srcdir, top_builddir, and such are not available for the shell code in the configure.ac. The manual does not mention them. (Yes, there is something about having the available in AC_CONFIG_* macros, but that's not the case here.)
These variables are available in the file _created_ by configure, specifically in the makefiles.
So, formally speaking, the observed problem with backward compatibility of 2.61 is caused by relying on undocumented features in the autoconfigury of openccs.
Let me outline the way to fix this. src/make.rules should use $(top_srcdir) and such like this:
GLOB_INCLUDE = \ -I$(top_srcdir) \ -I$(top_srcdir)/include TOOLS_INCLUDE = \ -I$(top_srcdir)/shared/rte \ -I$(top_builddir)/shared/comm \ -I$(top_srcdir)/shared/comm \ -I$(top_srcdir)/shared/filterIdent \ -I$(top_srcdir)/shared/tools
AM_CPPFLAGS = $(GLOB_DEFINES) $(GLOB_INCLUDE) $(TOOLS_INCLUDE)
Note:
- the two lines quoted in the top of this mail should go away from configure.in, GLOB_INCLUDE in defined directly in make.rules
- likewise, TOOLS_INCLUDE shall not be AC_SUBSTed
- some Makefile.am contain INCLUDE = @GLOB_INCLUDE@ and such; these are redundant and should go away
- $(GLOB_DEFINES) works even though it is not spelled as @...@; thats because all AC_SUBSTed variables are inherited in makefiles
Hope this explanation will drag you back to the sane world. ;-)
Have a nice day, Stepan Kasal
Hi,
thank you for your advice! I'm going to fix the package tomorrow. (hopefully the doctor will let me go home tomorrow ;) )
christoph