Re: [cmake-developers] PLplot contract test

2017-11-09 Thread Alan W. Irwin

On 2017-11-08 18:00-0800 Alan W. Irwin wrote:

[...]

Changing topics back to the Nightly case where the job is started in a
crontab environment rather than on the normal desktop command line as
above, further research indicates it is possible to set DISPLAY for
such environments (assuming that DISPLAY exists at the time the
crontab job fires as is typical for my case).  So I am going to try
that to see if that change plus the above setting of XAUTHORITY solves
the Nightly issue as well.


Thanks to that crontab change to define the DISPLAY environment
variable, all is now well with the Nightly case, see
.

So that appears to be the end of the configuration issues with the
Contracts.PLplot test, and my thanks to Brad for implementing this
test in the first place, and both Brad and Ben for some key help with
my configuration of this test.

So for others here that might be interested, Contracts.PLplot tests a
build of the stage/master/nightly/latest branch of CMake by using
ExternalProject_Add to git checkout a specified version of PLplot and 
to configure, build, and install that version with user control of the

PLplot version selected for the test and the CMake options used to
build PLplot.  So this test is good from the PLplot perspective
because it makes it more difficult for some new CMake development to
cause PLplot developers problems without us knowing it long in advance
of CMake releases.  And it is also good from the CMake testing
perspective since it is a test that exercises a lot of different CMake
functionality in a realistic way (i.e., as used in a rather complex
build system, warts and all).  Additional notes are (1) because of the
relatively small size of the PLplot project (despite its build-system
complexity) this test adds less than ~30 per cent to the overall cost
of building and testing CMake, and (2) this test should work on
essentially all platforms (the build of PLplot is known to work on at
least Linux, Mac OS X, Cygwin, MinGW-w64/MSYS2, and MSVC). So if
anyone else is interested in trying this test on their favorite
platform(s), feel free to contact me for help with configuring it and
overcoming any PLplot build failures in the unlikely event of you
encountering those.

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
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-11-08 Thread Alan W. Irwin

On 2017-11-08 16:14-0500 Ben Boeckel wrote:


On Wed, Nov 08, 2017 at 12:39:15 -0800, Alan W. Irwin wrote:

software@raven> time (nice -19 ctest -S 
~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV >& ctest.out16)
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.

The only thing I can find in ctest.out16 corresponding to these
warnings is

264: application-specific initialization failed: couldn't connect to display 
"localhost:10.0"
264: Error in startup script: couldn't connect to display "localhost:10.0"


The Xauthority file is not available to the nightly build job.


Hi Ben:

Note the above issue is for an Experimental test and not for a Nightly
one, i.e., the above errors occurred for a command-line environment
where X authentication normally just works (i.e., I can fire up
another konsole or xterm, run "xauth list", etc. without issues).  The
corresponding X authority file is located at
/home/software/.Xauthority.

Following up on another comment you made concerning the
XAUTHORITY environment variable I decided to try setting
that environment variable using

macro(dashboard_hook_build)

set(ENV{XAUTHORITY} /home/software/.Xauthority)

endmacro()

within my Scripts/CMakeScripts/my_dashboard.cmake
file following how I set other environment variables
for this contract test.

That change completely solved the above Experimental X authority
issues and the Tk-related components of PLplot built for that
particular test.

So thanks very much for that XAUTHORITY idea!

Changing topics back to the Nightly case where the job is started in a
crontab environment rather than on the normal desktop command line as
above, further research indicates it is possible to set DISPLAY for
such environments (assuming that DISPLAY exists at the time the
crontab job fires as is typical for my case).  So I am going to try
that to see if that change plus the above setting of XAUTHORITY solves
the Nightly issue as well.

@Brad:

I still have no idea why setting XAUTHORITY to the file that is used
in any case should be needed, and I am therefore pretty sure doing
that as above merely works around an issue with contract tests (or
deeper) where it is possible not enough care is being used to
propagate X authority.

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
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-11-08 Thread Ben Boeckel
On Wed, Nov 08, 2017 at 12:39:15 -0800, Alan W. Irwin wrote:
> software@raven> time (nice -19 ctest -S 
> ~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV >& ctest.out16)
> X11 connection rejected because of wrong authentication.
> X11 connection rejected because of wrong authentication.
> X11 connection rejected because of wrong authentication.
> X11 connection rejected because of wrong authentication.
> X11 connection rejected because of wrong authentication.
> X11 connection rejected because of wrong authentication.
> X11 connection rejected because of wrong authentication.
> 
> The only thing I can find in ctest.out16 corresponding to these
> warnings is
> 
> 264: application-specific initialization failed: couldn't connect to display 
> "localhost:10.0"
> 264: Error in startup script: couldn't connect to display "localhost:10.0"

The Xauthority file is not available to the nightly build job. You can
share it using the XAUTHORITY environment variable and putting it in a
place that both the user running the X server and the job know about and
can access.

See also the `xhost` tool for managing the file itself. You may need to
authorize other users to use the X server, but I've only needed that for
a setup here where the host provides a VNC server for a Docker image to
use (which also needs cross-host authentication allowances).

--Ben
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-11-08 Thread Alan W. Irwin

On 2017-11-08 06:54-0500 Brad King wrote:

[...]

I've updated the test.  Change the name from _ARGS to _FLAGS:

```
CMake_TEST_CONTRACT_PLplot_CMAKE_FLAGS:STRING=-DBUILD_TEST=ON -DBUILD_DOC=ON 
-DBUILD_DOX_DOC=ON
```

[...]

I've added an option:

```
CMake_TEST_CONTRACT_PLplot_GIT_TAG:STRING=plplot-5.12.0
```

The value can be anything that `git checkout` understands
(tag, branch, commit sha1, etc.).


Hi Brad:

Thanks for these changes which all work well (see
 for
details).  The Contracts.PLplot test (for the current PLplot master
branch HEAD) passed in < 10 minutes (even with
all the extra documentation building I have configured) which is
acceptable when compared to the total length of this test.

As far as I can tell there is only one issue left which
is I get the following X11 authentication warnings when running this test in
Experimental mode.

# Check DISPLAY environment variable
software@raven> printenv |grep DISPLAY
DISPLAY=localhost:10.0

software@raven> time (nice -19 ctest -S 
~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV >& ctest.out16)
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.
X11 connection rejected because of wrong authentication.

The only thing I can find in ctest.out16 corresponding to these
warnings is

264: application-specific initialization failed: couldn't connect to display 
"localhost:10.0"
264: Error in startup script: couldn't connect to display "localhost:10.0"

As a result of that error, the PLplot build system concludes Tk does
not work for the given platform and as a result it disables building
all Tk-related components of PLplot for this contract test.  Which
makes this contract test not quite as powerful as it should be.

What is going on behind the scenes is the PLplot build system executes
the Tk "wish" command to simply confirm version consistency.  So it is
used in a noninteractive way even though by default wish momentarily
displays a blank GUI before wish exits with the required version
information.

That works fine when I run cmake by hand to configure PLplot since for
those cases I never get the above X11 authentication errors.  And I
can launch any X application I like (such as wish or xterm) without
such authentication errors as well.  In other words, my X11
authentication environment is just fine.  As a result for my
interactive desktop environment, running wish with execute_process
and configuring PLplot always "just works".

But in Nightly mode, a crontab environment obviously does not include
a DISPLAY variable so any attempt to configure PLplot in that
environment would encounter this same error.  So I plan to
drop the wish version consistency check that is currently implemented
whenever the DISPLAY environment variable is not set, and I
am virtually positive that will fix this issue for the Nightly case.

However, it appears this planned change will NOT fix the issue for the
above Experimental case because I am pretty sure DISPLAY was defined
internally when the above ctest command was being executed (because
the error message referred to "localhost:10.0" which is the same as
the DISPLAY environment variable set before the above ctest command
was executed).  So if that proves to be the case, I also plan to drop
the wish-based version consistency checks when a particular PLplot
build-system option is set, and also set that option for the
Experimental case.  Of course, if that additional fix (beyond the
DISPLAY check) is necessary it smacks of a workaround for some X11
authentication issue for the CMake contract testing environment for
the Experimental case so I thought I should bring that issue to your
attention just in case there is an easy solution you could implement
for that issue.

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
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.

Re: [cmake-developers] PLplot contract test

2017-11-08 Thread Brad King
On 11/07/2017 03:50 PM, Alan W. Irwin wrote:
>> # Do build of PLplot as a ctest of CMake.
>> set(CMake_TEST_CONTRACT_PLplot:BOOL=ON)
>
> Why could I set garbage in the cache
> file as above with the result that that garbage was read
> and ignored with no error message?  Isn't that a CMake bug?

The `#` is a comment whiel the `//` is documentation.
The format of the cache entries themselves is *very* tolerant.
Your line set a variable called "set(CMake_TEST_CONTRACT_PLplot"
to the value "ON)".

> CMake_TEST_CONTRACT_PLplot_CMAKE_ARGS:STRING=-DBUILD_TEST=ON -DBUILD_DOC=ON 
> -DBUILD_DOX_DOC=ON

I've updated the test.  Change the name from _ARGS to _FLAGS:

```
CMake_TEST_CONTRACT_PLplot_CMAKE_FLAGS:STRING=-DBUILD_TEST=ON -DBUILD_DOC=ON 
-DBUILD_DOX_DOC=ON
```

> Finally, how can I change the default tag currently used
> ("plplot-5.13.0") for checking out PLplot?

I've added an option:

```
CMake_TEST_CONTRACT_PLplot_GIT_TAG:STRING=plplot-5.12.0
```

The value can be anything that `git checkout` understands
(tag, branch, commit sha1, etc.).

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-11-07 Thread Alan W. Irwin

On 2017-11-07 07:14-0500 Brad King wrote:


On 11/06/2017 05:24 PM, Alan W. Irwin wrote:

https://open.cdash.org/viewTest.php?onlypassed&buildid=5131552
Is there something I have missed in those results or something wrong?


Your script now has:

```
set(dashboard_cache "
...
# Do build of PLplot as a ctest of CMake.
set(CMake_TEST_CONTRACT_PLplot:BOOL=ON)
...
")
```

but it should be:

```
set(dashboard_cache "
...
// Do build of PLplot as a test of CMake.
CMake_TEST_CONTRACT_PLplot:BOOL=ON
...
")
```



Why could I set garbage in the cache
file as above with the result that that garbage was read
and ignored with no error message?  Isn't that a CMake bug?


Your suggested change above does work, but the default PLplot
configuration only enables part of the potential configure, build, and install
tests.  Therefore, to remove that limitation on this test, I would like to set 
the
following CMake options in the PLplot configure step:

-DBUILD_TEST:BOOL=ON -DBUILD_DOC=ON -DBUILD_DOX_DOC=ON

(to build additional PLplot examples in the build tree, to build the
DocBook documentation, and to build the Doxygen documentation.)

I tried

set(dashboard_cache "
...
CMake_TEST_CONTRACT_PLplot_CMAKE_ARGS:STRING=-DBUILD_TEST=ON -DBUILD_DOC=ON 
-DBUILD_DOX_DOC=ON
...
)

and that partially works:  The relevant PLplot CMakeCache.txt file
includes the line

BUILD_TEST=ON -DBUILD_DOC=ON -DBUILD_DOX_DOC=ON


From the results, the first part of that line is

accepted and the rest ignored (rather than erroring out, see aside
above).  So what syntax do I have to use to set

BUILD_TEST=ON
BUILD_DOC=ON
BUILD_DOX_DOC=ON

on separate lines in the PLplot CMakeCache.txt file?

Finally, how can I change the default tag currently used
("plplot-5.13.0") for checking out PLplot?

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
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-11-07 Thread Brad King
On 11/06/2017 05:24 PM, Alan W. Irwin wrote:
> https://open.cdash.org/viewTest.php?onlypassed&buildid=5131552
> Is there something I have missed in those results or something wrong?

Your script now has:

```
set(dashboard_cache "
...
# Do build of PLplot as a ctest of CMake.
set(CMake_TEST_CONTRACT_PLplot:BOOL=ON)
...
")
```

but it should be:

```
set(dashboard_cache "
...
// Do build of PLplot as a test of CMake.
CMake_TEST_CONTRACT_PLplot:BOOL=ON
...
")
```

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-11-06 Thread Alan W. Irwin

On 2017-11-06 11:01-0500 Brad King wrote:


On 10/30/2017 11:38 AM, Brad King wrote:

FYI I'm refactoring the way the existing contract tests work to make
it easier to add and maintain one for PLplot.  Once that is done I'll
look at actually adding PLplot and report back here.


I've opened a MR to add the PLplot contract test here:

* https://gitlab.kitware.com/cmake/cmake/merge_requests/1452

Please revise your dashboard script to add the following line to
the `dashboard_cache` setting:

```
CMake_TEST_CONTRACT_PLplot:BOOL=ON
```

The MR is already staged so this should activate the contract
test on the next build after you update the script.


Hi Brad:

I followed the above directions in Experimental mode (and also
they will be followed later in Nightly mode as well).

But I can see nothing related to a PLplot git checkout, configuration
or build in the Experimental mode results, see
.

Is there something I have missed in those results or something wrong?

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
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-11-06 Thread Brad King
On 10/30/2017 11:38 AM, Brad King wrote:
> FYI I'm refactoring the way the existing contract tests work to make
> it easier to add and maintain one for PLplot.  Once that is done I'll
> look at actually adding PLplot and report back here.

I've opened a MR to add the PLplot contract test here:

* https://gitlab.kitware.com/cmake/cmake/merge_requests/1452

Please revise your dashboard script to add the following line to
the `dashboard_cache` setting:

```
CMake_TEST_CONTRACT_PLplot:BOOL=ON
```

The MR is already staged so this should activate the contract
test on the next build after you update the script.

Thanks,
-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-10-31 Thread Brad King
On 10/30/2017 12:54 PM, Alan W. Irwin wrote:
> superficially appears that some of the tests are timing out.

No, they are passing.  The time status column is for trying to detect
tests that suddenly jump in time required.  It's based on some kind of
model of the time that takes a while for CDash to stabilize.

> the output from the test is being truncated because
> it is over the rather small 1024 default limit.

This is done for passing tests to reduce the amount uploaded.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-10-30 Thread Alan W. Irwin

Hi Brad:

If you look at
 it
superficially appears that some of the tests (e.g., BootstrapTest) are timing 
out. But if
you look deeper, the output from the test is being truncated because
it is over the rather small 1024 default limit.

I have checked the aaargh.kitware.com dashboard, and the BootstrapTest
results for that case do not show this issue, i.e., they are quite
large and clearly beyond the 1024 default limit so I suspect what has
occurred for aaargh.kitware.com is this problem has been corrected on
an individual basis.

Could I do that for the raven results by, e.g.,

set(CTEST_CUSTOM_MAXIMUM_PASSED_TEST_OUTPUT_SIZE 10240)
set(CTEST_CUSTOM_MAXIMUM_FAILED_TEST_OUTPUT_SIZE 10240)

in my my_dashboard.cmake file or is the fix for this truncation issue
more complex than that?

In any case I suggest it would be better for you to implement
the fix for this issue in cmake_common.cmake so those who submit CMake
dashboards don't have to fix this issue individually.

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
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-10-30 Thread Brad King
On 10/26/2017 01:10 PM, Brad King wrote:
> Thanks.  I'll take a look at adding a test to build that when I get
> a chance.

FYI I'm refactoring the way the existing contract tests work to make
it easier to add and maintain one for PLplot.  Once that is done I'll
look at actually adding PLplot and report back here.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-10-27 Thread Alan W. Irwin

On 2017-10-27 07:02-0400 Brad King wrote:


On 10/26/2017 09:58 PM, Alan W. Irwin wrote:

However, one of the deficiencies of this third method is the
bootstrap script only pays attention to CXXFLAGS and CFLAGS when
setting compile flags for building the preliminary version of CMake

[...]


You could do this to apply flags to bootstrap and configuration
steps but not to the tests:

```
set(ENV{CXXFLAGS} "-O3 -DNDEBUG")
set(ENV{CFLAGS} "-O3 -DNDEBUG")
set(CTEST_BUILD_CONFIGURATION "")
macro(dashboard_hook_build)
 unset(ENV{CXXFLAGS})
 unset(ENV{CFLAGS})
endmacro()
```


Thanks for that idea which I have adopted (using
set(CTEST_BUILD_CONFIGURATION "Release")).  It generates perfect
dashboards (see the Experimental raven result for today).

Should at least some of these considerations concerning CXXFLAGS and
CFLAGS (e.g., they normally should be unset to assure a standard build
configuration corresponding to CTEST_BUILD_CONFIGURATION) be
documented in comments in cmake_common.cmake?

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
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-10-27 Thread Brad King
On 10/26/2017 09:58 PM, Alan W. Irwin wrote:
> While trying to set up a clean Experimental dashboard, I have noticed
> a minor spelling issue (furhter ==> further in
> a comment in cmake_common.cmake).

Fixed, thanks.

> unset(ENV{CXXFLAGS})
> unset(ENV{CFLAGS})
> unset(ENV{FFLAGS})
> set(CTEST_BUILD_CONFIGURATION Release)

This is the intended way for dashboard scripts.

> That gave a completely clean result (see the second Experimental
> "raven" results on 2017-10-26 for commit fc3668). I also followed up
> with a Nightly raven result (generated by crontab).  That also gave a
> perfectly clean result (see the first Nightly "raven" results on
> 2017-10-26 for commit da363e).  So it looks like I am basically in
> business (except for the PLplot build part of the test that you
> plan to work on as time permits).

Great!

> However, one of the deficiencies of this third method is the
> bootstrap script only pays attention to CXXFLAGS and CFLAGS when
> setting compile flags for building the preliminary version of CMake so
> that build is unoptimized in this case which will significantly add to
> the time taken to configure the build of the full version of CMake

I doubt it would make much difference.  Most of the configuration
time is spent waiting for try_compile to complete and such, though
I've never timed it.

You could do this to apply flags to bootstrap and configuration
steps but not to the tests:

```
set(ENV{CXXFLAGS} "-O3 -DNDEBUG")
set(ENV{CFLAGS} "-O3 -DNDEBUG")
set(CTEST_BUILD_CONFIGURATION "")
macro(dashboard_hook_build)
  unset(ENV{CXXFLAGS})
  unset(ENV{CFLAGS})
endmacro()
```

> debug whatever is wrong on the CMake end for those 4 test failures.

That would be nice if anyone has time.  However, I think at least some
of them may be testing per-config behavior, so by adding `-DNDEBUG`
to the all-config flags they get confused.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-10-26 Thread Alan W. Irwin

Hi Brad:

While trying to set up a clean Experimental dashboard, I have noticed
a minor spelling issue (furhter ==> further in
a comment in cmake_common.cmake).

I also noticed a somewhat more serious issue concerning the consistency
of build flags.  I attempted to use consistent compile flags as
follows:

set(ENV{CXXFLAGS} "-O3 -DNDEBUG")
set(ENV{CFLAGS} "-O3 -DNDEBUG")
set(CTEST_BUILD_CONFIGURATION None)

This "first" method apparently did generate consistent build flags,
but the complex, complexOneConfig, Preprocess, and Qt4Deploy tests
failed (see the first Experimental "raven" results on 2017-10-26 for
commit fc3668).

A similar test with None replaced above by Release (call this the
"second" method) was headed to a
similar failure (I noticed Preprocess had failed and quit the test before
it encountered the other 3 failures and before a dashboard was submitted).

So I fell back to using a "third" method which was

unset(ENV{CXXFLAGS})
unset(ENV{CFLAGS})
# Just in case any of the Fortran tests pay attention to FFLAGS which
# I often set.
unset(ENV{FFLAGS})
set(CTEST_BUILD_CONFIGURATION Release)

That gave a completely clean result (see the second Experimental
"raven" results on 2017-10-26 for commit fc3668). I also followed up
with a Nightly raven result (generated by crontab).  That also gave a
perfectly clean result (see the first Nightly "raven" results on
2017-10-26 for commit da363e).  So it looks like I am basically in
business (except for the PLplot build part of the test that you
plan to work on as time permits).

However, one of the deficiencies of this third method is the
bootstrap script only pays attention to CXXFLAGS and CFLAGS when
setting compile flags for building the preliminary version of CMake so
that build is unoptimized in this case which will significantly add to
the time taken to configure the build of the full version of CMake
(although that time is likely negligible compared to the time required
to pass all the 500 tests).

If you know of a simple way to fix this inconsistency between the
compile flags used to build the preliminary and final versions of
CMake, please let me know.

I thought the first method I tried above would do exactly that (since
the adopted CXXFLAGS and CFLAGS should give you exactly the same as
"Release" on Linux, but that method also causes those four test
failures for unknown reasons. So if you feel the first method should
be supported, then the solution of this issue would be to debug
whatever is wrong on the CMake end for those 4 test failures.

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
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-10-26 Thread Brad King
On 10/26/2017 11:53 AM, Alan W. Irwin wrote:
> git://git.code.sf.net/p/plplot/plplot

Thanks.  I'll take a look at adding a test to build that when I get
a chance.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-10-26 Thread Alan W. Irwin

On 2017-10-26 08:36-0400 Brad King wrote:


Once an experimental submission is clean, please switch the model to
Nightly and schedule a cron job to run it sometime after 1:15am UTC.


Will do.




So what is the next step toward the goal of adding a test consisting
of a build of PLplot?


We need to add a contract test to CMake's source so that one of the
tests that your nightly build runs is an entire build of PLplot.
What is your official Git repository URL?


git://git.code.sf.net/p/plplot/plplot

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
__
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers


Re: [cmake-developers] PLplot contract test

2017-10-26 Thread Brad King
On 10/25/2017 03:43 PM, Alan W. Irwin wrote:
> In any case, my dashboard submission is working now using
> 
> ctest -S ~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV

Great!

> See the raven-without-fixed-IP

The `-without-fixed-IP` suffix has no meaning to readers on CDash.

> perfect other than one CMake configure warning due to a minor system
> issue (misspelled COPYONLY as COPY_ONLY) with Debian Jessie Qt5 which

We cannot let that warning persist on the dashboard because it may
distract from other real warnings that show up.  You could try dropping
`BUILD_QtDialog:BOOL=1` to avoid it.  You won't need cmake-gui built
to test PLplot, and we have plenty of other builders that cover it.

Once an experimental submission is clean, please switch the model to
Nightly and schedule a cron job to run it sometime after 1:15am UTC.

> So what is the next step toward the goal of adding a test consisting
> of a build of PLplot?

We need to add a contract test to CMake's source so that one of the
tests that your nightly build runs is an entire build of PLplot.
What is your official Git repository URL?

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers