Click to See Complete Forum and Search --> : Inkscape Deps


madcompnerd
04-09-2005, 01:53 PM
Alright, am I crazy here or are the inkscape dependencies a little rediculous? It needs:
libsigc++ (this is probably pretty inescapable for some reason).
garbage collector (Come on!)
gtkmm/glibmm (this one actually is the most annoying, because gtk's c libraries aren't hard to use at all in c++, maybe a little inconvenient but I just have never understood the use of gtkmm.)

Anyway, I've spent about 2 hours today (actually about 30 minutes of my time, lots of compiling) trying to install inkscape today because RHEL doesn't seem to provide any of their dependencies; so I decided to just build them. I still haven't finished, but I'm running out of things to do while I watch it compile.
The one that gets me the most is the garbage collector. To me, if you need so many deps to make development easier, why not just not use c++? I suppose they wanted c++ so they could have quick algorythms to handle the image work, maybe that's why?

Inkscape is a cool app, but I don't know why they made an autopackage for it when it's such a pain to get all the deps anyway, heh..

Am I the last guy out their who believes shared libraries are for saving people memory usage, easing distribution (legally and bandwidth), and speeding things up? Is it all for making development a little bit easier by alleviating you of the terrible burden of using free(void*) and the delete operator?

/rant

bwkaz
04-09-2005, 08:54 PM
GC is why so many people like Perl, Python, and PHP. And Lisp, although there aren't scores of them like there are for Perl, Python, and PHP. Maybe also Java, although Java is way too hyped to know for sure right now.

Heck, and VB, for that matter. Even though you don't get true GC until VB.Net (the GC in VB <=6 is much closer to what happens in C++ when a stack variable goes out of scope), it's so buried in VB <=6 that you don't have to worry about it, which is close enough.

It may not be hard to remember to free() a pointer in small programs, but when you start making programs the size of OpenOffice, it really becomes tedious to have to include all that boilerplate code. It's very difficult to go back to having to worry about freeing (or deleting) variables once you've gotten used to something like Lisp or Python where you don't have to bother, which may be why the author uses that library.

madcompnerd
04-09-2005, 09:57 PM
This is what products like valgrind are for. Do the best you can to free, and when you miss some you'll see it in testing and can reasonably find and clear major leaks.

It's not that hard, it's just harder than not doing it. I remember my second semester programming teacher talking about the buggy c++ collectors, but I didn't realize many people actually used them. I wonder though if they put it in and then try to free but it's just there for the occasional spots they forget.

Personally, I found things like dynamic datatypes to be attractive when I used php. If I wanted to go from string to int I just used it as either, and it converted it sensibly with no questions asked.

madcompnerd
04-09-2005, 09:59 PM
Turned out that GC was the easiest dep to resolve. Gtkmm was the most obnoxious, especially since it required 2.4.. That and the fact that it took me an hour to build gtkmm, surprising and not surprising at the same time heh.

bwkaz
04-10-2005, 02:05 PM
Yes, dynamic data types are cool (in fact, I'd probably say that they're cooler than GC also). But GC is definitely valuable. Even if you can find leaks with a good debugger, the entire prospect of leaks (or worse, double-frees -- those cause security holes) is something you don't have to worry about if you have a GC'ing language.

And every level of abstraction that you can introduce helps when writing programs. The more abstract you get, the less you have to worry about, and (therefore) the fewer bugs you'll introduce.

On another note, it's funny how the median language (among people who program on their own, anyway -- corporate programmer drone types usually have to use whatever the company makes them use) is slowly moving toward Lisp. The top of the line programming languages are slowly catching up with 1960. ;)

madcompnerd
04-10-2005, 04:55 PM
I've never touched lisp; I do understand it's a more natural language to write in, but a less natural language for a single processor to compute..
One of these days I do plan to play with lisp. However, I'd say the majority of code out there is c/c++, with some Java, a lot of Python and now an increasing amount of c#.
The only program I ever use that I think lisp is used in is emacs. Personally, I like c; because I find it more natural to have data types where I know their size in memory, I find it more natural to know when I'm allocating and freeing RAM, and etc. But it does make for a slower development pace, that's for sure.

But yes, in any language. The more you can abstract speific things the better. It makes things more portable later on and at first it makes it easier to fix bugs in basic procedures.

enshum
04-10-2005, 07:00 PM
have you tried installing it with autopackage? I inatalled it with no problems.:)