Michael Robinson wrote:
>Why is Lua changing anyways?

Unfortunately, a lot of Open Source software is constantly changing
(in ways that aren't backward compatible).  In many cases, if you see
a large jump in version numbers that means a major modification has
taken place and compatibility is not guaranteed.  You can easily get
into topics on what's more important, technological advancement and
improvement or backward compatibility and needing to support legacy
code/uses.  My personal opinion is that in most cases if a design
can't maintain at least some backward compatibility, someone didn't do
a good forward thinking design in the first place.  However, I'm sure
there are many members of the Open Source community who would
disagree.

> Lua wasn't listed as a dependency for gnome, so I'm guessing that going
without it won't have a significant impact on gnome functionality wise.

I first ran across software using Lua when I started using SciTE (a
very flexible programming editor).  Lua is a programming language that
can be used as an embedded language in applications.  It can be used
for writing scripts that help customize an application.  I can't see
how an embedded language would be a required prerequisite for desktop
software, but then I don't use Gnome.  So, I'm not that familiar with
it.

I am having similar backward compatibility problems with other
libraries.  Fox Toolkit version 1.7 adds some internationalization
support.  However, most of the applications that run on it are
designed for 1.6 and may not necessarily run on 1.7.  Not sure whether
to try to get things working on 1.7 (not going too well so far) or go
back to 1.6.  Anyone else using Fox Toolkit for anything?  FLTK is
getting better fortunately.  They had a lot of versions split off and
many were completely incompatible.  Version 1.3 is working toward
unifying a lot of those splits and getting more applications working
with it.  SDL also has more than one development line each with
different licensing and functionality.  Most programs I've run across
still use the SDL 1.2 line.  However, there's also 2.0 (was 1.3).
Since, you're working on Gnome, you're probably more familiar with
GTK.  A few lightweight distributions are still using GTK+ (the
version 1 line).  Most distributions have switched to 2.  However,
I've seen a lot of complaints from users interested in efficiency on
their machines that the code is bloated.  There are some compatibility
switches for attempting to build GTK+ 1 applications with GTK+ 2.
Developers and distributions are now moving to GTK+ 3.  Some projects
are starting to add in support for moving to that version because most
GTK programs won't work as is with the new version of GTK+ 3.  With
libpng, I've had to make a few minor modifications to most
applications that need it in order to deal with changes made in later
versions of that library.  Having similar problems with applications
that use libfribidi.  Again there are two development lines.  I'm
currently looking at the code for sdcv (which worked with some
patching with later versions of GTK+ 2).  Don't know if it'll work
with GTK+ 3 at all.  I'm going in and recoding it and removing all the
GTK dependencies so they won't be an issue for me.  I could keep going
with other libraries, but I'll stop here.

So, this kind of thing happens all the time.  Typically, I try to keep
up with latest versions.  However, what can one do when most of the
Open Source applications only work with earlier versions of a library?
 The only way to ensure a library doesn't change too much is work with
developers who care about backward compatibility, use tools that are
no longer updated (however, if they have major dependencies you have
the same issue only worse), minimize dependencies as much as possible
or write it yourself.  The last option guarantees backward
compatibility if you want it and I personally use that option
sometimes.  Would be very interested to hear what others do about
these types of issues.

Sincerely,
Laura
http://www.distasis.com/cpp
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to