autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can't repeat build.


From: Ralf Wildenhues
Subject: Re: Can't repeat build.
Date: Sat, 24 Jan 2009 10:53:37 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

* Dan Smithers wrote on Fri, Jan 23, 2009 at 03:22:18PM CET:
> >>>> bin_PROGRAM=exec
> >>>> exec_SOURCES=exec.c
> >>>> exec_LDADD=$(top_builddir)/../libname/src/.libs -lname
> >>> Please replace this line with
> >>>   exec_LDADD=$(top_builddir)/../libname/src/libname.la
> >>>
> >>> but I do wonder: $(top_builddir)/.. points outside of the build tree.
> >>> Is that an error or on purpose?
> >> It points to a neighbouring tree set up by autotools.
> > 
> > Ah, ok.  So you require that users of your packages also need this
> > same setup.
> 
> At the moment I am the main user of the packages.

Yes, but we're all hoping the stuff we're writing for ourselves will be
the next cool trend everybody wants, no?  ;-)

So then, you just go ahead and encapsulate all your sub packages with
one thin wrapper package:

# configure.ac:
AC_INIT([AG set of packages], ...)
AM_INIT_AUTOMAKE([...])
AC_CONFIG_SUBDIRS([components bla blub])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT

# Makefile.am
SUBDIRS = components bla blub

> >> alms_LDADD= -L$(BOOSTDIR)/lib -lboost_regex
> >> -L$(top_builddir)/../libag/src -lagthread -lagmessage -laglogger -lagcomms
> > 
> > If some of those are uninstalled libtool libraries, they should be
> > specified as relative/path/to/libagmessage.la here
> 
> Ahh, what I really want to do is to be able to install the libraries,
> but also use local versions for development.

Well, if you write relative/path/to/libagmessage.la here, then, for the
uninstalled programs, the uninstalled libraries will be used, and upon
"make install", things are arranged such, that for the installed
programs, the installed libraries are used.

> >> AM_CFLAGS=-Wall -Werror
> >> AM_CXXFLAGS=$(AM_CFLAGS)
> > 
> > Those aren't portable to non-GCC, but I guess you knew that; and they
> > are overridable by CFLAGS and CXXFLAGS.
> 
> Yes thanks, when I use other compilers then I set them explicitly. E.g.
> 
> configure CC=icc CXX=icc CFLAGS=<icc C compiler flags>
> CPPFLAGS=<Preprocessor flags> CXXFLAGS=<icc C++ compiler flags>

That's fine.

* Dan Smithers wrote on Fri, Jan 23, 2009 at 04:14:05PM CET:
> >>> BOOSTDIR=[/vol/build/boost_1_37_0]
> >> For eventual other users of your package, this should not be hard-coded
> >> but made configurable.
> > 
> > I think that it can be overridden in the call to
> > <path_to configure>/configure BOOSTDIR=<new boost location>
> 
> I'v just checked and it can't be done this way - presumably this needs
> to be done before autoreconf is run. I can't find a way to add an
> argument to autoreconf.

Why add it to autoreconf?  The simplest would be something like
  : ${BOOSTDIR=/vol/build/boost_1_37_0}

which only sets the variable if it was unset before; but that leaves off
documentation.  You can use AC_ARG_VAR to make BOOSTDIR precious and add
some doc snippet to 'configure --help' output.  Or, and this seems to be
preferred by most other packages, go with some --with-boostdir switch,
added by AC_ARG_WITH (including --help addition and all; see the manual
for details).

Cheers,
Ralf




reply via email to

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