[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Robbie Morrison
Subject: [Help-glpk] Help-glpk] [Fwd: CMAKE build environment (and version control)]
Date: Mon, 13 Dec 2010 12:12:46 +1300 (NZDT)
User-agent: SquirrelMail/1.4.17

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


>  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
>  ( ).

Just added a GLPK wikibook entry for LEMON:

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.


>  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 ( ) 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
>  (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]

reply via email to

[Prev in Thread] Current Thread [Next in Thread]