[Lemon-devel] LEMON questions/comments

[Alpár Jüttner]

On Fri, 2012-03-02 at 19:39 +0100, Martin Mokrejs wrote:
> Hi,
>   I lack in the INSTALL file in lemon-1.2.3.tar.gz a note what is glpk, cplex, soplex, coin.
> I figured out glpk, please add a pointer to http://www.gnu.org/software/glpk. Same should be
> listed on your webpage at https://lemon.cs.elte.hu/trac/lemon/wiki/InstallGuide

Right. The next release will have new INSTALL instruction (for CMAKE)
which will probably spend some words on this.

>   How can I create a dynamic library

cmake -DBUILD_SHARED_LIBS=TRUE ..

Somehow cmake-gui doesn't display this configuration option. A cannot
really understand why.

>  and why isn't that preferred over static?

Because it make no sense using dynamic lib.

The LEMON library is very small and only a very few parts of LEMON do
actually depend on it. Statically linking to the lib will only add a
couple of KBs to the executable (or nothing).

On the other hand, dynamic linking is always a headache, it causes
compatibility and portability problems.

The two perceived advantages of using dynamic libraries are
      * saving memory by sharing the lib
      * allowing upgrade of the library without recompiling the
        executable.
Both advantages are pretty questionable in general, an certainly false
for LEMON.

>   I see configure checks for python. What is it useful for?

The documentation generation uses it for creating the references from
the bibtex file.

The version ID was also determined by Python script when you a
repository checkout version is used. It was replaced by a direct call of
hg recently.

Otherwise, LEMON doesn't need Python.

>  Is this because of pyLemon bundled
> into the archive?

Certainly not.

> But where is it?

It is in a separate repository, now it is private.

>  Where is its setup.py file?

Nowhere, pyLemon is basically in a proof-of-concept state. What it
worse, it looks like a dead end.

Currently, I'm thinking on a Cython based implementation, which looks a
more promising direction than building the interface by hand.
A volunteer is very welcome.

> BTW this link is broken: http://lime.cs.elte.hu/~alpar/hg/hgwebdir.cgi/pylemon/

Indeed. Thanks for pointing out. I removed the link from the wiki page.
I can send you the repo privately if you need it.

>   Regarding your trac tickets, I don't think Autotools support should be phased out, it is
> much nicer than CMake, IMHO. ;)

I'm afraid, it has already been decided.

Autotool
      * is overly complex
      * doesn't support out-of-source build (i.e. it inevitably spams
        the source code tree)
      * is not multiplatform
      * doesn't support cross compiling
      * doesn't make is possible the have such a nicety as
        lemon-project-template
        ( https://lemon.cs.elte.hu/trac/lemon/wiki/ProjectTemplate )

The trade-off is that autotool needs only a shell to build from a
release tarball (which is good) but needs tons of tools to build a
development version (which is bad). In contract, CMAKE needs cmake in
both case (which is acceptable).

So, we needed cmake, then we made is the default build system for its
advantages. Then, we decided to phase out autotool because it has very
little (read: no) advantages over CMAKE. We simply doesn't have the
resources for maintaining an alternative build system for nothing.


>   Finally, I have sketched a package for Gentoo Linux for Lemon, and
> now will move back to cufflinks. Hope it will link with the static lib.

I'm sure it will.

As an advice, being LEMON is basically a template library, you may want
to consider integrating LEMON into the source code of your project. You
can easily do it (see lemon-project-template), and it is a very safe
solution to tie a certain version with your code and ship in along. We
use this approach basically in all our internal projects with great
success.
LEMON's licencing scheme also makes it easy to do.

Regards,
Alpar