If you are going to make any changes to MySQL++, this file has some
hints and commentary you may find helpful.


Subversion Access
~~~~~~~~~~~~~~~~~
	To check out the current development version from the Gna!
	Subversion repository, say:

		$ svn co svn://svn.gna.org/svn/mysqlpp/trunk mysqlpp

	If you're a MySQL++ committer, use svn over ssh instead:
	
		$ svn co svn+ssh://LOGIN@svn.gna.org/svn/mysqlpp/trunk mysqlpp

	where LOGIN is your Gna! login name.  You will have to have your
	ssh public key registered with Gna! for this to work.


Submitting Patches
~~~~~~~~~~~~~~~~~~
	If you wish to submit a patch to the library, please send it to
	the MySQL++ mailing list.  We want it in unified diff format.

	The easiest way to do this is to check out a copy of the current
	MySQL++ tree as described in the previous section.  Then make
	your change, cd to the root directory of the project, and ask
	Subversion to generate the diff for you:

		$ svn diff > mychange.patch

	If your patch adds new files to the distribution, you can say
	"svn add newfile" before you do the diff, which will include
	the contents of that file in the patch.  (You can do this even
	when you've checked out the tree anonymously.)	Then say "svn
	revert newfile" to make Subversion forget about the new file.

	If you're making a patch against a MySQL++ distribution tarball,
	then you can generate the diff this way:

		$ diff -ruN mysql++-olddir mysql++-newdir > mychange.patch

	The diff command is part of every Unix and Linux system, and
	should be installed by default.  If you're on a Windows machine,
	GNU diff is part of Cygwin (http://cygwin.com/).  Subversion is
	also available for all of these systems.  There are no excuses
	for not being able to make unified diffs.  :)


Adding Support for a Different Compiler
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	MySQL++ now uses the Bakefile system for creating project
	files and makefiles.  This allows us to make changes to a
	single set of files, and have the proper changes be made
	to all generated project files and makefiles.  In the past,
	we used more ad-hoc systems, and we'd frequently forget to
	update individual project files and makefiles, so at any
	given time, at least one target was likely to be broken.

	If MySQL++ doesn't currently ship with project files or
	makefiles tuned for your compiler of choice, you need
	to work through the Bakefile mechanism to add support.
	We're not willing to do ad-hoc platform support any more,
	so please don't ask if you can send us project files instead;
	we don't want them.

	If you want to port MySQL++ to another platform, we need to
	be confident that the entire library works on your platform
	before we'll accept patches.  In the past, we've had broken
	ports that were missing important library features, or
	that crashed when built in certain ways.  Few people will
	knowingly use a crippled version of MySQL++, since there are
	usually acceptable alternatives.  Therefore, such ports become
	maintenance baggage with little compensating value.


Maintaining a Private CVS Repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	You may find it helpful to maintain your own CVS repository.
	Whenever there is a new MySQL++ release, import it on the vendor
	branch like this:

		$ cvs import -m "Version 1.7.35" software/mysql++ mysql++ mysql++-1_7_35

	(This assumes that you have your CVSROOT environment variable
	set properly.)

	Update the HEAD branch like this:

		$ cd mysql++
		$ cvs update -PdA
		$ cvs update -j HEAD -j mysql++-1_7_35 -Pd
		$ cvs ci -m "merged 1.7.35 into HEAD"
		$ cvs tag mysql++-1_7_35-merged

	Then any changes you make can easily be tracked, and diffs can
	be produced with rdiff:

		$ cvs rdiff -ru mysql++-1_7_35 -r mysql++-1_7_35_equal_list \
			$(cat CVS/Repository) > equal_list.patch


On Manipulating the Bakefiles and Autoconf Files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	If change any of the Bakefiles (*.bkl) or the autoconf stuff
	(configure.ac and everything in the config subdir), you need
	to run the command:

		$ ./bootstrap [pedantic] [noexamples] [configure options]

	This command rebuilds all of the project files and makefiles
	that depend on the Bakefiles and Autoconf stuff.

	If you pass 'pedantic' to the bootstrap script, it will set
	up the autoconf build system so it turns on all of GCC's
	warnings and such.  It's useful to build the library in this
	mode when making changes to make sure there are no obvious
	problems with the code.

	If you pass 'noexamples', the examples won't be built.

	You can pass any of the previous options in any order.
	As soon as the bootstrap script sees an options that it
	doesn't understand, it stops processing the command line.
	Any subsequent options are passed (indirectly) to the configure
	script.  See README.unix for more on configure script options.