On Fri, 9 Sep 2005, Michael Stassen wrote:
> I get the same thing on Mac OS X 10.3.9. My thinking was that rather than
> replying with an unhelpful "Me too", I would do some digging and then reply
> with what I found. I realize now that left you hanging (sorry), so I'll
> report what I've found so far.
Ok, thanks for this report, which is in plenty of detail, even if it
is "so far" :-)
> The test suite is broken.
Who guards the guards? :-)
> The archive test is meant to test the archive table engine, but the archive
> engine is not built into mysql by default. You have to add the
> --with-archive-storage-engine if you want it. You didn't do that, so the
I'm not sure what it is, so I probably don't need it.
> archive test should have been skipped.
> With mysql 4.1.12, `make -n test` reveals
> cd mysql-test; ./mysql-test-run && ./mysql-test-run --ps-protocol
> With 4.1.14, that has changed to
> cd mysql-test; perl mysql-test-run.pl && perl mysql-test-run.pl
> Apparently, the test program shell script, mysql-test-run, has been rewritten
> as a perl script, though there is no mention of this in the change log
> <http://dev.mysql.com/doc/mysql/en/news-4-1-x.html>. A quick glance at the
I was rather surpised about the dependency on Perl.
> source shows that the perl script is not finished -- it has quite a few
> commented-out, "fix me" sections.
I'll have a look.
> You still have a couple of options to test your build. You can run the new
> test suite with the --force option. Do what make would do, `cd mysql-test`,
> then `perl mysql-test-run.pl --force`. You will see that every test that
> should have been skipped will instead be run and fail (archive, the bdb
> tests, blackhole, csv, example, func_des_encrypt, isam, the ndb tests,
I'm fairly fluent in perl, though mine's a bit Chaucerian, since I
learned Perl4 :-), and am not *so* familiar with the 5 constructs, but
I could try to send patches (to whom?).
> openssl_1, raid, and so on). If every test passes except for tests of things
> you don't have, you should be OK. In particular, there are a set of innodb
> tests which should answer your question about whether or not innodb is
> working in your build.
> There's a second way, which I think is better. It turns out that the old
> shell-script test suite is still built. Hence, you can still test the old
Yes, and It may be worth trying both.
> cd mysql-test && ./mysql-test-run --force
> This will properly skip tests of features not compiled in. Note that I added
I can probably steal how to skip them and stick that in the Perl.
> --force because, at least in my case, the new embedded test,
> not_embedded_server, is run and fails. I'm not yet sure if that should have
> been skipped.
The errors explicitly told me I needed --force, so that's OK.
> As the old test script is still built and the new test script is unfinished,
> undocumented, and broken, I am suspicious that the real problem is that make
> was prematurely (accidentally?) changed to use the new one before it was
> ready. I've copied the bugs list in hopes of an answer.
Definitely some weirdness about the release process there :-) I'm
sure I've done worse in the past, though.
I'm not subscribed to the bugs list, so this might bounce back off
The third way, I suppose, is to ask whether I'm actually using the
correct version -- should I be on 4.1,x, or 4.0.x, or what? I'm under
the impression that for work with Ruby on Rails I need the latest
4.x but I could have misunderstood something. What I really mean
is: which versions are considered stable? [Ruby has a custom that
minor release numbers are odd for developement, even for stable, but
minorminor ones increment successively after that: 1.8.2, and 1.8.3
(due soon) are stable, 1.9.x is development (at present). I'm not
sure how things work in the MySQL world.]
> P.S. Out of curiosity, why did you find it necessary to edit
> BUILD/compile-solaris-sparc? Couldn't you make the changes you wanted with
> options to configure?
I was passing options to configure, and the was a bit of setup in
compile-solaris-sparc that was probably there for a reason. So I
changed it there. I changed it to give me the alternative port and
directory so I don't munge things for people using V3.x, used for
teaching. [Besides, I'd have to mess with autoconf to fix configure
properly, as it is setup by that, and I'm not so fluent in autoconf
as I'd wish, plus it seems silly to mod the autoconf stuff for
something so parochial as port + directory.] Maybe there's a better
place altogether to define this stuff?