[cmake-developers] On-going UseSWIG troubles with the official versions

[Alan W. Irwin]

On 2017-04-23 17:10+0200 Rolf Eike Beer wrote:


The somewhat longer story is just at the start (fortunately for me) of
that simplification process, I double checked the source of both
FindSWIG.cmake and UseSWIG.cmake as used by PLplot, and those turned
out to be special cutting-edge versions recommended by one user of the
cmake bug tracking system from a decade (!) ago.  Oops!  Those
versions did continue to work for a very long time for our simple swig
needs, but those are obviously well past their "best buy" date, and
complete removal of those "special" versions from PLplot (so PLplot is
now using the official version of those modules that is distributed by
whatever CMake version a user chooses) works without the warning
messages for both CMake-3.0.2 AND CMake-3.8.0-rc4.


So something in that range of versions has broken those old modules. It would
be interesting to find out if that was breaking a never-really-supported case
or something else.


Hi Rolf:

It turns out I will be following up on that question because (sigh) my
further testing showed the versions of FindSWIG.cmake and
UseSWIG.cmake from CMake-3.0.2 has build failures for Java and Lua,
and the versions from CMake-3.6.2 and 3.8.0-rc4 have build failures
for Java even though none of these "official" versions exhibited the
rule contamination.  And, of course, our special versions of
FindSWIG.cmake and UseSWIG.cmake built our Python, Java, Lua, and
Octave bindings without any issues (except for the peculiar rule
contamination between Python and _Pltk_init).  So the current status
is the official versions partly fail, and the special versions partly
fail in a completely different way (ugh).

For the official versions, the consistently good results for Python
and Octave and the lack of rule contamination that is obtained argue
that my overall goal should be to figure out how to make PLplot use
the official versions without any errors for Lua and Java.  So more
later once I get this mess untangled using many different diff results
between the various versions of FindSWIG.cmake and UseSWIG.cmake and
comparing how our CMake code uses the UseSWIG facilities for Lua and
Java compared to the rest of our swig-generated bindings.

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] [UseSWIG] regression in results from CMake-3.0.2 to recent versions --SOLVED

[Rolf Eike Beer]

> The somewhat longer story is just at the start (fortunately for me) of
> that simplification process, I double checked the source of both
> FindSWIG.cmake and UseSWIG.cmake as used by PLplot, and those turned
> out to be special cutting-edge versions recommended by one user of the
> cmake bug tracking system from a decade (!) ago.  Oops!  Those
> versions did continue to work for a very long time for our simple swig
> needs, but those are obviously well past their "best buy" date, and
> complete removal of those "special" versions from PLplot (so PLplot is
> now using the official version of those modules that is distributed by
> whatever CMake version a user chooses) works without the warning
> messages for both CMake-3.0.2 AND CMake-3.8.0-rc4.

So something in that range of versions has broken those old modules. It would 
be interesting to find out if that was breaking a never-really-supported case 
or something else.

Eike

signature.asc
Description: This is a digitally signed message part.
-- 

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] [UseSWIG] regression in results from CMake-3.0.2 to recent versions --SOLVED

[Alan W. Irwin]

On 2017-04-22 21:46-0700 Alan W. Irwin wrote:


So my next steps are gross simplification (to prove this
cross-contamination of build rules for UseSWIG-generated modules in
the same CMakeLists.txt file really is due to a regression in CMake
somewhere between CMake-3.0.2 and 3.7.2.  Note that both CMake-3.7.2
and CMake-3.8.0-rc4 show the warning problem.)


Well, the short story is there was no such regression.  Note the
"--SOLVED" in the revised subject line.  Also, sorry for the noise!

The somewhat longer story is just at the start (fortunately for me) of
that simplification process, I double checked the source of both
FindSWIG.cmake and UseSWIG.cmake as used by PLplot, and those turned
out to be special cutting-edge versions recommended by one user of the
cmake bug tracking system from a decade (!) ago.  Oops!  Those
versions did continue to work for a very long time for our simple swig
needs, but those are obviously well past their "best buy" date, and
complete removal of those "special" versions from PLplot (so PLplot is
now using the official version of those modules that is distributed by
whatever CMake version a user chooses) works without the warning
messages for both CMake-3.0.2 AND CMake-3.8.0-rc4. In fact (as I
expected since I am an optimist) but unlike the extremely peculiar
result I had before, inspection of
bindings/python/CMakeFiles/_Pltk_init.dir/build.make showed no
contamination from plplotc rules at all.

So problem solved completely!  Thus, thanks to swig, and official
versions of FindSWIG.cmake and UseSWIG.cmake that vary with CMake
version but which are good enough for our needs despite that
variation, I now have my test of our Tcl/Tk "plframe" plotting GUI
working well for both Python 2 and Python 3 for a very large range of
CMake versions.

I hasten to add we will not support that large a range of CMake
versions too much longer although that supported range actually helped
to figure out the current problem. Indeed, I soon plan to bump our
minimum CMake version from 3.0.2 to 3.6.2 which will allow me to
greatly simplify our build system by stripping out a whole lot of
cruft that was necessary to work around issues that existed for quite
a few versions after CMake-3.0.2 was released.

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] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?

[Konstantin Podsvirov]

23.04.2017, 12:26, "Alan W. Irwin" :
> On 2017-04-23 10:24+0300 Konstantin Podsvirov wrote:
>
>>  Hi Alan!
>>
>>  23.04.2017, 10:01, "Alan W. Irwin" :
>>>  On 2017-04-23 08:30+0300 Konstantin Podsvirov wrote:
>>>
   Where execute_process INPUT_CONTENT or INPUT_VARIABLE?

   This would be very convenient for a small input.

   Why should I always write a file for input?
>>>
>>>  Hi Konstantin:
>>>
>>>  I assume that last sentence refers to using the CMake FILE command
>>>  directly to write the required file at cmake time in the build tree
>>>  (as opposed to having to create an actual permanent file in the source
>>>  tree to be used directly or as a prototype for a configured file in
>>>  the build tree)? If so, I use that approach quite a bit in various
>>>  build systems I have helped to develop to help drastically reduce the
>>>  number of small CMake-related files in the source tree. And I far
>>>  prefer that approach to what you seem to be asking for above which is
>>>  some added syntax variation to EXECUTE_PROCESS to provide the same
>>>  ability that the FILE command currently has.
>>>
>>>  Note, I had to make some assumptions when answering you, and my
>>>  apologies in advance if I have misinterpreted anything you said
>>>  above.
>>
>>  You have correctly understood and assumed. Thanks for your reply.
>
>>  But imagine that we need to perform a simple process and process its
>
> standard output. But this process unfortunately awaits user input to
> complete.
>
> Interesting use case!
>
> Of course, if it is really simple user input to the process involving
> just a few values, then for that use case the user could enter those
> values via environment variables or CMake variables while the designed
> build system writes those via FILE to a temporary file in the right
> order that is then read by the process that is being executed by
> execute_process. But that idea becomes clumsy as the number of values
> increases. So I agree it would be useful to deal with the case where
> user input of a substantial number of values via stdin (presumably
> interactively prompted by the process to help guide that user input)
> is the best and most flexible way to control the process.

No. Do not complicate things. You do not need to implement interactive 
communication with the user through CMake streams.
I just want to add the convenient INPUT_CONTENT and INPUT_VARIABLE options.
The input data is known in advance, even before the process is started.

> One possibility to address that use case is whenever an appropriate
> optional argument was specified to execute_process, i.e., that
> execute_process command had the correct optional signature, then, for
> example, you could connect cmake stdin with the stdin for the process
> that is being executed by execute_process.
>
> Of course, one concern with this solution for the use case might be
> this makes the user build process difficult for a project's developers
> to debug in case the whole thing is failing because the user typed in
> the wrong stdin data for the process. But I would argue against that
> concern because this capability does give CMake-based build-system
> designers more power and freedom which I fundamentally like as such a
> build-system designer. And with each such additional increase in power
> and freedom of CMake, build-system designers have a documentation
> responsibility (i.e., in this case documenting exactly the stdin user
> choices for the process they have forced users to run at cmake time
> with execute_process), and the process design responsibility
> (sanitizing user input, prompting user input, etc.). Also
> build-system users have the responsibility of reading that process
> input documentation! :-)
>
> I must stop there because I have test project simplification and very
> likely git bisect work to do on a completely different issue I have
> raised here today.
>
> 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
> __

--
Regards,
Konstantin Podsvirov
-- 

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: 

Re: [cmake-developers] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?

[Alan W. Irwin]

On 2017-04-23 10:24+0300 Konstantin Podsvirov wrote:


Hi Alan!

23.04.2017, 10:01, "Alan W. Irwin" :

On 2017-04-23 08:30+0300 Konstantin Podsvirov wrote:


 Where execute_process INPUT_CONTENT or INPUT_VARIABLE?

 This would be very convenient for a small input.

 Why should I always write a file for input?


Hi Konstantin:

I assume that last sentence refers to using the CMake FILE command
directly to write the required file at cmake time in the build tree
(as opposed to having to create an actual permanent file in the source
tree to be used directly or as a prototype for a configured file in
the build tree)? If so, I use that approach quite a bit in various
build systems I have helped to develop to help drastically reduce the
number of small CMake-related files in the source tree. And I far
prefer that approach to what you seem to be asking for above which is
some added syntax variation to EXECUTE_PROCESS to provide the same
ability that the FILE command currently has.

Note, I had to make some assumptions when answering you, and my
apologies in advance if I have misinterpreted anything you said
above.


You have correctly understood and assumed. Thanks for your reply.




But imagine that we need to perform a simple process and process its

standard output. But this process unfortunately awaits user input to
complete.

Interesting use case!

Of course, if it is really simple user input to the process involving
just a few values, then for that use case the user could enter those
values via environment variables or CMake variables while the designed
build system writes those via FILE to a temporary file in the right
order that is then read by the process that is being executed by
execute_process.  But that idea becomes clumsy as the number of values
increases. So I agree it would be useful to deal with the case where
user input of a substantial number of values via stdin (presumably
interactively prompted by the process to help guide that user input)
is the best and most flexible way to control the process.

One possibility to address that use case is whenever an appropriate
optional argument was specified to execute_process, i.e., that
execute_process command had the correct optional signature, then, for
example, you could connect cmake stdin with the stdin for the process
that is being executed by execute_process.

Of course, one concern with this solution for the use case might be
this makes the user build process difficult for a project's developers
to debug in case the whole thing is failing because the user typed in
the wrong stdin data for the process.  But I would argue against that
concern because this capability does give CMake-based build-system
designers more power and freedom which I fundamentally like as such a
build-system designer. And with each such additional increase in power
and freedom of CMake, build-system designers have a documentation
responsibility (i.e., in this case documenting exactly the stdin user
choices for the process they have forced users to run at cmake time
with execute_process), and the process design responsibility
(sanitizing user input, prompting user input, etc.).  Also
build-system users have the responsibility of reading that process
input documentation!  :-)

I must stop there because I have test project simplification and very
likely git bisect work to do on a completely different issue I have
raised here today.

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] Where execute_process INPUT_CONTENT or INPUT_VARIABLE?

[Konstantin Podsvirov]

Hi Alan!

23.04.2017, 10:01, "Alan W. Irwin" :
> On 2017-04-23 08:30+0300 Konstantin Podsvirov wrote:
>
>>  Where execute_process INPUT_CONTENT or INPUT_VARIABLE?
>>
>>  This would be very convenient for a small input.
>>
>>  Why should I always write a file for input?
>
> Hi Konstantin:
>
> I assume that last sentence refers to using the CMake FILE command
> directly to write the required file at cmake time in the build tree
> (as opposed to having to create an actual permanent file in the source
> tree to be used directly or as a prototype for a configured file in
> the build tree)? If so, I use that approach quite a bit in various
> build systems I have helped to develop to help drastically reduce the
> number of small CMake-related files in the source tree. And I far
> prefer that approach to what you seem to be asking for above which is
> some added syntax variation to EXECUTE_PROCESS to provide the same
> ability that the FILE command currently has.
>
> Note, I had to make some assumptions when answering you, and my
> apologies in advance if I have misinterpreted anything you said
> above.

You have correctly understood and assumed. Thanks for your reply.

But imagine that we need to perform a simple process and process its standard 
output. But this process unfortunately awaits user input to complete.

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

My suggestion:

Add support for the INPUT_CONTENT or INPUT_VARIABLE arguments in 
execute_process command.

It seems to me that this will be a very useful improvement.

Will anyone take up the implementation of this improvement?

--
Regards,
Konstantin Podsvirov
-- 

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