Rich Felker wrote:
>On Mon, Apr 22, 2013 at 06:47:02PM +0200, Daniel Cegiełka wrote:
>>
>> https://github.com/rofl0r/gettext-tiny
>I think the goal is to have gettext functionality, not just stubs.
>Please correct me if I'm mistaken.
>
>With that said, an old version of GNU gettext should work fine. I
>wasn't even aware that the current version depends on glib; it
>certainly didn't in the past.
Correct, I was looking for a functional drop-in replacement that was better designed or at least needed less dependencies. Gettext was looking for libxml2, libcroco and glib or would happily use its own versions if not supplied. It also has a circular reference with libiconv on some platforms. Was hoping for something more lightweight or at least with less dependencies.
Wasn't aware that older versions didn't have all those dependencies. That definitely gives me one more alternative. I did find an old version of bsd gettext ( http://www.postgresql.org/message-id/Pine.LNX.4.30.0105222006170.757-100000@peter.localdomain ) that appears to be able to replace libintl and gettext. It doesn't supply replacements for msgfmt, msgmerge, xgettext. Was checking if gettext-tiny might replace them, but doesn't seem to supply the functionality used by the Open Source program I was trying to compile. Doesn't even get past the configure tests. Might look into the possibility of combining the older bsd gettext with any current modifications that might look useful from BSD Citrus project. Not sure if what I currently have works properly for every language, but it at least appears to be working for what I tested and it's a start.
Luca Barbato wrote:
> https://github.com/pkgconf/pkgconf might be handy btw.
Was going to mention that yesterday as well. pkgconf is a great drop-in replacement for pkgconfig and does not require glib or any circular library references. The developers of pkgconf were also nice about adding support and/or receiving patches. I absolutely cannot say the same thing about the glib developers.
Rich Felker wrote:
>If you want the data structures, I think that means you should be using C++, not C.
This may be very much a matter of taste, because you can write data structures in any language, but that certainly sums up my preferences. I find C++ a very useful language for expressing data structures.
Rob Landley wrote:
>Many moons ago I started a thread on here (or was it on freenode?) asking about lightweight alternatives to stuff and the need for a wiki page tracking them.
I try to document them as I have time at my own web site. I also add links to the MinGW and OpenWatcom wikis if I find libraries or tools that might be useful to developers. I know there are some die-hard Linux advocates on this list. My own bias is toward cross-platform portability. I started out and still am a cross-platform programmer. I prefer to be able to write programs in such a way that they're easy to port to any machine. I don't like to be locked into only being able to use one operating system. Sometimes one doesn't have a choice at work which operating system one is stuck with and it's nice to be able to have Open Source tools and utilities to work on any system.
Here's what I've dug up for MinGW as far as various tools, utilities and libraries:
http://www.mingw.org/wiki/Community_Supplied_Links
The links are definitely slanted toward working with MinGW, but as I mentioned, my preference is for cross-platform, so many of the libraries and some of the utilities links work on a variety of operating systems. A few of them came from Linux/Unix environments and I had to send in patches to port before they'd even work with MinGW.
Rob Landley wrote:
>I know we discussed more stuff (rxvt, xcfe and lxde...)
I'll throw in a mention of razor-qt and Equinox Desktop Environment as lighter-weight desktop environment alternatives. Personally, I've never found xfce efficient on my older machine. I currently prefer a lightweight window manager and a few utilities over a desktop. I also like rxvt-unicode. The ability to run multiple terminal windows with a daemon in order to save memory is really nice. The other terminals with this feature (like LXTerminal, lilyterm, evilvte and Sakura) all seem to require VTE and don't seem as efficient in some ways.
Connochaetos has some helpful memory usage information for comparing various desktop and X applications. Gives some statistics of rxvt-unicode versus other terminals too in case anyone's curious.
http://www.connochaetos.org/wiki/devel:x-apps
Sincerely,
Laura
http://www.distasis.com/cpp/osrclist.htm