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
> necessary
> > > infrastructure that will auto-enable Boost in less time than we
spent on
> > > this discussion. Is this correct?
> >
> > Yes.
> >
> > > * Given the above infrastructure, what will the average Boost
developer
> do
> > > 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
person
> > whenever there were changes that required modification of the Jam
build.
>
> "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
would be
> > added to the release checklist: update libtool library version
numbers,
> > and change the Boost version number in configure.ac.
>
> Good!
>
> * What is stopping auto* experts from contributing the necessary
> infrastructure?
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.
Braden