[Lemon-devel] LEMON questions/comments

[Martin Mokrejs]

Hi Alpar,
  thank you very much for you thorough explanation. I am now just lazy
to Google for the "cplex, soplex, coin" so please let me know when the
updated INSTALL file is out. I will continue on this later on. 
  The package for Gentoo Linuxis ready, and thanks to autotools ;-)
it was simple for me. Once you drop autotools I will bother to investigate
how to use cmake for the build process. ;-) I will probably file a bugreport
on Gentoo website to keep somewhere your explanations on how to compile
the shared lib and why it is not available by default (just in case somebody
would complain later on). I understand you reasonings so let's stay with
the static lib only.
Best regards,
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
> 
> 
>