Re: [bug-GNUnet] problem building GNUnet-0.6.0a

[Mike Castle]

On Sat, Apr 24, 2004 at 06:11:40PM -0500, Christian Grothoff wrote:
> 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?

The section from the INSTALL doc that discusses this is here:

Compiling For Multiple Architectures
====================================

   You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory.  To do this, you must use a version of `make' that
supports the `VPATH' variable, such as GNU `make'.  `cd' to the
directory where you want the object files and executables to go and run
the `configure' script.  `configure' automatically checks for the
source code in the directory that `configure' is in and in `..'.

   If you have to use a `make' that does not support the `VPATH'
variable, you have to compile the package for one architecture at a
time in the source code directory.  After you have installed the
package for one architecture, use `make distclean' before reconfiguring
for another architecture.

And later with:

`--srcdir=DIR'
     Look for the package's source code in directory DIR.  Usually
     `configure' can determine that directory automatically.


The way I typically do it is something like the following:

tar xzf /usr/mirror/gnu/gnunet/GNUnet-0.6.0a.tar.bz2
mkdir GNUnet-0.6.0a-build
cd GNUnet-0.6.0a-build
../GNUnet-0.6.0a/configure --prefix=.....

On most modern systems, --srcdir really isn't necessary.

> > 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.  

You could always do something like:

include $(top_srcdir)/makefile.common

And do something like:

INCLUDES = -I$(top_srcdir)/path/to/include/directory

in makefile.common

But, typically, that's not how automaked programs are done.  After all, if
you have to touch each file to put in the makefile include, just as easy to
put in the INCLUDES instead.


> > 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).  

The thing is, this is inherently unstable.

What if I'm trying to compile against another package that, for some
strange reason, decides to use the USE_OPENSSL define that has completely
different semantics than you have?

You can only control what is used inside of your package, not the rest of
the world.  You have to be defensive.  That means that the API that is
exposed to the world should not matter at all on whether or not SSL was
selected or not.

Imagine the case where GNUnet got installed and no OPENSSL was installed.
Then someone installed OPENSSL.  Now suppose a new application gets
installed that uses GNUnet, and detects OPENSSL is present in it's
configure and so sets USE_OPENSSL.

> 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...).

Understand.  I'm on close to 200 email lists as is; I don't need to sign up
for many more.  ;->

Far as more experience?  Not really.  But I do read the autoconf lists, and
this particular question might be better answered there.

GNUnet is not alone as an example of a library that changes how it
functions (or what functions are active) depending upon what software was
previously installed on the system.  The autoconf list can probably give
you a good example to look at (I can't think of one off the top of my
head).  Well, maybe the Gnome library libsoup would work.  It can use SSL
and GNUTLS and so on.  But no installed API files depend on having that
knowledge ahead of time.

mrc
-- 
     Mike Castle      address@hidden      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc