[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-GNUnet] problem building GNUnet-0.6.0a
From: |
Christian Grothoff |
Subject: |
Re: [bug-GNUnet] problem building GNUnet-0.6.0a |
Date: |
Sat, 24 Apr 2004 18:11:40 -0500 |
User-agent: |
KMail/1.6.1 |
On Thursday 15 April 2004 16:59, Mike Castle wrote:
> I try to build all autoconfiscated packages outside of srcdir (that is
> srcdir != builddir). The INSTALL that comes with GNUnet suggests that this
> should work.
Well, INSTALL is the generic INSTALL file generated by the autotools. But I
can't find anything about this in INSTALL. Which configure options did you
use?
> This fails for GNUnet-0.6.0a with the following:
>
> i386-linux-gcc -DHAVE_CONFIG_H -I. -I../../../GNUnet-0.6.0a/src/util
> -I../../src/include -DPLUGIN_PATH=\"/usr/lib\" -DELIBDIR=\"\"
> -fno-strict-aliasing -Wall -g -O2 -MT bloomfilter.lo -MD -MP -MF
> .deps/bloomfilter.Tpo -c ../../../GNUnet-0.6.0a/src/util/bloomfilter.c
> -fPIC -DPIC -o .libs/bloomfilter.lo
> ../../../GNUnet-0.6.0a/src/util/bloomfilter.c:42:25: gnunet_util.h: No such
> file or directory
>
> Followed by a whole bunch of errors....
>
> Now the thing is that configure.ac has config.h go into src/include, which
> causes $(top_builddir)/src/include to be added to DEFAULT_INCLUDES. When
> building inside the srcdir, this causes the correct src/include to be added
> to the list of includes quite by accident.
>
> What should probably be done is change to AM_CONFIG_HEADER([config.h]), and
> add appropriate INCLUDES to various Makefile.am to allow proper
> compilation.
I can see that this would be cleaner, although I'd prefer a way of setting the
INCLUDES once globally instead of in each Makefile.am individually.
> Hmm... it looks like at least one of the files includes config.h. This is
> probably a really bad idea. The includes should be refactored so that
> installed headers either don't need to include certain files, or it should
> be required that the calling application includes things in the correct
> order.
Yes, this is likely to be a problem, but I don't see how we can do tests like
#ifdef CYGWIN or other platform and configure-specific tests (#if
USE_OPENSSL) without including the autoheader generated config.h. The best
solution I can think of at the moment is to actually make sure that we
*install* config.h (probably renamed to gnunet_config.h to avoid conflicts).
You seem to have a bit more experience with these things, so do you have any
better suggestions? (Btw, the response is a bit late because I didn't check
the administrative requests for bug-gnunet for a while and somehow
mail.gnu.org did not send E-mail notifications for these requests, so sorry
for the delay...).
Christian