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

[Andrew Makhorin]

> > I would like to note that glpk is part of the GNU project, so it is
> > constrained to follow the GNU coding standards, where using GNU
> > autotools is essential requirement
> 
> Not really. The related part of the GNU Coding Standards[1] only
> requires a configure script with a given minimal set of parameters. It
> explicitly allows using different build systems:
> 
>         "Each GNU distribution should come with a shell script named
>         configure. [...] Many packages implement it using GNU Autoconf
>         (see Introduction in Autoconf) and/or GNU Automake (see
>         Introduction in Automake), but you do not have to use these
>         tools. You can implement it any way you like; for instance, by
>         making configure be a wrapper around a completely different
>         configuration system.
> 
> So, CMAKE perfectly fits this requirement assuming that a wrapper
> configure script is written to it (but I bet nobody will ever use it).

I remember that many issues concerning configure scripts and makefiles
appeared in the past. Probably I referred to a non-relevant document,
however, AFAIK, GNU autotools is highly recommended for all GNU
packages. For example, the script invoked for authentication on
uploading tarballs to ftp.gnu.org checks that the configure script is
built with appropriate version of GNU autoconf/automake (this is because
of some vulnerabilities detected in older versions). So I'm even not
sure that I could upload the tarball with a configure script generated
by something other than GNU autotool.

> 
> I must add that there are _major_ GNU projects that do _not_ even
> provide a configure script.
> 
> >  (in particular, it is important for
> > down-stream maintainers who maintain glpk, for example, for GNU/Linux).
> 
> I'm afraid I must also disagree here. Packaging a CMAKE based project is
> no more difficult than those using autotool. All the distros providing
> KDE has managed to solve it.

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?

> 
> Not to mention the Windows packagers - CMAKE will essentially transform
> their task to something like
> 
>         cmake ..
>         nmake 
>         cpack

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

>         
> 
> > However, if you post me a cmake makefile for glpk, I can include it in
> > the glpk distribution.
> 
> Here you can find a patch adding them:
> 
> http://lemon.cs.elte.hu/hg/glpk-cmake/raw-rev/4c8956a7bdf4
> 
> Though it is still a preliminary version and needs some polishing. For
> example the doc creation (make pdfdoc) is not very beautiful, and right
> now it creates both static and shared lib's, I'm not sure they are both
> necessary.

Thank you for the link.

> 
> It would be nice if others could test it and comment. I'm happy to make
> any adjustments upon request. It also contains a simple tool that
> includes the hg revision number into the version string. This part is
> useless (though doesn't hurt) if the code is not under hg.
> 
> >  I need some template, because all glpk makefiles
> > are generated automatically on creating the tarball.
> 
> Hmmm. Being a cross platform build tool, CMAKE is actually pretty much a
> replacement for this makefile generator generator. :)
> 


Andrew Makhorin