[Top][All Lists]

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

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

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

Hi all

To:          Alpar Juttner <address@hidden>
Subject:     Re: [Help-glpk] Help-glpk] [Fwd: CMAKE build environment (and
Message-ID: <address@hidden>
From:        Andrew Makhorin <address@hidden>
Date:        Wed, 15 Dec 2010 23:46:45 +0300

The build system is of secondary importance, unless it
is really getting in the way.  The main thing, of course,
is the GLPK codebase.


>  - Cross compilation.
> Not sure what Alpar refers to here, autoconf/automake
> are ideally suited for that.

I occasionally cross-compile my project using GCC/Linux
to produce statically-linked Windows binaries.  In
contrast, Xypron, I believe, builds native Windows
executables using Microsoft Visual Studio.

>  - Windows support.
> Both autoconf and automake work on Windows, and you
> can cross compile for mingw or cygwin.  Supporting
> Windows shouldn't be a priority, but if someone
> supplies patches that don't cause havoc then there is
> never harm in applying them.

By way of disclosure!  I use Linux and UNIX
exclusively.  Indeed, I happily abandoned my last aging
Windows machine about six years ago.  That said, I
believe it is important for GLPK to support Windows, if
at all possible.

The reason I say this is that my partner teaches
conventional and experimental power plant simulation
(Aspen, Gatecycle, Ebsilon, if that means anything) at
the Technical University of Berlin.  Now you might
imagine that at least some of the engineering students
would run Linux.  But no.  Their laptops come preloaded
with Windows and Microsoft products are nominally free
for academic use.  So that is what they use.  The only
break from this orthodoxy is the occasional Mac.  And
the only chink in this proprietary landscape is
LibreOffice (was OpenOffice) because this is exactly
free.  Normative arguments about the merits of open
source appear to be completely absent.

That said, it seems that the current system works for
GLPK?  Andrew and others concentrate on the core code.
And some separate but related initiatives build
executables and write BAT files for Windows and so forth.

In many respects, I though the comment from Alpar about
adopting 'mercurial' or 'git' was the more significant.
But judging by blogs from other software projects, the
decision to change source code management practices is
normally lengthy and involved.  For GLPK, the current
system works.  But it does seem not to encourage or
provoke many contributions to the core code.  Perhaps
that could be considered a benefit, but I rather think not.

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]