Saturday, November 27, 2010

Perl is probably a fine scripting language, but on Windows...

Please do not assume Perl is always installed on all platforms. In particular not on Windows! Just as it is probably a bad idea to assume that Windows DOS commands work on Linux! Come on now!

Why am I making a fuzz you ask, do I have a problem with you writing stuff in Perl (personally, I don't even like Perl, but that's another issue)? Nope. But somewhat modern software really should not assume that you have Perl, or DOS, or some other arcane, not terribly standardized piece of software around for a server to do it's job. And MySQL still have a way to go to be reasonably good on Windows. Downloading the lastest RC, 5.5.7, MySQLhas managed to screw up at least two things, at least, in my mind. But maybe that's just me:

  • The optimzied. non debug libraries, are now in /lib under the distribution, not in /lib/opt where they used to be. I see no good reason for this, to be honest (place the libraries where you want, of course, but once a release is out, don't move them around at random in upcoming releases). This has been reported as bug #58532
  • To make it realhard for us in the community to test this release Candidate version of MySQL, to iron out the bugs, MySQL decided not to include dynamic debug client libraries, only the static ones. Why this makes things difficult, you have to do some development on Windows to userstand. For a bunch of reasons (not necessarily good reasons, but if you are Microsoft, you are allowed to do whatever you choose, no reason needed, except that maybe it's the 7th hour on the 7th month and it's afull moon coming up or something), Micosoft compiles stuff so that a static library depends on stuff included by the compiler itself. So if the compiler version changes, the library will not work properly anymore. In short, you need to build your applications with the same version of Visual Studio as the MySQL Client library was built with. Yikes! (For more Yikes, see MySQL bug #58531)
None of this is any fun. And to add insult to injury, in the bin directory of the MySQL distribution on Windows, in 5.5.7, I find the following files: mysql_config.pl, mysqld_multi.pl and 4 more. Yes, Perl programs. No, I do not have Perl install on my Windows boxes. I'm about to test this and see how it worls aout. Above all, I want to test if mysql_config works as expected.

All in all: Please remove Perl depenent client programs from the MySQL distribution! And mysqld_multi seems rather superflous on Windows in general, if you ask me (not that it even works, check bug #58553).

/Karlsson

9 comments:

szabgab.com said...

Or they should distribute their own version of Perl with every installation of MySQL just as Oracle does. Oh wait, MySQL is Oracle now.

Peter said...

Scripting on Windows should use Windows *Powershell* available in recent Windows.

-- Peter Laursen

Roland Bouman said...

Peter,

powershell is no included by default in windows versions prior to Windows 2008R2 server and Windows 7.

Many people are still on XP, Windows 2003 and 2008 Server. Personally, I don't think it's a good idea to add a dependency on powershell yet.

Karlsson said...

If MySQL wants to ship Perl scripts, then I agree that MySQL should also include a Perl interpreter. Which is not to say that the Perl scripts would work. And why there are only 2 Perl scripts with the 64-bit version of the same MySQL version for Windows still confuses me. Like mysqld_multi.pl what A) doesn't work (see bug #58553) and B) is pretty useless (on Windows, whereas on other platforms it's just buggy and confusin) anyway.

wlad said...

Anders, things you mentiondo have a rationale. If you look exactly an how standalone packages are structured on Windows and everywhere else, now Windows packages are much more similar all another platforms. There is no "opt" directory because it is not there anywhere else. There is no debug shared library because it is not there everywhere else.

There *is* a debug static client library, even if it is not there anywhere else, just to give people a chance to avoid link error when they happen to compile with static debug CRT (VS2008) and with static client library.

Re. perl stuff, is it really important? I do not know if those scripts were included prior, I have not checked, but this stuff is in source code repository for ages, and MySQL has at the moment nothing better to offer for these scripts on Windows. There was never a better version of say mysql_install_db . There was one shell script and there was one perl script. I'd argue perl is not as embarassing as shell scripts on Windows, right?

Karlsson said...

wlad!

Right, Perls scripts of current MySQL are not as bad as the shell scripts MySQL used to ship. Moving things around between releases though, I think is completely innecessary. And if the rationale behind there not being an "opt" directory is that there is none of those on other platforms, let me tell you that it has net been like that on other platforms before, but that there HAS been an opt directory on previous Windows distributions of MySQL!
The same goes for the debug DLL. Is used to be there with MySQL on Windows before, but not in 5.5. As a Windows user, I don't care much how things look at Windows Linux or something like that.
Now, none of this would be a big issue if mysql_config works, but it doesn't on Windows, unless you have Perl installed, which I am NOT going to assume people have on Windows.
MySQL Windows compatability was supposed to get better, but I'm not seeing it, which is the whole deal here. Debug DLLs used to be there, now they are gone. With disregard for existing users/application on Windows, libs have been moved around compared to previous MySQL versions on Windows, and the Perl scripts are still there and some still don' work. And there are different Perl scripts on 64 and 32 bit platforms also? Why, I do not know.

/Karlsson

Mark Grennan said...

Don't pick on PERL. Your beef really seems to be with distributions reluctance use native tools are provide the necessary parts to complete your project.

This has been a frustration for all time. Do you include the functions in the code or a library? Do you rewrite the script in Shell, Perl, Python, Power Shell or DOS Batch? Will the user be caught in "dependency hell"?

I guess what I really want to say is, get over it. These sort of problem is why we get paid the big bucks.

Karlsson said...

Mark!

Oh, for myself, I don't have a big problem here. And Perl is in and of itself not the problem, I'm not picking on Perl here. And in all honsesty, if you are a Linux / Unix user (which I have been close to 30 years), then Perl is no surprise.
But in this case, it makes cross-platform troblesome, some features (like mysql_config) doesn't work properly and all in all, this will aleniate Windows only users. And I want everyone on the MySQL train, not only the hardcore Linux folk who, reluctantky, prts an app to Windows, and want Windows to look at much as Linux as possible.

/Karlsson

water outbreaks said...

I don't see the issue with the perl scripts. If somewhere before you downloaded mysql for windows, it told you it had some scripts included that required perl, or even had the installer ask you if you wanted perl, wouldn't that be ok? Perl is a fine cross platform scripting language. Its just as good on Windows as it is in gnu/linux.