[Lemon-devel] LEMON questions/comments

[Martin Mokrejs]

Thanks, was blind when I was looking for it. ;)
Martin

Kovács Péter wrote:
> 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
>>>
>>>
>>>
> 
>