In August Productions

Thanks to Jobin's work with mingw and getting libdrizzle to compile on Windows at all, I have been able to get it working in Visual Studio natively. The code is in trunk now.

The approach I took, which is how I'm going to approach Windows and Visual Studio for all of our stuff, is to not worry with analogues to things like configure on Windows. Windows is a very different platform from Linux, and there is no need to attempt to duplicate Linux process there. To that end, the goal at least for now will be static VS Solution files and a set of instructions of how to get depends installed so that the Solution can find them. 

I'm excited to start poking at Garrett Serack's CoApp Project, which has some tools do do tracing of things like make to help with the initial project creation... and I fully expect to take advantage of his work in terms of creating installable packages.

Jobin has started working on Drizzle itself and has the drizzle client working so far.

Baron was just writing about problems with the Debian init scripts. The basic problem boils down to /etc/mysql/debian-start running mysqlcheck on every table.

Kolbe Kolbe and Harrison Fisk pointed this  out to me last February, and as a result I re-wrote the debian-start.inc script to only operate on MyISAM tables. Additionally, the default config was changed to turn on the myisam-recover option, so even for the MyISAM tables, all we do is touch the table to get MySQL to recover it if needed. (Which I promise you, you really want if you're modifying MyISAM tables on a production server. Don't do that, really, but that's another issue.) The new process essentiall looks like this:

for table in `select TABLE_NAME from information_schema.TABLES where ENGINE='MyISAM'":

  select count(*) into @discard from TABLE_NAME 

If the table is MyISAM and is not damaged, the select count(*) will be very, very quick and not noticable. If even this is too much, then just remove the myisam-recover entry from your /etc/mysql/my.cnf file, and the debian-start script should be essentially a no-op.

So while I obviously agree with Baron here about the root problem, I'd suggest that rather than disabling the debian-start script, you upgrade to a recent version of it.  If it's still a problem, ping me and we can talk about improving the script.

I decided I'd be a good sport and try to do some build work for Drizzle on OpenSolaris to make sure we weren't accidentally Linux-ifying something. Nevermind OpenSolaris installing an nsswitch file set up to not use DNS by default. Nevermind OpenSolaris reinventing the wheel for package management rather than starting with a package management system already in use by people (or and then fixing the things . Nevermind the GPL incompatible CDDL license... I'd be a good sport and give it (another) try.
I should add, in all honesty, I really do want OpenSolaris to be good. I think monocultures are bad, and I think Solaris can be useful in the growth of the ecosystem.
Step one. Install bzr.

pkg search bzr

Nothing. Wasn't expecting much. That's ok. Grab tarball. Unpack.
FAIL
Silly me. There is no sudo, so I had become root first (sure - I'm sure there is a better solaris way to accomplish sudo... please provide a sudo command line that accesses the superior solaris tool please?)

tar xvfz bzr.tar.gz

tar: z: unknown function modifier

Must use gtar. Old broken Solaris tar is still default for root user. Pointless. Stupid. Must die.
Ok. Fine. Unpack bzr.

python setup.py build

FAIL
many error messages about ld not working. Something like this:

ld.so.1: ld: fatal: libld.so.4: version `SUNWprivate_4.2' not found (required by file /usr/bin/ld)

Fine. ld is installed but for some reason doesn't work.

pkg install SUNWprivate_4.2

FAIL
That's not a package... After cursing and googling, I finally found this:

pkg install SUNWtoo

THAT certainly makes sense from the error message.
Somewhere in looking for the answer above, I also did:

pkg install gcc-dev

(Notice lovely lack of SUNW prefix) This seems to have installed all of the gcc/automake/autoconf I need. First nice thing... although gcc-dev makes me think it's going to be files to help me hack on gcc... but I'll live with it. It's DEFINITELY the best part of the pkg system so far.
Yay. bzr is installed.
Grab my drizzle tree:

bzr init-repo drizzle
cd drizzle
bzr branch lp:~mordred/drizzle/codestyle

Woot! That works!

cd codestyle
./config/autorun.sh

Woot! That works! Up to date autoconf and automake even! (beating CentOS/RHHEL 5 here... really? autoconf 2.59 and automake 1.9? come on RedHat...)

./configure

Can't find libevent... that's ok. It's a new system.

pkg search libevent

FAIL
silly me. It's SUNWlibevent. How obvious. (Hint to Sun... the legacy Solaris users are not the target audience you should care about if you want new users here... There are many places where Linux has been eating your lunch for years. Package naming is apparently one of them. Fix it. Change. Grow up. Welcome to 2008 )

pkg install SUNWlibevent
./configure

Can't find readline. Sigh. That's less ok. It's a standard lib guys... oh, wait... hrm. CDDL? Anybody remember why it annoys me?
FAIL FAIL FAIL
There is no readline pacakge.
That's ok. I've been doing this for a while... I know where ftp.gnu.org is. (You know, RMS is right ... it IS GNU/Linux that we all run..., with a heavy emphasis on the GNU part.)
Grab readline tarball.
Unpack.
Build.
Install.
Back to drizzle...

./configure

FAIL FAIL FAIL
no ncurses. no ncurses package either.
download. unpack. build. install... (why is there a package manager on this system? )
Back to drizzle.

./configure

no pcre. I can live with that... It's in SUNWpcre

./configure

FAIL
can't find pcre.
#$%@%^@
Whoops. Even though OpenSolaris decides to install pcre headers in /usr/include/pcre, which it includes a pkg-config .pc file specifying, pcre doesn't depend on pkg-config. This is good because...
FAIL FAIL FAIL FAIL FAIL
there is no pkg-config package.
Swear. Curse. Spit. /me punches OpenSolaris in the face.
I KNOW it has to be in there, OpenSolaris is running Gnome after all.
google. read forums. WHERE IS pkg-config??!??1
SUNWgnome-common-devel
Silly me.

pkg install SUNWgnome-common-devel
./configure  # finally works.
make

EPIC FAIL
The final straw for the night... OpenSolaris 2008.05... the most recent release... released this year... 2008... ships with gcc 3.4. From 2004. That gcc 3.4. There is also no gcc4 package. It's not even old gcc4.0... it's gcc3.4.
Sigh.
It's 1AM. I've picked on OpenSolaris enough for one night. I'll give it another go tomorrow.

I was just reading Jan's post about how to write a good build system

I'm in the need for a portable, fast build-system.

While I'm not about to write a build system in lua - or anything else, I thought I'd pitch in my thoughts as I've been having a similar problem recently. The problem is, autotools is the only system that doesn't require some prereq to be installed on the system ... other than a working build system. The only real downside to autotools (other than needing to learn m4) is that it is useless on Windows.

As Jan says, though, the other systems fall down on the make dist part. This is way important to me, as I also work in my tree alot and I really want to have an automated step to make sure I'm packaging up all the files I need, but not too many. This leads Jan to the inevitable choice of building his own

As a matter of fact here I stand without build-system that meets my needs. My current target is building the MySQL Proxy on Linux, MacOS X and win32.

Throwing lua into the game as a nice side-effect: the scripting language is clean and simple. You can also think about adding the lua-src itself to the build-system to do a full bootstrap in case the user doesn't have it install

First problem - if the user doesn't have the build system, and if autotools won't cut it, then how are they going to build the lua-src.

I'd like to point out that most of this is because Windows is crap. The autotools design goal of not requiring user to install a special build system other than Make is a great one. But because Windows can't even manage to ship a decent POSIX environment, this is broken. Ever tried sharing source with someone who's using VisualStudio? Ever get pissed off because there's no way to have the source figure out where a library dependency is without setting some property in the source by hand?

Anyway - I do think Jan is on to something (as usual) but I don't think the whole system needs to be rewritten - just autoconf.

Automake runs on the maintainer's machine, as does autoconf, but the automake output are the Makefile.in files that autoconf replaces stuff in. There's nothing really broken about this. make, make dist, make distcheck should all still work (ok, except on Windows where they don't have tar... my sympathy is low) But if you made a program in lua that created something like a configure script that could be run with minimal install requirements on the client (I think needing lua is ok here - as Jan says, it's easy to install)

That leaves the requirement of producing MSI targets. I think this is a requirement that should be shucked, because it's not an apples/apples thing. MSI files are the same as RPMs or DEBs. They are packaging, not part of the build, and I think if emitting them is part of the needs, then the build system also needs to be able to make debs. Divorce the work of making MSI files from the build and I think the task is really doable in the short term.

I think that the m4 stuff in autoconf is the only part of autotools that people really get annoyed with. So kill it. Replace it with lua. Or python. Or anything that's cross platform and low impact. (and by that I do not mean Java - sorry guys, the nightmare that is installing Java environments is a subject of an upcoming rant)

Powered by ScribeFire.

il corra walks you through building mysql-proxy for ubuntu.
il corra » mysql-proxy on ubuntu 7.04 feisty

First of all, there is not a packetized mysql-proxy for Ubuntu, so the only way to install it is to build it from the source

Which is great. But I'd like to take this opportunity to tell people that I've actually been working on packages for debian/ubuntu. They're almost ready to be released into the wild (I'm waiting on an almost non-related event) If you'd like to play with the packaging stuff before then, check out http://launchpad.net/mysql-proxy
I'll be sure to let everyone know when the packages themselves are in an APT repository.