[C++-sig] Preparations for release

David Abrahams dave at boost-consulting.com
Sat Sep 28 17:33:17 CEST 2002


Ladies & Gentlemen,

I'm working on the Boost.Python v2 docs now, and not touching the code
until further notice.

If you want to help get Boost.Python v2 ready for release, aid with any or
all of the following would be greatly appreciated (some of these jobs seem
to require CVS write permission, but actually you can do everything up to
the commit without write permission, and that would still be highly
valuable):

1. Merge everything that's happened on the main trunk of libs/python and
boost/python into the RC_1_29_0 branch and test it. I think this just
amounts to:

    cd $BOOST_ROOT
    cvs up -P -d -rRC_1_29_0
    cvs up -P -d -jHEAD libs/python boost/python

    # Run tests and let me know if there are any problems

    cvs commit
    cvs tag -F RC_1_29_0_last_merge libs/python boost/python

  1a. You could also start testing the merged RC_1_29_0 branch against
  the Python release22-maint cvs branch. Quoth Guido:

    If you check out the release22-maint branch of Python from CVS and
    subscribe to the python-checkins list
    (http://mail.python.org/mailman/listinfo/python-checkins) you should
    be able to track the work leading up to 2.2.2 pretty closely.

    (2.2.2 will be released approximately concurrently with Boost 1.29.0)

2. Sort out which files are only part of Boost.Python v1 and create two
archives, .zip and .tgz, then

    cvs remove the v1-only files
    test Boost.Python v2 to make sure it still works
    cvs commit

3. Think about providing some alternate approaches to building
Boost.Python.

 I have really mixed feelings about this since I don't want to maintain
 multiple build systems, but I also think:

   1. Windows users really expect a MS Visual studio project file that
   generates a differently-named lib/dll for debug-python builds, and the
   current Boost.Build strategy of renaming the libraries doesn't actually
   work because the original name of the dll gets encoded in the object
file
   dynamic linking fails.

   2. Some of the platforms we don't currently support in Boost.Build might
   be handled automatically by distutils. I'm thinking, for example of
   MacOS X. I seem to recall someone sending me distutils scripts for
building
   Boost.Python as part of a bug report long ago but I don't know where
they
   went :(. Any distutils experts out there?

4. Help to prepare documentation. Achim Domma has generously contributed a
bunch of documentation templates available at
www.procoders.net/dave/boostdocs.zip. These include many more
automatically-generated pages than we have public headers, so you could
ignore most of it. Even if you can't fill in everything, there's a lot of
structure and rote editing which you could do to prepare these for
inclusion into the distro. Let me know if you'd like to help and we can
negotiate a task.

Thanks,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com







More information about the Cplusplus-sig mailing list