Slashdot Mirror
APR 1.0.0 Goes Gold
cliffwoolley writes "After several years of development, the Apache Portable Runtime, which is the portability library underlying the Apache HTTP Server 2.x, has finally reached its own 1.0.0 release. If you want to write a portable app without the headaches, APR is the way to do it. Grab a copy and check it out. The full announcement is here."
Any comparisons out there between APR and things like SDL?
APR is for servers, SDL is for games.
this a C library, not a virtual machine/language like jvm/java. the idea is not to have code run without recompile on all platforms, but rather that *all* you need is a recompile. more specifically, you don't need to have platform specific cases in your code. code becomes pretty unmaintainable when it is littered with #ifdefs
BSD is for people who love UNIX. Linux is for those who hate Microsoft.
But SDL provides cross-platform threading and such. It's been used in many things other than just games (which is why it's not just sound and video)
Disconnect and self-destruct, one bullet at a time.
glib didn't exist at the time the APR was started. Also glib is still not quite useful on windows.
You have the wrong idea of what APR is.
/dale
APR is a library which, at its basic level, provides wrapper functions to syscalls of many different operating systems. Why? because the same syscall on one OS sometimes behaves differently, have bugs, or take slightly different arguments from the same syscall on other OSes.
APR addresses these differences and provides you, the app developer, with a common set of functions.
So if you're say coding your own FTP server project and you main development platform is linux or what have you, if you use APR's wrtite() or APR's sendfile(), you know that your call to that will also work on Solaris, FreeBSD, Darwin, etc... because APR takes care of all the abstraction at compile time.
This is a C library that provides cross-platform compatibility with respect to file IO, threading, and other fundamental actions. It is not a virtual machine!
That is *exactly* the sort of stuff glib was intended for, to wrap system calls on specific platforms and provide a cross-platform API for basic syscalls. It was the low-layer abstraction of cross-platform things GTK/GDK needed, and has grown from there.
XML is like violence. If it doesn't solve the problem, use more.
First of all, APR is not a virtual machine or bytecode interpreter like that of .NET common language runtime or JVM. APR is a library (collection of functions) written in C, for C programs. It contains a lot of wrappers to the real standard C library functions, because some conventions of standard library still varies from OS to OS.
For example, the path separator is different in Unix ("/"), Windows ("\"), MacOS (":" - pre X, but also Finder in OS X). Another example is loading dynamically linked libraries (DSO in APR speech). Yet another example is threads.
Besides wrappers, APR has its own memory management routines. APR also adds utility functions not found in the standard library, such as hash table.
By the way, it would be helpful if someone can post a comparison between NSPR (netscape portable runtime) and APR.
I once had a signature.
Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. It is used by MPEG playback software, emulators, and many popular games, including the award winning Linux port of "Civilization: Call To Power."
Simple DirectMedia Layer supports Linux, Windows, BeOS, MacOS Classic, MacOS X, FreeBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. There is also code, but no official support, for Windows CE, AmigaOS, Dreamcast, Atari, NetBSD, AIX, OSF/Tru64, RISC OS, and SymbianOS.
SDL is written in C, but works with C++ natively, and has bindings to several other languages, including Ada, Eiffel, Java, Lua, ML, Perl, PHP, Pike, Python, and Ruby.
---
It's too bad someone hasn't yet taken the effort to integrate all of this stuff into a super library for GUI, networking, io, threads, email, video, blah blah blah...
---
Well, I and others have built HTTP servers using just the sockets provided in wxWidgets - and it's not that difficult.
As for email - you've got wxSMTP
http://www.frank-buss.de/wxwindows/
Also, one of the core developers wrote an entire cross-platform e-mail program with it
http://mahogany.sourceforge.net/
In addition, wxWidgets supports everything you mentioned except video - however, there is a lot of development in that area at the moment... there is a contrib that does this for windows, and there are already a couple of competing libs to do it on mac - linux of course is a different story since native libs don't support it.
In fact, if you use it with allegro (alleg.sourceforge.net) you have a fairly complete solution for pretty much anything.
I think you've got that backwards. APR requires gmake, automake, autoconf and libtool to build. You can build those things without APR.
apr-0.9.4_9
The Apache Group's Portability Library
Maintained by: rodrigc@crodrigues.org
Requires: autoconf-2.59_2, automake-1.8.5_2, expat-1.95.8, gettext-0.13.1_1, gmake-3.80_2, libiconv-1.9.2_1, libtool-1.5.8, m4-1.4.1, perl-5.8.5
APR and GLib have slighlty different design goals. GLib is the low-level of GTK (desktop environment) and APR is the low-level library of Apache 2 (server-side).
So APR was designed to work in servers: it has support for memory pools, filesystems routines, network lacking in GLib. But GLib has support for GObjects, signals which are used heavily in GTK.
So if you're writing a portable server-side application in C/C++ then APR is for you.
PS: Subversion (the great VCS) uses APR.
Unfortunatly g++ is not a good c++ compiler so all the Unix nerds look at the size of the compiled program and time to execute and assume the problem is with C++ itself and then continue to work in C.
There is alot of anti c++ sentiment in the unix community because of that.
http://saveie6.com/
By my reading of the liscence, it makes absolutly no distinction between static and dynamic linking. Therefore, the only way that it could cause a difference is within the definition of a 'derived work'. To quote the licence:
If you link, or bind by name, to the interfaces of the Work, then your code is not a derived work. Thus, the only applicable terms in the licence are those that govern use and distribution of the code. The licence grants you the right to distribute in source or object form the work.
Accordingly, my reading is that this is semantically virtually equivlent to the BSD licence for case specified (and, in fact, the same as BSD for pretty much any case of use and distribution).
Short answer: Stick a mention of it in the NOTICE text file, tell people what liscene the Work (in this case the APR) was under, and go ahead.
Interestingly, this licence would, as I read it, allow you to make a derived work, and redistribute that in binary form only. It doesn't grant you the right to change liscence, or apply restrictions, so a Derived Work wouldn't work as a commerical product (as the first purachaser can redisribute it).
But, as it specifically excludes linking to the interfeces specified, then for a Work which is a library [0], the only clause that imparts any restriction is 4(d) [1]
In fact, I can see no part of the liscence that would prevent one from taking a program under this liscence, creating a Derived Work that is that program implemented as a library, with well defined interfaces, and then linking to said library from a commercial/closed program. There is no requirement to publish Derived Works [2]. The only mildly non-obvious outcome is that if the library was extracted from the final disribution, the licence allows for its free distribution and use, which is not a restriction.
Of course, if this is for commerical software, you'll have the money to speak to a lawyer licence to practice in your juristriction first.
[0] And where that library is used unmodified
[1] And the expiration of patent licences in event of you issuing a patent suit.
[2] Only that you make any changes clear if you do publish.
NSPR, ACE, and the wxWidgets toolkit are all for C++. APR is for C. About the only thing that comes close is glib, and it's actually a pretty poor fit on non-unix platforms.
Actually Subversion trunk can already build against APR 1.0.0. We had a lengthy discussion about this a while back. I'm not sure we ever really resolved it. But the general consensus seemed to be that enforcing majors of our dependency to always be the same wasn't something we were enforcing binary compatability for.
I.E. Subversion's compatability guarantees are only good to the degree that you don't go changing major versions of the libraries.
You are correct that Apache 2.0.x will continue using APR 0.9.x, but Apache 2.2.x (currently called 2.1.x) will use APR 1.0.0. If we enforce the major of APR we can only function with Apache 2.0.x, which is not a requirement we really want to limit ourselves to.
BOOST certainly deserves mention