From: braden_mcdaniel (braden_at_[hidden])
Date: 2002-02-26 11:45:56
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: "Braden McDaniel" <braden_at_e...>
> > > * My estimate is that an autoconf/automake expert can produce the
> > > infrastructure that will auto-enable Boost in less time than we
> > > this discussion. Is this correct?
> > Yes.
> > > * Given the above infrastructure, what will the average Boost
> > > in order to support it?
> > If we take "average Boost developer" to mean one who does not want to
> > mess with the autotools build, s/he would mail an autotools build
> > whenever there were changes that required modification of the Jam
> "Average Boost developer" as in, maintains a library that doesn't need
> special configuration or build steps, the only thing that changes is the
> list of .cpp files.
Build targets for libraries look basically like this in automake:
lib_LTLIBRARIES = libfoo.la
libfoo_la_SOURCES = source1.cpp source2.cpp
Changing the list of sources for a library is as simple as changing
the contents of the SOURCES variable. Installed headers are basically
the same (though of course they don't get compiled individually):
include_HEADERS = header1.hpp header2.cpp
I am simplifying a *little* bit for clarity, but not much. Automake
works its magic by looking at the names of these variables and
generating make targets appropriately.
> > For the persons in charge of making Boost releases, a few steps
> > added to the release checklist: update libtool library version
> > and change the Boost version number in configure.ac.
> * What is stopping auto* experts from contributing the necessary
I thought Timothy Shead was going to submit some work he's already
done. If that doesn't happen, I'll see what I can put together.
> * How can I (or we, the Boost developers in general) help?
You could learn the autotools. :-) If you don't want to do that, then
I'd say just keep an autotools build person informed when the
requirements change for your library's build.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk