* 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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
