Ralf Wildenhues wrote:
> * 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
I thought that configure.ac in the components directory would be the
wrapper for the components. The relative path $(top_builddir) is made in
the components configuration.
>>>> 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).
I'll look into those options.
thanks
dan
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
