autotools runs
- Fix recognition of --with-debug=full in configure wrapper
- Remove CMakeCache.txt in configure wrapper, to match the original
- Fix recognition of max-no-ndb
- Fix broken dependencies of mysql_fix_privilege_table.sql from 
  mysql_system_tables.sql and mysql_system_tables_fix.sql
- Add "distclean target" that informs user about appropriate bzr command

suffer. The problem was that when custom C flags were defined with in environment 
variable CFLAGS, WITH_DEBUG did not have any effect. Also, switch from 
WITH_DEBUG=ON to WITH_DEBUG=OFF   was not handled correctly .Expected is switch 
to with RelwithDebInfo or when custom compiler flags  are defined, to None.

Fixed the missing initialization of locker_lost.

This fix is not strictly necessary, but is desirable to re-align the code
from 5.5 and 6.0, and reduce the spurious code differences.

This will facilitate maintenance and help to apply patches cleanly, for merges.

Followup: Changes in sys_vars test suite

  mysql-test/suite/sys_vars/r/optimizer_search_depth_basic.result
    Added warnings.

into mysql-next-4284 tree.

into mysql-next-4284.

restoring the maximum of slave_net_timeout as defined
#define LONG_TIMEOUT ((ulong) 3600L*24L*365L)

      
Add deprecation warning when variable optimizer_search_depth is given
the value 63.
      
  mysql-test/r/greedy_optimizer.result
    Updated with warning text.
  mysql-test/r/mysqld--help-notwin.result
    Updated with warning from mysqld --help --verbose.
  mysql-test/r/mysqld--help-win.result
    Updated with warning from mysqld --help --verbose.
  sql/sys_vars.cc
    Added an update check function to the constructor invocation for
    the optimizer_search_depth variable. The function emits a
    warning message for the value 63.

into mysql-next-4284 tree.

Fixed failed assert on 64 bit platforms, introduced by the previous fix.

mysqld: sys_vars.h:125: Assertion `size == sizeof(T)' failed.

    Since 5.5 FLUSH TABLES requires unlocked tables so the old LOCK TABLES/FLUSH TABLES
    model fails. Use atomic FLUSH TABLES WITH READ LOCK instead.

per-file comments:
  scripts/mysqlhotcopy.sh
Bug#42465      mysqlhotcopy fails with "Table '<y>' was locked with a READ lock" error message.
     Use FLUSH TABLES WITH READ LOCK instead of LOCK TABLES / FLUSH TABLES pair.
     Keep the old scheme for older servers.

a small refinement to the test

There was auto-reconnecting by slave earlier than a prescribed by slave_net_timeout value.
The issue happened on 64bit solaris that spotted rather incorrect casting of 
the ulong slave_net_timeout into the uint of mysql.options.read_timeout.

Notice, that there is no reason for slave_net_timeout to be of type of ulong.
Since it's primarily passed as arg to mysql_options the type can be made
as uint to avoid all conversion hassles.
That's what the fixes are made.
A "side" effect of the patch is a new value for the max of slave_net_timeout
to be the max of the unsigned int type (therefore to vary across platforms).

Note, a regression test can't be made to run reliably without making it to last over some 
20 secs. That's why it is placed in suite/large_tests.

on Windows".

On platforms where read-write lock implementation does not
prefer readers by default (Windows, Solaris) server might
have deadlocked while detecting MDL deadlock.

MDL deadlock detector relies on the fact that read-write
locks which are used in its implementation prefer readers
(see new comment for MDL_lock::m_rwlock for details).
So far MDL code assumed that default implementation of
read/write locks for the system has this property.
Indeed, this turned out ot be wrong, for example, for
Windows or Solaris. Thus MDL deadlock detector might have
deadlocked on these systems.

This fix simply adds portable implementation of read/write
lock which prefer readers and changes MDL code to use this
new type of synchronization primitive.

No test case is added as existing rqg_mdl_stability test can
serve as one.

Extend and implement the grammar that allows to FLUSH WITH READ LOCK
a list of tables, rather than all of them.

Incompatible grammar change:
Previously one could perform FLUSH TABLES, HOSTS, PRIVILEGES in a single
statement.
After this change, FLUSH TABLES must always be alone on the list.
Judging by the test suite, however, the old extended syntax
was never or very rarely used.

The new statement requires RELOAD ACL global privilege and
LOCK_TABLES_ACL | SELECT_ACL on individual tables.
In other words, it's an atomic combination of LOCK TALBES <list> READ
and FLUSH TABLES <list>, and requires respective privileges.

For additional information about the semantics, please
see WL#5000 and the comment for flush_tables_with_read_lock()
function in sql_parse.cc

Before this fix, the performance schema file instrumentation would treat:
- a relative path to a file
- an absolute path to the same file
as two different files.

This would lead to:
- separate aggregation counters
- file leaks when a file is removed.

With this fix, a relative and absolute path are resolved to the same file instrument.

into mysql-next-4284 tree.

mysql-next-4284.

mysql-next-4284 tree.

The problem was that ALTER TABLE on a merge table which was locked 
using LOCK TABLE ... WRITE, by mistake gave 
ER_TABLE_NOT_LOCKED_FOR_WRITE.

During opening of the table to be ALTERed, open_table() tried to
get an upgradable metadata lock. In LOCK TABLEs mode, this lock
must already exist (i.e. taken by LOCK TABLE) as new locks of this
type cannot be acquired for fear of deadlock. So in LOCK TABLEs
mode, open_table() tried to find an existing upgradable lock for
the table to be altered.

The problem was that open_table() also tried to find upgradable
metadata locks for children of merge tables even if no such
locks are needed to execute ALTER TABLE on merge tables.

This patch fixes the problem by making sure that open tables code
only searches for upgradable metadata locks for the merge table
and not for the merge children tables. 

The patch also fixes a related bug where an upgradable metadata
lock was aquired outside of LOCK TABLEs mode even if the table in
question was temporary. This bug meant that LOCK TABLES or DDL on
temporary tables by mistake could be blocked/aborted by locks held
on base tables with the same table name by other connections.

Test cases added to merge.test and lock_multi.test.

Attempts to execute RESET statements within a transaction that
had acquired metadata locks, led to an assertion failure on 
debug servers. This bug didn't cause any problems on release
builds.

The triggered assert is designed to check that caches are not
flushed or reset while having active transactions. It is triggered
if acquired metadata locks exist that are not from LOCK TABLE or
HANDLER statements.

In this case it was triggered by RESET QUERY CACHE while having
an active transaction that had acquired locks. The reason the
assertion was triggered, was that RESET statements, unlike the
similar FLUSH statements, was not causing an implicit commit.

This patch fixes the problem by making sure RESET statements
commit the current transaction before executing. The commit
causes acquired metadata locks to be released, preventing the
assertion from being triggered.

Incompatible change: This patch changes RESET statements so
that they cause an implicit commit.

Test case added to query_cache.test.

The problem was incorrect escaping used inside a strnig : in \"$MYSQLD\" was written as "\MYSQL\" 
(backslash and quote characters transposed), when defining FIND_PROC  variable for BSD or SysV
style "ps" command-

Additionally fixed obvious code duplication and random naming in CHECK_PID test.

           bool MDL_context::try_acquire_lock(MDL_request*)

This assert was triggered in the following way:
1) HANDLER OPEN t1 from connection 1
2) DROP TABLE t1 from connection 2. This will block due to the metadata lock
held by the open handler in connection 1.
3) DML statement (e.g. INSERT) from connection 1. This will close the table
opened by the HANDLER in 1) and release its metadata lock. This is done due
to the pending exclusive metadata lock from 2). 
4) DROP TABLE t1 from connection 2 now completes and removes table t1.
5) HANDLER READ from connection 1. Since the handler table was closed in 3),
the handler code will try to reopen the table. First a new metadata lock on
t1 will be granted before the command fails since the table was removed in 4).
6) HANDLER READ from connection 1. This caused the assert.

The reason for the assert was that the MDL_request's pointer to the lock
ticket was not reset when the statement failed. HANDLER READ then tried to
acquire a lock using the same MDL_request object, triggering the assert.
This bug was only noticeable on debug builds and did not cause any problems
on release builds.

This patch fixes the problem by assuring that the pointer to the metadata 
lock ticket is reset when reopening of handler tables fails.

Test case added to handler.inc

Crash happens in dlopen() code when trying to load the library. Crash does not happen when library is 
not DTrace instrumented . Additionally, crash does not happen with default Solaris 10 GCC 3.4.3 and
it does not happen if main executable is instrumented.

So , just check for this specific situation (32 bit, GCC3.4.6 , Solaris) and disable Dtrace in shared libraries.
We have only single plugin so far that is instrumented (ha_example)

    Two problems addressed here:
       Embedded-server linking failure.
          sql/sys_vars.cc absents in the libmysqld/CMakeLists.txt
       The PERFORMANCE_SCHEMA-related failure of the embedded-server compilation.
          We try to disable the PERFORMANCE_SCHEMA in the embedded server
          as it's considered useless there. But we do it in wrong way as
          we only disable header's links to the PF, not the PF's library itself.
          So on Unix-ex the embedded library still contains the PF code and
          grows bigger with no reason. On Windows that just fails to compile.
             
per-file comments:
  include/my_global.h
Bug#41103      6.0 Windows embedded-server tests fail
      No PERFORMANCE_SCHEMA disabling in the embedded server. User can
      just use the --without-perfschema-engine-plugin option to exclude it
      from the compilation.