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

[Alpar Juttner]

Hi,

> I don't argue. The point is that all these things are used not by me,
> because I am not a GNU/Linux maintainer. Building binary package
> distributions is automated process, and I cannot imagine that cmake
> could met all necessary requirements. Probably cmake is more convenient
> than autotools, but the end user is not interested to know how configure
> script and makefile's were generated (until he would like to change
> something), isn't he?

I'm pretty much an end user as far as GLPK is concerned, still I'm
interested in the CMAKE adoptation. (Just to be clear, I'm also a simple
end user of CMAKE.) The reason is that the install&use approach does not
always work. For example when
      * you want the use a specific - or even patched - version of GLPK
        in your project.
      * different projects (or different versions of the same projects)
        need different version of GLPK.
      * you need GLPK compiled with different flags (in line with the
        flags you use in your own code). For example you need it in
        debug and also in release (optimized) mode.
      * you want to develop cross platform application. It is very
        difficult to set up a reliable configuration in this case.

Now, the safe and flexible solution for these problems is that you embed
the source code of GLPK into your application and build it along with
yours. CMAKE helps to solve all the cross compilation and configuration
issues. Once you have a CMAKE config for GLPK, it's basically enough to
put GLPK into a subdirectory of your code, then add the line

ADD_SUBDIRECTORY(glpk-dir)

into your main config. If CMAKE config is shipped with GLPK, it means
you don't have to manually adjust the CMAKE config on each GLPK upgrade.

In fact, in several cases we ruled out using COIN-OR::CLP/CBC and opted
for GLPK simply because a CMAKE config for GLPK was relatively easy to
set-up, whilst it would have been an incredible work to do for CLP/CBC.

> As a rule MS Windows should not be considered at all, because it is
> proprietary software.
> 

:)

Then, why on Earth are those .bat files there in the GLPK release? Why
the precompiled MS Windows package was even mentioned in the last
release announcement?

It may be that MS Windows should not be considered at all, but I really
happy to consider the MS Windows users, no matter what makes them using
that OS. I think Xypron is also worth "being considered" for his efforts
to make the precompiled binary.

Regards,
Alpar