MySQL++

Check-in [596aa10b32]
Login

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

Overview
Comment:Merged trunk changes for v3.2.5 into release branch
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | release | v3.2.5
Files: files | file ages | folders
SHA3-256: 596aa10b32f3fefe86a23e7bc0626b7acd2d7e3fdca2f23857ec08730b0e8d31
User & Date: tangent 2019-07-21 10:47:07
Context
2019-07-21
11:06
Merged in trunk changes check-in: e61010433e user: tangent tags: release, v3.2.5
10:47
Merged trunk changes for v3.2.5 into release branch check-in: 596aa10b32 user: tangent tags: release, v3.2.5
10:43
Fix to bootstrap to cope with autoreconf's unwillingness to provide install-sh and such even though we passed -i. check-in: a15f552cc5 user: tangent tags: trunk
10:35
Released v3.2.5 check-in: b0b6e246e9 user: tangent tags: trunk
2018-07-27
06:13
Merged in trunk fixes to release 3.2.4 check-in: 64fd6873ed user: tangent tags: release, v3.2.4
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Added .fossil-settings/crlf-glob.





>
>
1
2
*.md
*.txt

Changes to ChangeLog.md.

1















2
3
4
5
6
7
8
# Change Log
















## 3.2.4, 2018.07.26

*   Added the `MYSQLPP_UTF8_CS` and `MYSQLPP_UTF8_COL` macros to allow a
    given bit of code use either the legacy "utf8" character set or the
    new full-Unicode "utf8mb4" version depending on whether MySQL++ is
    built against MySQL 5.5 or newer, the version where `utf8mb4` was

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>







1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# Change Log

## 3.2.5, 2019.07.21

*   Supports `ulonglong` in MySQL++-to-SQL data type conversions so you
    can pass the return from `Result.insert_id()` and such into another
    SQL expression.  This previously required an explicit cast to one of
    the `sql_*` types when using a C++ compiler that can’t figure out
    that `sql_bigint` is equivalent on its own.

*   Updates to support newer versions of MySQL and MariaDB.

*   Assorted documentation improvements.

*   Assorted build system improvements.


## 3.2.4, 2018.07.26

*   Added the `MYSQLPP_UTF8_CS` and `MYSQLPP_UTF8_COL` macros to allow a
    given bit of code use either the legacy "utf8" character set or the
    new full-Unicode "utf8mb4" version depending on whether MySQL++ is
    built against MySQL 5.5 or newer, the version where `utf8mb4` was

Changes to HACKERS.md.

1
2
3
4
5
6
7
8
9
10
11






12
13
14
15
16
17
18
19
20
21
22
23
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
...
109
110
111
112
113
114
115


116
117

118
119
120
121
122
123
124
...
148
149
150
151
152
153
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
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
...
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
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
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
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
...
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
...
493
494
495
496
497
498
499

500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
...
533
534
535
536
537
538
539
540


# 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.







You must be running Fossil version 2.1 or higher to access the MySQL++
repository. If your operating system includes an older Fossil package,
you will either have to install [an official binary][fslb] or [build
it from source][fsls].

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 fossils are kept
        mysqlpp.fossil
    ~/src/                     # Working tree for software projects
        mysqlpp/
            skull/             # Fossil head, get it?   I crack me up.
            trunk -> skull/    # Alias to match Fossil branch naming
            some-branch/       # Separately-opened working branch
            3.2.3/             # Tagged release checkout

Fossil will let you make any modifications you like to your local
repository copy. For those with privileges on the upstream copy,
checkins get automatically synced with it by default. (If you prefer
Git or Mercurial style two-phase commits, you can say `fossil settings
autosync off`.) If you don't have such permissions, you just modify
your local copy, 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
[mailing list][ml] 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

[fsl]:  http://fossil-scm.org/
[fslb]: http://fossil-scm.org/index.html/uv/download.html
[fslq]: http://fossil-scm.org/index.html/doc/trunk/www/quickstart.wiki
[fsls]: http://fossil-scm.org/index.html/doc/trunk/www/build.wiki
[ml]:   https://lists.mysql.com/plusplus/



## 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`

    Asks `cmd.exe` to run `bootstrap.bat` for you. This is useful when
    using Cygwin just as a command shell in preference to `cmd.exe`, as
    opposed to using Cygwin to build MySQL++ using its native tools.






    Passing 'bat' stops all command line processing in the bootstrap
    script, so if you also pass some of the other options, make "`bat`"
    last.  The only options that affect the built project files and
    `Makefiles` work are the no* ones.




















*   `configure` script options

    As soon as the bootstrap script sees an option that it doesn't
    understand, it stops processing the command line.  Any subsequent
    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
................................................................................
do something, it's likely it just can't do it. Bakefile is a
high-level abstraction of build systems in general, so it'll never
support all the particulars of every odd build system out there.

[bkl]: https://tangentsoft.com/mysqlpp/file/mysql%2B%2B.bkl



## Submitting Patches

If you wish to submit a patch to the library, please send it to the


[MySQL++ mailing list][ml].  We want patches in unified diff format.

We will also accept trivial patches not needing discussion as text
in a Fossil ticket.

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][pbr], then send a [bundle][fb] instead of a patch.

If you've sent patches to MySQL++ before and don't have a Fossil
developer login, another alternative is to ask for a login before you
begin work so that your changes are automatically sync'd to the main
Fossil repository as you work, so you don't have to send bundles or
patch files. We generally don't refuse such requests if you've already
proven your ability to work well with the MySQL++ project.

If you're making a patch against a MySQL++ distribution tarball, then
you can generate a patch 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/). Fossil is also available for all of
these systems. There are no excuses for not being able to make unified
diffs. :)











[fb]:  http://fossil-scm.org/index.html/help?cmd=bundle
[pbr]: https://tangentsoft.com/mysqlpp/file/HACKERS.md#private


## The MySQL++ Code Style

Every code base should have a common code style. Love it or
hate it, here are MySQL++'s current code style rules:

................................................................................

-   DOS line endings, again for the Notepad reason. And on modern Unixy
    platforms, the tools cope with DOS line endings reasonably well.
    Better than the converse, anyway.


When in doubt, mimic what you see in the current code. When still in
doubt, ask on the [mailing list][ml].


## Testing Your Proposed Change

MySQL++ includes a self-test mechanism called `dtest`. It's a Bourne
shell script, run much like `exrun`:

................................................................................
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.



## <a name="private"></a>Maintaining a Private Repository

Although Fossil syncs changes back to the `tangentsoft.com/mysqlpp`
Fossil repository by default, it is possible to maintain a private copy
that simply pulls changes in occasionally.

The first step is to turn off the auto-sync feature:

     $ fossil set autosync 0

Then, I recommend that you make any local changes on a branch:

    ...hack, hack, hack...
    $ fossil ci --branch my-local-branch

After you give the `--branch` option on a checkin, Fossil automatically
................................................................................
modify your clone, only the working checkout directory. You must then
say `fossil ci` once you're happy with the merge. Until then, all the
usual Fossil commands like `fossil diff` and `fossil status` will help
you come to that decision.

If you ever decide to contribute your private branch to the MySQL++
project, there are a couple of easy ways to achieve that. Ask about it
on the [mailing list][ml] if you find yourself in this situation.








|




>
>
>
>
>
>













|













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




|
|








|
|
|
>

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



>

|
|
|
<
>


|







 







>
>
|
<
>







 







|
>




|
>



|
|



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












|


|
|
|

|



|







 







|
|
|
|
|
|






|
|

|
|
<
|










|
<


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







 







|
|
|
|
|













|







 







>


|
>
>
|


|


<
>
|






|






|












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







 







|







 







>
|

|
|




|







 







|
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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
200
201
202
203
204
205


206
207
208
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
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
...
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374

375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
...
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
...
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
...
611
612
613
614
615
616
617
618
619
620
# 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.
For example, you could use MySQL++ as a submodule in a larger Git
project via this channel. [Changes to MySQL++](#patches) still must go
go through the Fossil repository.

You must be running Fossil version 2.1 or higher to access the MySQL++
repository. If your operating system includes an older Fossil package,
you will either have to install [an official binary][fslb] or [build
it from source][fsls].

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
    system files when you give "`bat`".  In particular, the files
    generated by `bootstrap.bat` make no distinction between "pedantic"
    and normal builds.

    Passing `bat` stops all command line processing in the `bootstrap`
    script, so if you also pass some of the other options, "`bat`" must


    be last.
    
    The `bootstrap.bat` script is useful only when you intend to build
    MySQL++ with MinGW or Visual C++, and you are using Cygwin only as a
    command line environment.  If you intend to build MySQL++ with
    Cygwin's GCC toolchain, you must not give this option, else you will
    not end up with the necessary build system files.

    One advantage of this feature is that the commands necessary to
    achieve a given effect with `bootstrap.bat` when run via `bootstrap`
    are shorter than when you run the batch file directly.

    Another advantage is that this low-strength version of the bootstrap
    script runs faster than the full-strength form, because it produces
    fewer files.

    Finally, running `bootstrap.bat` indirectly like this lets you avoid
    using `cmd.exe`, a command shell greatly inferior to any of those
    available for Cygwin.

*   `configure` script options

    As soon as the bootstrap script sees an option that it doesn't
    understand, it stops processing the command line.  Any subsequent
    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
................................................................................
do something, it's likely it just can't do it. Bakefile is a
high-level abstraction of build systems in general, so it'll never
support all the particulars of every odd build system out there.

[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.

If you've sent patches to MySQL++ before and don't have a Fossil
developer login, another alternative is to ask for a login before you
begin work so that your changes are automatically sync'd to the main
Fossil repository as you work, so you don't have to send bundles or
patch files. We generally don't refuse such requests if you've already
proven your ability to work productively with the MySQL++ project.

If you're making a patch against a MySQL++ distribution tarball, then
you can generate a patch 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/). Fossil is also available for all of
these systems. There are no excuses for not being able to make unified
diffs. :)

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

Every code base should have a common code style. Love it or
hate it, here are MySQL++'s current code style rules:

................................................................................

-   DOS line endings, again for the Notepad reason. And on modern Unixy
    platforms, the tools cope with DOS line endings reasonably well.
    Better than the converse, anyway.


When in doubt, mimic what you see in the current code. When still in
doubt, ask on [the forum][for].


## Testing Your Proposed Change

MySQL++ includes a self-test mechanism called `dtest`. It's a Bourne
shell script, run much like `exrun`:

................................................................................
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.


<a name="private"></a>
## Maintaining a Private Repository

Although Fossil syncs changes back to the [MySQL++ Fossil
repository][home] by default, it is possible to maintain a private copy
that simply pulls changes in occasionally.

The first step is to turn off the auto-sync feature:

     $ fossil set autosync off

Then, I recommend that you make any local changes on a branch:

    ...hack, hack, hack...
    $ fossil ci --branch my-local-branch

After you give the `--branch` option on a checkin, Fossil automatically
................................................................................
modify your clone, only the working checkout directory. You must then
say `fossil ci` once you're happy with the merge. Until then, all the
usual Fossil commands like `fossil diff` and `fossil status` will help
you come to that decision.

If you ever decide to contribute your private branch to the MySQL++
project, there are a couple of easy ways to achieve that. Ask about it
on [the forum][for] if you find yourself in this situation.

[home]: https://tangentsoft.com/mysqlpp/

Changes to LICENSE.txt.

Changes to README-Cygwin.txt.

Changes to README-Linux.txt.

Changes to README-Mac-OS-X.txt.

Changes to README-Solaris.txt.

Changes to README-Unix.txt.

Changes to README-Visual-C++.txt.

Changes to README-examples.txt.

Name change from README.txt to README.md.

1
2

3
4
5
6
7
8
9
10




11


12

13
14

15
16
17
18
19
20
21
22
23

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


124
125
126
127
128


What It Is
~~~~~~~~~~

    MySQL++ is a C++ wrapper for MySQL's C API.  It is built around STL
    principles, to make dealing with the database as easy as dealing
    with an STL container.  MySQL++ relieves the programmer of dealing
    with cumbersome C data structures, generation of repetitive SQL
    statements, and manual creation of C++ data structures to mirror
    the database schema.

    Its home page is http://tangentsoft.net/mysql++/









Prerequisites
~~~~~~~~~~~~~

    To build MySQL++, you must have the MySQL C API development
    files installed.

    On Unixy systems (Linux, Mac OS X, Cygwin, *BSD, Solaris...),
    the MySQL development files are installed if you build MySQL
    from source.  If you installed MySQL as a binary package, then
    the development files are often packaged separately from the
    MySQL server itself.  It's common for the package containing the
    development files to be called something like "MySQL-devel".


    If you're building on Windows with Visual C++ or MinGW, you
    need to install the native Win32 port of MySQL from mysql.com.
    The development files are only included with the "complete"
    version of the MySQL installer, and some versions of this
    installer won't actually install them unless you do a custom





    install.  Another pitfall is that MySQL++'s project files assume
    that you've installed the current General Availability release of
    MySQL (v5.0 right now) and it's installed in the default location.
    If you've installed a different version, or if MySQL Inc. changes
    the default location (which they seem to do regularly!) you'll have


    to adjust the link and include file paths in the project settings.


Additional Things to Read
~~~~~~~~~~~~~~~~~~~~~~~~~

    Each major platform we support has a dedicated README-*.txt
    file for it containing information specific to that platform.
    Please read it.

    For authorship information, see the CREDITS.txt file.

    For license information, see the COPYING.txt file.

    If you want to change MySQL++, see the HACKERS.txt file.

    You should have received a user manual and a reference manual
    with MySQL++.  If not, you can read a recent version online:

        http://tangentsoft.net/mysql++/doc/



    Search the MySQL++ mailing list archives if you have more
    questions:






        http://lists.mysql.com/plusplus/


Building the Library
~~~~~~~~~~~~~~~~~~~~

    MySQL++ uses Bakefile (http://bakefile.org/) to generate
    platform-specific project files and makefiles from a single set
    of input files.  We currently support these build systems:

    autoconf:
        For Unixy platforms, including Linux, Mac OS X, and Cygwin, in
        addition to the "real" Unices.  See README-Unix.txt for general
        instructions.  Supplementary platform-specific details are
        in README-Cygwin.txt, README-Linux.txt, README-Mac-OS-X.txt,



        and README-Solaris.txt.

    MinGW:
        We ship Makefile.mingw for MinGW.  It currently only builds the
        static version of the library for technical reasons.  This has
        licensing ramifications.  See README-MinGW.txt for details.



    Visual C++:
        We ship Visual Studio 2003, 2005, and 2008 project files.


        No older version of Visual C++ will build MySQL++, due to
        compiler limitations.  See README-Visual-C++.txt for more
        details.


    Xcode:
        We ship an Xcode v2 project file.  It hasn't been tested

        much yet, since the autoconf method works just fine on OS X.
        As a result, we need both success and failure reports on the
        mailing list.  See README-Mac-OS-X.txt for more information.


















Example Programs
~~~~~~~~~~~~~~~~

    You may want to try out the programs in the examples subdirectory
    to ensure that the MySQL++ API and your MySQL database are both
    working properly.  Also, these examples give many examples of
    the proper use of MySQL++.  See README-examples.txt for further
    details.



Unsupported Compliers
~~~~~~~~~~~~~~~~~~~~~
    If you're on Windows but want to use some other compiler besides
    Visual C++ or GCC, you are currently on your own.  There have
    been past efforts to port MySQL++ to other Windows compilers,
    but for one reason or another, all of these ports have died.

    On Unixy systems, GCC still works best.  "Native" compilers and
    third-party compilers may work, but you're on your own to get
    it working.


    We have nothing in particular against these unsupported systems.
    We just lack the time and resources to support everything
    ourselves.  If you are sufficiently motivated to get MySQL++
    working on one of these alternate systems, see the HACKERS.txt
    file first for guidance.  If you follow the advice in that file,
    your patch will be more likely to be accepted.






If You Want to Hack on MySQL++...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    If you intend to change the library or example code, please read
    the HACKERS.txt file.



    If you want to change the user manual, read doc/userman/README.txt

    If you want to change the reference manual, see the Doxygen manual:
    http://www.stack.nl/~dimitri/doxygen/manual.html


|
<
>
|
|
|
|
|
|
|
|
>
>
>
>
|
>
>
|
>
|
<
>
|
|
|
|
|
|
<
|
|
>
|
|
<
<
<
<
>
>
>
>
>
|
|
<
|
<
>
>
|
|
|
|
<
>
|
|
|
|
|
|
|
|
|
|
|
|
|
<
>
>
|
<
<
|
>
>
>
>
>
|
|
|
|
<
>
|
|
|
|
<
<
<
<
<
>
>
>
|
|
<
<
<
<
>
>
|
<
|
>
>
|
<
<
>
|
<
<
>
|
<
<
|
>
>
>
>
>
>
>
|
>
>
>
>
>
>
>
>
>
|
<
>
|
|
|
|
<
|
>
|
<
<
<
<
<
<
|
<
<
<
>
|
<
<
<
<
<
<
>
>
|
>
>
|
<
<
<
<
>
>
|
<
|
<
<
>
>
1

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

21
22
23
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
124






125
126
127
128
129
130




131
132
133

134


135
136
# What It Is


MySQL++ is a C++ wrapper for the MySQL and MariaDB C APIs.  It is built
around STL principles, to make dealing with the database as easy as
dealing with an STL container.  MySQL++ relieves the programmer of
dealing with cumbersome C data structures, generation of repetitive SQL
statements, and manual creation of C++ data structures to mirror the
database schema.

MySQL++’s development home is its [Fossil repository][home]. You may be
reading this via its [GitHub mirror][ghm], but that repository is
read-only, meant as a download-only mirror and for use by automation
tooling based on Git. Checkins to the Fossil repository get pushed
into the GitHub mirror within a day.

[ghm]:  https://github.com/tangentsoft/mysqlpp
[home]: https://tangentsoft.com/mysqlpp/


# Prerequisites


To build MySQL++, you must have the MySQL/MariaDB C API development
files installed.

On Unixy systems (Linux, Mac OS X, Cygwin, \*BSD, Solaris...), the MySQL
development files are installed if you build MySQL from source.  If you
installed MySQL as a binary package, then the development files are

often packaged separately from the MySQL server itself.  It's common for
the package containing the development files to be called something like
`MySQL-devel`, `libmysqlclient-dev`, etc.

If you're building on Windows with Visual C++ or MinGW, you need to




install the native Windows port of MySQL or MariaDB.  The way that’s
packaged changes occasionally, so you might have to select a "complete"
version rather than the server-only version. You might also have to
choose a “custom” installation option to get the development files.

Another pitfall is that the project files we ship assume that you've
installed the current General Availability release of MySQL in its

default location on your computer. If you've installed a different

version, or if those packaging the development files move them around —
which happens occasionally! — you'll have to adjust the link and include
file paths in the project settings.


# Additional Things to Read


Each major platform we support has a dedicated `README-*.txt`
file for it containing information specific to that platform.
Please read it.

For authorship information, see [the CREDITS.txt file][f1].

For license information, see [the COPYING.txt file][f2].

If you want to change MySQL++, see [the HACKERS.md file][f3].

You should have received a user manual and a reference manual with
MySQL++. If not, you can read a recent version [online][docs].


Search the MySQL++ [mailing list archives][ml] and [its forum][for] if
you have more questions.




[docs]: https://tangentsoft.com/mysqlpp/doc/
[f1]:   https://tangentsoft.com/mysqlpp/doc/trunk/CREDITS.txt
[f2]:   https://tangentsoft.com/mysqlpp/doc/trunk/COPYING.txt
[f3]:   https://tangentsoft.com/mysqlpp/doc/trunk/HACKERS.md
[for]:  https://tangentsoft.com/mysqlpp/froum/
[ml]:   http://lists.mysql.com/plusplus/


# Building the Library


MySQL++ uses [Bakefile](http://bakefile.org/) to generate
platform-specific project files and makefiles from a single set
of input files.  We currently support these build systems:






*   **autoconf:** Use this method for most Unix type platforms along
    with [the generic instructions][unix].  We have supplemental
    information for [Linux][linux], [macOS][macos], [Cygwin][cyg], and
    [Solaris][sol].





*   **MinGW:** We ship `Makefile.mingw` for MinGW. See
    [its README][mingw] for details.


*   **Visual C++:** We ship Visual Studio 2003, 2005, and 2008 project
    files. Newer versions of Visual C++ can upgrade these automatically,
    though the result sometimes requires manual adjustment. No older
    version of Visual C++ will build MySQL++, due to compiler


    limitations.  See [its README][vcpp] for more details.



*   **Xcode:** We ship an Xcode project file, but it hasn't been well
    tested, since the autoconf method works just fine on macOS.



[cyg]:   https://tangentsoft.com/mysqlpp/doc/trunk/README-Cygwin.txt
[linux]: https://tangentsoft.com/mysqlpp/doc/trunk/README-Linux.txt
[macos]: https://tangentsoft.com/mysqlpp/doc/trunk/README-Mac-OS-X.txt
[mingw]: https://tangentsoft.com/mysqlpp/doc/trunk/README-MinGW.txt
[sol]:   https://tangentsoft.com/mysqlpp/doc/trunk/README-Solaris.txt
[unix]:  https://tangentsoft.com/mysqlpp/doc/trunk/README-Unix.txt
[vcpp]:  https://tangentsoft.com/mysqlpp/doc/trunk/README-Visual-C%2B%2B.txt



# Unsupported C++ Compilers and Operating Systems

If you get MySQL++ to build under an operating system or with a C++
compiler not listed above, we’re likely to accept a patch for it.  See
[the HACKERS file][f3] for guidance.


# Example Programs


You may want to try out the programs in the examples subdirectory
to ensure that the MySQL++ API and your MySQL database are both
working properly.  Also, [these examples][exr] give many examples of
the proper use of MySQL++.


[exr]: /doc/trunk/README-examples.txt











# If You Want to Hack on MySQL++...







If you intend to submit a change to the MySQL++ project, see
[the HACKERS file][f3].

If you want to change the MySQL++ user manual, also read
[the user manual’s README][umr].





If you want to change the MySQL++ reference manual, see
[the Doxygen manual][dgm].





[dgm]: http://www.doxygen.nl/manual/
[umr]: https://tangentsoft.com/mysqlpp/doc/trunk/doc/userman/README.md

Changes to RELEASE-CHECKLIST.txt.

37
38
39
40
41
42
43
44

45


46
47
48
    Those are safe.

- Re-bootstrap it again without "pedantic", to avoid shipping the
  pedantic build files.

- Run tools/mkrel to check the new ChangeLog.md, configure.ac, and
  mysqyl++.bkl files in with the proper version tag and to merge it into
  the release branch.




- Copy mysql++-$(VERSION).tar.gz to tangentsoft.com releases directory.

- Update "MySQL++" wiki document to point to new release.







|
>
|
>
>
|
|
|
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
    Those are safe.

- Re-bootstrap it again without "pedantic", to avoid shipping the
  pedantic build files.

- Run tools/mkrel to check the new ChangeLog.md, configure.ac, and
  mysqyl++.bkl files in with the proper version tag and to merge it into
  the release branch.  This also creates mysql++-$(VERSION).tar.gz and
  synchs it up to tangentsoft.com in the MySQL++ releases directory.

- On a CentOS 7 box, say "make rpm" from the "release" branch tree.
  Copy the resulting ~/rpmbuild/SRPMS/mysql++-$(VERSION)-1.el7.src.rpm
  to that same releases directory.

- Update "MySQL++" wiki document to point to new release packages.

Changes to bootstrap.

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
			;;

		*)
			ARGS=0
			;;
	esac
done
































# Check for existence of needed tools, so we can give a better error
# message than the shell will.
tools="make"											# POSIX
tools="$tools aclocal autoconf autoheader libtoolize"	# autotools
tools="$tools bakefile bakefilize bakefile_gen"			# Bakefile
for tool in $tools
do
	if ! type -p $tool > /dev/null
	then
		echo "FAILED to find build tool '$tool'!"
		echo
		echo BOOTSTRAP FAILED!
		echo
		exit 1
	fi
done

# Find location of Bakefile's stock M4 autoconf macros
for d in /usr/share/aclocal /usr/local/share/aclocal \
	'/c/Program Files (x86)/Bakefile/autoconf'
do
	BAKEFILE_M4="$d"
	if [ -e "$BAKEFILE_M4/bakefile.m4" ] ; then break ; fi
done
if [ ! -e "$BAKEFILE_M4/bakefile.m4" ]
then
	echo
	echo "Failed to find bakefile.m4.  Add the directory containing"
	echo "this to the bootstrap script."
	echo
	exit 1
fi

# Do Bakefile stuff first.  Autoconf can't succeed without
# autoconf_in.m4, which Bakefile creates.
success=
set -x &&
	for d in 3 5 8 ; do mkdir -p vc200$d ; done &&
	bakefilize &&
	rm -f INSTALL &&
	bakefile_gen $BF_OPTIONS &&
	bakefile -f gnu -o Makefile.simple -DBUILDLIBRARY=no mysql++.bkl &&
	set +x &&
	success=shonuff

# Do the autotools stuff if Bakefile steps succeeded






if [ -n "$success" ]
then
	rm -f config.cache
	mv autoconf_inc.m4 config > /dev/null 2>&1	# don't care if it fails
	set -x &&

		aclocal -I config -I "$BAKEFILE_M4" &&
		libtoolize &&
		autoheader &&
		autoconf &&
		./configure $MAINT_FLAGS $* &&
		make lib/querydef.h lib/ssqls.h &&
		set +x &&
		success=awyeah
fi

# Detect failure in any part of above








>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>


|
|
|












<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<





|







>
>
>
>
>
>





>
|
<
<
<







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



124
125
126
127
128
129
130
			;;

		*)
			ARGS=0
			;;
	esac
done

# Find location of Bakefile stuff.
bakefilize=bakefilize
for d in /usr/share/aclocal /usr/local/share/aclocal \
	'/c/Program Files (x86)/Bakefile/autoconf'
do
	BAKEFILE_M4="$d"
	if [ -e "$BAKEFILE_M4/bakefile.m4" ]
	then
		if [ -x "$d/bakefilize" ]
		then
			bakefilize="$d/bakefilize"
		fi
		break
	fi
done
if [ ! -e "$BAKEFILE_M4/bakefile.m4" ]
then
	echo
	echo "Failed to find bakefile.m4.  Add the directory containing"
	echo "this to the bootstrap script."
	echo
	exit 1
fi
if [ ! -x "$bakefilize" ] && ! type -p "$bakefilize" > /dev/null
then
	echo
	echo "Failed to find the bakefilize script.  Is Bakefile installed?"
	echo
	exit 1
fi

# Check for existence of needed tools, so we can give a better error
# message than the shell will.
tools="make"														# POSIX
tools="$tools aclocal autoconf autoheader autoreconf libtoolize"	# Autotools
tools="$tools bakefile bakefile_gen"								# Bakefile
for tool in $tools
do
	if ! type -p $tool > /dev/null
	then
		echo "FAILED to find build tool '$tool'!"
		echo
		echo BOOTSTRAP FAILED!
		echo
		exit 1
	fi
done

















# Do Bakefile stuff first.  Autoconf can't succeed without
# autoconf_in.m4, which Bakefile creates.
success=
set -x &&
	for d in 3 5 8 ; do mkdir -p vc200$d ; done &&
	"$bakefilize" &&
	rm -f INSTALL &&
	bakefile_gen $BF_OPTIONS &&
	bakefile -f gnu -o Makefile.simple -DBUILDLIBRARY=no mysql++.bkl &&
	set +x &&
	success=shonuff

# Do the autotools stuff if Bakefile steps succeeded
#
# We're calling automake only because autoconf depends on install-sh or
# similar, and it *ass*umes you're using automake as well, so it
# delegates installation of that to automake!  This is why we ignore its
# errors: it fails because configure.ac doesn't refer to AM_* and there
# is no Makefile.am file, but it does still copy over the missing files.
if [ -n "$success" ]
then
	rm -f config.cache
	mv autoconf_inc.m4 config > /dev/null 2>&1	# don't care if it fails
	set -x &&
        automake --add-missing > /dev/null 2>&1 ;
		autoreconf -i -I "$BAKEFILE_M4" &&



		./configure $MAINT_FLAGS $* &&
		make lib/querydef.h lib/ssqls.h &&
		set +x &&
		success=awyeah
fi

# Detect failure in any part of above

Changes to configure.ac.

10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#
# You should have received a copy of the GNU Lesser General Public
# License along with MySQL++; if not, write to the Free Software
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301
# USA

# Standard autotools stuff
AC_INIT(mysql++, 3.2.4, plusplus@lists.mysql.com, mysql++)
AC_CONFIG_HEADER(config.h)
AC_CONFIG_MACRO_DIR([config])
AC_CANONICAL_SYSTEM


# Enable libtool to decide shared library compile flags (ie -fPIC)
AC_PROG_LIBTOOL







|







10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#
# You should have received a copy of the GNU Lesser General Public
# License along with MySQL++; if not, write to the Free Software
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301
# USA

# Standard autotools stuff
AC_INIT(mysql++, 3.2.5, plusplus@lists.mysql.com, mysql++)
AC_CONFIG_HEADER(config.h)
AC_CONFIG_MACRO_DIR([config])
AC_CANONICAL_SYSTEM


# Enable libtool to decide shared library compile flags (ie -fPIC)
AC_PROG_LIBTOOL

Name change from doc/userman/README.txt to doc/userman/README.md.



1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

20
21
22
23
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
124
125
126
127
128

129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144


The user manual is written in XML DocBook format, version 4.4.  It uses
the official DocBook XSL stylesheets, and will build with versions at
least as far back as 1.69.1.  (Why these versions?  They're what comes
with CentOS 5, the oldest system I still use.)

To make the HTML version of the user manual, just type 'make' in this
directory.  (Or 'make html' if you want to be pedantic.)  To make the
PDF version of the manual, say 'make pdf'.  To make both versions,
say 'make all'.



The most likely cause of build failures is not having the right
processing programs installed.  The DocBook processing model looks
like this:

    DocBook --[XSLT proc.]-+-> HTML
                   ^       |
                   |       +-> XSL-FO --[XSL-FO proc.]--> PDF

                   |
           {XSL stylesheets}

"DocBook" above is a file in DocBook XML format.  In this case,
it's in userman.dbx.






There are many alternatives for the tools in the square brackets:




    The first replaceable piece is an XSLT processor, which
    translates XML into other text formats, such as HTML or other
    varieties of XML.  We use xsltproc from the Gnome project.
    (http://xmlsoft.org/XSLT/)  There are numerous alternatives,
    but each supports different extensions to the standard, so it's
    simplest if everyone uses the same processor for a given document.




    We use the XSLT processor to do two transforms.  One is directly to
    HTML.  The other is to XSL-FO, an XML-based page layout language.
    We do this intermediary transform because XSLT is not good at
    creating binary formats like PDF.








    The second replaceable piece in the diagram above is an XSL-FO
    processor, which converts XSL-FO to a more directly useful page
    layout format, like PDF.  The user manual's build system supports
    several alternatives.

    The build system relies on a simple script in this directory --
    fo2pdf -- to find an XSL-FO formatter and run it.  It looks first
    for RenderX's XEP, which comes in a free-as-in-beer version for
    personal use.  (http://renderx.com/download/personal.html)  If
    you're in a commercial environment, RenderX wants you to use their
    commercial trial version which will format this manual without
    complaint, but it puts watermarks and blank pages into the output.
    As of July 2018, they want $400 for the single-user to get clean
    output.  It's the same as the free personal version, just with a
    different license.  You don't need the higher-end versions of XEP;
    they don't do anything we need here.

    If fo2pdf can't find XEP, it then looks for Antenna House's XSL
    Formatter (http://antennahouse.com/).  It's pretty much the same
    deal as XEP: crippled demo version for testing, and a single-user
    version for $400.  There is no free version for personal use,
    however.

    Failing all that, fo2pdf falls back to the only free-as-in-speech
    XSL-FO formmatter, Apache FOP (http://xmlgraphics.apache.org/fop/).

    FOP may be available through your OS's package system.  For
    instance, with Debian tyep OSes, you can just say

       sudo apt-get install fop

    If FOP is not in your OS's package system, you can download
    pre-built binaries from the FOP web site that will run with the
    version of Java that almost certainly is available with your OS's
    package system.

    You might be wondering why fo2pdf looks for FOP last, given that
    MySQL++ is itself free software and relies on a lot of other
    free software.  It's just that it's a good bet that if there's
    a commercial processor on the system, it was put there quite
    purposefully by someone who paid (or caused money to be paid) for

    it, and so wants it to be used.  The commercial vendors can still
    get money for their products because FOP hasn't caught up with
    them in several important areas.  That said, don't feel that you
    need to go and buy an XSL-FO processor just to build the manuals.
    We try to always keep the manual in a state where FOP can generate
    adequate output.








The third replaceable piece above is the DocBook XSL stylesheet set.
The stylesheets are the XSLT processor's rules, controlling how the
input XML gets transformed to the output format.  The standard DocBook
stylesheet set includes stylesheets for HTML and XSL-FO output.
Normally, xsltproc looks for these first on your local system, and

failing to find them, tries to download them on the fly from the
Internet.  Because this slows processing quite a bit even if you have a
fast Internet connection, we've disabled this feature of xsltproc, so
you must have the DocBook XSL stylesheets locally installed to build the
user manual.

Most Unixy type systems have pre-built DocBook XSL stylesheet packages
available:

    Red Hat/Fedora: docbook-style-xsl RPM package, base OS repository
    macOS:          docbook-xsl Homebrew package (http://brew.sh/)
    Cygwin:         docbook-xml?? package (?? = DocBook version)
    Ubuntu/Debian:  docbook-xsl package, standard APT repository

Please send the name of the package for your system to the mailing list
if it isn't listed above, and I'll add it to the list.

If you can't find a package for your system, you can get the DocBook
stylesheets from the source: http://docbook.sourceforge.net/  They're
a bit tricky to set up correctly, so it's better to use a pre-built
package if you can.

If you are still having problems, post the details about it to the
MySQL++ mailing list, and I'll try to help you debug the problem.
You might also find the FOP and/or DocBook mailing lists helpful.






If you're looking to hack on the manual, here are some helpful
resources for getting up to speed on DocBook:

    Mills' "Installing And Using An XML/SGML DocBook Editing Suite"
    article:

        http://tinyurl.com/8alb2


        This is the best tutorial I've found.
        

    Walsh and Muellner's _DocBook: The Definitive Guide_ book:

        https://tdg.docbook.org/

        This is the official DocBook referece.  It is available both
        online and in dead-tree versions.


    The official DocBook site:

        http://docbook.org/

>
>



|

|
|
|
<







|
|
<
>
|
|

|
<
>

>
>
>
>
|

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

|
|
<
<
>

>
>
>
>
>
>
|
|
|
|

|
|
|
<
|
|
|
|
|
|
|

|
|
|
|
<

|
<
>
|
|

|

|
|
|
|

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

>
>
>

>
>
>



|
<
>
|
|
|
|
|




|
|
|
|

|



|



|
|


>


>




|
<
<
|
>

<
<
<
|
<
|
<
<
|

<
|

<
<
1
2
3
4
5
6
7
8
9
10

11
12
13
14
15
16
17
18
19

20
21
22
23
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
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143


144
145
146



147

148


149
150

151
152


# Overview

The user manual is written in XML DocBook format, version 4.4.  It uses
the official DocBook XSL stylesheets, and will build with versions at
least as far back as 1.69.1.  (Why these versions?  They're what comes
with CentOS 5, the oldest system I still build this manual on.)

To make the HTML version of the user manual, just type `make` or `make
html` in this directory.  To make the PDF version of the manual, say
`make pdf`.  To make both versions, say `make all`.




The most likely cause of build failures is not having the right
processing programs installed.  The DocBook processing model looks
like this:

    DocBook --> [XSLT proc.] --+--> HTML
                     ^         |

                     |         +--> XSL-FO --> [XSL-FO proc.] --> PDF
                     |
             [XSL stylesheets]

"DocBook" above is a file in DocBook XML format.  It's `userman.dbx` in

the case of the MySQL++ User Manual.



# Interchangeable Elements

There are many alternatives for the elements in the square brackets:


## XSLT Processor

The first replaceable piece is an XSLT processor, which translates XML
into other text formats, such as HTML or other varieties of XML.  We use
[`xsltproc`][1] from the Gnome project.  There are several other widely



available XSLT processors, but because we use some nonstandard
extensions to XSLT — primarily [XIncludes][2] — not all XSLT processors
function as drop-in replacements.

We use the XSLT processor to do two transforms.  One is directly to
HTML.  The other is to XSL-FO, an XML-based page layout language. This


brings us to...

[1]: http://xmlsoft.org/XSLT/
[2]: https://en.wikipedia.org/wiki/XInclude


## XSL-FO Processor

The second replaceable piece in the diagram above is an XSL-FO
processor, which converts XSL-FO to a more directly useful page
layout format, like PDF.  The user manual's build system supports
several alternatives.

The build system relies on a simple script in this directory — `fo2pdf`
 to find an XSL-FO formatter and run it.  It looks first for [RenderX
XEP][3], which comes in a free-as-in-kitten version for personal use.

If you're in a commercial environment, RenderX wants you to use their
commercial trial version which will format this manual without
complaint, but it puts watermarks and blank pages into the output.  As
of May 2019, they want $400 for the single-user to get clean output.
It's the same as the free personal version, just with a different
license.  You don't need the higher-end versions of XEP; they don't do
anything we need here.

If `fo2pdf` can't find XEP, it then looks for [Antenna House XSL
Formatter][4].  It's pretty much the same deal as XEP: crippled demo
version for testing, and a single-user “Lite” version for $400.  There
is no free version for personal use, however.


Failing all that, `fo2pdf` falls back to the only free-as-in-liberty

XSL-FO formmatter, [Apache FOP][5].  FOP
may be available through your OS's package system.  For instance, with
Debian tyep OSes, you can just say

    $ sudo apt install fop

If FOP is not in your OS's package system, you can download
pre-built binaries from the FOP web site that will run with the
version of Java that almost certainly is available with your OS's
package system.

You might be wondering why `fo2pdf` looks for FOP last, given that
MySQL++ is itself free software and relies on a lot of other free
software.  It's just that it's a good bet that if there's a commercial
processor on the system, it was put there quite purposefully by someone

who went out of their way to make it available on that system, and so
wants it to be used.  The commercial vendors can still get money for
their products because FOP hasn't caught up with them in several
important areas.  That said, don't feel that you need to go and buy an
XSL-FO processor just to build the manuals.  We try to always keep the
manual in a state where FOP can generate adequate output.


[3]: http://renderx.com/download/personal.html
[4]: http://antennahouse.com/
[5]: http://xmlgraphics.apache.org/fop/


## DocBook XSL Stylesheets

The third replaceable piece above is the DocBook XSL stylesheet set.
The stylesheets are the XSLT processor's rules, controlling how the
input XML gets transformed to the output format.  The standard DocBook
stylesheet set includes stylesheets for HTML and XSL-FO output.  The

default behavior of `xsltproc` is look for these first on your local
system, and then if it fails to find them, tries to download them on the
fly from the Internet.  Because this slows processing quite a bit even
if you have a fast Internet connection, we've disabled this feature of
`xsltproc`, so you must have the DocBook XSL stylesheets locally
installed to build the user manual.

Most Unixy type systems have pre-built DocBook XSL stylesheet packages
available:

*   **Red Hat/Fedora:** `docbook-style-xsl` RPM package, base OS repository
*   **macOS:**          `docbook-xsl` [Homebrew](http://brew.sh/) package 
*   **Cygwin:**         `docbook-xml??` package (?? = DocBook version)
*   **Ubuntu/Debian:**  `docbook-xsl` package, standard APT repository

Please send the name of the package for your system to [the forum][for]
if it isn't listed above, and I'll add it to the list.

If you can't find a package for your system, you can get the DocBook
stylesheets from [the source](http://docbook.sourceforge.net/).  They're
a bit tricky to set up correctly, so it's better to use a pre-built
package if you can.

If you are still having problems, post the details about it to [the
MySQL++ forum][for], and I'll try to help you debug the problem.
You might also find the FOP and/or DocBook mailing lists helpful.

[for]: https://tangentsoft.com/mysqlpp/forum


# Hacking on the Manual

If you're looking to hack on the manual, here are some helpful
resources for getting up to speed on DocBook:

*   Mills' [_Installing And Using An XML/SGML DocBook Editing


    Suite_](http://tinyurl.com/8alb2) article is the best tutorial I've
    found.




*   Walsh and Muellner's [_DocBook: The Definitive Guide_

    book](https://tdg.docbook.org/) is the official DocBook referece.


    It is available both online and in dead-tree versions.


*   [The official DocBook site](https://docbook.org/)



Changes to doc/userman/userman.dbx.in.

27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
			<author>
				<firstname>Warren</firstname>
				<surname>Young</surname>
			</author>
		</authorgroup>

		<copyright>
			<year>1998-2001, 2005-2018</year>
			<holder>Kevin Atkinson (original author)</holder>
			<holder>MySQL AB</holder>
			<holder>Educational Technology Resources</holder>
		</copyright>

		<pubdate><?dbtimestamp format="B d, Y"?></pubdate>
	</articleinfo>







|







27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
			<author>
				<firstname>Warren</firstname>
				<surname>Young</surname>
			</author>
		</authorgroup>

		<copyright>
			<year>1998-2001, 2005-2019</year>
			<holder>Kevin Atkinson (original author)</holder>
			<holder>MySQL AB</holder>
			<holder>Educational Technology Resources</holder>
		</copyright>

		<pubdate><?dbtimestamp format="B d, Y"?></pubdate>
	</articleinfo>

Changes to lib/common.h.

84
85
86
87
88
89
90













91
92
93
94
95
96
97
...
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
#		pragma warning(disable: 4290)
		// Disable whining about using 'this' as a member initializer on VC++.
#		pragma warning(disable: 4355)
		// Disable whining about implicit conversions to bool
#		pragma warning(disable: 4800)
		// Disable nagging about new "secure" functions like strncpy_s()
#		pragma warning(disable: 4996)














		// Prior to Visual C++ 2015, we must use _snprintf()
#		if _MSC_VER < 1900
#			define snprintf _snprintf
#		endif
#	endif

................................................................................

// Workarounds for deprecations in C++11 and newer.  We must still
// support systems whose contemporaneous C++ compiler only understands
// C++98.  Because of the large gap between C++98 and C++11, it will
// likely be years yet until we can start using C++11 unconditionally
// within MySQL++, then years more until we can use C++14, etc.
//
// Our test here currently only works for g++ and clang++: it's testing
// for C++17.
//
// That release finally did away with throwspecs, a feature of C++ that
// is only used by the oldest parts of MySQL++.  We can't drop the
// throwspecs until MySQL++ 4, if we ever get around to that, since
// that would break the library's ABI on systems whose C++ compiler
// still supports throwspecs.
#if __cplusplus < 201703L
#	define MAY_THROW(what) throw(what)
#else
#	define MAY_THROW(junk) noexcept(false)
#endif

// C++11 added unique_ptr as a replacement for auto_ptr.  We don't have
// the ABI problem above with this one, so we switch to it with the







>
>
>
>
>
>
>
>
>
>
>
>
>







 







|
|
|
|
|
|
|
|
<







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
...
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159

160
161
162
163
164
165
166
#		pragma warning(disable: 4290)
		// Disable whining about using 'this' as a member initializer on VC++.
#		pragma warning(disable: 4355)
		// Disable whining about implicit conversions to bool
#		pragma warning(disable: 4800)
		// Disable nagging about new "secure" functions like strncpy_s()
#		pragma warning(disable: 4996)

		// Disable warning about exporting a class from a DLL which is
		// derived from a non-exported class in another DLL.  This is
		// safe to do with Standard C++ library types per:
		//
		//  https://msdn.microsoft.com/en-us/library/3tdb471s.aspx
		//
		// We don't hit this any other way in MySQL++.
#		pragma warning(disable: 4275)

		// Squish warning about passing no args to MAY_THROW() when
		// building with newer C++ support.  We're doing it on purpose.
#		pragma warning(disable: 4003)

		// Prior to Visual C++ 2015, we must use _snprintf()
#		if _MSC_VER < 1900
#			define snprintf _snprintf
#		endif
#	endif

................................................................................

// Workarounds for deprecations in C++11 and newer.  We must still
// support systems whose contemporaneous C++ compiler only understands
// C++98.  Because of the large gap between C++98 and C++11, it will
// likely be years yet until we can start using C++11 unconditionally
// within MySQL++, then years more until we can use C++14, etc.
//
// C++11 deprecated throwspecs, a feature of C++ that is only used by
// the oldest parts of MySQL++.  We can't drop the throwspecs until
// MySQL++ 4, if we ever get around to that, since that would break
// the library's ABI on systems whose C++ compiler still supports
// throwspecs.  This feature isn't completely gone until C++17, but we
// don't want the warnings on certain newer compilers expecting C++11
// or newer C++ dialects.
#if __cplusplus < 201103L

#	define MAY_THROW(what) throw(what)
#else
#	define MAY_THROW(junk) noexcept(false)
#endif

// C++11 added unique_ptr as a replacement for auto_ptr.  We don't have
// the ABI problem above with this one, so we switch to it with the

Changes to lib/field_names.cpp.

53
54
55
56
57
58
59
60






61
62
63
64
65
66
67
{
	std::string temp1(s);
	internal::str_to_lwr(temp1);
	for (const_iterator it = begin(); it != end(); ++it) {
	std::string temp2(*it);
		internal::str_to_lwr(temp2);
		if (temp2.compare(temp1) == 0) {
			return it - begin();






		}
	}

	return end() - begin();
}

} // end namespace mysqlpp







|
>
>
>
>
>
>



|



53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
{
	std::string temp1(s);
	internal::str_to_lwr(temp1);
	for (const_iterator it = begin(); it != end(); ++it) {
	std::string temp2(*it);
		internal::str_to_lwr(temp2);
		if (temp2.compare(temp1) == 0) {
			// The cast is necessary for compilers where sizeof(int) !=
			// sizeof (void*) with sufficiently good warnings.  Yes,
			// technically this does risk data loss, but for that to
			// happen you'd have to have more than 2^(sizeof(int)*8)-1
			// fields in your table.  If you do that, you deserve to
			// lose anyway.
			return (unsigned int)(it - begin());
		}
	}

	return (unsigned int)(end() - begin());	// same as above
}

} // end namespace mysqlpp

Changes to lib/options.cpp.

63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
...
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
...
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
...
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
356
357
358
				Option::err_NONE : Option::err_api_reject;
}


Option::Error
GuessConnectionOption::set(DBDriver* dbd)
{
#if (MYSQL_VERSION_ID >= 40101 && MYSQL_VERSION_ID <= 80100) || defined(MARIADB_BASE_VERSION)
	return dbd->connected() ? Option::err_connected :
			dbd->set_option(MYSQL_OPT_GUESS_CONNECTION) ?
				Option::err_NONE : Option::err_api_reject;
#else
	return Option::err_api_limit;
#endif
}
................................................................................
#endif
}


Option::Error
SecureAuthOption::set(DBDriver* dbd)
{
#if MYSQL_VERSION_ID >= 40101
	return dbd->connected() ? Option::err_connected :
			dbd->set_option(MYSQL_SECURE_AUTH, &arg_) ?
				Option::err_NONE : Option::err_api_reject;
#else
	return Option::err_api_limit;
#endif
}
................................................................................
				Option::err_NONE : Option::err_api_reject;
}


Option::Error
SetClientIpOption::set(DBDriver* dbd)
{
#if (MYSQL_VERSION_ID >= 40101 && MYSQL_VERSION_ID <= 80100) || defined(MARIADB_BASE_VERSION)
	return dbd->connected() ? Option::err_connected :
			dbd->set_option(MYSQL_SET_CLIENT_IP, arg_.c_str()) ?
				Option::err_NONE : Option::err_api_reject;
#else
	return Option::err_api_limit;
#endif
}
................................................................................
#endif
}


Option::Error
UseEmbeddedConnectionOption::set(DBDriver* dbd)
{
#if (MYSQL_VERSION_ID >= 40101 && MYSQL_VERSION_ID <= 80100) || defined(MARIADB_BASE_VERSION)
	return dbd->connected() ? Option::err_connected :
			dbd->set_option(MYSQL_OPT_USE_EMBEDDED_CONNECTION) ?
				Option::err_NONE : Option::err_api_reject;
#else
	return Option::err_api_limit;
#endif
}


Option::Error
UseRemoteConnectionOption::set(DBDriver* dbd)
{
#if (MYSQL_VERSION_ID >= 40101 && MYSQL_VERSION_ID <= 80100) || defined(MARIADB_BASE_VERSION)
	return dbd->connected() ? Option::err_connected :
			dbd->set_option(MYSQL_OPT_USE_REMOTE_CONNECTION) ?
				Option::err_NONE : Option::err_api_reject;
#else
	return Option::err_api_limit;
#endif
}







|







 







|







 







|







 







|












|







63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
...
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
...
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
...
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
356
357
358
				Option::err_NONE : Option::err_api_reject;
}


Option::Error
GuessConnectionOption::set(DBDriver* dbd)
{
#if (MYSQL_VERSION_ID >= 40101 && MYSQL_VERSION_ID <= 80003) || defined(MARIADB_BASE_VERSION)
	return dbd->connected() ? Option::err_connected :
			dbd->set_option(MYSQL_OPT_GUESS_CONNECTION) ?
				Option::err_NONE : Option::err_api_reject;
#else
	return Option::err_api_limit;
#endif
}
................................................................................
#endif
}


Option::Error
SecureAuthOption::set(DBDriver* dbd)
{
#if (MYSQL_VERSION_ID >= 40101 && MYSQL_VERSION_ID <= 80002) || defined(MARIADB_BASE_VERSION)
	return dbd->connected() ? Option::err_connected :
			dbd->set_option(MYSQL_SECURE_AUTH, &arg_) ?
				Option::err_NONE : Option::err_api_reject;
#else
	return Option::err_api_limit;
#endif
}
................................................................................
				Option::err_NONE : Option::err_api_reject;
}


Option::Error
SetClientIpOption::set(DBDriver* dbd)
{
#if (MYSQL_VERSION_ID >= 40101 && MYSQL_VERSION_ID <= 80003) || defined(MARIADB_BASE_VERSION)
	return dbd->connected() ? Option::err_connected :
			dbd->set_option(MYSQL_SET_CLIENT_IP, arg_.c_str()) ?
				Option::err_NONE : Option::err_api_reject;
#else
	return Option::err_api_limit;
#endif
}
................................................................................
#endif
}


Option::Error
UseEmbeddedConnectionOption::set(DBDriver* dbd)
{
#if (MYSQL_VERSION_ID >= 40101 && MYSQL_VERSION_ID <= 80003) || defined(MARIADB_BASE_VERSION)
	return dbd->connected() ? Option::err_connected :
			dbd->set_option(MYSQL_OPT_USE_EMBEDDED_CONNECTION) ?
				Option::err_NONE : Option::err_api_reject;
#else
	return Option::err_api_limit;
#endif
}


Option::Error
UseRemoteConnectionOption::set(DBDriver* dbd)
{
#if (MYSQL_VERSION_ID >= 40101 && MYSQL_VERSION_ID <= 80003) || defined(MARIADB_BASE_VERSION)
	return dbd->connected() ? Option::err_connected :
			dbd->set_option(MYSQL_OPT_USE_REMOTE_CONNECTION) ?
				Option::err_NONE : Option::err_api_reject;
#else
	return Option::err_api_limit;
#endif
}

Changes to lib/stadapter.h.

218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
	/// initialized (default ctor called, and no subsequent assignment)
	/// or if there are not at least i + 1 characters in the buffer.
	///
	/// WARNING: The throw-spec is incorrect, but it's irrelevant since
    /// they're obsolete in modern C++ now anyway, since they were
    /// always unreliable.  If we ever get to MySQL++ 4 and can break
    /// the ABI, this throw-spec will just go away.
#if !defined(DOXYGEN_IGNORE) && __cplusplus >= 201703L
    // Can't use MAY_THROW() here: it confuses Doxygen 1.8.14.
	char at(size_type i) const noexcept(false);
#else
	char at(size_type i) const throw(std::out_of_range);
#endif

	/// \brief Compare the internal buffer to the given string







|







218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
	/// initialized (default ctor called, and no subsequent assignment)
	/// or if there are not at least i + 1 characters in the buffer.
	///
	/// WARNING: The throw-spec is incorrect, but it's irrelevant since
    /// they're obsolete in modern C++ now anyway, since they were
    /// always unreliable.  If we ever get to MySQL++ 4 and can break
    /// the ABI, this throw-spec will just go away.
#if !defined(DOXYGEN_IGNORE) && __cplusplus >= 201103L
    // Can't use MAY_THROW() here: it confuses Doxygen 1.8.14.
	char at(size_type i) const noexcept(false);
#else
	char at(size_type i) const throw(std::out_of_range);
#endif

	/// \brief Compare the internal buffer to the given string

Changes to lib/type_info.cpp.

97
98
99
100
101
102
103





104
105
106
107
108
109
110
...
176
177
178
179
180
181
182







183
184
185
186
187
188
189
	sql_type_info("TIMESTAMP NOT NULL", typeid(sql_timestamp),
			MYSQL_TYPE_TIMESTAMP),
	sql_type_info("BIGINT NOT NULL", typeid(sql_bigint),
			MYSQL_TYPE_LONGLONG, mysql_ti_sql_type_info::tf_default),
	sql_type_info("BIGINT UNSIGNED NOT NULL", typeid(sql_bigint_unsigned),
			MYSQL_TYPE_LONGLONG, mysql_ti_sql_type_info::tf_default |
			mysql_ti_sql_type_info::tf_unsigned),





	sql_type_info("MEDIUMINT NOT NULL", typeid(sql_mediumint),
			MYSQL_TYPE_INT24, mysql_ti_sql_type_info::tf_unsigned),
	sql_type_info("MEDIUMINT UNSIGNED NOT NULL", typeid(sql_mediumint_unsigned),
			MYSQL_TYPE_INT24, mysql_ti_sql_type_info::tf_unsigned),
	sql_type_info("DATE NOT NULL", typeid(sql_date),
			MYSQL_TYPE_DATE, mysql_ti_sql_type_info::tf_default),
	sql_type_info("TIME NOT NULL", typeid(sql_time),
................................................................................
			MYSQL_TYPE_TIMESTAMP),
	sql_type_info("BIGINT NULL", typeid(Null<sql_bigint>),
			MYSQL_TYPE_LONGLONG, mysql_ti_sql_type_info::tf_default |
			mysql_ti_sql_type_info::tf_null),
	sql_type_info("BIGINT UNSIGNED NULL", typeid(Null<sql_bigint_unsigned>),
			MYSQL_TYPE_LONGLONG, mysql_ti_sql_type_info::tf_default |
			mysql_ti_sql_type_info::tf_null |







			mysql_ti_sql_type_info::tf_unsigned),
	sql_type_info("MEDIUMINT NULL", typeid(Null<sql_mediumint>),
			MYSQL_TYPE_INT24, mysql_ti_sql_type_info::tf_null),
	sql_type_info("MEDIUMINT UNSIGNED NULL", typeid(Null<sql_mediumint_unsigned>), 
			MYSQL_TYPE_INT24, mysql_ti_sql_type_info::tf_null |
			mysql_ti_sql_type_info::tf_unsigned),
	sql_type_info("DATE NULL", typeid(Null<sql_date>),







>
>
>
>
>







 







>
>
>
>
>
>
>







97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
...
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
	sql_type_info("TIMESTAMP NOT NULL", typeid(sql_timestamp),
			MYSQL_TYPE_TIMESTAMP),
	sql_type_info("BIGINT NOT NULL", typeid(sql_bigint),
			MYSQL_TYPE_LONGLONG, mysql_ti_sql_type_info::tf_default),
	sql_type_info("BIGINT UNSIGNED NOT NULL", typeid(sql_bigint_unsigned),
			MYSQL_TYPE_LONGLONG, mysql_ti_sql_type_info::tf_default |
			mysql_ti_sql_type_info::tf_unsigned),
	sql_type_info("BIGINT NOT NULL", typeid(longlong),
			MYSQL_TYPE_LONGLONG, mysql_ti_sql_type_info::tf_default),
	sql_type_info("BIGINT UNSIGNED NOT NULL", typeid(ulonglong),
			MYSQL_TYPE_LONGLONG, mysql_ti_sql_type_info::tf_default |
			mysql_ti_sql_type_info::tf_unsigned),
	sql_type_info("MEDIUMINT NOT NULL", typeid(sql_mediumint),
			MYSQL_TYPE_INT24, mysql_ti_sql_type_info::tf_unsigned),
	sql_type_info("MEDIUMINT UNSIGNED NOT NULL", typeid(sql_mediumint_unsigned),
			MYSQL_TYPE_INT24, mysql_ti_sql_type_info::tf_unsigned),
	sql_type_info("DATE NOT NULL", typeid(sql_date),
			MYSQL_TYPE_DATE, mysql_ti_sql_type_info::tf_default),
	sql_type_info("TIME NOT NULL", typeid(sql_time),
................................................................................
			MYSQL_TYPE_TIMESTAMP),
	sql_type_info("BIGINT NULL", typeid(Null<sql_bigint>),
			MYSQL_TYPE_LONGLONG, mysql_ti_sql_type_info::tf_default |
			mysql_ti_sql_type_info::tf_null),
	sql_type_info("BIGINT UNSIGNED NULL", typeid(Null<sql_bigint_unsigned>),
			MYSQL_TYPE_LONGLONG, mysql_ti_sql_type_info::tf_default |
			mysql_ti_sql_type_info::tf_null |
			mysql_ti_sql_type_info::tf_unsigned),
	sql_type_info("BIGINT NULL", typeid(Null<longlong>),
			MYSQL_TYPE_LONGLONG, mysql_ti_sql_type_info::tf_default |
			mysql_ti_sql_type_info::tf_null),
	sql_type_info("BIGINT UNSIGNED NULL", typeid(Null<ulonglong>),
			MYSQL_TYPE_LONGLONG, mysql_ti_sql_type_info::tf_default |
			mysql_ti_sql_type_info::tf_null |
			mysql_ti_sql_type_info::tf_unsigned),
	sql_type_info("MEDIUMINT NULL", typeid(Null<sql_mediumint>),
			MYSQL_TYPE_INT24, mysql_ti_sql_type_info::tf_null),
	sql_type_info("MEDIUMINT UNSIGNED NULL", typeid(Null<sql_mediumint_unsigned>), 
			MYSQL_TYPE_INT24, mysql_ti_sql_type_info::tf_null |
			mysql_ti_sql_type_info::tf_unsigned),
	sql_type_info("DATE NULL", typeid(Null<sql_date>),

Changes to mysql++.bkl.

59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
...
166
167
168
169
170
171
172
173
174
175
176
177
178

179
180
181
182
183
184
185
...
201
202
203
204
205
206
207

208
209

210
211
212
213
214
215
216
...
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
256
257
258
...
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
    <set-srcdir>..</set-srcdir>
  </if>

  <if cond="BUILDLIBRARY=='yes'">
    <dll id="mysqlpp">
      <dllname>mysqlpp$(DEBUG_SUFFIX)</dllname>
      <libname>mysqlpp$(DEBUG_SUFFIX)</libname>
      <so_version>3.2.4</so_version>

      <sources>
        lib/beemutex.cpp
        lib/cmdline.cpp
        lib/connection.cpp
        lib/cpool.cpp
        lib/datetime.cpp
................................................................................

    <threading>$(THREAD_TYPE)</threading>
    <cxx-rtti>on</cxx-rtti>
    <cxx-exceptions>on</cxx-exceptions>
    <debug-info>$(DEBUGINFO)</debug-info>
    <optimize>$(OPTIMIZE_FLAG)</optimize>

    <if cond="FORMAT in ['autoconf', 'gnu', 'mingw', 'xcode2']">
      <include>lib</include>
        <include>@MYSQL_C_INC_DIR@</include>
        <lib-path>@MYSQL_C_LIB_DIR@</lib-path>
      <lib-path>.</lib-path>
    </if>

    <if cond="FORMAT in ['msvs2003prj', 'msvs2005prj', 'msvs2008prj']">
      <include>../lib</include>
    </if>

    <if cond="FORMAT=='xcode2'">
      <define>HAVE_POSIX_GETOPT</define>
      <define>MYSQLPP_XCODE</define>
................................................................................
    </if>

    <if cond="FORMAT=='mingw'">
      <define>MYSQLPP_NO_DLL</define>
      <ldflags>
        -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-stdcall-fixup
      </ldflags>

      <include>"$(MYSQL_WIN_DIR)\include"</include>
      <lib-path>"$(MYSQL_WIN_DIR)\lib"</lib-path>

      <sys-lib>mysql</sys-lib>
      <sys-lib>mysqlpp$(DEBUG_SUFFIX)</sys-lib>
    </if>

    <if cond="FORMAT in ['msvs2003prj', 'msvs2005prj', 'msvs2008prj']">
      <lib-path>$(BUILD)</lib-path>
      <include>$(MYSQL_WIN_DIR)\include</include>
................................................................................
      <sys-lib>mysqlclient</sys-lib>
      <sys-lib>mysqlpp$(DEBUG_SUFFIX)</sys-lib>
    </if>
  </template>

  <if cond="BUILDLIBRARY=='yes'">
    <!-- SSQLS v2 parser convenience library -->
    <lib id="ssqls2parse" template="programs">


      <depends>mysqlpp</depends>




      <libname>mysqlpp_ssqls2parse</libname>
      <sources>ssx/parsev2.cpp</sources>
      <include>.</include>


    </lib>

    <!-- Build rules for ssqlsxlat tool -->
    <exe id="ssqlsxlat" template="programs">
      <sources>ssx/genv2.cpp</sources>
      <sources>ssx/main.cpp</sources>
      <depends>ssqls2parse</depends>
      <sys-lib>mysqlpp_ssqls2parse</sys-lib>
      <sys-lib>mysqlpp</sys-lib>
    </exe>
  </if>

  <!-- Define library testing programs' output targets, if enabled -->
  <if cond="BUILDTEST=='yes'">
    <exe id="test_array_index" template="programs">
      <sources>test/array_index.cpp</sources>
................................................................................
    <exe id="test_qstream" template="programs">
      <sources>test/qstream.cpp</sources>
    </exe>
    <exe id="test_sqlstream" template="programs">
      <sources>test/sqlstream.cpp</sources>
    </exe>
    <if cond="BUILDLIBRARY=='yes'">
      <exe id="test_ssqls2" template="programs">
        <sources>test/ssqls2.cpp</sources>
        <depends>ssqls2parse</depends>
        <sys-lib>mysqlpp_ssqls2parse</sys-lib>
        <sys-lib>mysqlpp</sys-lib>
      </exe>
    </if>
    <if cond="FORMAT!='msvs2003prj'">
      <!-- VC++ 2003 can't compile this -->
      <exe id="test_string" template="programs">
        <sources>test/string.cpp</sources>
      </exe>







|







 







|

|
|


>







 







>


>







 







|
>
>

>
>
>
>



>
>



|


<
<
<







 







|



<







59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
...
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
...
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
...
234
235
236
237
238
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
...
298
299
300
301
302
303
304
305
306
307
308

309
310
311
312
313
314
315
    <set-srcdir>..</set-srcdir>
  </if>

  <if cond="BUILDLIBRARY=='yes'">
    <dll id="mysqlpp">
      <dllname>mysqlpp$(DEBUG_SUFFIX)</dllname>
      <libname>mysqlpp$(DEBUG_SUFFIX)</libname>
      <so_version>3.2.5</so_version>

      <sources>
        lib/beemutex.cpp
        lib/cmdline.cpp
        lib/connection.cpp
        lib/cpool.cpp
        lib/datetime.cpp
................................................................................

    <threading>$(THREAD_TYPE)</threading>
    <cxx-rtti>on</cxx-rtti>
    <cxx-exceptions>on</cxx-exceptions>
    <debug-info>$(DEBUGINFO)</debug-info>
    <optimize>$(OPTIMIZE_FLAG)</optimize>

    <if cond="FORMAT in ['autoconf', 'gnu', 'xcode2']">
      <include>lib</include>
      <include>@MYSQL_C_INC_DIR@</include>
      <lib-path>@MYSQL_C_LIB_DIR@</lib-path>
      <lib-path>.</lib-path>
    </if>

    <if cond="FORMAT in ['msvs2003prj', 'msvs2005prj', 'msvs2008prj']">
      <include>../lib</include>
    </if>

    <if cond="FORMAT=='xcode2'">
      <define>HAVE_POSIX_GETOPT</define>
      <define>MYSQLPP_XCODE</define>
................................................................................
    </if>

    <if cond="FORMAT=='mingw'">
      <define>MYSQLPP_NO_DLL</define>
      <ldflags>
        -Wl,--enable-auto-import -Wl,--enable-runtime-pseudo-reloc -Wl,--enable-stdcall-fixup
      </ldflags>
      <include>lib</include>
      <include>"$(MYSQL_WIN_DIR)\include"</include>
      <lib-path>"$(MYSQL_WIN_DIR)\lib"</lib-path>
      <lib-path>.</lib-path>
      <sys-lib>mysql</sys-lib>
      <sys-lib>mysqlpp$(DEBUG_SUFFIX)</sys-lib>
    </if>

    <if cond="FORMAT in ['msvs2003prj', 'msvs2005prj', 'msvs2008prj']">
      <lib-path>$(BUILD)</lib-path>
      <include>$(MYSQL_WIN_DIR)\include</include>
................................................................................
      <sys-lib>mysqlclient</sys-lib>
      <sys-lib>mysqlpp$(DEBUG_SUFFIX)</sys-lib>
    </if>
  </template>

  <if cond="BUILDLIBRARY=='yes'">
    <!-- SSQLS v2 parser convenience library -->
    <template id="ssqlsv2">
      <depends>ssqls2parse</depends>
      <sys-lib>mysqlpp_ssqls2parse</sys-lib>
      <depends>mysqlpp</depends>
      <sys-lib>mysqlpp</sys-lib>
    </template>

    <lib id="ssqls2parse" template="programs">
      <libname>mysqlpp_ssqls2parse</libname>
      <sources>ssx/parsev2.cpp</sources>
      <include>.</include>
      <depends>mysqlpp</depends>
      <sys-lib>mysqlpp</sys-lib>
    </lib>

    <!-- Build rules for ssqlsxlat tool -->
    <exe id="ssqlsxlat" template="programs,ssqlsv2">
      <sources>ssx/genv2.cpp</sources>
      <sources>ssx/main.cpp</sources>



    </exe>
  </if>

  <!-- Define library testing programs' output targets, if enabled -->
  <if cond="BUILDTEST=='yes'">
    <exe id="test_array_index" template="programs">
      <sources>test/array_index.cpp</sources>
................................................................................
    <exe id="test_qstream" template="programs">
      <sources>test/qstream.cpp</sources>
    </exe>
    <exe id="test_sqlstream" template="programs">
      <sources>test/sqlstream.cpp</sources>
    </exe>
    <if cond="BUILDLIBRARY=='yes'">
      <exe id="test_ssqls2" template="programs,ssqlsv2">
        <sources>test/ssqls2.cpp</sources>
        <depends>ssqls2parse</depends>
        <sys-lib>mysqlpp_ssqls2parse</sys-lib>

      </exe>
    </if>
    <if cond="FORMAT!='msvs2003prj'">
      <!-- VC++ 2003 can't compile this -->
      <exe id="test_string" template="programs">
        <sources>test/string.cpp</sources>
      </exe>

Added tools/corecount.



































































































>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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
#!/bin/sh
########################################################################
# corecount - Prints the number of CPU cores found on this system
#
# Copyright © 2017-2018 by Warren Young
# 
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the
# "Software"), to deal in the Software without restriction, including
# without limitation the rights to use, copy, modify, merge, publish,
# distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so, subject to
# the following conditions:
# 
# The above copyright notice and this permission notice shall be included
# in all copies or substantial portions of the Software.
# 
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
# IN NO EVENT SHALL THE AUTHORS LISTED ABOVE BE LIABLE FOR ANY CLAIM,
# DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
# OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
# THE USE OR OTHER DEALINGS IN THE SOFTWARE.
# 
# Except as contained in this notice, the names of the authors above shall
# not be used in advertising or otherwise to promote the sale, use or
# other dealings in this Software without prior written authorization from
# those authors.
########################################################################

sys=`uname -s`
if [ -r /proc/cpuinfo ]
then
	# It's a Linux box, or something that *looks* like one, such as
	# NetBSD, Cygwin, or the Windows Subsystem for Linux.
	grep -Ec '^processor[[:space:]]+:' /proc/cpuinfo
elif [ "$sys" = "Darwin" -o "$sys" = "OpenBSD" -o "$sys" = "NetBSD" ]
then
	# It's a macOS or BSD box
	/usr/sbin/sysctl -n hw.ncpu
elif [ "$sys" = "FreeBSD" ]
then
    # FreeBSD puts sysctl elsewhere
	/sbin/sysctl -n hw.ncpu
else
	# No known way to find out, so report only 1 core
	echo 1
fi

Added tools/mkrel.

























































































































>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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
#!/bin/bash
########################################################################
# mkrel - Automatically merge trunk changes into the release branch
#   for a new public release of the software.  Also tags the trunk with
#   the date of release, so old releases can be easily checked out.
#
# Copyright © 2016-2019 Warren Young
#
# Permission is hereby granted, free of charge, to any person obtaining
# a copy of this software and associated documentation files (the
# "Software"), to deal in the Software without restriction, including
# without limitation the rights to use, copy, modify, merge, publish,
# distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so, subject to
# the following conditions:
#
# The above copyright notice and this permission notice shall be
# included in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
# IN NO EVENT SHALL THE AUTHORS LISTED ABOVE BE LIABLE FOR ANY CLAIM,
# DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT
# OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
# OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#
# Except as contained in this notice, the names of the authors above
# shall not be used in advertising or otherwise to promote the sale,
# use or other dealings in this Software without prior written
# authorization from those authors.
########################################################################

set -e

ggrep=$(which ggrep grep 2> /dev/null | head -1)
ver=$(grep -F so_version mysql++.bkl | $ggrep -Po '\d+\.\d+.\d+')
if [ $? != 0 ] || [ -z "$ver" ]
then
    echo "Failed to extract version info from Bakefile!"
    echo
    exit 1
fi

make=$(which gmake make 2> /dev/null | head -1)
alias f=fossil
f update &&
	( test -z "$(f changes --no-classify)" || f ci -m "Released v$ver" ) &&
	cd ../release &&
	f update release &&
	f merge trunk &&
	test -z "$(f changes --conflict)" &&
	f diff -w --tk &&
	tools/mmake &&
    $make dist &&
    cp mysql++-${ver}.tar.gz ~/tangentsoft.com/mysqlpp/releases &&
    cd ~/tangentsoft.com &&
    $make synch &&
    cd - &&
	f ci --tag v$ver -m "Merged trunk changes for v$ver into release branch"

Added tools/mmake.













































































>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#!/bin/bash
########################################################################
# mmake - Runs make -jN where N is 1.5x the number of CPU cores
#
# Copyright © 2017-2019 Warren Young
#
# Permission is hereby granted, free of charge, to any person obtaining
# a copy of this software and associated documentation files (the
# "Software"), to deal in the Software without restriction, including
# without limitation the rights to use, copy, modify, merge, publish,
# distribute, sublicense, and/or sell copies of the Software, and to
# permit persons to whom the Software is furnished to do so, subject to
# the following conditions:
#
# The above copyright notice and this permission notice shall be
# included in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
# IN NO EVENT SHALL THE AUTHORS LISTED ABOVE BE LIABLE FOR ANY CLAIM,
# DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT
# OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE
# OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#
# Except as contained in this notice, the names of the authors above
# shall not be used in advertising or otherwise to promote the sale,
# use or other dealings in this Software without prior written
# authorization from those authors.
########################################################################

MAKE=make
MAKE=$(which gmake make 2> /dev/null | head -1)

BDIR="$(dirname "$0")"
if [ -z $BDIR ] ; then BDIR="$(dirname "$(which "$0")")" ; fi

$MAKE -j$(($("$BDIR"/corecount) * 15 / 10)) "$@"