Wow, I'm actually writing something here; already at the second post :)

I feel obligated to put a quick view of EDE we are working on now. That view is about differences with old, efltk powered version, architectural changes and so.

I sumarized some things before. Some of them changed, some not (so there is no need to write about latter). The biggest change (from EDE 1.x) is that famous switch to FLTK 1.x and integrating freedesktop.org standards. This maybe sounds "no too much", but these short sentences are often proved to be opposite. And it is.

EDE 1.x was so tied to eFLTK (which extended FLTK just for EDE needs) that doing simple "compile on FLTK" was simply impossible (since eFLTK was based on first versions of FLTK 2.0, API-s between 1.x and that 2.0 was very much the same, but under the hood, mostly layouting code was totaly different; later FLTK 2.0 API went crazy which is story for itself). Now you see why I put "impossible".

That was clear indication that we should either dig into eFLTK and remove GUI parts (because you know, we would use FLTK 1.x that already provides it) or to start things from scratch, learning from eFLTK what we need and what not. As you guess, we went to latter; now you should have a clue what is edelib module on repository.

Basically, edelib is what FLTK does not provides (which is good or it would be too boring) and what we don't like in it. Plus things we would like to have. And plus freedesktop.org specific things. Enough said.

Here is the one curiosity: EDE had a library named edelib once, which had also needed things for EDE; later it evolved into eFLTK. I'm not sure why; probably due FLTK 2.0 "never-released" curse or else, since I was not part of the project then. Original edelib code was lost when I did a major CVS cleanup which had a tons of started but never finished programs. Probably I made a mistake; probably I should moved everything in a separate module for history reasons, but I can't recall why I didn't. The only thing I know is I had it on my hard drive, which died long time ago.

But, believe me or not, name of the current edelib wasn't choosen due history; it simply popped up, probably inspired by kdelibs for KDE (Vedran when joined to EDE did some work for KDE so you know where inspiration could came from).

So, due those history reasons (and to follow EDE versioning), current edelib is tagged at 2.0.0 version. Just in case you starts to ask when we released edelib 1.0 :)

Second major chaged (or third, lost in counting) is that we are using Jam. I never liked automake; in EDE 1.x we had our own build system, much more like FLTK have and was very limited. You couldn't say "give only to foo.cpp -D_BLA_ flag" nor "link edewm with libdemo_debug.so but the rest with libdemo.so" without writing make code, which is a good chance to yield unportable code between implementations even in the simplest form.

Ah yes, our build system used "recursive make feature", mostly because is very easy to write it without complicating the matter. So, we managed to learn how this was bad when obvious changes in the source files wasn't registered and rebuilded (see Recursive Make Considered Harmful for more info).

Jam does not have these problems; hey, it even allows you to write own, sane "build library" (example is autojam) and to overwrite builtin functions (in jam vocabulary it is a "rule"). Not everything is very bright: jam introduce it's own way of managing dependencies, which is pretty alien to "make commers"; documentation badly sucks giving incomplete information about latter (which is very, very bad since your project will not be built)...

But, small source size (binary too), easily hackable code (I think so), speed (did I mention how it is fast!), damnit good per target (file, target, pseudo target, soon-to-be-generated-file, just name it) options (set per target variables, call functions, etc.) are good arguments to forget flaws. And you don't have to run "makedepend" since it will scan every header in given build files automatically.

I'm lacking of inspiration; remained stuff I will try to finish next time.