As 5.1 series are to be unmasked shortly: I'm on x86, storage/innodb_plugin/plug.in adds '-prefer-non-pic' resulting in TEXTREL QA on the plugin. configure: WARNING: unrecognized options: --with-row-based-replication, --with-zlib - I think it's self explanatory * QA Notice: USE Flag 'pbxt' not in IUSE for dev-db/mysql-5.1.43 * QA Notice: USE Flag 'xtradb' not in IUSE for dev-db/mysql-5.1.43 seems portage doesn't like the way these are added to IUSE For simplicity sake, let's ignore dodoc warnings for now. Also there are a few warnings about cmake. It's probably caused by calling cmake on a CMakeLists.txt that was not meant to be toplevel. The very least that should be done is changing in storage/innobase/CMakeLists.txt: INCLUDE("${PROJECT_SOURCE_DIR}/storage/mysql_storage_engine.cmake") to: INCLUDE("${CMAKE_SOURCE_DIR}/storage/mysql_storage_engine.cmake") so it finds that file and defines the macro correctly. Adding from the toplevel CMakeLists.txt: CMAKE_MINIMUM_REQUIRED(VERSION 2.6 FATAL_ERROR) IF(COMMAND cmake_policy) cmake_policy(SET CMP0005 NEW) ENDIF(COMMAND cmake_policy) looks like a good idea too.
- configure options fixed (overlay). - USE flag stuff fixed (overlay). Patches please for the cmake stuff, I'm out of my expertise there.
I'll try to cook something up, however: 1. I'm not sure if those two build systems were meant to be mixed (actually, I doubt it, it seems cmake part was added to make things simpler for Windows people) 2. I'm not sure if '--with-plugins' is used properly in the eclass - it's meant to build static plugins (as stated in INSTALL-SOURCE), dynamic are built unless disabled, so perhaps it should be guarded by 'static' useflag 3. as I stated in a few different bugs, eautoreconf is recursive, so for 5.0 series (at least the more recent ones), it was run twice in innodb dir I see you didn't address x86 TEXTREL problem. Also, do you have any idea on this: * size of dev-db/mysql-5.0.84-r1 Total files : 2571 Inaccessible files : 1 Total size : 52559.55 KiB * size of dev-db/mysql-5.1.43 Total files : 4145 Total size : 103591.60 KiB Source tarball is of the same time, smaller, yet at same useflags, it's nearly twice the size.
OK, I should have expected it: most of it is mysql-test dir. So a better question then: is there any reason a 'test' useflag can't be added, that, while unset, would remove that dir at the end of the install ? Unless I'm looking for the wrong string, it doesn't seem any binary is actually hardcoding existence of that dir.
Oh, and unless mysql is using those la files (doesn't look that way, seems to use dlopen directly), you may get a 'flameeyes' bug about it.
(In reply to comment #2) > I'll try to cook something up, however: > 1. I'm not sure if those two build systems were meant to be mixed > (actually, I doubt it, it seems cmake part was added to make > things simpler for Windows people) They are meant to be mixed unfortunately. Later releases of 5.5 are planning to move to pure cmake, but in the meantime, some of the parts that are developed externally are using cmake already, while the main codebase uses autotools still. > 2. I'm not sure if '--with-plugins' is used properly in the eclass > - it's meant to build static plugins (as stated in INSTALL-SOURCE), > dynamic are built unless disabled, so perhaps it should be guarded > by 'static' useflag Checking, I think the upstream build logic on these. I don't see any explicit way anymore to build as dynamic. > 3. as I stated in a few different bugs, eautoreconf is recursive, > so for 5.0 series (at least the more recent ones), it was run twice > in innodb dir Sure of that for 5.1? The ONLY eautoreconf call I see in my output is: === Running eautoreconf in '/dev/shm/portage/dev-db/mysql-5.1.44/work/mysql' ... === And for some versions of 5.0, it's NOT properly recursive. the toplevel call sometimes missed the innobase directory. > I see you didn't address x86 TEXTREL problem. sed in the overlay eclass now. > Also, do you have any idea on this: > * size of dev-db/mysql-5.0.84-r1 > Total files : 2571 > Inaccessible files : 1 > Total size : 52559.55 KiB > * size of dev-db/mysql-5.1.43 > Total files : 4145 > Total size : 103591.60 KiB > Source tarball is of the same time, smaller, yet > at same useflags, it's nearly twice the size. The testsuite got bigger. We've always installed the testsuite in the past. No binary depends on it, but it's very useful to validate your configuration. I added it's removal unless USE=test exists now.
Yes, for 5.1 there's no additional autoconf file, so no recursive entry in toplevel configure.in and it called only once. I've mentioned 5.0, as I've been mentioning it in other bugs. However, I'm nearly certain you're wrong about that cmake thing, at least as far as storage/innobase dir goes - there is a chain of automake files leading into it (at least in 5.1.43 tarball). I'll test it. As for dynamic plugins, unless they've documented it wrong, if they're build dynamic by default, if only static is available, by default it's not built, UNLESS it's listed among '--with-plugins'. Unless you want to disable specific plugins, default should work.
Well, tests seem to confirm my idea. However, not only extraengines useflag is currently broken (it's logic needs to be reversed - probably: if ! use extraengines for i in ${plugins} myconf="${myconf} --without-plugin-${i}" fi if I understand the docs correctly), but it seems that section for innobase and innodb_plugin needs to be removed, as otherwise innobase is probably built only as static and linked into server (I've actually gained /usr/lib/ha_innodb.so* and /usr/lib/mysql/plugin/ha_innodb.* files when I've commented out that section).
Short of cmake patches and information from upstream, nothing further is going to happen on this yet. 5.1.44 is going to ~arch now. (In reply to comment #6) > Yes, for 5.1 there's no additional autoconf file, so no > recursive entry in toplevel configure.in and it called only once. > I've mentioned 5.0, as I've been mentioning it in other bugs. So RESO-FIXED for 5.1 already. > However, I'm nearly certain you're wrong about that cmake thing, > at least as far as storage/innobase dir goes - there is a chain of > automake files leading into it (at least in 5.1.43 tarball). I'll test it. Patches for cmake stuff then, but it's not actually broken at the moment, merely QA-fail and ugly. > As for dynamic plugins, unless they've documented it wrong, > if they're build dynamic by default, if only static is available, > by default it's not built, UNLESS it's listed among '--with-plugins'. > Unless you want to disable specific plugins, default should work. Earlier in 5.1.x they defaulted to off, with --with-plugins=X causing dynamic, and --with-plugin-X causing static. The new automagic behavior is worse IMO, as you need to know what plugins exist, rather than being able to say: Turn off everything EXCEPT the following which should be built as static/dynamic. I'm discussing with upstream already, will probably be in the form of --with-plugins=$X:$mode,... or --with-plugin-X=[static|dynamic]. Not touching it yet because of that. (In reply to comment #7) > Well, tests seem to confirm my idea. > > However, not only extraengines useflag is currently broken > (it's logic needs to be reversed - probably: > if ! use extraengines > for i in ${plugins} myconf="${myconf} --without-plugin-${i}" > fi > if I understand the docs correctly), > but it seems that section for innobase and innodb_plugin > needs to be removed, as otherwise innobase is probably built > only as static and linked into server > (I've actually gained /usr/lib/ha_innodb.so* > and /usr/lib/mysql/plugin/ha_innodb.* files > when I've commented out that section). Due to the need to do LOAD PLUGIN ... with the above, we're going to KEEP base innodb and myisam built-in always, otherwise an upgrade from 5.0 to 5.1 will break. The rest can potentially move to dynamic once the issues above are resolved. The following engines I'm strongly considering having always-on: archive, blackhole, csv, innodb_plugin In addition to the existing: heap, myisam, myisammrg That leaves the following as optional: partition, example, federated These will be disabled: ndbcluster (per upstream requests to move it to mysql-cluster package with different sources).
What I'm trying to say is that given these lines of build log: config.status: creating storage/innobase/Makefile config.status: creating storage/innodb_plugin/Makefile whatever you're trying to do with cmake is redundant for 5.1.43 (whole 5.1 series perhaps) - cmake only creates Makefiles and those from configure will overwrite cmake ones. Those cmake lines should probably simply be removed (from 5.1 part of the eclass). Perhaps it's different in the later series. There's also a concept of sort-of toplevel CMakeLists.txt (one in topdir) - it's not as strict as toplevel Makefile.am, but those warnings came from ignoring that fact. As for the engines - you're the expert on mysql here. Also, I agree with that bit about logic. So, innobase is meant to be builtin, same for innodb_plugin ?
(In reply to comment #9) > What I'm trying to say is that given these lines of build log: > config.status: creating storage/innobase/Makefile > config.status: creating storage/innodb_plugin/Makefile > > whatever you're trying to do with cmake is redundant for 5.1.43 > (whole 5.1 series perhaps) - cmake only creates Makefiles > and those from configure will overwrite cmake ones. > Those cmake lines should probably simply be removed (from 5.1 part > of the eclass). Perhaps it's different in the later series. Ah, I'll try that shortly. > There's also a concept of sort-of toplevel CMakeLists.txt > (one in topdir) - it's not as strict as toplevel Makefile.am, > but those warnings came from ignoring that fact. > > As for the engines - you're the expert on mysql here. > Also, I agree with that bit about logic. > So, innobase is meant to be builtin, same for innodb_plugin ? innobase builtin, innodb_plugin dynamic only, but always compiled (I missed it in my list previously).
Don't forget to fix plugins="csv,myisam,myisammrg,heap" too, as now all of those are builtin, not plugin - hard to tell which ones were intended. On a semi-related note: would be nicer, if innobase and innodb_plugin had different messages in configure output, so you could distinguish one from the other.
cmake stuff and engines should be more commented/cleaned now, reopen if needed.
