MySQL++

Check-in [b5a68d6801]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Assorted improvements to HACKERS.md
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: b5a68d68018a92c127120667fd183692be08631fd75b87400ccbc49b1d4464ef
User & Date: tangent 2019-05-11 12:47:38
Context
2019-07-17
14:22
Found a ChangeLog from MySQL saying that several MYSQL_* options disappeared in 8.0.4, not in 8.1.0 as we previously thought. Dialed back the ifdefs preventing lib/options.cpp from attempting to check them. check-in: dd6889ae32 user: tangent tags: trunk
2019-05-11
12:47
Assorted improvements to HACKERS.md check-in: b5a68d6801 user: tangent tags: trunk
11:57
Typo fix check-in: b4ddded8f0 user: tangent tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to HACKERS.md.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
..
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

49
50
51
52
53
54
55
56
57





58
59
60
61
62
63

64

65
66
67
68
69
70
71
72
..
73
74
75
76
77
78
79
80
81
82

83
84
85
86
87











88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
...
115
116
117
118
119
120
121


122
123

124
125
126
127
128
129
130
...
154
155
156
157
158
159
160
161

162
163
164
165
166

167
168
169
170
171
172
173
174
175
176
177
178
...
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
...
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278

















279
280
281
282
283
284
285
286
...
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
...
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
...
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
# Hacking on MySQL++

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


## Code Repository Access

MySQL++ uses the [Fossil][fsl] [distributed version control
system][dvcs]. See its [quick start guide][fslq] if you are unfamilar
with Fossil.

That Fossil repository is also [mirrored to GitHub][ghm] nightly, but
this is a read-only mirror, meant for use with Git automation tooling.
................................................................................
To clone the MySQL++ repository anonymously, say:

    $ fossil clone https://tangentsoft.com/mysqlpp mysqlpp.fossil

If you have a developer account on the MySQL++ Fossil instance, just add
your username to the URL like so:

    $ fossil clone https://username@tanentsoft.com/mysqlpp mysqlpp.fossil

That will get you a file called `mysqlpp.fossil` containing the [abridged
version history][avh] of MySQL++ back to the project's founding.

The repository clone file can be named anything you like. Even the
`.fossil` extension is just a convention, not a requirement.

To "open" the repo clone so you can hack on it, say:

    $ mkdir mysqlpp
    $ cd mysqlpp
    $ fossil open ../mysqlpp.fossil

We created a new subdirectory because the `open` command checks out the
tip of the repository's trunk into the current directory by default.

As with `mysqlpp.fossil`, you can call the working directory anything

you like. I actually prefer a working tree that looks like this:

    ~/museum/                  # Where one keeps fossils, right?
        mysqlpp.fossil
    ~/src/                     # Working tree for software projects
        mysqlpp/
            trunk/             # Primary working branch for MySQL++
            other-branch/      # Separate working branch checkout
            3.2.3/             # Older tagged stable release checkout






Fossil will let you make any modifications you like to your local
repository copy. For those with check-in privileges on the upstream
copy, changes get automatically synced with it by default. (If you
prefer Git or Mercurial style two-phase commits, you can say `fossil set
autosync off`.) If you don't have such permissions, check-ins just

modify your local repository clone, then have to merge in upstream

changes when updating your local clone.

Developers are expected to make all changes that affect the libary's
API, ABI, or behavior on a branch, rather than check such changes
directly into the trunk. Once we have discussed the change on the
[forum][for] and resolved any isssues with the experimental branch, it
will be merged into the trunk.

................................................................................
Creating a branch in Fossil is scary-simple, to the point that those
coming from other version control systems may ask, "Is that really all
there is to it?" Yes, really, this is it:

    $ fossil checkin --branch new-branch-name

That is to say, you make your changes as you normally would; then when
you go to check them in, you give the `--branch` option to the
`ci/checkin` command to put the changes on a new branch, rather than add
them to the same branch the changes were made against.


At some point, the trunk version becomes the next major version. Stable
versions become either tags or branches. (The only difference between
tags and branches in Fossil is that branches may have subsequent changes
made to them.)












[avh]:  https://tangentsoft.com/mysqlpp/wiki?name=Abridged+Version+History
[dvcs]: http://en.wikipedia.org/wiki/Distributed_revision_control
[for]:  https://tangentsoft.com/mysqlpp/froum/
[fsl]:  http://fossil-scm.org/
[fslb]: http://fossil-scm.org/fossil/uv/download.html
[fslq]: http://fossil-scm.org/fossil/doc/trunk/www/quickstart.wiki
[fsls]: http://fossil-scm.org/fossil/doc/trunk/www/build.wiki
[ghm]:  https://github.com/tangentsoft/mysqlpp


## Bootstrapping the Library

When you check out MySQL++ from Fossil, there are a lot of things
"missing" as compared to a distributed tarball, because the Fossil
repository contains only source files, no generated files.  The
process that turns a fresh MySQL++ repository checkout into
something you can build and hack on is called bootstrapping.

................................................................................
manager to install suitable versions.

There's a third tool you'll need to bootstrap MySQL++ called
[Bakefile][bf]. The syntax used in `mysql++.bkl` requires at least
Bakefile 0.2.5 or higher, which in turn requires Python 2.3 or higher to
run. You may require a newer version of Bakefile to support newer OSes
and Python versions; we've tested with versions up to 0.2.11


successfully.  Do not use any of the Bakefile 1.x versions: it's a major
change in direction which we haven't tried to follow.


Once you have all the tools in place, you can bootstrap MySQL++ with a
Bourne shell script called `bootstrap`, which you get as part of the
Fossil checkout. It's fairly powerful, with many options.  For most
cases, it suffices to just run it without any arguments:

    $ ./bootstrap
................................................................................
    The generated `Makefiles` and project files won't try to build the
    MySQL++ library.

*   `nomaint`

    Turn off "maintainer mode" stuff in the build. These are features
    used only by those building MySQL++ from Fossil. The `dist` build
    target uses this when creating the tarball.


*   `noopt`

    Compiler optimization will be turned off. (This currently has no
    effect on MinGW or Visual C++.)


*   `pedantic`

    Turns on all of GCC's warnings and portability checks.  Good for
    checking changes before making a public release.

*   `bat`

    Runs `bootstrap.bat` via `cmd.exe` for you, passing along equivalent
    options to any of the "*no*" options you give before it.

    Only the "*no*" options above have an effect on the generated build
................................................................................
    options are passed to the `configure` script. See
    [README-Unix.txt][rmu] for more on `configure` script options.

[bf]:  http://bakefile.org/
[rmu]: https://tangentsoft.com/mysqlpp/file/README-Unix.txt


## Bootstrapping the Library Using Only Windows

The thing that makes bootstrapping on Windows difficult is that one of
the required steps uses a Unix-centric tool, `autoconf`.  This section
is about working out a way to get that working on Windows, or avoiding
the need for it, so you can get on with hacking on MySQL++ on Windows.

The thing `autoconf` does that's relevant to Windows builds of MySQL++
is that it substitutes the current MySQL++ version number into several
source files. This allows us to change the version number in just one
place — `configure.ac` — and have it applied to all these other places.
Until you do this step, an Fossil checkout of MySQL++ won't build,
because these files with the version numbers in them won't be generated.


### Option 1: Copy the generated files over from a released version

Only one of these generated files is absolutely critical to allowing
MySQL++ to build: `lib/mysql++.h`. So, the simplest option you have to
................................................................................
    install.hta
    mysql++.spec
    doc/userman/userman.dbx
    lib/Doxyfile

Having done that, you can complete the bootstrapping process by running
`bootstrap.bat`. It has the same purpose as the Bourne shell script
described above, but much simpler. It has none of the command line
options described above, for one thing.

The main downside of doing it this way is that your changed version will
have the same version number as the release of MySQL++ you copied the
files from, unless you go into each file and change the version numbers.


### Option 2: Cygwin

If you'd like to hack on MySQL++ entirely on Windows and have all the
build freedoms enjoyed by those working on Unixy platforms, the simplest
solution is probably to [install Cygwin][cyg64]. (64-bit. A [32-bit
installer][cyg32] is also available.)

When you run it, it will walk you through the steps to install Cygwin.
Autoconf and Perl 5 aren't installed in Cygwin by default, so when you
get to the packages list, be sure to select them. Autoconf is in the
Devel category, and Perl 5 in the Interpreters category.

You will also need to install the native Windows binary version of
[Bakefile](http://bakefile.org/).  Don't get the source version and try
to build Bakefile under Cygwin; it won't work. The Windows binary
version of Bakefile includes an embedded version of Python, so you won't
need to install Cygwin's Python.

Having done all this, you can follow the Unix bootstrapping
instructions in the previous section.

[cyg32]: http://cygwin.com/setup-x86.exe
[cyg64]: http://cygwin.com/setup-x86_64.exe



















### Option 3: ["Here's a nickel, kid, get yourself a better computer."][dc]

Finally, you might have access to a Unixy system, or the ability to set
one up. You don't even need a separate physical computer, now that
virtual machine techology is free.

Given such a machine, you'd do the Fossil checkout of MySQL++ on that
machine, then bootstrap it there using the instructions in the previous
................................................................................
section, and copy the generated files back to the Windows box.

[dc]: http://tomayko.com/writings/that-dilbert-cartoon


## On Manipulating the Build System Source Files

One of the things the bootstrapping system described above
does is produces various types of project and make files from a
small number of source files. This system lets us support many
platforms without having to maintain separate build system files
for each platform.

[Bakefile](http://bakefile.org/) produces most of these project and make
files from a single source file called [`mysql++.bkl`][bkl].

Except for small local changes, it's best to change `mysql++.bkl` and
"re-bake" the project and make files rather than change those files
directly. You can do this with the bootstrap scripts covered above. On
Windows, if all you've changed is `mysql++.bkl`, you can use
`rebake.bat` instead, which doesn't try to do as much as
`bootstrap.bat`.

Bakefile produces finished project files for Visual C++ and Xcode and
finished `Makefiles` for MinGW. It also produces `Makefile.in`, which is
input to GNU Autoconf along with configure.ac and `config/*`. You may
need to change these latter files in addition to or instead of
`mysql++.bkl` to get the effect you want.  Running bootstrap
incorporates changes to all of these files in the GNU Autoconf output.

While Bakefile's documentation isn't as comprehensive as it
ought to be, you can at least count on it to list all of the
available features. So, if you can't see a way to make Bakefile
................................................................................
[bkl]: https://tangentsoft.com/mysqlpp/file/mysql%2B%2B.bkl


<a id="patches"></a>
## Submitting Patches

If you wish to submit a patch to the library, it’s probably simplest to
paste it into a [forum post][for] if it’s small. If it’s large, put it
in Pastebin or similar, then link to it from a forum post.  We want
patches in unified diff format.

We will also accept trivial patches not needing discussion as text
or attachments to [a Fossil ticket][tkt].

The easiest way to get a unified diff is to check out a copy of the
current MySQL++ tree as described above. Then make your change, `cd`
to the MySQL++ root directory, and ask Fossil to generate the patch
for you:

    $ fossil diff > mychange.patch

If your patch adds new files, moves files, or needs to be understood in
terms of multiple checkins, it's best to do that work on a [private
local branch](#private), then send a [bundle][fb] instead of a patch.
................................................................................
Although MySQL++ does have a [GitHub mirror][ghm], we do not acccept PRs
via that channel, because the mirror is read-only. You can still send us
a PR through GitHub, but realize that what’s going to happen on the back
end is that we’ll generate a patch and apply it to the Fossil repo by
hand, then update the mirror, so you won’t get GitHub credit for the PR.
Sorry; there’s no easy way for this mirroring system to accept
contributions back the other direction. If you want credit for the
commit, ask us for an account on the Fossil repo and commit it there
instead.

[fb]:  http://fossil-scm.org/fossil/help?cmd=bundle
[tkt]: https://tangentsoft.com/mysqlpp/tktnew


## The MySQL++ Code Style






|







 







|













|
|
<
<
>
|




|

|
|
>
>
>
>
>





|
>
|
>
|







 







|
|
|
>

<
|
|
|
>
>
>
>
>
>
>
>
>
>
>











|







 







>
>
|
<
>







 







|
>




|
>



|
|







 







|


|
|
|

|



|







 







|
|
|
|
|
|






|
|

|
|
<
|










|
<


>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
|







 







|
|
|
|
|













|







 







|







|
|







 







|







1
2
3
4
5
6
7
8
9
10
11
12
13
14
..
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
..
79
80
81
82
83
84
85
86
87
88
89
90

91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
...
132
133
134
135
136
137
138
139
140
141

142
143
144
145
146
147
148
149
...
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
...
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
...
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283

284
285
286
287
288
289
290
291
292
293
294
295

296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
...
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
...
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
...
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
# Hacking on MySQL++

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


## <a id="repo"></a>Code Repository Access

MySQL++ uses the [Fossil][fsl] [distributed version control
system][dvcs]. See its [quick start guide][fslq] if you are unfamilar
with Fossil.

That Fossil repository is also [mirrored to GitHub][ghm] nightly, but
this is a read-only mirror, meant for use with Git automation tooling.
................................................................................
To clone the MySQL++ repository anonymously, say:

    $ fossil clone https://tangentsoft.com/mysqlpp mysqlpp.fossil

If you have a developer account on the MySQL++ Fossil instance, just add
your username to the URL like so:

    $ fossil clone https://username@tangentsoft.com/mysqlpp mysqlpp.fossil

That will get you a file called `mysqlpp.fossil` containing the [abridged
version history][avh] of MySQL++ back to the project's founding.

The repository clone file can be named anything you like. Even the
`.fossil` extension is just a convention, not a requirement.

To "open" the repo clone so you can hack on it, say:

    $ mkdir mysqlpp
    $ cd mysqlpp
    $ fossil open ../mysqlpp.fossil

This two step “clone and open” process may seem weird if you’re used to
Git, but it’s a feature. It means the repository and working directories


are separate, allowing you to create multiple independent checkouts from
a single repo clone. I like a working tree that looks like this:

    ~/museum/                  # Where one keeps fossils, right?
        mysqlpp.fossil
    ~/src/                     # Working tree for software projects
        mysqlpp/               # A directory for each project
            trunk/             # Primary working branch for MySQL++
            v2.3.2-modern/     # Checkout for another branch
            v3.2.3/            # Checkout for a tagged stable release

You check out a branch or tag like so:

    $ cd ~/src/mysqlpp/v3.2.3
    $ fossil open ~/museum/mysqlpp.fossil v3.2.3

Fossil will let you make any modifications you like to your local
repository copy. For those with check-in privileges on the upstream
copy, changes get automatically synced with it by default. (If you
prefer Git or Mercurial style two-phase commits, you can say `fossil set
autosync off`, then later say `fossil push` after making one or more
checkins.) If you don't have commit capability on the central repository
server, checkins just modify your local repository clone. If you do such
checkins on a branch, you don’t need to worry about conflicts when
pulling down upstream changes into your local clone.

Developers are expected to make all changes that affect the libary's
API, ABI, or behavior on a branch, rather than check such changes
directly into the trunk. Once we have discussed the change on the
[forum][for] and resolved any isssues with the experimental branch, it
will be merged into the trunk.

................................................................................
Creating a branch in Fossil is scary-simple, to the point that those
coming from other version control systems may ask, "Is that really all
there is to it?" Yes, really, this is it:

    $ fossil checkin --branch new-branch-name

That is to say, you make your changes as you normally would; then when
you go to make the first checkin, you give the `--branch` option to put
the changes on a new branch, rather than add them to the same branch the
changes were made against. Every subsequent checkin without a `--branch`
option gets checked in as the new tip of that branch.


If you’re creating a branch that will probably live a long enough time
that you’ll want to return to trunk one or more times while that branch
lives, you might follow the above command with a sequence like this:

    $ fossil update trunk           # return working dir to tip-of-trunk
    $ mkdir ../new-branch-name
    $ cd ../new-branch-name
    $ fossil open ~/museum/mysqlpp.fossil new-branch-name

Now you can bounce back and forth between trunk and your new branch with
a simple `cd` command, rather than switching in place, as is typical
with Git. This style of work avoids invalidating build system outputs,
and it makes it possible to switch branches without checking in or
stashing your work on the other branch first.

[avh]:  https://tangentsoft.com/mysqlpp/wiki?name=Abridged+Version+History
[dvcs]: http://en.wikipedia.org/wiki/Distributed_revision_control
[for]:  https://tangentsoft.com/mysqlpp/froum/
[fsl]:  http://fossil-scm.org/
[fslb]: http://fossil-scm.org/fossil/uv/download.html
[fslq]: http://fossil-scm.org/fossil/doc/trunk/www/quickstart.wiki
[fsls]: http://fossil-scm.org/fossil/doc/trunk/www/build.wiki
[ghm]:  https://github.com/tangentsoft/mysqlpp


## <a id="bootstrap"></a>Bootstrapping the Library

When you check out MySQL++ from Fossil, there are a lot of things
"missing" as compared to a distributed tarball, because the Fossil
repository contains only source files, no generated files.  The
process that turns a fresh MySQL++ repository checkout into
something you can build and hack on is called bootstrapping.

................................................................................
manager to install suitable versions.

There's a third tool you'll need to bootstrap MySQL++ called
[Bakefile][bf]. The syntax used in `mysql++.bkl` requires at least
Bakefile 0.2.5 or higher, which in turn requires Python 2.3 or higher to
run. You may require a newer version of Bakefile to support newer OSes
and Python versions; we've tested with versions up to 0.2.11
successfully.

Do not use any of the Bakefile 1.x versions: it’s an incompatible

change, and we currently have no intention to switch from Bakefile 0.x.

Once you have all the tools in place, you can bootstrap MySQL++ with a
Bourne shell script called `bootstrap`, which you get as part of the
Fossil checkout. It's fairly powerful, with many options.  For most
cases, it suffices to just run it without any arguments:

    $ ./bootstrap
................................................................................
    The generated `Makefiles` and project files won't try to build the
    MySQL++ library.

*   `nomaint`

    Turn off "maintainer mode" stuff in the build. These are features
    used only by those building MySQL++ from Fossil. The `dist` build
    target uses this when creating the tarball, because it reduces the
    build time somewhat.

*   `noopt`

    Compiler optimization will be turned off. (This currently has no
    effect on the generated MinGW Makefile or the Visual C++ project
    files.)

*   `pedantic`

    Turns on all of GCC's warnings and portability checks.  We use this
    as part of our [release process](./RELEASE-CHECKLIST.txt).

*   `bat`

    Runs `bootstrap.bat` via `cmd.exe` for you, passing along equivalent
    options to any of the "*no*" options you give before it.

    Only the "*no*" options above have an effect on the generated build
................................................................................
    options are passed to the `configure` script. See
    [README-Unix.txt][rmu] for more on `configure` script options.

[bf]:  http://bakefile.org/
[rmu]: https://tangentsoft.com/mysqlpp/file/README-Unix.txt


## <a id="winbs"></a>Bootstrapping the Library Using Only Windows

The thing that makes bootstrapping on Windows difficult is that one of
the required steps uses a Unix-centric tool, Autoconf.  This section
gives alternatives for either getting Autoconf working on Windows or
avoiding the need for it.

The thing Autoconf does that's relevant to Windows builds of MySQL++
is that it substitutes the current MySQL++ version number into several
source files. This allows us to change the version number in just one
place — `configure.ac` — and have it applied to all these other places.
Until you do this step, a Fossil checkout of MySQL++ won't build,
because these files with the version numbers in them won't be generated.


### Option 1: Copy the generated files over from a released version

Only one of these generated files is absolutely critical to allowing
MySQL++ to build: `lib/mysql++.h`. So, the simplest option you have to
................................................................................
    install.hta
    mysql++.spec
    doc/userman/userman.dbx
    lib/Doxyfile

Having done that, you can complete the bootstrapping process by running
`bootstrap.bat`. It has the same purpose as the Bourne shell script
described [above](#bootstrap), but with a different and simpler usage:

    C:\> bootstrap.bat [bakefile-options]

Any options passed are passed as-is to Bakefile. This is normally used
to pass `-D` options to affect the generated build system output files.


### Option 2: Cygwin

If you'd like to hack on MySQL++ entirely on Windows and have all the
build freedoms enjoyed by those working on Unixy platforms, the simplest
solution is probably to [install Cygwin][cyg]. It doesn’t matter whether
you use the 32-bit or 64-bit version, for our purposes here.

While in the Cygwin setup program, you will have to add the Autoconf and
Perl 5 packages, which aren't installed in Cygwin by default.  Autoconf

is in the Devel category, and Perl 5 in the Interpreters category.

You will also need to install the native Windows binary version of
[Bakefile](http://bakefile.org/).  Don't get the source version and try
to build Bakefile under Cygwin; it won't work. The Windows binary
version of Bakefile includes an embedded version of Python, so you won't
need to install Cygwin's Python.

Having done all this, you can follow the Unix bootstrapping
instructions in the previous section.

[cyg]: http://cygwin.com/



### Option 3: Windows Subsystem for Linux (WSL)

If you’re on Windows 10, you have the option of [installing WSL][wsl], a
lightweight Linux kernel and user environment that runs atop Windows.
This is fundamentally different technology than Cygwin, but the
user-level effect of it is the same as far as MySQL++’s build system
goes.

Assuming you use the default Ubuntu enviroment atop WSL, the [standard
bootstrapping process](#bootstrap) applies, after you install the needed
tools:

    $ apt install bakefile build-essential perl libmysqlclient-dev

[wsl]: https://docs.microsoft.com/en-us/windows/wsl/install-win10


### Option 4: ["Here's a nickel, kid, get yourself a better computer."][dc]

Finally, you might have access to a Unixy system, or the ability to set
one up. You don't even need a separate physical computer, now that
virtual machine techology is free.

Given such a machine, you'd do the Fossil checkout of MySQL++ on that
machine, then bootstrap it there using the instructions in the previous
................................................................................
section, and copy the generated files back to the Windows box.

[dc]: http://tomayko.com/writings/that-dilbert-cartoon


## On Manipulating the Build System Source Files

One of the things the bootstrapping system described [above](#bootstrap)
does is produces various types of project and make files from a small
number of source files. This system lets us support many platforms
without having to maintain separate build system files for each
platform.

[Bakefile](http://bakefile.org/) produces most of these project and make
files from a single source file called [`mysql++.bkl`][bkl].

Except for small local changes, it's best to change `mysql++.bkl` and
"re-bake" the project and make files rather than change those files
directly. You can do this with the bootstrap scripts covered above. On
Windows, if all you've changed is `mysql++.bkl`, you can use
`rebake.bat` instead, which doesn't try to do as much as
`bootstrap.bat`.

Bakefile produces finished project files for Visual C++ and Xcode and
finished `Makefiles` for MinGW. It also produces `Makefile.in`, which is
input to GNU Autoconf along with `configure.ac` and `config/*`. You may
need to change these latter files in addition to or instead of
`mysql++.bkl` to get the effect you want.  Running bootstrap
incorporates changes to all of these files in the GNU Autoconf output.

While Bakefile's documentation isn't as comprehensive as it
ought to be, you can at least count on it to list all of the
available features. So, if you can't see a way to make Bakefile
................................................................................
[bkl]: https://tangentsoft.com/mysqlpp/file/mysql%2B%2B.bkl


<a id="patches"></a>
## Submitting Patches

If you wish to submit a patch to the library, it’s probably simplest to
paste it into a [forum post][for], if it’s small. If it’s large, put it
in Pastebin or similar, then link to it from a forum post.  We want
patches in unified diff format.

We will also accept trivial patches not needing discussion as text
or attachments to [a Fossil ticket][tkt].

The easiest way to get a unified diff is to check out a copy of the
current MySQL++ tree [as described above](#repo). Then make your change,
`cd` to the MySQL++ root directory, and ask Fossil to generate the patch
for you:

    $ fossil diff > mychange.patch

If your patch adds new files, moves files, or needs to be understood in
terms of multiple checkins, it's best to do that work on a [private
local branch](#private), then send a [bundle][fb] instead of a patch.
................................................................................
Although MySQL++ does have a [GitHub mirror][ghm], we do not acccept PRs
via that channel, because the mirror is read-only. You can still send us
a PR through GitHub, but realize that what’s going to happen on the back
end is that we’ll generate a patch and apply it to the Fossil repo by
hand, then update the mirror, so you won’t get GitHub credit for the PR.
Sorry; there’s no easy way for this mirroring system to accept
contributions back the other direction. If you want credit for the
commit, ask us for an account on the Fossil repo, and commit it there
instead.

[fb]:  http://fossil-scm.org/fossil/help?cmd=bundle
[tkt]: https://tangentsoft.com/mysqlpp/tktnew


## The MySQL++ Code Style