[CMake] Suggestion for CMake platform/compiler detection

[Arjen Markus]

Alan W. Irwin wrote:

> On 2006-11-18 10:16-0800 Brandon J. Van Every wrote:
>
>> I would like to know in the case of PLplot, how mature the Unix / 
>> Cygwin / MinGW / MSVC builds already were.  Did they all essentially 
>> work already?
>
>
> Under autotools, Linux and Mac OS X were fine, other Unices were 
> untested.
> Cygwin and MinGW/MSYS worked reasonably well (I believe everything worked
> but dynamically loaded plug-in devices), but that took a dedicated
> effort (for example, a patch to libtool that was accepted by that team to
> correct bugs in shared library support for MinGW/MSYS a year or so 
> ago). Our
> bare windows (i.e, windows without Cygwin or MinGW/MSYS) build was 
> done with
> a completely different home-brew build system which provided a PLplot 
> that
> was far from full featured.  (I think just the core static library +
> examples, but Arjen may correct me.)

There was/is a version of the makefiles to build a DLL, but the makefile 
for the
examples was a nuisance.

The real problem was twofold:
- We needed (or so it appeared) a separate device for "bare" Windows and
   separate intermediate routines to link the C and C++ parts.
- The makefiles were derived from MSVC project files and went through
   a series of edits to add more functionality.

(I only inherited the maintenance of this part :), but I do feel 
responsible
for it. I do not mean it as a criticism, at the time there was little choice
due to compiler limitations)

While I immediately admit that an IDE like MSVC's (the MicroSoft Visual
Studio or Developer Studio or whatever the proper name) is very, very
useful in setting up a project *for your own benefits*, it fails utterly 
when
it comes to deliver a build system where users can fill in a few details to
match their set-up and their needs:
- The user has no help in selecting the right options - they are implemented
  as C macros and the user must define and set them directly (the IDE
  offers no help).
- The user has to add paths to external libraries they wish to use, as
  well as set the right options (macros) to make the project take them
  into account during the build.
- External tools like Swig to build interface code are extremely
  awkward to incorporate. Oh, you can build in a user-defined rule
  for particular files, but that only adds the complexity of knowing
  _if_ it is there, _where_ it is and if the user wants to actually
  use it.

Deriving makefiles from the project files does not make things simpler.
I experimented with a small configuration program to manipulate the
makefiles and while in itself this does the job, it is very limited. One
particular limit: finding external libraries.

CMake has enabled us to get easy-to-use configuration tools onto
"bare" Windows. That may not be a solution for everyone, mind you
- we also have users who would like to work with project files or
"solutions" in modern MSVC speak.

Sorry, for the somewhat lengthy reply. But it is an opportunity to
highlight why we think CMake rocks for at least PLplot.

Regards,

Arjen