[Help-glpk] Help-glpk] [Fwd: CMAKE build environment (and version control)]

[Robbie Morrison]

Hello GLPK list, hello Alpar

>  ------------------------------------------------------------
>  To:          address@hidden
>  Subject:     [Help-glpk] [Fwd: CMAKE build environment
>                    (and version control)]
>  Message-ID: <address@hidden>
>  From:        Andrew Makhorin <address@hidden>
>  Date:        Sat, 11 Dec 2010 19:47:20 +0300
>  ------------------------------------------------------------
>
>  -------- Forwarded Message --------
>  From: Alp??r J??ttner <address@hidden>
>  To: address@hidden
>  Subject: CMAKE build environment (and version control)
>  Date: Sat, 11 Dec 2010 16:13:19 +0100

[snip]

>  We also provide an high level C++ interface to GLPK
>  (and other LP/MIP solvers) in our open source graph and
>  network optimization library called LEMON
>  (http://lemon.cs.elte.hu ).

Just added a GLPK wikibook entry for LEMON:

  http://en.wikibooks.org/wiki/GLPK/Third-party_API_wrappers#LEMON_graph_library

Edit this as you (Alpar) see fit (or send me a
private email suggesting changes, if you prefer
to do it that way).

GLPK people should note the following presentation
is well worth reading for an overview.  Knowledge
of C++ is assumed:

  Jüttner, Alpár, Balázs Dezs&#337;, Péter Kovács.  2010.
    LEMON : library for efficient modeling and
    optimization in networks -- presentation.
    Department of Operations Research, Eötvös Loránd
    University, Budapest, Hungary.  30 April.  PDF.

  http://lemon.cs.elte.hu/pub/doc/lemon-intro-presentation.pdf

[snip]

>  It pretty well substitutes all the build tools and .bat
>  files GLPK currently has, thus - after some fine tuning
>  - it would be nice to include into the future
>  releases. The other build tools may even be deprecated
>  in the long run.

Can I suggest that, if GLPK adopts CMAKE, that
folk *other* than Andrew develop and test this new
build system.

>  I would be happy to hear any feedback and comment.

I have no strong opinion on this.  The current
arrangements work acceptably for me on Linux
+ GCC.

>  As you may have already noticed, I've also created a
>  GLPK repository using the Mercurial distributed version
>  control system ( http://mercurial.selenic.com/ ) which
>  I suggest for adoption, too.  I believe the principle
>  of distributed version control fits very well GLPK. If
>  you want to check it out, install mercurial (I suggest
>  TortoiseHG version on Windows) and type
>
>  hg clone http://lemon.cs.elte.hu/hg/glpk-cmake
>
>  (Or right click -> TortoiseHg -> Clone in the file browser on windows)

I guess this is a good time to bring up the
general question of whether GLPK should move to a
centralized (svn) or distributed (hg, git) source
code management system.  That said, the current
tar-ball and occasional patch method works fine
for me.  Linus Torvalds comments that the early
years of Linux kernel development used tarballs
+ patches .. though I doubt they would return to
that system now.

Fantastic to see a university project with proper
software engineering.  Congratulations!
---
Robbie Morrison
PhD student -- policy-oriented energy system simulation
Technical University of Berlin (TU-Berlin), Germany
University email (redirected) : address@hidden
Webmail (preferred)           : address@hidden
[from Webmail client]