bug-gnunet
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]