Alan D. Cabrera wrote:

I'm not sure that we need to choose one over the other. Let me ask you this, why would we need fine grained detail such as "i386 vs. i586 vs. i686"? Is that really necessary?

It is, because code compiled for i686 won't run on an i386, and code written for i386 may not run as effectively as code for i686. One shouldn't make arbitrary restrictions on how specific the platform can be.

I'm not sure why APR would allow such a system dependancy. APR is supposed to make application developers' lives easier. Why would I have to worry about libuuid1 missing? I'm new to APR and am getting my head around what it will and will not do for me.

A bit of history on APR and why it exists.

Way back when, when people tried to make Apache httpd portable to many platforms, the httpd code started getting filled up with endless #ifdefs that said "if this system do this, if that system do that".

To try and return some sanity, an effort was made to herd together all the non portable code in httpd into one single library. That library would offer some portable concepts like (for example) an apr_socket_t instead of an integer socket, and you would not have to care what platform you were on any more, you could just use sockets and take it for granted that they would "just work".

The library that resulted is APR.

Like the JVM itself, APR tries very hard to be portable across platforms, and to do this, it needs to know how that particular platform works so you don't have to.

APR makes your life easier because all you need to do is write code that depends on APR, and (within reason) you no longer have to care exactly how the particular functionality you are using works on that platform. Sockets work differently on Windows? You don't have to care.

The problem is that APR itself *does* have to care how the system works, and about details like libraries that may or may not be installed, so anybody wanting to package APR into a bundle is going to have to worry about these issues.

Imagine if you had to try and package up the JVM and include it in a maven repo, the problems you would face there are similar to the APR case.

Regards,
Graham
--

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to