[Lemon-devel] LEMON questions/comments

[Kovács Péter]

Hi,

> BTW, under what license is the package released? I need to tag this in the Gentoo package.

Boost Software License, Version 1.0

> If it is some your own license then I need it in a plaintext file. Usually, it is in the
> tarballs in a file named LICENSE or COPYRIGHT.

Yes, exactly. It is in the LEMON tarball in a file named LICENSE.

Regards,
Peter


> Alpár Jüttner wrote:
>> 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
>>
>>
>>