[Olsr-dev] lua in olsrd sources

[Bernd Petrovitsch]

On Die, 2012-02-07 at 10:11 -0500, Hans-Christoph Steiner wrote:
> On Feb 4, 2012, at 7:51 AM, Bernd Petrovitsch wrote:
[....]
> > Perhaps Andreas T. - from which I more or less took over maintainership
> > ages ago - knows how/when/why the LUA interpreter ended up in there.
> 
> Its easy enough to make it build against an external version of Lua,
> and Lua is included in Debian, Ubuntu, Fedora, Mac OS X/Fink,
> MacPorts, Cygwin, etc.  Its also easy to build using MinGW.

Very probably - that is really not the problem.
But not the whole world is some well-known Linux distro on a
IBM-compatible PC (and from the pure deployed numbers of systems they
are actually not really that relevant. Yes, the PC world doesn't know or
fail to accept that. But that's another story ...).

> I think the path of least resistance would be to remove the lua
> sources and just build against external sources.  I can do the build
> part.

Strategically olsrd never used external libs (except of course libc but
that is always a special case).
One reason was that there were no real tempting candidates for anything,
e.g.
- glib, liboop or something similar for the main-loop.
- APR or something similar to "ease porting"</salesdroid> is
  IMHO for olrsd far more work to integrate, use and maintain then the
  gain because olsrd is quite small and compact anyways.
- a lib for the Dijkstra algo: I don't know if such a beast actually
  exists.

The next reason is that that lib should exist/work/be ported on all
supported platforms - at that time Linux distros, openwrt, *BSD, CygWin.

In an ideal world, you have cooperative people with sufficient know-how
and interest to work with who - at least - try new versions out and help
to nail bugs - both build time and run-time.
Well, the world was (much) less then ideal (and many thanks once more
for those who tried to make the world more ideal and who sent not only
bug reports but also patches fixing it locally for them at least).

The 3rd reason is that using external libs usually
a) implies run-time bloat because it is quite unlikely that a daemon
   needs really all of it.
   IIRC we actually avoided libm explicitly.
   So think twice about it in the embedded world.
   And you very probably get the run-time bloat even if you link the
   lib statically hoping the linker removes all unused parts (because
   most libs tend to have lots internal stuff which is not trivially
   avoidable).
   Try that with GNU-libc and see how much code is pulled in ....
b) implies another abstraction layer (the API of the lib) and at that
   time olsrd already had (far) too many of them internally (and Hannes
   Gredler and I tried to kill some of them mainly because the didn't
   buy anything and just costs performance and source code and run-time
   code bloat).
   Don't know about today.
c) you have to cope with their API - which maybe easy or not.
d) possibly handle with a changing API - both feature-wise and bug-wise.
   Compile-testing is easy, but that won't catch all changes -
   especially not the semantic ones.
   In the Linux distro area, the distributor handles updates etc. here,
   but who does it for openwrt, CygWin or *BSD?
   And there people actually update there systems once in a while too.

And the main issue with external libs is that historically openwrt
running on Linksys with 16 MB RAM[0] and other (somewhat) embedded stuff
were the main platform - and some not some random "PC Linux distro".
I don't know how that is today - Henning should know.

IMHO it's the maintainers opinion that counts and, consequently,
decision - the above is just my experience with (real) embedded Linux
systems[1] and view on that issue (and I purposely do not write (more
about;-) what I should have done ages ago or what I would do today if I
were in that position;-).

Kind regards,
	Bernd

[0]: That was - later on - the "L" edition. A stripped down version of
     openwrt (no webinterface or other bells and whistles) actually ran
     on the newer, smaller ones with smaller ones - 8 MB RAM.
[1]: Hardware with 128 MB RAM and 1 GB Flash-RAM is easy - just run some
     stripped down Linux distro on them. But there was hardware with 4
     MB Flash-RAM and and 16 MB RAM.
-- 
Bernd Petrovitsch                  Email : (spam-protected)
                     LUGA : http://www.luga.at