On Fri, 9 Sep 2005, Michael Stassen wrote:
Hugh,
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
--ps-protocol
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.
Thanks.
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
way.
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
there.
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.]
Michael
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?
Thank you,
Hugh
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
