Re: Can't repeat build.

[Dan Smithers]

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