[Lemon-devel] LEMON questions/comments

Martin Mokrejs mmokrejs at fold.natur.cuni.cz
Mon Mar 5 08:57:41 CET 2012


BTW, under what license is the package released? I need to tag this in the Gentoo package.
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.
Thanks,
Martin

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
> 
> 
> 



More information about the Lemon-devel mailing list