plplot-devel

[Plplot-devel] CMake minimum version has just been bumped

[Alan W. I. <ir...@be...>]

On 2015-12-10 11:17-0800 Alan W. Irwin wrote:

> On 2015-12-10 10:54-0000 Phil Rosenberg wrote:
>
>> Hi Alan
>> This is just a note about cmake version bumping. You have been
>> increasing the required CMake version lately, which I generally have
>> no problem with, however CMake 3.4.1 seems to have a major issue on
>> Windows, in that it cannot seem to find the latest visual studio
>> compiler (which happens to be the version I am using). I reported a
>> bug and it has been marked as a duplicate of another bug reported
>> early November (https://cmake.org/Bug/view.php?id=15831). Therefore
>> can I ask that until this bug is fixed we do not bump up any further.
>
> Agreed.

Hi Phil:

I notice at <https://cmake.org/Bug/view.php?id=15831> that this bug
has been marked as fixed for 3.4.2, and one other key Windows fix was
recently made for 3.4.3.  So that appears to satisfy the request
you made above.

Therefore (as of commit 640fd5c) I bumped the minimum CMake version to
3.4.3 for all PLplot platforms (other than Linux and Cygwin where will
still use 3.0.2 as the minimum version).  Please see the commit
message for all the successful tests I did of CMake-3.4.3 on Linux.

However, if you discover any regression of CMake-3.4.3 compared to
CMake-3.3.2 (the previous minimum version) let me know, and I will
either adjust our build system to be more in tune with 3.4.3 or else
revert the changes in commit 640fd5c until we can figure out what is
wrong for the 3.4.3 case.

Note, the next release of CMake after 3.4.3 is going to be 3.5.0. A
release candidate (3.5.0-rc1) has been distributed for that, but I
haven't bothered to try it since it appears there are a whole host of
problems for that release candidate.  But since 3.4.3 was such a
success for me, and to help out the CMake developers, I am going to
try one of the later release candidates for 3.5.0 just to investigate
whether there are any showstopper CMake-3.5.0-rc? bugs found by the
PLplot build to report to the CMake developers.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] CMake minimum version has just been bumped

[Greg J. <gv...@gm...>]

I'd like to make a pitch for maintaining a lower general cmake minimum
until
more compelling  bug fixes or features are introduced.
 I have over 6 platforms standardized on cmake 3.3.2.
Maybe the new version requirement should be restricted to those platforms
where they are needed?  And an update message issued for those that are
not required to update? (i.e. "cmake 3.6.2 looks really spiffy; try it and
avoid
seeing this annoying message!")

Greg


On Sat, Feb 6, 2016 at 9:53 PM, Alan W. Irwin <ir...@be...>
wrote:

> On 2015-12-10 11:17-0800 Alan W. Irwin wrote:
>
> > On 2015-12-10 10:54-0000 Phil Rosenberg wrote:
> >
> >> Hi Alan
> >> This is just a note about cmake version bumping. You have been
> >> increasing the required CMake version lately, which I generally have
> >> no problem with, however CMake 3.4.1 seems to have a major issue on
> >> Windows, in that it cannot seem to find the latest visual studio
> >> compiler (which happens to be the version I am using). I reported a
> >> bug and it has been marked as a duplicate of another bug reported
> >> early November (https://cmake.org/Bug/view.php?id=15831). Therefore
> >> can I ask that until this bug is fixed we do not bump up any further.
> >
> > Agreed.
>
> Hi Phil:
>
> I notice at <https://cmake.org/Bug/view.php?id=15831> that this bug
> has been marked as fixed for 3.4.2, and one other key Windows fix was
> recently made for 3.4.3.  So that appears to satisfy the request
> you made above.
>
> Therefore (as of commit 640fd5c) I bumped the minimum CMake version to
> 3.4.3 for all PLplot platforms (other than Linux and Cygwin where will
> still use 3.0.2 as the minimum version).  Please see the commit
> message for all the successful tests I did of CMake-3.4.3 on Linux.
>
> However, if you discover any regression of CMake-3.4.3 compared to
> CMake-3.3.2 (the previous minimum version) let me know, and I will
> either adjust our build system to be more in tune with 3.4.3 or else
> revert the changes in commit 640fd5c until we can figure out what is
> wrong for the 3.4.3 case.
>
> Note, the next release of CMake after 3.4.3 is going to be 3.5.0. A
> release candidate (3.5.0-rc1) has been distributed for that, but I
> haven't bothered to try it since it appears there are a whole host of
> problems for that release candidate.  But since 3.4.3 was such a
> success for me, and to help out the CMake developers, I am going to
> try one of the later release candidates for 3.5.0 just to investigate
> whether there are any showstopper CMake-3.5.0-rc? bugs found by the
> PLplot build to report to the CMake developers.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] CMake minimum version has just been bumped

[Alan W. I. <ir...@be...>]

On 2016-02-06 23:09-0800 Greg Jung wrote:

> I'd like to make a pitch for maintaining a lower general cmake minimum
> until
> more compelling  bug fixes or features are introduced.
> I have over 6 platforms standardized on cmake 3.3.2.
> Maybe the new version requirement should be restricted to those platforms
> where they are needed?  And an update message issued for those that are
> not required to update? (i.e. "cmake 3.6.2 looks really spiffy; try it and
> avoid
> seeing this annoying message!")

Hi Greg:

It is a difficult value judgement to decide how close to the CMake
cutting edge we should be for our minimum version.  From my
build-system developer perspective it is good to stay close to the
cutting edge since that minimizes the restrictions we have on taking
advantage of bug fixes and new features that are constantly being
developed for CMake.  Also, self-diagnosis is much better for later
CMake versions so tests of our build system on all platforms using
cutting-edge CMake helps to reduce problematic CMake logic in our
build system.

But it is definitely convenient for our Linux users and other
platforms like Cygwin that offer cmake as part of a coherent
distribution of free software that we support a much older version of
CMake as well.  So that is why we support CMake 3.0.2 for Linux and
Cygwin, but I am not really happy with that compromise since it forces
us to work around some bugs/misfeatures in 3.0.2 that have long since
been fixed in 3.3.2. For that reason I am definitely looking forward
to bumping our Linux minimum to 3.3.2 just as soon as most Linux
distributions offer that version or higher.  And similar arguments can
be made for Cygwin and possibly MinGW-w64/MSYS2.

On the other hand, for those users who are using platforms such as
MSVC _without_ a coherent free software distribution, my thought is
they are going to have to build (or download from Kitware) a CMake
version in any case so why not ask such users to use the latest
matured version?

This, of course, assumes our build system has been changed so that it
works well with the latest matured version (although in the present
case of the bump from the matured 3.3 to matured 3.4, i.e., from 3.3.2
to 3.4.3, no such build system changes were necessary).  Note, that a
new minor version of CMake, e.g., the 0, 1, 2, etc., in 3.0, 3.1, 3.2
etc. is released every 3 months or so that is the rough interval
between when matured versions are released, e.g., between 3.3.2 and
3.4.3.  So we assume that 3-month interval below.

Anyhow, I don't think we are asking too much of our MSVC users (and
users of other platforms without a coherent free software
distribution) to download or build CMake every 3 months or so as
3.3.z, 3.4.z, etc., mature. Note, I am not asking you to do that for
your Linux and Cygwin platforms, and I could add MinGW-w64/MSYS2 to
the list of platforms where 3.0.2 is the minimum version as well if
you think that is desireable.

So my question for you is do you really think it is going to be that
onerous for you to move from 3.3.2 to 3.4.3 just for MSVC and
classical MinGW/MSYS? After all, I have already given 3.4.3 a pretty
good thrashing on Linux so I expect there is an excellent chance it
will be reliable for all your various platform needs as well.

Finally, note that if you convince me to go with the second latest
mature version (i.e., 3.3.2 now rather than 3.4.3) it will give you a
3-month break, but then after that, keeping up with second latest
mature version will still require you to build/download CMake every 3
months or so.  So why not go with latest mature rather than second
latest if they are essentially going to be the same trouble for you?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] CMake minimum version has just been bumped

[Greg J. <gv...@gm...>]

Hi all,
Alan>

> Anyhow, I don't think we are asking too much of our MSVC users (and
> users of other platforms without a coherent free software
> distribution) to download or build CMake every 3 months or so as
> 3.3.z, 3.4.z, etc., mature. Note, I am not asking you to do that for
> your Linux and Cygwin platforms, and I could add MinGW-w64/MSYS2 to
> the list of platforms where 3.0.2 is the minimum version as well if
> you think that is desirable.
>

The platform where bugs are appearing is MSVC because of the new OS.
MSYS2, rabid advocates of bleeding edge, only has 3.4.1 to-date for mingw,
3.2.3 for the posix cmake (which includes a lot of patching of .cmake files
as
well as a special runtime).

> Alan:

> So my question for you is do you really think it is going to be that
> onerous for you to move from 3.3.2 to 3.4.3 just for MSVC and
> classical MinGW/MSYS? After all, ...


I'm pretty sure 3.4.3, without modifications, will break in plplot
comprehensive
on my 'puter when it picks up a windows' pythonlib from the registry.
So I would have to fix 3.4 again, re-make the directory links, etc.
 It may not be onerous but If its not relevant I'd rather not tinker with
it.

I have already given 3.4.3 a pretty
>
> good thrashing on Linux so I expect there is an excellent chance it
> will be reliable for all your various platform needs as well.

Of course, Linux is the worst test because it is most likely to be
compliant,
the most tested and consistent.   The minority case uses are where issues
are more likely to arise.

On Sun, Feb 7, 2016 at 3:41 AM, Alan W. Irwin <ir...@be...>
wrote:

> On 2016-02-06 23:09-0800 Greg Jung wrote:
>
> I'd like to make a pitch for maintaining a lower general cmake minimum
>
>

>
>>
> Finally, note that if you convince me to go with the second latest
> mature version (i.e., 3.3.2 now rather than 3.4.3) it will give you a
> 3-month break, but then after that, keeping up with second latest
> mature version will still require you to build/download CMake every 3
> months or so.  So why not go with latest mature rather than second
> latest if they are essentially going to be the same trouble for you?
>
> When I upgrade I'll want to go to a version well ahead of the minimum.

Regards,
Greg

Re: [Plplot-devel] CMake minimum version has just been bumped

[Alan W. I. <ir...@be...>]

On 2016-02-07 12:29-0800 Greg Jung wrote:

> The platform where bugs are appearing is MSVC because of the new OS.

Hi Greg:

There were clearly some MSVC bugs in immature versions of both 3.3 and
3.4 so that is why I avoid such immature versions when setting the
minimum version.  So the current choices are just 3.3.2 or 3.4.3. My
further impression from following both the cmake and cmake-devel lists
is that MSVC works better for 3.4.3 than it does for 3.3.2, i.e., over
time the MSVC support is greatly improving, but I obviously don't have
any hands-on MSVC experience in that regard.

> I'm pretty sure 3.4.3, without modifications, will break in plplot
> comprehensive
> on my 'puter when it picks up a windows' pythonlib from the registry.

I am virtually positive there is a way around the issue of finding your
desired Python version with vanilla CMake even on Windows platforms.
For example,
$install_prefix/share/cmake-3.4/Modules/FindPythonLibs.cmake
says:

# If you'd like to specify the installation of Python to use, you should
# modify the following cache variables:
#
# ::
#
#   PYTHON_LIBRARY             - path to the python library
#   PYTHON_INCLUDE_DIR         - path to where Python.h is found

i.e., use the cmake command-line options
-DPYTHON_LIBRARY:PATH=whatever -DPYTHON_INCLUDE_DIR:PATH=whichever

So I would strongly advise you to use that solution as opposed
to hacking CMake itself to make your life with regard to cmake
upgrades much easier.

>
> I have already given 3.4.3 a pretty
>>
>> good thrashing on Linux so I expect there is an excellent chance it
>> will be reliable for all your various platform needs as well.
>
> Of course, Linux is the worst test because it is most likely to be
> compliant,
> the most tested and consistent.   The minority case uses are where issues
> are more likely to arise.

That is a very good point.  And I am also concerned with Mac OS X
users as well who will be affected by this change. So I now realize I
got ahead of myself and before doing the bump I should have encouraged
all here to test 3.4.3 on platforms of interest to them.

Thus, I am currently leaning toward reverting this change for say the
next 3 months while users do such testing.

I would also like to hear from other MSVC users and also Mac OS X
users about what ideal schedule they would like to see for bumping the
minimum version, e.g., once each CMake minor version matures (i.e.,
cmake-3.4.3, cmake-3.5.last, cmake-3.6.last, ...) or once every other
CMake minor version matures (cmake-3.4.3, cmake-3.6.last,
cmake-3.8.last, ...)?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Re: [Plplot-devel] CMake minimum version has just been bumped

[Alan W. I. <ir...@be...>]

After thinking about this issue some more I have decided to adopt
for the short term a minimum CMake version of 3.0.2 for Linux, and
3.3.2 for all other platforms. See
<http://sourceforge.net/p/plplot/plplot/ci/3ece747fbb1d1da888abff7a9b486834a538e719>
for the rules of thumb for Linux and non-Linux platforms which lead me
to this choice.

N.B. According to those rules of thumb I will be bumping the minimum
version for the non-Linux platform case from 3.3.2 to 3.4.3 fairly
soon after both Cygwin and MinGW-w64 provide that latter version.

Thus, that next bump will likely occur within a few weeks since the
time between released matured versions of CMake (e.g., 3.3.2 to 3.4.3)
is typically 3 months and both Cygwin and MinGW-w64 (both of which
provide rolling releases) provided CMake-3.3.2 in late October.

Given that 3.4.3 is flawless from the perspective of PLplot on Linux
and given that I will likely want to bump (on non-Linux platforms)
from 3.3.2 to 3.4.3 fairly soon, I would appreciate it if everyone
gives 3.4.3 a try here to make sure it works as well or better for
them than 3.3.2 on the platforms you have access to.

The principal reason I am forcing the pace on keeping close to the
latest matured minor release of CMake-3 is my judgement that major
CMake release series is already mature on Linux and finally beginning
to mature on non-Linux platforms.  What I mean by that latter
statement is each matured minor release in that major series (e.g.,
3.3.2 and 3.4.3) is actually a significant improvement over previous
matured minor releases for non-Linux platforms. I base this judgement
on the large amount of effort I see on the cmake-devel list that is
devoted to maintaining and improving the various non-Linux platforms.
Thus, in my view keeping close to the latest matured minor release
should significantly help our users on non-Linux platforms and keep
build-system issues encountered by such users _a lot_ simpler for me
to diagnose since if they use 3.3.2 it reduces the chance that the
issue is due to CMake, and that chance is likely to be reduced still
more as they progress to 3.4.3, 3.5.<matured>, 3.6.<matured>, etc.
However, this is just an informed guess, and if any of you find that
3.4.3 is actually worse than 3.3.2 on any of the platforms of interest
to you, please let me know in a hurry.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________