Hello GLPK list, hello Alpar > ------------------------------------------------------------ > To: [email protected] > Subject: [Help-glpk] [Fwd: CMAKE build environment > (and version control)] > Message-ID: <1292086040.2977.0.ca...@none> > From: Andrew Makhorin <[email protected]> > Date: Sat, 11 Dec 2010 19:47:20 +0300 > ------------------------------------------------------------ > > -------- Forwarded Message -------- > From: Alp??r J??ttner <[email protected]> > To: [email protected] > 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ő, 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) : [email protected] Webmail (preferred) : [email protected] [from Webmail client] _______________________________________________ Help-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-glpk
