Re: [CMake] #cmakedefine vs #define

[Alan W. Irwin]

On 2011-03-15 16:26-0600 Balamurali Ananthan wrote:


Hello,

Sorry if this question is too primitive. I am trying to extract the build dir 
into the source code by populating it in a variable in my config.h file.


I do this by adding the following line in config.h.in

#cmakedefine PROJ_BUILD_DIR_CMAKEDEFINE ${PROJECT_BINARY_DIR}

In the config.h, this produces

/* #undef PROJ_BUILD_DIR_CMAKEDEFINE */



But if i replace it to this in config.h.in,

#define PROJ_BUILD_DIR_DEFINE ${PROJECT_BINARY_DIR}

Then the right value is populated in the config.h

#define PROJ_BUILD_DIR_DEFINE /home/bala/projects/myproj/trunk/builds

Wondering why didn't the cmakedefine work in this case? Any clues?


The man page for cmake covers this.  #cmakedefine VAR will be
replaced with either #define VAR or /* #undef VAR  */
depending on  the  setting  of  VAR in CMake.

Note that VAR is the CMake variable name and not its value.
PROJ_BUILD_DIR_CMAKEDEFINE does not exist as a CMake variable in your
project so its CMake value is false and you get the above commented
out #undef result just like the man page says.  OTOH if you had
specified instead,

#cmakedefine PROJECT_BINARY_DIR

that would have configured (since PROJECT_BINARY_DIR is True in the
CMake sense for your project) as

#define PROJECT_BINARY_DIR

Of course, that would not have been too helpful to you since there is
no associated explicit value, but note #cmakedefine is quite useful
for the case of conditional programming depending on #ifdef (i.e.,
True/False binary macro logic).

For cases where you need to #define an explicit value, then you should
forget about #cmakedefine and use the configured #define (as you did
above).

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] One too many ../ instances in the relative paths generated by file(GLOB_RECURSE variable RELATIVE ...)

[Alan W. Irwin]

I am using the following CMake code fragment to collect file depends for a 
custom
target that generatates doxygen documentation:

  # Collect essentially same source code dependencies that are in Doxyfile
  # including most of the template files for configured code files.
  set(doxygen_prefixes  
*.c;*.cc;*.cxx;*.cpp;*.c++;*.d;*.java;*.h;*.py;*.f90;*.f)
  set(doxygen_directories libs;src;bindings;drivers;include)
  set(doxygen_globs)
  foreach(directory ${doxygen_directories})
foreach(prefix ${doxygen_prefixes})
  list(APPEND doxygen_globs ${CMAKE_SOURCE_DIR}/${directory}/${prefix})
endforeach(prefix ${doxygen_prefixes})
  endforeach(directory ${doxygen_directories})
  #message(STATUS DEBUG: doxygen_globs = ${doxygen_globs})

  file(GLOB_RECURSE doxygen_file_depends ${doxygen_globs})
  # message(STATUS DEBUG: doxygen_file_depends = ${doxygen_file_depends})

All is well with the file dependencies generated this way.  When I
touch (say) include/plplot.h, the doxygen documentation is regenerated
just like I want when I run the custom target.  However, I noticed
that the doxygen_globs list was getting really huge due to the
long absolute pathnames so out of curiosity I tried

file(GLOB_RECURSE doxygen_file_depends RELATIVE ${doxygen_globs})

instead, and the result has one too many ../ instances in
the relative paths.  That is, when I run the custom target, the
result is

make[3]: *** No rule to make target
/home/software/plplot_svn/HEAD/plplot_cmake_qt/doc/../../include/ps.h',
needed by doc/doxygen'.  Stop.

Note, doc and include are subdirectories of the top-level source
directory, /home/software/plplot_svn/HEAD/plplot_cmake_qt so there
is one too many ../ instances in the above relative path, and I
have printed out doxygen_globs to verify that this issue
occurs for all relative paths.

Is this extra ../ issue with GLOB_RECURSE and RELATIVE for
the file command a known bug?

I happen to have run this test with cmake-2.8.4-rc2, although I
would be happy to move to 2.8.4 instead if anybody is having
trouble replicating this 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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] One too many ../ instances in the relative paths generated by file(GLOB_RECURSE variable RELATIVE ...)

[Alan W. Irwin]

On 2011-03-19 07:32+0100 Michael Hertling wrote:


On 03/18/2011 09:28 PM, Alan W. Irwin wrote:

I am using the following CMake code fragment to collect file depends for a 
custom
target that generatates doxygen documentation:

   # Collect essentially same source code dependencies that are in Doxyfile
   # including most of the template files for configured code files.
   set(doxygen_prefixes  
*.c;*.cc;*.cxx;*.cpp;*.c++;*.d;*.java;*.h;*.py;*.f90;*.f)
   set(doxygen_directories libs;src;bindings;drivers;include)
   set(doxygen_globs)
   foreach(directory ${doxygen_directories})
 foreach(prefix ${doxygen_prefixes})
   list(APPEND doxygen_globs ${CMAKE_SOURCE_DIR}/${directory}/${prefix})
 endforeach(prefix ${doxygen_prefixes})
   endforeach(directory ${doxygen_directories})
   #message(STATUS DEBUG: doxygen_globs = ${doxygen_globs})

   file(GLOB_RECURSE doxygen_file_depends ${doxygen_globs})
   # message(STATUS DEBUG: doxygen_file_depends = ${doxygen_file_depends})

All is well with the file dependencies generated this way.  When I
touch (say) include/plplot.h, the doxygen documentation is regenerated
just like I want when I run the custom target.  However, I noticed
that the doxygen_globs list was getting really huge due to the
long absolute pathnames so out of curiosity I tried

file(GLOB_RECURSE doxygen_file_depends RELATIVE ${doxygen_globs})


AFAICS, the first item in doxygen_globs is taken as the path the
following items are to be relative to. You probably need to say:

file(GLOB_RECURSE doxygen_file_depends
RELATIVE ${CMAKE_SOURCE_DIR} ${doxygen_globs})
 ^^^


Hi Michael:

Actually, the working directory for the custom command that runs
doxygen and which needs the file dependencies is the (default)
${CMAKE_CURRENT_SOURCE_DIR} for my example so I tried RELATIVE
${CMAKE_CURRENT_SOURCE_DIR} in the spirit of what you suggested, and it
works (i.e., file dependencies work) and provides much shorter paths
for each of the list elements.

Thanks for your help (especially the simple illustrative example that
clarified how to use RELATIVE).  I note the cmake documentation for
GLOB_RECURSE does say [RELATIVE path], but at one point I had
convinced myself through some experiments that were yielding no
results at all that that path was a misprint so I dropped it for all
further experiments.  The whole adventure illustrates the fundamental
principle of cmake debugging which is to try a simple example to
clarify documentation you don't quite understand.  That principle is
especially true in the present case because the lists involved in the
real example have several hundred elements.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] 2.8.4 order of tests

[Alan W. Irwin]

On 2011-02-21 12:42-0500 David Cole wrote:


This should be fixed already in CMake's 'next' branch. If you can try
a nightly installer, or build yourself from 'next', let me know if
there is still any problem.

Fix will be in 2.8.5 when it comes out in a few months.


I got bitten by this bug today in 2.8.4 so I am glad Allen found it
earlier, and it will be fixed in 2.8.5.

My own use case is I don't particularly care about the order of the tests 
except that one
of them is dependent on most of the rest as I discovered when the
tests were run in an unusual order with CMake-2.8.4.  Running the 
set_tests_properties
command according to
http://cmake.org/cmake/help/cmake-2-8-docs.html#prop_test:DEPENDS
works around the issue and is probably a good idea in general when one
test depends on others.

Note, however, that although most PLplot users are presumably using
cmake-2.8.x, PLplot users are still allowed to use cmake-2.6.4 (and
that will continue a bit longer). Thus, I had to surround the
set_tests_properties command with this CMake version check;

if(CMAKE_MAJOR_VERSION EQUAL 2 AND NOT CMAKE_MINOR_VERSION LESS 8)

because DEPENDS does not exist in cmake-2.6.x as a test property
according to the cmake-2.6.x documentation.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Bug fix requests for the *next* release of CMake...

[Alan W. Irwin]

On 2011-03-29 13:56-0400 David Cole wrote:


Hi all,

Now that we have released CMake 2.8.4, *now* would be a great time to 
prioritize bug fixes for the next release of CMake.

Replies requested. Read on. Just a short reply with bug numbers or links to 
the bugs is all we need here. Please move specific
discussions into the bugs themselves or start a new thread to talk about it... 
Replies on this thread should just be a collector for bug
numbers.


Please do a fundamental fix for http://public.kitware.com/Bug/view.php?id=9220.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Updated: CMake 2.8.4-1

[Alan W. Irwin]

On 2011-05-19 10:55-0400 Bill Hoffman wrote:


CMake 2.8.4-1  is now available on Cygwin mirrors.


Hi Bill:

Could you give some background information about why you create a
binary version of cmake for Cygwin that is separated in time and
location from the usual binaries that come with any release of cmake?

Could any Cygwin user create that binary using an older Cygwin cmake
binary + source code?  Or are additional Cygwin-only cmake source code
patches and/or special configuration required as well?

IOW, is there anything special going on here or is this just a routine
binary build of cmake for Cygwin users' convenience?

I am interested in the requested background information because I hope
to test builds of cmake, PLplot, and other software shortly under
wine/Cygwin.  (Similar to my earlier build tests of cmake, etc. on a
wine/MinGW/MSYS platform.)

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Updated: CMake 2.8.4-1

[Alan W. Irwin]

On 2011-05-19 14:19-0400 Bill Hoffman wrote:


On 5/19/2011 2:11 PM, Alan W. Irwin wrote:

On 2011-05-19 10:55-0400 Bill Hoffman wrote:


CMake 2.8.4-1 is now available on Cygwin mirrors.


Hi Bill:

Could you give some background information about why you create a
binary version of cmake for Cygwin that is separated in time and
location from the usual binaries that come with any release of cmake?

Could any Cygwin user create that binary using an older Cygwin cmake
binary + source code? Or are additional Cygwin-only cmake source code
patches and/or special configuration required as well?

IOW, is there anything special going on here or is this just a routine
binary build of cmake for Cygwin users' convenience?

I am interested in the requested background information because I hope
to test builds of cmake, PLplot, and other software shortly under
wine/Cygwin. (Similar to my earlier build tests of cmake, etc. on a
wine/MinGW/MSYS platform.)



My bad, I will try to be better about it in the future.  I have no good 
excuse.  :)


Actually, I didn't mean to question why this Cygwin release of cmake
was later than the normal release of cmake-2.8.4.  (These things
happen.) But the separate nature of all the Cygwin releases (not just
this one) got me curious about whether there are any special
circumstances for building cmake on Cygin compared to the other
platforms you cover in your normal release.  If there is nothing
special (i.e., bog-standard cmake on Cygwin with no special
configuration or patches), please let me know as well.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake pod cast

[Alan W. Irwin]

On 2011-05-26 22:14-0400 Bill Hoffman wrote:

Last week I did an interview for the High Performance Computing (HPC) and 
Research Computing Podcast.  It can be found here:


http://www.rce-cast.com/


I enjoyed that interview.  For example, I suspect that
autotools-oriented guy will take a look at CMake because of the
information you gave him.

Thanks for that link.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] TGZ installer following links

[Alan W. Irwin]

On 2011-06-22 12:04-0400 Bill Hoffman wrote:


On 6/21/2011 4:43 PM, Alan W. Irwin wrote:


So it is not a regression, but in my opinion it is still a bug.

More comments at http://public.kitware.com/Bug/view.php?id=12284.

Please fix.



Patches are welcome, please send one...   It would have to be an option 
somehow at this point so as not to break existing code.


I am fine with such an option.  GNU tar (at least) also has an option
to follow symlinks or not.  Of course, the CPack option will have
a different default than the GNU tar one, but that is required for
CPack backwards compatibility.

I don't understand C++ or the C++ internals of CMake well enough to
put together a patch to solve this issue.  So I am limited to helping
you guys out by doing testing to help clarify CMake bug issues and
commenting on the practical implications of certain CMake bug reports
like this one for the build systems of software projects like PLplot
and FreeEOS to give you a better idea of what is at stake.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Parallel make custom command

[Alan W. Irwin]

On 2011-06-30 22:15+0200 Alexander Neundorf wrote:


On Wednesday 29 June 2011, Marcel Loose wrote:
...

After I had posted my question I realized that this issue has come up
quite recently on the mailing list in a thread that I started -- see
http://www.mail-archive.com/cmake@cmake.org/msg36362.html. Although the
original question was related to building mulitple targets in parallel,
Michael Hertling showed that CMake inherently has problems with parallel
builds when custom targets/commands come into play.


Really ?
We use a lot of custom commands in KDE, all the time, everywhere, and people
build KDE on big build clusters, i.e. very parallel, without problems.

Maybe there are problems when multiple targets depend on the same generated
file, but I think the cmake inherently has problems with parallel builds when
custom targets/commands come into play. is wrong in this very generic way.


I agree with Alex here.  It is always possible, of course, to set up
custom commands and custom targets properly so that parallel builds
work correctly.  The trick is to avoid two or more targets depending
on the same custom command.  So bug 0012311 should just be closed
since that is based on a misunderstanding of how to properly set up
custom commands and targets.

The above rule of thumb is easy to implement for simple build systems,
but for complex build systems it is easy to make file or target
dependency mistakes so that parallel builds do not work correctly.
This is the number-one issue I have had difficulty with for our PLplot
CMake-based build system because that system has lots of custom
commands and a complex web of file and target dependencies that
changes each time we add new build or test features.

To help with the general difficulty of getting dependencies right,
would it be possible to implement a CMake change so that for a given
flag (say --check-dependencies) the cmake application issued warnings
for file and target dependency issues that would cause problems for
parallel builds for a given CMake-based build system?  That would help
a lot to solve this topic that keeps coming up again and again on this
list and also make existing CMake-based build systems much easier to
maintain.

Assuming such a change was implemented, then the standard FAQ response
to this topic would then boil down to run cmake with the
--check-dependencies flag to find out the dependency issues you have
to solve before you can reliably run a parallel build.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Parallel make custom command

[Alan W. Irwin]

Hi Bill:

Thanks for your response.  More comments below.

On 2011-06-30 22:03-0400 Bill Hoffman wrote:


On 6/30/2011 5:23 PM, Alan W. Irwin wrote:

To help with the general difficulty of getting dependencies right,
would it be possible to implement a CMake change so that for a given
flag (say --check-dependencies) the cmake application issued warnings
for file and target dependency issues that would cause problems for
parallel builds for a given CMake-based build system? That would help
a lot to solve this topic that keeps coming up again and again on this
list and also make existing CMake-based build systems much easier to
maintain.

Assuming such a change was implemented, then the standard FAQ response
to this topic would then boil down to run cmake with the
--check-dependencies flag to find out the dependency issues you have
to solve before you can reliably run a parallel build.



If we had a magic flag that did --check-dependencies we would just auto add 
the depends.


I agree that a magic flag to automatically generate all depends is a
difficult/impossible thing to implement.  But to be fair that is a
much tougher problem than checking an existing chain of dependencies
for validity.

The problem is these depends can be hard to find. Some of them 
can not even be found until everything has been built or at least all files 
have been generated, and all source files have been scanned for depend 
information.  CMake saves the depend generation of source files to build 
time.  So, at CMake time we don't even know which source files include which 
other source files.   This stuff can be nested as well.  You could generated 
foo.c which includes bar.h which is also generated right after car.h which is 
included by car.c all of which might be in different targets and directories. 
So, although all things are possible, this one is very hard to do


I have had an idea based on your description of why it is essentially
impossible to check the validity of dependencies automatically at
cmake time. Could this check be implemented instead at run time when
all the dependencies are known?

One relatively simple possibility is an optional run-time check that a
given custom command is never duplicated by any particular parallel
build.  (Although not a comprehensive check for bad dependencies, this
idea would already give much more reliable detection of dependency
issues than relying on build errors to find the problem for you since
re-running a custom command might or might not generate a build error
depending on whether the duplicate commands are run sufficiently close
in time by the parallel build.) Other more comprehensive run-time
checks for dependency issues might be possible as well.

If it turns out that a run-time dependency check of any kind could be
implemented, that would shore up what I consider to be the principal
weakness of CMake-based build systems which is they can have subtle
dependency clashes which only give intermittent and hard-to-reproduce
parallel build problems.  For example, I have discovered a number of
dependency clashes for the PLplot build system in the past by varying
the build timing with different GNU make -j parameters until I
discovered a build error.  But such checking can take a lot of time
and can never be exhaustive even on one platform and may miss build
issues that would occur on other platforms because of different
timing. That is why I would welcome any way to improve dependency
checking at run time.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem running cmake 2.8.4 on Ubuntu 10.04

[Alan W. Irwin]

On 2011-07-06 11:36+0200 pellegrini wrote:


Hello everybody,

I have troubles running cmake 2.8.4 on my ubuntu 10.04 machine.
I must use that version because of a bug fix concerning rc files.

When running cmake, I get the following error message:

##

-- The Fortran compiler identification is Intel
-- Check for working Fortran compiler: /home/pellegrini/bin/ifort
-- Check for working Fortran compiler: /home/pellegrini/bin/ifort  -- works
-- Detecting Fortran compiler ABI info
CMake Error at 
/home/pellegrini/Downloads/cmake-2.8.4-Linux-i386/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:31 
(TRY_COMPILE):

Cannot copy output executable

  ''

to destination specified by COPY_FILE:

  
'/home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeDetermineCompilerABI_Fortran.bin'

Unable to find the executable at any of:

  
/home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeTmp/cmTryCompileExec
  
/home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec
  
/home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeTmp/Development/cmTryCompileExec

Call Stack (most recent call first):
/home/pellegrini/Downloads/cmake-2.8.4-Linux-i386/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:59 
(CMAKE_DETERMINE_COMPILER_ABI)

CMakeLists.txt:73 (PROJECT)


-- Detecting Fortran compiler ABI info - done
CMake Error at 
/home/pellegrini/Downloads/cmake-2.8.4-Linux-i386/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:48 
(FILE):

file STRINGS file
/home/pellegrini/Diffraction/crysfml/build/ifort_release_win/CMakeFiles/CMakeDetermineCompilerABI_Fortran.bin
cannot be read.
Call Stack (most recent call first):
/home/pellegrini/Downloads/cmake-2.8.4-Linux-i386/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:59 
(CMAKE_DETERMINE_COMPILER_ABI)

CMakeLists.txt:73 (PROJECT)


-- Checking whether /home/pellegrini/bin/ifort supports Fortran 90
-- Checking whether /home/pellegrini/bin/ifort supports Fortran 90 -- yes
-- Configuring incomplete, errors occurred!

##

The same settings work well on my windows machine ...

would you have any idea ?


Hi Eric:

I have no experience with ifort, but I do have just a quick thought
which may or may not have anything to do with the Linux build errors
you are seeing.

I noticed ifort_release_win in your above error messages.  Just in
case that win has anything to do with your Windows build, you must
do your Linux build starting with a completely empty build tree. For
example, stale Windows build results in that tree would completely
mess up your Linux build.  Even if you confine your builds to one
platform, if things go wrong (like above) it is always a good idea to start over
with a fresh build starting with an empty build tree in case your
build is getting messed up by stale build results on the same
platform.  Of course, none of these comments are relevant if you
get the above error messages starting with an empty build tree.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problem running cmake 2.8.4 on Ubuntu 10.04

[Alan W. Irwin]

On 2011-07-06 17:25+0200 pellegrini wrote:


thanks Alan for your help,

indeed 'ifort_release_win' stands for a build with ifort using  a graphical 
user interface. I just realize it was certainly not the best name for my 
build directory (ifort_release_gui would have led to less confusion I guess).


In the meantime, I found that cmake 2.8.0, 2.8.1, 2.82 works and starting 
from 2.8.3 the ABI steps fails. I may be wrong but it seems to be related to 
some addings in the version 2.8.3 and 2.8.4.


Hi Eric:

My impression is there has been a lot of changes in Fortran support in
the 2.8.x series. Perhaps for ifort you have to do something different
on Linux for 2.8.3 or 2.8.4.  Alternatively, there might be a regression
in ifort support starting with 2.8.3.

I am not a CMake developer so cannot speak for them, but their track
record is they are extremely concerned about such regressions if they
exist.  But you have to get their attention first with a simple
example. So if you make a simple self-contained fortran project (say
one ~5-line main routine) that shows an ifort issue for CMake-2.8.3
and 2.8.4, but not for 2.8.2, my guess is they would be extremely
interested.  On the other hand, if your simple project shows no ifort
problems, but your complicated one does, then obviously there is some
fundamental issue with the CMake-based build system for the
complicated project that is exposed by CMake-2.8.3 and beyond.  So you
make the simple project more and more like the complicated one until
you find the CMake logic in the complicated one that is the source
of the trouble for CMake-2.8.3 or later.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Invalid library output directory when VC++ solution is generated

[Alan W. Irwin]

On 2011-07-25 12:19+0100 Laura Autón García wrote:


Hello all,
In the project I am collaborating on, CMake is used in Windows in
order to generate a Visual C++ solution to be compiled afterwards. In
this process, everything seems to work fine as the external
directories and libraries are well included and everything compiles
and so. However, we are experiencing problems with the directory in
which our dll library is to be created.
We specify in CMake that the directory is ../lib but
when checking the configuration in Visual C++ software, it seems to be
../bin/Release directory, so the library is generated there.
The CMake sentences we wrote regarding this issue are as follows:

 SET(LIB_DIR  ${PROJECT_SOURCE_DIR}/lib)
 SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIB_DIR} CACHE PATH Directory
for libraries)


One possibility is you are setting CMAKE_LIBRARY_OUTPUT_DIRECTORY
after your dll's are built.

Just in case that is not the source of the problem, here is
some further discussion.

I cannot spot anything wrong with your command above.  However, our
project (PLplot) hasn't tried that recommended variable yet.  Instead
we use the deprecated LIBRARY_OUTPUT_PATH variable (mentioned in the
documentation) like the following (because we are a cross-platform
project):

# in windows all created dlls are gathered in the dll directory
# if you add this directory to your PATH all shared libraries are
available
if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
  set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
endif(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)

This works on Windows according to others, and I have also
personally verified that it works under Wine.

Although a different variable is used, note the differences with
how that variable is set with your case.

(1) The subdirectory is in the build tree rather than the source
tree.

(2) We don't cache the variable.

I don't think any of these differences should matter in terms of
whether the functionality works or not, but you might want to try them
with CMAKE_LIBRARY_OUTPUT_DIRECTORY just in case that might be the
source of your difficulty.  You could also set LIBRARY_OUTPUT_PATH
like we do as a test, but it would be better to figure out how to get
CMAKE_LIBRARY_OUTPUT_DIRECTORY to work correctly since our approach is
deprecated.  (It wasn't deprecated when we started using CMake years
ago, and we plan to switch over to the recommended method at some point.)

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Invalid library output directory when VC++ solution is generated

[Alan W. Irwin]

On 2011-07-25 07:59-0700 Alan W. Irwin wrote:


One possibility is you are setting CMAKE_LIBRARY_OUTPUT_DIRECTORY
after your dll's are built.


That was sloppy language.  What I meant was after your dll targets
are configured by 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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Bug fix requests for the *next* release of CMake...

[Alan W. Irwin]

Please do a fundamental fix for http://public.kitware.com/Bug/view.php?id=9220.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Bug fix requests for the *next* release of CMake...

[Alan W. Irwin]

http://public.kitware.com/Bug/view.php?id=12301
___
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake support D programming?

[Alan W. Irwin]

Hi Jonathan:

I certainly agree with your implicit assumption that D language
support is important for CMake.

On 2011-08-07 03:00+0200 jonathan MERCIER wrote:


Since Fedora 16 will add a D2 compiler (ldc), i would like to know if
cmake support yet this language?


As far as I know, not directly, but there is dated CMake language support
for D via third parties.

If you download the stable version of CMake D language support (trunk-r29.zip)
from http://www.dsource.org/projects/cmaked, you will find files
dated 2007-08-28 in that zip.

Werner Smekal of the PLplot project downloaded those in 2009, and we
have updated those files a bit afterwards.  They seem to work for us
even for CMake-2.8.5, but we are not expert enough to answer questions
about those files. (For example, we have changed things by rote
without much understanding of language support under CMake other than
what you can read at cmake-2.8.5/Modules/CMakeAddNewLanguage.txt). 
You will find our versions of those D language support files at


http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/language_support/cmake/
and
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/language_support/cmake/Platform

Ideally, CMake developers will take over these modules at some point
or better yet develop D language support for modern CMake by doing the
necessary minor modifications of the modern C language support they have
already developed.

Same comment about the Ada language support files that are at the same
PLplot location and which also work for us under the same conditions
(mostly by rote with very little understanding).

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake support D programming?

[Alan W. Irwin]

On 2011-08-07 09:21+0200 jonathan MERCIER wrote:


Le samedi 06 août 2011 à 20:00 -0700, Alan W. Irwin a écrit :



Thanks for your answer, i have read this file:
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/language_support/cmake/Platform/Linux-dmd.cmake?revision=10805view=markup

And i see a problem, line 28:
SET (CMAKE_D_FLAGS_INIT -version=Posix ${DSTDLIB_FLAGS} -I
$ENV{D_PATH}/include -I$ENV{D_PATH}/import)

include dir and import dir is same thing and in fedora d includedir is
loctated in /usr/include/d or here path have a hardcoded suffix
/include  /import


Hi Jonathan:

On my Debian Squeeze system, it is even worse.  The includedir is versioned so 
that
it is /usr/include/d/4.3/.  But it makes no actual difference; the
CMake D language support with PLplot still works fine on that system.

Here is why.  I looked further for the use of D_PATH, and I found the
following in CMakeTestDCompiler.cmake

  MESSAGE(STATUS Check for working D compiler: ${CMAKE_D_COMPILER} --
broken)
  message(STATUS To force a specific D compiler set the DC
environment variable)
  message(STATUS ie - export DC=\/opt/dmd/bin/dmd\)
  message(STATUS If the D path is not set please use the D_PATH
variable)
  message(STATUS ie - export D_PATH=\/opt/dmd\)

So it appears D_PATH is an emergency backup measure that is used if
all else fails.  Under these emergency conditions, the authors of this
module had to make some assumption about the layout of the special
version of the D compiler package.  They obviously made the simplest
assumption (the D include files would be stored in
$ENV{D_PATH}/include and/or $ENV{D_PATH}/import).  That assumption
might work in an emergency (presumably they had access to some D
compiler package with that layout) or they may have just blindly
copied it from somewhere else.  In any case, that assumption does
no harm at all for the usual case where the D_PATH environment
variable is not set since all it does is set some additional -I flags
that point to /include and /import directories that don't exist and
which are therefore effectively ignored.

I should also point out that one of the PLplot users has taken on
the responsibilty of packaging PLplot for Fedora, and he has not
reported any difficulty with D.  Thus, I suggest if you give these
language support modules a try on your own Fedora system, they will
probably work for you as well.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] append command

[Alan W. Irwin]

On 2011-08-09 17:19+0100 Glenn Coombs wrote:


Probably too late now and there isn't a bug filed so far as I know, but one 
thing I would love to see added to cmake is an append command
so that lines like this:

    set(CMAKE_EXE_LINKER_FLAGS_RELEASE ${CMAKE_EXE_LINKER_FLAGS_RELEASE} 
/INCREMENTAL:NO)

become shorter and easier to understand:

    append(CMAKE_EXE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO)

The existing syntax for the set command is just ugly when appending.  I know 
you can define a macro or function to do this but I just
feel that it should be supported out of the box as it would make CMakeLists.txt 
files more readable.



Hi Glenn:

I am changing the subject line to keep discussion out of the
bugfix thread as requested by Dave.

It appears what you want is the list APPEND command for
blank-delimited strings.  But then later someone will want to add
other parts of the list functionality to blank-delimited strings as
well such as removing items from the blank-delimited list.  Until you
have two parallel list systems, one for blank delimited strings and
one for semicolon-delimited strings (i.e., the current lists).

I think most would reject the idea of having two parallel list systems
with different delimiters so here is one possibility.

For now just stick to list functionality, e.g.,

list(APPEND CMAKE_EXE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO)

and then change the semicolon delimiters to blanks using

strings(REGEX REPLACE ...)

once you have the list completely assembled.  Of course, that will not
work for the corner case where the strings contain semicolons. So in
the long term, the right thing to do with lists might be to allow a
choice of delimiter if you could do that in such a way as to preserve
backwards compatibility.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] append command

[Alan W. Irwin]

On 2011-08-11 17:20+0200 Michael Wild wrote:


How about

string(APPEND  /newstuff xyz)

It is not satisfactory in that it doesn't follow the semantics of all
the other string(...) commands which never modify their input.


I like that idea, but I would generalize it as

string(APPEND string output_variable input [input...])

to make it similar to other string commands.

BUT if no input is given take it from ${output_variable} just as
for your suggestion.

I would also make that same change for all other string commands of
the same form, i.e., the various REGEX and REPLACE commands.  For those, I
find the input string is often ${output_variable} so I believe this
generalization would be a useful convenience for all users of those
string subcommands.  Furthermore, even though this generalization of
REGEX et all is a major change, IIRC you get a wrong number
of arguments now for, e.g.,

string(REGEX REPLACE regular_expression replace_expression output
variable)

so I believe this generalization would be backwards compatible.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] append command

[Alan W. Irwin]

On 2011-08-11 17:35-0400 David Cole wrote:


It's clear what you mean with the REGEX signatures, but I disagree about the 
optional nature of at least one input.

In my experience, the lack of an input to one of these signatures usually means 
there's a typo in a dereferenced variable name, or the
variable is unexpectedly empty.

It may or may not be the same as the output variable... but I think it's a good 
thing when you get a CMake error in such a case, as is
the case now. I hesitate to stop generating that error.


I assumed the CMake logic parser could distinguish by a count of
arguments between the case where the last input argument was missing
(i.e. nothing specified by the user) as opposed to the cases you
mention where there is something there such as a dereferenced
non-existent variable or variable that is unexpectedly empty.
However, if the parser cannot distinguish the non-existent last
argument case from all others, then I would sadly have to agree with
your conclusion that my idea should be rejected.  Because I do agree
you want to continue to generate CMake errors for the cases you
mention.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Visualizing all build-system options

[Alan W. Irwin]

I was just replying to an acquaintance who was e-mailing me about CMake
configuration when I realized that CMake configuration options
which are only available depending on how other configuration
options are set could be analyzed/displayed using graph theory
(from a 5-minute study of graph theory from reading the first
paragraph of the Wikipedia article on that :-) ).

I looked for a graphviz output file option for this in the cmake
documentation and only found the --graphviz option which will
Generate a graphviz input file that will contain all the library and
executable dependencies in the project. I used that for PLplot once.
It worked and gave a pretty impressive visual demonstration of all the
complicated and numerous PLplot dependencies.  I wasn't surprised by
any of those detailed relationships because I have them pretty much
memorized, but such information would be a definite help to someone
just getting up to speed with the PLplot build system (or any
CMake-based build system)

Could something similar be done for the dependencies between CMake
options?  I think that would be quite useful (especially if it
included the documentation of the options) for further graphviz
analysis and display of the
relationships between the totality of all the CMake options for a
given build system.  The problem with using cmake-gui for this task
(or the equivalent cmake + looking at the resulting CMakeCache.txt
file) is you only see the first layer of possible configurations as
opposed to the totality of options you could visualize with a graphviz
file.

Moving to a related topic, if you run cmake with no -D options in an
empty build tree, you get the first layer of options available to you
for a particular build system in nicely documented form in
CMakeCache.txt.  Once you set some of those as cmake -D options
(always run within an empty build tree), then you get the next layer
of options available to you, and so on, with each iteration
accumulating the command-line -D options you need from the combination
of previous sets of options and the new ones.

I am not familiar with the CMake GUI's, cmake-gui and ccmake, but I
assume they do exactly this same task of displaying the documented
currently available options that can be set depending on the previous
layer of set options.  But do any of these GUI's have an undo button
(and redo button to undo the undo) so you can easily and consistently
navigate to any previous layer of options that you have effectively
tried before for an empty build tree like you can so easily do (simply
using up arrow or down arrow to remove the build tree and navigate to
some other previously tried set of -D options) with the command-line
approach?  It appears from discussions with my GUI-oriented
acquaintance, undo and redo buttons would be worthwhile now if those
haven't been implemented yet in the CMake GUI's.

I hope in this post I have given this audience some useful food for
thought about potential improvements to CMake concerning (1) a
graphviz output file of all options including their documentation to
help display an overview of all options and their logical
relationships and (2) possibly additional ease of use for CMake GUI's
with undo and redo (if those haven't been implemented yet) in setting
various layers of those options that become available depending on
other options set in previous layers. I admit to being unfamiliar with
the CMake GUI's (because I was not impressed with them years ago), but
if they already have undo and redo implemented perhaps it is time to
learn about them (and especially if they are exactly equivalent to the
situation I understand which is running cmake in an empty build tree
with various layers of possible -D options set on the cmake command
line).

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Visualizing all build-system options

[Alan W. Irwin]

On 2011-09-01 18:00-0400 David Cole wrote:


Sounds like a great research project for somebody. Would be cool to
see CMake options visualized for some larger projects...

Not sure of its feasibility in terms of completeness, however. I'm
sure you could come up with something rudimentary that seems to work
for some cases.

There are some cases that you will simply never reach, even though the
code is in there.

For example, consider what happens when you have this code:

if(WIN32)
 option(SOME_WIN32_SPECIFIC_OPTION ...)
endif()

And then you run your tool on your Linux box. I don't care how many
iterations you do, you're simply never going to see the platform
specific option.

Also, in order to aim for completeness, you'd need to deal with
potential code like this:

if(optA AND optB AND optC AND optD OR NOT (optE AND optF))
 option(REALLY_WELL_HIDDEN_OPTION ...)
endif()

Basically, the inner option will only be triggered in a very
specific set of true-false values of all the outer options...

The combinatorial nature of the arbitrary logic enabled by the IF
command makes it very difficult for an analysis tool like this to
achieve guaranteed completeness.

However, even without completeness, it would still be a neat tool, and
I'd love to see what sorts of graphs are out there in the wild.



Hi Dave:

Interesting examples.  I suspect that graphviz can handle all sorts of
different types of relationships, but if you just focus on
dependencies alone (and not what those dependencies are), then I
believe that all graphviz would need to know is that
SOME_WIN32_SPECIFIC_OPTION depended on the WIN32 variable and
REALLY_WELL_HIDDEN_OPTION depended on the optA, optB, etc., option
variables.  The cmake
parser presumably skips everything inside the if(WIN32) block on a
Linux system so I guess you would have to go to an external tool (or a
special CMake parsing mode) to parse every CMake logic branch to
discover all dependencies.  But that could obviously be done to
collect information on all option dependencies.

I think you will agree with me that the the interesting visualization
results would be for option dependencies since those dependencies are
the ones that complicate the art of CMake configuration. However, from
your first example the intrusion of non-option variables in the
dependency visualization system would obviously be a necessary
extension of my original idea.  So you would have to include
non-option variables in the dependency tree for options as well, but
to simplify the final graph concerning option dependencies it would
probably be a good idea to drop all variables from the results which
were not depended upon by option variables.



- 2 cents worth... :-)



Yeah, it is fun to speculate about something new like this that would
be of considerable benefit to help a project's developers and users
visualize the complete set of options and their dependencies for their
project's build system.  Unfortunately I don't have sufficient
knowledge of the CMake code base (or C++ for that matter) to do this
myself, and I assume nobody at Kitware has spare time to do such an
implementation. However, maybe someone else here or perhaps a GSOC
student next year might be interested in fleshing this idea out into
something useful.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake example for Qt console application (without GUI)

[Alan W. Irwin]

On 2011-09-12 09:04+0200 Reinhard Thies wrote:


Hello,

I am looking for a cmake example for a Qt console application.
Are there any ?


Sure.  PLplot has a CMake-based build system which we use (among many
other things) to configure one of the PLplot device drivers called qt.
That device driver implements 11 different plot devices.  One of those
is an interactive GUI, but a lot of them can be run directly from the
command line (if that is what you mean by a Qt console application).
For example, our pngqt device driver creates a PNG plot file from the
command-line by combining the capabilities of the PLplot principal
library with Qt4 capabilities, and similarly for our epsqt, pdfqt,
svgqt, etc., drivers.

I suspect others can come up with much simpler examples, but if not
contact me off list if you have further questions about the PLplot
build-system, and how it configure linking with Qt4 for both
interactive GUI and noninteractive file device drivers.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.6-rc3 ready for testing!

[Alan W. Irwin]

On 2011-09-20 11:53-0600 Orion Poplawski wrote:


On 09/20/2011 08:38 AM, David Cole wrote:

On Tue, Sep 20, 2011 at 8:27 AM, Andrea Galeazzigalea...@korg.it  wrote:


Any news about when will it be finalized?




Soon... Stay tuned...



Not before a proper fix for http://public.kitware.com/Bug/view.php?id=12457 I 
hope.  As it stands, building KDE (and probably lots of other things) with 
2.8.6 is broken.  We've had to pull the rc builds out of Fedora rawhide.


Hi Orion:

Does lots of other things include PLplot (which for the benefit of
others here is one of the packages you maintain for Fedora)? It
appears to me from a quick read of the discussion in bug 12457, that
the predicted broken builds would occur for the optimized build case. 
Do I have that right?


Anyway, I tried a build of svn trunk PLplot here (my Debian squeeze
system) (with -DENABLE_ocaml=OFF for other reasons) with

export CFLAGS='-O3 -fvisibility=hidden'
export CXXFLAGS=$CFLAGS
export FFLAGS=$CFLAGS

and for cmake-2.8.6-rc3 there were no obvious problems with that
build.

I don't want to overly dilute what seems to be your really important
message that there are serious build problems for cmake-2.8.6-rc3, but
if nothing else, your post should galvanize lots of testing of
cmake-2.8.6-rc3 which is a good thing.  When I did such build
testing myself, the optimized build of PLplot appears to be OK for
cmake-2.8.6-rc3 on at least my platform.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.6-rc3 ready for testing!

[Alan W. Irwin]

On 2011-09-20 11:56-0700 Alan W. Irwin wrote:


I don't want to overly dilute what seems to be your really important
message that there are serious build problems for cmake-2.8.6-rc3, but
if nothing else, your post should galvanize lots of testing of
cmake-2.8.6-rc3 which is a good thing.  When I did such build
testing myself, the optimized build of PLplot appears to be OK for
cmake-2.8.6-rc3 on at least my platform.


P.S. I should have mentioned that the bug concerned FindThreads.cmake,
and the PLplot build system does use find_package(Threads) for the
xwin device driver.  So I am a bit surprised I am not seeing the issue
for an optimized build that includes that device driver.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.6-rc3 ready for testing!

[Alan W. Irwin]

On 2011-09-20 13:01-0700 Alan W. Irwin wrote:


On 2011-09-20 11:56-0700 Alan W. Irwin wrote:


I don't want to overly dilute what seems to be your really important
message that there are serious build problems for cmake-2.8.6-rc3, but
if nothing else, your post should galvanize lots of testing of
cmake-2.8.6-rc3 which is a good thing.  When I did such build
testing myself, the optimized build of PLplot appears to be OK for
cmake-2.8.6-rc3 on at least my platform.


P.S. I should have mentioned that the bug concerned FindThreads.cmake,
and the PLplot build system does use find_package(Threads) for the
xwin device driver.  So I am a bit surprised I am not seeing the issue
for an optimized build that includes that device driver.


P.P.S.  Strike that.  I found the issue at PLplot run-time, not build
time for CMake-2.8.6-rc3 (probably because the PLplot library
dynamically loads device drivers such as xwin).  So I strongly second
Orion's call for a fix before 2.8.6 is released.

Here is the evidence:

software@raven examples/c/x01c -dev xwin
PLplot library version: 5.9.8
examples/c/x01c: symbol lookup error:
/home/software/plplot_svn/HEAD/build_dir/drivers/xwin.so: undefined
symbol: pthread_mutexattr_init

software@raven ldd -r drivers/xwin.so |grep undefine
undefined symbol: pthread_mutexattr_settype (drivers/xwin.so)
undefined symbol: pthread_create(drivers/xwin.so)
undefined symbol: pthread_mutexattr_init(drivers/xwin.so)
undefined symbol: pthread_cancel(drivers/xwin.so)
undefined symbol: pthread_join  (drivers/xwin.so)

Thanks, Orion, for catching this problem.  Recently, I have become
quite lazy about testing cmake RC's because normally they just
work.  But cmake-2.8.6-rc3 is definitely an exception to that
rule and a general wakeup call for everyone to thoroughly test
the CMake RC's both at build time _and_ run time.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.6-rc3 ready for testing!

[Alan W. Irwin]

On 2011-09-20 16:21-0400 David Cole wrote:


I will be reverting the commits associated with the bad bug fix
mentioned here, so that we will end up with equivalent to 2.8.5
behavior with respect to this.

We'll have to shoot for a real fix for next time.


Thanks, Dave, for that good decision.

BTW, I normally don't test the optimised case like I just did for
2.8.6-rc3.  Therefore as due diligence, I repeated that exact
optimized test for 2.8.5, and all was well. So equivalent to 2.8.5
should work here, but I will check once you get out the next RC just
to be absolutely sure that 2.8.6 will be fine for 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.6-rc4 ready for testing!

[Alan W. Irwin]

On 2011-09-22 16:14-0400 David Cole wrote:


Please try this version of CMake on your projects and report any
issues to the list or the bug tracker.

Happy building!


Hi Dave:

I have done fairly exhaustive tests of the PLplot build and test system
using CMake-2.8.6-rc4, and unlike rc3 all seems well for rc4.  As far as I
am concerned, bring on 2.8.6-final!

Much thanks to you and the rest of the CMake development team for this
effort!

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake Using a C Preprocessor for Fortran Source Files

[Alan W. Irwin]

On 2011-11-02 19:27- Schuchard, Matthew wrote:


If it matters, these source files will always be built on Linux, so that allows 
for some flexibility in solutions.


For that case, I find fortran preprocessing for gfortran works correctly if I do
the following:

set_source_files_properties(fortran_source.f PROPERTIES COMPILE_FLAGS -cpp)

This solution was based on documentation from info gfortran which
states the following:

Many Fortran compilers including GNU Fortran allow passing the source
code through a C preprocessor (CPP; sometimes also called the Fortran
preprocessor, FPP) to allow for conditional compilation. In the case of
GNU Fortran, this is the GNU C Preprocessor in the traditional mode. On
systems with case-preserving file names, the preprocessor is
automatically invoked if the filename extension is .F', .FOR',
.FTN', .fpp', .FPP', .F90', .F95', .F03' or .F08'. To manually
invoke the preprocessor on any file, use -cpp', to disable
preprocessing on files where the preprocessor is run automatically, use
-nocpp'.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Adding a new language

[Alan W. Irwin]

On 2011-11-14 13:30-0500 Stefan Monnier wrote:


I'd still like to know how to explain to cmake that the command produces
2 files, but at least I can get rid of my hack.


That (assuming just a simple object file is produced by compilation)
is one of several general limitations with CMake language support. For
example, my understanding is this issue has been taken care of for
Fortran 95 (where compilation produces both object and module files)
with Fortran-95 specific changes to the C++ cmake code.  But I would far
prefer to see a generic mechanism for this to not only to deal with
the Fortran 95 module issue, but also the compilation-generated Ada
library identification (*.ali) files, and also the similar issue for
OCaml compiler generated files that you have described.

Because of this and other struggles I had trying to implement Ada
language support for CMake, I didn't even consider implementing CMake
language support for OCaml for the PLplot OCaml bindings.  Instead we
currently use (many!) custom commands and targets for that case, but
I would be happy to change to your CMake OCaml language support
if/when that works.

Here is what I suggest you do to move forward with that project. 
Present a complete summary of your OCaml compilation needs for the

CMake developers.  That is, state what commands are used to build
libraries, what commands are used to build executables, what kinds of
files are generated for each stage of each kind of build, and what
directories need to be identified at each stage of the build to gain
access to files generated in previous stages of the build process.
Furthermore, a complicating factor with OCaml is there are two kinds
of executables (and libraries?) based on whether ocamlc or ocamlopt is
used to respectively produce bytecode executable files that are
executed with the OCaml interpreter (ocamlrun) or native executable
files that are executed with the ordinary run-time loader. If there
are different generic build needs for ocamlc versus ocamlopt be sure
to include those differences in your summary.

If you are willing to make such an OCaml summary, I would be willing
to do the same thing for Ada to make our joint case to the CMake
developers of what kind of additional generic language support is
needed by CMake to deal with the complicated build needs of languages
such as OCaml and Ada (and Fortran 95) in a completely generic way.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Adding a new language

[Alan W. Irwin]

On 2011-11-15 22:13-0500 Stefan Monnier wrote:


I'd still like to know how to explain to cmake that the command produces
2 files, but at least I can get rid of my hack.

That (assuming just a simple object file is produced by compilation)
is one of several general limitations with CMake language support. For
example, my understanding is this issue has been taken care of for
Fortran 95 (where compilation produces both object and module files)
with Fortran-95 specific changes to the C++ cmake code.  But I would far
prefer to see a generic mechanism for this to not only to deal with
the Fortran 95 module issue, but also the compilation-generated Ada
library identification (*.ali) files, and also the similar issue for
OCaml compiler generated files that you have described.


Hmm...


Because of this and other struggles I had trying to implement Ada
language support for CMake, I didn't even consider implementing CMake
language support for OCaml for the PLplot OCaml bindings.  Instead we
currently use (many!) custom commands and targets for that case, but
I would be happy to change to your CMake OCaml language support
if/when that works.


I'm trying to use CMake for a new project here.  This project (a new
programming language, whose first implementation is in OCaml) is
currently in the very first stages (I have barely more than the lexer
written) and doesn't require anything sophisticated (there's only
1 OCaml file for now ;-).  So my language support is very primitive
and rather than fight CMake, I'll probably just switch to something
else :-(


Hi Stefan:

I am sorry that CMake support for new languages with complicated needs
is not there yet, and I completely understand why you don't want to
get involved with that general problem for your limited OCaml needs.

However, I wouldn't give up on CMake entirely because of that
constraint.  Instead, I would suggest you use the alternative of
low-level CMake custom commands and custom targets to build what you
need to build with OCaml. For a detailed example of that approach, see
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/ocaml.cmake?view=log
(which sets things up for the OCaml parts of the PLplot build) ,
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/bindings/ocaml/CMakeLists.txt?view=log
(which gives examples of relevant custom commands and targets to build
the PLplot OCaml bindings), and
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/examples/ocaml/CMakeLists.txt?view=log
(which shows how we build the PLplot OCaml examples).

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Adding a new language

[Alan W. Irwin]

On 2011-11-15 23:35-0500 Bill Hoffman wrote:


On 11/14/2011 3:24 PM, Alan W. Irwin wrote:



If you are willing to make such an OCaml summary, I would be willing
to do the same thing for Ada to make our joint case to the CMake
developers of what kind of additional generic language support is
needed by CMake to deal with the complicated build needs of languages
such as OCaml and Ada (and Fortran 95) in a completely generic way.



There is no case to make, I would love to improve the general language 
support.  However, either you find someone to develop this for you, or you 
find someone willing to pay someone to develop it.  That is really how open 
source works.  Creating a generic way to add new languages that will work on 
all platforms is a pretty huge task, and will require some serious funding, 
or someone with lots of free time and skill.


Hi Bill:

Your summary shows you misunderstood what I said so I have to correct
that.  The basic issue I have with your interpretation is additional
generic language support != Creating a generic way to add new
languages

What I said refers to step by step revisions in how CMake supports
languages.  Each such step has to be evaluated on its merits, costs,
etc., i.e., what I was referring to by make our joint case. The
other is indeed a huge project, but gives a wrong impression of
what I was asking for which must be corrected.

To use a specific example of such a step, the Ada compiler generates
both *.o files and *.ali (Ada library information) files. The *.ali
files are similar to Fortran 95 module files in the sense that the
location of all *.ali files needs to be known for further Ada binding
and linking steps, and the *.ali files need to be installed.  OCaml
has similar issues.  These issues have already been completely solved
in the Fortran 95 case with special code for the Fortran case. Would
it be difficult to generalize that Fortran-specific code so that Ada
(and OCaml when the time comes) could use it?

Right now for the Ada case I work around the *.ali issues by many
additional compile and link flags in the relevant CMakeLists.txt files
to locate where the *.ali files are generated in the build tree or
installed in the install tree and by using an additional
install(FILES ... command and clean logic for the *.ali files. It
would be nice to get that mess cleaned up with a proper generalization
of the Fortran modules case, and it would make implementing proper
OCaml language support (if and when) a lot easier. Thus, I think it
makes sense for CMake developers (not necessarily just KitWare
developers, but on the other hand I don't have the required C++ skills
to do this myself) to evaluate the cost of this specific requested
generalization while being careful not to confuse that relatively
small cost with the huge costs of Creating a generic way to add new
languages.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [RFC] How to use pkg-config under Windows (... and OSX) ?

[Alan W. Irwin]

Hi Alex:

On 2011-11-15 18:07+0100 Alexander Neundorf wrote:


Hi,

cmake ships with a FindPkgConfig.cmake file, which is used by some Find-
modules.
Also in KDE, we have quite a lot of Find-modules which use
FindPkgConfig.cmake.

Now, some of them put a

if(UNIX)
 find_package(PkgConfig)
endif()

around it, some use it on all platforms.

In theory it works also on Windows, and also on OSX, so that this if() would
not be necessary.

But our (KDEs) Windows developer team says that even if pkg-config is found
under Windows, and even if it reports something, they actively want to ignore
it.

The reason for this is that for those packages under Windows the user decides
at install-time where the package will be installed, while the pc-files for
pkg-config have been generated at build-time with the install directory the
developer chose at build-time.
This directory chosen by the developer and hardcoded into the pc-files and the
actual install directory chosen by the user can very well be different.

If this is the case, then pkg-config reports wrong include and wrong link
directories, and the build will work worse than without pkg-config.

Similar issues may exist under OSX, for libraries which are installed as a
package where the user can decide at install time where to put them.


So, I am looking for a, if possible, generic solution to his problem.

Options I see:

1) exclude it from being used under Windows in the Find-modules:
if(UNIX)
 find_package(PkgConfig)
endif()

2) completely exclude it under Windows by putting something like the following
into FindPkgConfig.cmake:
if(WIN32)
 return()
endif()

3) don't exclude it, but hope it reports good results (our Windows developers
disagree)

4) add cache option whether pkg-config should be used under Windows, so
something like the following would be in FindPkgConfig.cmake:

if (NOT CMAKE_USE_PKGCONFIG_UNDER_WIN32)
 return()
endif()


5) something else...


The Linux (also Unix?) tradition is to allow some flexibility with
install location by allowing the user to specify at least the install
prefix at configuration (i.e. cmake) time.  For relative install
paths, CMake supports this idea with CMAKE_INSTALL_PREFIX.  For
absolute install paths, it is the responsibility of the developer of
the CMake-based build system to prefix the absolute install paths with
CMAKE_INSTALL_PREFIX. For example, that is the approach we take with
PLplot.

Anyhow, if the developer of a CMake-based build system has been
careful to support CMAKE_INSTALL_PREFIX (either with relative install
paths or absolute ones that have ${CMAKE_INSTALL_PREFIX} prefixed),
that generally gives users all the installation location control they
need.  For example, in PLplot all generated pkg-config files are
installed in an absolute location that is automatically prefixed by
${CMAKE_INSTALL_PREFIX}.

I don't completely understand the use case that you have described for
the KDE windows developers. If they just want their users to be able
to control the installation prefix, why don't they advise those users
to use CMAKE_INSTALL_PREFIX?

I assume the KDE windows developers do not want their users to be able
to specify arbitrary installation locations for every KDE file since
that would be nothing but a horrible mess.  Also, I assume that asking
Windows users to specify the install prefix at configuration time
(i.e., cmake time) rather than install time is not a huge burden.
Thus, I am only left with the speculation that somehow
CMAKE_INSTALL_PREFIX is currently not being supported by the KDE build
system. Is that the real issue here?

The CMAKE_INSTALL_PREFIX approach works fine for PLplot (including the
locations of our pkg-config support files) on Linux, Mac OS X, and
Windows.  In fact, one of our two alternative test systems for our
installed examples is based on make and pkg-config.  Furthermore, our
important cairo device driver (based on the pango/cairo subset of
the GTK+ library stack) requires the use of pkg-config. Both that
alternative test system and our cairo device driver works fine under
MinGW/MSYS (I have tested that myself under wine with a Windows
installation of GTK+ and a special value
for CMAKE_INSTALL_PREFIX).  Both of those PLplot components should
also work fine under Cygwin.  Therefore, I wouldn't want to lose that
pkg-config capability under Windows so I would strongly object to any
Windows pkg-config limitations that were built right into CMake.

Of course, if KDE developers want to drop pkg-config support for the
Windows case within the KDE build system, that is their prerogative.
However, as the PLplot CMake-based build system shows, that is
certainly not necessary.  Also such a step for the KDE build system
removes some useful value (the ability to link applications against
KDE libraries using pkg-config) from that build system for those using
MSYS or Cygwin.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy

Re: [CMake] [RFC] How to use pkg-config under Windows (... and OSX)?

[Alan W. Irwin]

following the good GTK+ example.

III. The KDE users that got into trouble may have simply copied GTK+
files around rather than properly using the binary installer for the
Windows version of GTK+. I think this is a fairly unlikely possibility
because other things than pkg-config would be clobbered by doing
something stupid like that.

Note that none of the issues above have anything to do with CMake
pkg-config support, but we have to discuss these issues here to
make sure they are all off-topic for 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [RFC] How to use pkg-config under Windows (... and OSX)?

[Alan W. Irwin]

On 2011-11-17 21:43+0100 Hendrik Sattler wrote:


Am Donnerstag, 17. November 2011, 21:38:20 schrieb Hendrik Sattler:

Am Donnerstag, 17. November 2011, 18:26:08 schrieb Alexander Neundorf:

Let's say package Foo (unrelated to KDE, and unrelated to cmake) has been
ported from UNIX to Windows, and installs a pkgconfig file.
This pkgconfig file is generated at the time when the binary package for
Foo is generated.

Now a user downloads and installs the binary package of Foo, along with
the included pkgconfig file, which contains the install path from build
time. But the user can now decide where he will install this binary
package. This may differ from what is recorded in the pkgconfig file in
the binary package of Foo.
So the Foo.pc file is installed, and contains e.g. C:/Foo/include, but
the user decides to install it to D:/MyStuff/, so the include dir would
be D:/MyStuff/include.


Now cmake comes into play.
Let's say there is a project Bar, which uses Foo, so it does
find_package(Foo).

Now FindFoo.cmake uses pkgconfig:

find_package(PkgConfig)
pkg_check_modules(Foo ...)

Now this will report C:/Foo/include (because this is what the
pkgconfig-file contains), instead of D:/MyStuff/include, where the user
decided to install it.


No. Pkg-config should derive the prefix variable from the location of the
.pc file. According to documentation, it does this on Windows, so it
should report D:/MyStuff/include


See http://cgit.freedesktop.org/pkg-config/tree/parse.c#n1136


Thanks, Hendrik for reminding me of that pkg-config feature.
I haven't looked at that URL in any detail, but your summary jibes
with the man page for pkg-config which states the following:

WINDOWS SPECIALITIES
   If  a  .pc  file is found in a directory that matches the usual conven‐
   tions (i.e., ends with \lib\pkgconfig or \share\pkgconfig), the  prefix
   for  that  package  is  assumed  to be the grandparent of the directory
   where the file was found, and the prefix  variable  is  overridden  for
   that file accordingly.

   If the value of a variable in a .pc file begins with the original, non-
   overridden, value of the prefix variable, then the overridden value  of
   prefix is used instead.

So the explanation of why pkg-config works fine for the GTK+ stack of
libraries is much simpler than I thought.  The GTK+ *.pc files _are_
installed in a relative location within the install tree that matches
the standard conventions.  So the ~10 different prefix variables for
the ~30 *.pc files are completely overridden in that case to
correspond exactly to the up-to-date special install location chosen
by the user at binary installation time.

So everything works properly for pkg-config for the Windows case so
long as the binary package in question installs the *.pc files in the
right _relative_ location in the install tree.  That standard is
really easy for any software binary distribution to follow.  So if any
windows binary package is broken this way (remember nobody has given
specifics of even one such broken package yet), it should be
incredibly easy to fix.

It concerns me that some posts in this thread took the assertion that
pkg-config is systematically broken for Windows as the Gospel truth
without investigating that assertion any further.

That assertion has now been proved to be a myth by my prior
investigation showing pkg-config works fine to find compile and link
information for 33 GTK+ libraries installed in a non-standard location
for a Windows platform (Wine).  Furthermore, the man page section for
pkg-config explains the simple reason why that works which even more
strongly answers the assertion.

Alex, is it possible your KDE Windows developers who are objecting to
pkg-config tried a version from years ago when it did not have all
these Windows issues sorted out? I suggest you tell them to
investigate again using modern pkg-config.  For example, they could
follow the experiment I tried using the all-in-one GTK+ 2.22.1 bundle
you can download from http://www.gtk.org/download/win32.php.  If that
works (which it should do if the bundle is properly installed) or if
they use a modern binary version of pkg-config for Windows from that
same location, ask them to attempt to find any Windows binary package
that is broken with regard to pkg-config. There might be some of
those.  But I very much doubt that is a systematic problem since it is
so straightforward (install the *.pc files in the correct relative
location in the install tree) to deal with the pkg-config Windows
issue the KDE Windows developers have been so concerned about.

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

[CMake] Bad documentation of the LINK_INTERFACE_LIBRARIES property and other transitive linking topics

[Alan W. Irwin]

 with CMake. Are there still enterprise edition Linux distros
out there where turning off transitive linking would cause problems?
Does non-transitive linking cause problems on former or current
Windows or Mac OS X platforms?

Because of these concerns I will probably enable transitive linking by
default but have an option (which defaults to OFF) to disable
transitive linking with an associated docstring that warns that ON is
experimental and may not work on all platforms.

All this to quiet rpmlint warnings

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] transitive linking topics

[Alan W. Irwin]

On 2011-11-23 10:44+0100 Michael Wild wrote:


On 11/23/2011 10:25 AM, Alan W. Irwin wrote:

cmake-2.8.6 has the following documentation of the
LINK_INTERFACE_LIBRARIES property for targets:

  LINK_INTERFACE_LIBRARIES
   List public interface libraries for a shared library or executable.

   By default linking to a shared library target transitively links to
   targets with which the library itself was linked.  For an executable
   with exports (see the ENABLE_EXPORTS property) no default transitive
   link dependencies are used.  This property replaces the default
   transitive link dependencies with an explicit list.  When the target
   is linked into another target the libraries listed (and recursively
   their link interface libraries) will be provided to the other target
   also.  If the list is empty then no transitive link dependencies
will
   be incorporated when this target is linked into another target
even if
   the default set is non-empty.  This property is ignored for STATIC
   libraries.

I believe the reference to executables above is just plain
wrong/misleading.  For example, the FAQ states that
LINK_INTERFACE_LIBRARIES simply lists the libraries that should be
transitively included in the link by CMake with the clear implication
(also confirmed by experiment below) that this target property affects
_everything that links to the target whose property is being set_.
But nothing links to an executable so why are executables mentioned at
all?


That's not true. See the ENABLE_EXPORTS target property.


Oops.  You are right.  I had never ever heard of applications
exporting symbols before.  Live and learn.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] other transitive linking topics

[Alan W. Irwin]

On 2011-11-23 11:11+0100 Rolf Eike Beer wrote:


On 11/23/2011 10:25 AM, Alan W. Irwin wrote:



In sum, from this experiment it looks like I will have to set
LINK_INTERFACE_LIBRARIES to empty for all PLplot library targets that
depend on other library targets (e.g., B, C, D, and E, above, but _not_
main or A) created by our build system to comprehensively turn off
transitive linking and avoid overlinking that rpmlint is complaining
about.


Transitive linking is a tricky issue, especially if the new
--no-copy-dt-needed-entries default is active which means that if you
have e.g. a library A, a library B that links against A and an
executable C that uses symbols from both, A and B but only directly
links against B, you will get a linking error if --as-needed is enabled.


And the linker is absolutely right here: you have not linked against a
library you used symbols from. This has always been broken and works only
by accident. This should fail. This must fail. Setting
LINK_INTERFACE_LIBRARIES to empty to allow the linker detect this is a
good thing.


However, CMake can't know for you whether C actually needs to be linked
against A, so it takes the safe route. The alternative would be to not
do it, but then you would need to explicitly link C against A. See
http://wiki.debian.org/ToolChain/DSOLinking for more details.


And that would be a good thing, too.

The rules are absolutely simple (leaving dynamic plugins and dlopen()
stuff out): if you use a symbol from a library you have to link against
that library. And I don't see any value in helping people to ignore even
this absolutely basic rule of programming.


I agree. I have attempted to enforce that rule in the PLplot build
system for a long time by only mentioning the relevant directly linked
shared libraries using target_link_libraries, but it appears now I have a
tool (i.e. specify an empty LINK_INTERFACE_LIBRARIES for all
libraries) with CMake to make sure all relevant shared libraries are
mentioned and a tool with ldd -u to make sure that no irrelevant
shared libraries are mentioned.

That leaves the topic of whether transitive linking is ever required
(assuming you have done due diligence about the shared libraries that
need to be directly linked). I know that Linux demanded transitive
linking in the old days, and CMake certainly still uses transitive
linking by default. So my question is whether some enterprise Linux
distros or some existing Mac OS X, other Unix, or Windows platforms
still demand transitive linking of shared libraries.  If so, I would
turn off transitive linking for the PLplot build system only as an
experimental option so as not to interfere with PLplot building and
running on all platforms.  If not, should the CMake transitive linking
default for shared libraries be deprecated with a note in the
documentation that recommends using an empty LINK_INTERFACE_LIBRARIES?

Comments on platform issues (if any are left) with transitive linking
of shared libraries would be welcome.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] transitive linking topics

[Alan W. Irwin]

On 2011-11-23 22:35+0100 Michael Hertling wrote:


All this to quiet rpmlint warnings


Out of curiosity - I have not worked with RPM for ages: Are these
warnings and the related overlinking due to transitive dependencies
really an issue or just an inconvenience? Personally, I distinguish
between real overlinking, i.e. pulling in libraries not used at all,
and formal overlinking by DT_NEEDED tags for mediate prerequisites,
or in other words: Real overlinking means the dependency graph has
unnecessary nodes, and formal overlinking means is has unnecessary
edges. Of course, the former is a real penalty, but is the latter
also bad? If an executable X is linked against a shared library B,
and B against a shared A, is it really critical if A explicitly
appears among the dependencies of X, as A *is* needed for X?
Perhaps, you can share some experiences from your practice.


Hi Michael:

Thanks for your informative and detailed post.

However, it's going to take a while to absorb everything you said
(since, for example, I still need to educate myself on the exact
meaning of DT_NEEDED), but I can immediately answer the last question
above.

I have no experience with rpm myself. I was just commenting on the
CMake transitive linking implications of what Orion told me about
rpmlint warnings he had encountered (which I confirmed with ldd -u).
Since I wrote all this to quiet rpmlint warnings, it turns out the
PLplot Debian packager (again not me) confirmed today that the Debian
lint programme was also complaining about overlinking.  So it appears
there is consensus amongst the Linux rpm and deb software packaging
tools that the formal overlinking (using your terminology) created by
CMake by default is bad, but I don't know the practical justification
for that conclusion.  My guess is it may be related to the problem of
specifying unnecessary package dependencies that are incorrectly
determined by following unnecessary direct linking, but I don't know
for sure.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Best practices/preferred methods for linking external libraries

[Alan W. Irwin]

Hi Matt:

On 2011-12-02 19:33- Matthew LeRoy wrote:


Thanks, Alan, I'll give some of that a shot and see what we can come up with. 
Learning about another
project that uses CMake (PLplot) that we can look at for examples and 
inspiration helps, too.


From what I can tell, the stuff you mentioned seems to still rely on actually 
building and

installing ProjectA on the build system for ProjectB -- the paths that CMake 
writes to the config
file will be absolute paths, correct?


Yes.  Of course, you do have complete control of the installation prefix for
ProjectA.  So we can install PLplot with any such prefix, and the
independent CMake-based build system for those installed examples works
without issues.  But you don't have control of ProjectA's installation
prefix from ProjectB which is what I believe you are asking for.


Thus, we couldn't just do a build and install of ProjectA on
one system, and copy the install tree into version control, because depending 
on how another user
has things mapped from version control to disk, the absolute paths in the 
config file likely won't
be correct.

Assuming we want to just put the install tree in version control somewhere, and 
have ProjectB's
list files reference the install tree out of version control, is writing a Find 
module the best way
to do that?


I don't see any way your highly unusual use case could work unless you
adopt a common installation prefix for projectA that everybody can use
on their various systems.

I think the EXPORT idea is designed for known installation prefixes.
The mainstream use case would be to release binary (and source)
versions of ProjectA.  Then those who use ProjectB could just install
the binary versions of projectA in the designated install prefix.  (Of
course, if they built ProjectA from source they would have complete
control over the installation prefix.)

By the way, why don't you use that mainstream use case yourself?  That
is, just develop projectA like an ordinary independent software
project with library soversions, releases, etc., to keep track of ABI
changes for each release that will affect ProjectB.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Best practices/preferred methods for linking external libraries

[Alan W. Irwin]

On 2011-12-03 12:42-0800 Alan W. Irwin wrote:


On 2011-12-02 19:33- Matthew LeRoy wrote:
Assuming we want to just put the install tree in version control somewhere, 
and have ProjectB's
list files reference the install tree out of version control, is writing a 
Find module the best way

to do that?


I don't see any way your highly unusual use case could work unless you
adopt a common installation prefix for projectA that everybody can use
on their various systems.


Hi Matt:

On second thought I got too negative about your strange use
case, and to answer your question directly for that case, yes, with a
Find module written for ProjectA,  then your ProjectB users can install
ProjectA anywhere, and if they set CMAKE_LIBRARY_PATH and
CMAKE_INCLUDE_PATH properly, they _should_ be able to get the Find
module to find libraries, headers, etc., from ProjectA regardless of
where it is installed.

That said, I am still a little surprised you are not taking the
traditional independent software package approach for ProjectA.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] 2.8.7 implications for FindLAPACK problem

[Alan W. Irwin]

On 2011-12-13 12:15-0500 Tim Gallagher wrote:


My colleague, Andy Smith, found the problem.

The CMAKE_FIND_LIBRARY_SUFFIXES variable was mispelled as 
CMAKE_FIND_LIBRRAY_SUFFIXES causing errors.

I created a ticket in Mantis and attached patches for both origin/master and 
origin/release. The ticket is number 12624.


I have used FindLAPACK quite a bit in the past without issues for my
FreeEOS project. So your report surprised me.  However, on further
investigation, it turns out you have found a recursion introduced
between 2.8.5 and 2.8.6 which explains my good prior results and your
bad results now.  Of course, to help the CMake developers avoid such
regressions I should have tested FreeEOS builds against 2.8.6 before
it was released, but although I did test the PLplot build that way, I
forgot to do such a test for FreeEOS.

I hope your patch is quickly accepted by the CMake developers for
2.8.7 since 2.8.6 will have to be black-listed for FreeEOS (and
presumably many other projects that use lapack/blas).

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.7-rc2 ready for testing!

[Alan W. Irwin]

On 2011-12-21 20:42-0500 David Cole wrote:


The CMake 2.8.7 release candidate stream continues! You can find the
source and binaries here:

 http://www.cmake.org/files/v2.8/?C=M;O=D

This will become the final build of CMake 2.8.7 next Wednesday unless
somebody finds and reports a showstopping (crasher, serious behavioral
regression) issue between now and then.


Hi Dave:

Sorry for responding so late for your call for testing. A simple test
I did for PLplot seems fine, but from an additional test with FreeEOS
I just discovered there is still a potentially nasty regression for
FindLAPACK.cmake/FindBLAS.cmake from the good behavour we had for
2.8.5.

The issue is that if I set CMAKE_LIBRARY_PATH to find a special
version of lapack/blas, only the lapack part of that is honored.  For
example, if I set

export CMAKE_LIBRARY_PATH=/home/software/lapack/install_double/lib

Then here are the relevant cache results for 2.8.7

irwin@raven grep BLAS CMakeCache.txt |grep -v ADV |grep -v NOTFOUND
BLAS_atlas_LIBRARY:FILEPATH=/usr/lib/libatlas.so.3gf
BLAS_f77blas_LIBRARY:FILEPATH=/usr/lib/libf77blas.so.3gf
BLAS_f77blas_atlas_WORKS:INTERNAL=1
irwin@raven grep LAPACK CMakeCache.txt |grep -v ADV | grep -v NOTFOUND
LAPACK_lapack_LIBRARY:FILEPATH=/home/software/lapack/install_double/lib/liblapack.a
LAPACK_lapack_WORKS:INTERNAL=1

The resulting LAPACK_LIBRARIES uncached variable is

LAPACK_LIBRARIES =
/home/software/lapack/install_double/lib/liblapack.a;/usr/lib/libf77blas.so.3gf;/usr/lib/libatlas.so.3gf

i.e., a mixture between the very latest lapack results and older
system version blas results that I don't want. This inconsistent
mixture of libraries (which are for different versions of lapack/blas
and probably different compile flags as well) potentially could be a
complete disaster.  This odd combination of libraries actually worked
for my particular (FreeEOS) case, but I think that might be an
artifact of building and installing only static versions of
lapack/blas in the CMAKE_LIBRARY_PATH location.

In comparison here are the relevant cache results for 2.8.5

irwin@raven grep BLAS CMakeCache.txt |grep -v ADV |grep -v NOTFOUND
BLAS_blas_LIBRARY:FILEPATH=/home/software/lapack/install_double/lib/libblas.a
BLAS_blas_WORKS:INTERNAL=1
irwin@raven grep LAPACK CMakeCache.txt |grep -v ADV |grep -v NOTFOUND
LAPACK_lapack_LIBRARY:FILEPATH=/home/software/lapack/install_double/lib/liblapack.a
LAPACK_lapack_WORKS:INTERNAL=1

The resulting LAPACK_LIBRARIES uncached variable is

LAPACK_LIBRARIES =
/home/software/lapack/install_double/lib/liblapack.a;/home/software/lapack/install_double/lib/libblas.a

which is exactly what I want, i.e., no chance for inconsistency
between lapack and blas libraries.

There is probably some quick fix you can do to get FindBLAS.cmake to
properly honor CMAKE_LIBRARY_PATH, but since it is so late in the
release cycle there is not much chance to test such a change.  Note an
extreme degree of caution is warranted for changes in
FindLAPACK.cmake/FindBLAS.cmake because there are so many different
variants of those libraries available on various platforms.
Furthermore, the new versions of FindLAPACK.cmake/FindBLAS.cmake that
were introduced for 2.8.6 have already had two bugs fixed, with this
additional library inconsistency issue still to be fixed.  So these
new versions of the find modules don't appear to be completely matured
yet, and my recommendation would therefore be to revert back to the
time-tested versions of FindLAPACK.cmake/FindBLAS.cmake for 2.8.5 for
your 2.8.7 release, and re-introduce the new (with all known issues
fixed) versions of these modules for the next release cycle to give
them some additional testing before the next release.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.7-rc2 ready for testing!

[Alan W. Irwin]

On 2011-12-29 18:34-0500 David Cole wrote:


I've considered your plea, but after looking at the diffs between 2.8.5 and 
2.8.7-rc2, I think we ought to keep what we have and
continue moving forward with it.

The commits involved are easily seen with these git commands:

$ gitk v2.8.5..a1c9de56 -- Modules/FindLAPACK.cmake Modules/FindBLAS.cmake 

$ git log --oneline v2.8.5..a1c9de56 -- Modules/FindLAPACK.cmake 
Modules/FindBLAS.cmake 

b3c42cb FindLAPACK: List thread libs to avoid link errors (#12625)
f603cf2 FindLAPACK: Correct CMAKE_FIND_LIBRARY_SUFFIXES spelling (#12624)
f44f053 FindLAPACK: Fix linking to static LAPACK on Unix (#12477)
0cc8f05 FindBLAS/LAPACK fixes
145de0a FindBLAS/LAPACK fixes
cfad24a fixed: search of ATLAS library for C/C++-only projects
d5e6030 ACML-GPU supportede
af4c58b ACML-GPU supported
91b76e2 gotoblas supported
66a4bd0 fixed: search of acml libraries

I think the fixes that these commits represent outweigh the issue you've raised 
here late in the game. Especially since 7 of those
commits are already in the 2.8.6 release.


Hi Dave:

I was surprised you didn't take the conservative course here since
that is the CMake tradition for dealing with regressions, and the find
modules for lapack/blas are dealing with a particularly complicated
lapack/blas ecosystem where it is easy for these find modules to go wrong
for some platforms.  However, I also recognize that this is your
judgement call to make, and I do hope that you are correct that the
benefit of these post-2.8.5 changes is really worth the cost of the
lapack/blas library inconsistency regression that was introduced by
the changes.

I will try to come up with a fix for the regression early in the next
release cycle and run it by the lapack/blas find module maintainer,
Alexey Ozeritsky.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.7-rc2 ready for testing!

[Alan W. Irwin]

On 2011-12-30 11:22+0100 Eric Noulard wrote:


2011/12/30 David Cole david.c...@kitware.com:


There is no conservative course here. There is a choice of whether to make
CMake 2.8.7 behave the same as 2.8.6 or the same as 2.8.5.

For this to be a showstopper it would have had to be reported before we
tagged 2.8.6 -- since it is now already in 2.8.6, it should simply be
considered a bug that we will try to address as soon as possible and get it
merged into master in time for the following release.

It would also be nice if this were more than simply a back-and-forth
discussion between you and I. I would sure appreciate more input from other
LAPACK and BLAS clients.


May be no-so-simple Find modules
(FindLAPACK is 307 lines long and FindBLAS is 624 lines long)
deserve a dedicated dashboard.
The interested user could setup a submission to this dashboard for their
favorite software build such that testing would be more systematic.

May be it could be done with some ctest scripts that would submit
the update/configure/build/test of the interested project to
this FindLAPACK dashboard?


There is no doubt that the lapack/blas software ecosystem is one of
the most complicated out there with many different platforms so it is
easy to make a mistake in the associated find modules that slips
through because not all of those platforms are currently tested
systematically for a given CMake release cycle.

So I think Eric's idea of a dedicated dashboard to help organize
systematic platform testing for the lapack/blas find modules is an
excellent one.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.7-rc2 ready for testing!

[Alan W. Irwin]

On 2011-12-30 11:06+0100 Eric Noulard wrote:


2011/12/27 Alan W. Irwin ir...@beluga.phys.uvic.ca:

Hi Alan,


The issue is that if I set CMAKE_LIBRARY_PATH to find a special
version of lapack/blas, only the lapack part of that is honored.  For
example, if I set

export CMAKE_LIBRARY_PATH=/home/software/lapack/install_double/lib


Did you tried with CMAKE_FIND_ROOT_PATH instead?

cmake -DCMAKE_FIND_ROOT_PATH:PATH=/home/software/lapack/install_double
/path/to/source

in fact I wasn't even aware of the CMAKE_LIBRARY_PATH nor friends
like CMAKE_PREFIX_PATH and the like.


Hmm. I had never heard of CMAKE_FIND_ROOT_PATH until now, but it
certainly wasn't around when I learned all about CMAKE_LIBRARY_PATH
and CMAKE_INCLUDE_PATH years ago.  I guess the problem is I have too
long a history with CMake, and I haven't been paying enough attention to
the more recently developed features.  :-)

I tried the cmake option
-DCMAKE_FIND_ROOT_PATH:PATH=/home/software/lapack/install_double
with both cmake-2.8.5 and cmake-2.8.7-rc2 and got the same results
as before: the desired consistent lapack/blas libraries for 2.8.5, i.e.
-- LAPACK_LIBRARIES =
/home/software/lapack/install_double/lib/liblapack.a;/home/software/lapack/install_double/lib/libblas.a

and an inconsistent mixture of libraries for rc2, i.e.,

-- LAPACK_LIBRARIES =
/home/software/lapack/install_double/lib/liblapack.a;/usr/lib/libf77blas.so.3gf;/usr/lib/libatlas.so.3gf

The above two results were obtained both with and without CMAKE_LIBRARY_PATH
set.

So it appears this is a second regression for the rc2 version of the
lapack/blas find modules compared to 2.8.5; CMAKE_FIND_ROOT_PATH is
partially ignored.

I hope Dave draws the right conclusion here.  :-)

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.7-rc2 ready for testing!

[Alan W. Irwin]

I have investigated further, and I now think Dave is right with his
desire to go ahead with the release of the rc2 versions of the
lapack/blas find modules.  (Sorry, Dave, for this flip-flop at the
last minute, but such deeper investigations take time.)

What appears to be going on is that in 2.8.5 the usual mechanisms to
choose libraries (CMAKE_LIBRARY_PATH, CMAKE_FIND_ROOT_PATH) work
correctly because they trump (according to my tests) the vendor choice
(which defaults to ALL).
So even though my system has both an atlas and generic version of blas 
installed, that
is ignored for 2.8.5 and the generic blas version is used instead from
the location designated by CMAKE_LIBRARY_PATH or CMAKE_FIND_ROOT_PATH).

But in 2.8.7-rc2, the vendor choice trumps CMAKE_LIBRARY_PATH and
CMAKE_FIND_ROOT_PATH.  So given a choice between the generic version
of blas in CMAKE_LIBRARY_PATH and my system's generic and atlas
versions of blas, rc2 picks the system atlas version.  I guess that is
a reasonable choice because for large matrices atlas is normally
faster than the generic version.  However, for small matrices (such as
in FreeEOS) it is noticeably slower.

So in sum, there has been a fundamental shift in how the lapack/blas
libraries are chosen.  I assume that was a deliberate change in design
so it was probably unfair for me to call it a regression, but a
prominent announcement of this important change would have been
appropriate to avoid misunderstandings.

For my own use case, I have found setting -DBLA_VENDOR:STRING=Generic
and CMAKE_LIBRARY_PATH (or presumably CMAKE_FIND_ROOT_PATH which
I haven't tested for this configuration) gives me

-- LAPACK_LIBRARIES =
/home/software/lapack/install_double/lib/liblapack.a;/home/software/lapack/install_double/lib/libblas.a

i.e., the results I want for FreeEOS both 2.8.5 and 2.8.7-rc2.

That'a slightly more complicated for FreeEOS users (which tend to have
their own built versions of lapack/blas just like I do) than what
worked up to and including CMake-2.8.5.  But that additional
complication is completely acceptable.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Are u using mingw32 gcc / with Cmake?

[Alan W. Irwin]

On 2012-01-07 18:16+0100 Bram Kouwenberg wrote:


I'm looking for someone with a mingw32 install next to Cmake. I have a problem 
compiling probably because of mingw32 --look below if
you want.

shout out if you have mingw32


Hi Bram:


From time to time on a MinGW/MSYS/Wine platform, I have sucessfully

built CMake and other software projects.  The CMake build was
configured using the binary version of CMake for Windows that you can
download from cmake.org, and the rest of the builds were configured
with the Windows version of CMake that I built on my Wine platform.

For a while CMake was not compatible with the latest version of MinGW
(on my Wine platform and somebody else later reported the same problem
on a Microsoft version of the Windows platform).  The result was
uniformly broken builds for MinGW/CMake.  That CMake issue was
corrected fairly recently. Therefore, I suggest you try that latest
version of CMake (2.8.7) before you try anything else with MinGW.  I
also suggest you use the latest version of MinGW that can be installed
with the latest version of the MinGW/MSYS automatic installer.

To test whether your MinGW/CMake installation is working properly, I
suggest you first try to build CMake itself.  Once that works with
MinGW or MinGW/MSYS (whichever you prefer), then I would move on to
attempt other builds.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] mingw vs MSYS makefiles

[Alan W. Irwin]

On 2012-02-23 14:40-0600 Kenneth Boyd wrote:


On 2/23/2012 1:46 PM, Bill Hoffman wrote:


gmake behaves differently if /bin/sh is in the PATH.  The makefiles for 
MinGW Makefiles are written for gmake running in the mode where it does not 
have /bin/sh.   The makefiles for Msys Makefiles are written so that they 
work with /bin/sh mode of gmake.   It all has to do with which shell is 
running the commands from gmake.  In the MinGW case, it is using a windows 
cmd.com shell, and in the Msys case it is using /bin/sh.  They are of 
course very different.  There is no way to force gmake to use a particular 
shell, it is all based on what is in the PATH.
Right.  Unfortunately, I have MingW installed from official tarballs, rather 
than the MSYS executable installer; the MSYS installer *.exe critically 
failed for me back in 2001, so once I got a working install procedure from 
official tarballs I stuck with it.


What is happening is that I have an official MingW /bin/sh in my path (which 
triggers MSYS), but the pathnames required by windows-side tools such as 
MingW32 gcc are still Windows-ish (MingW).


About bug 7870, I am not sure that I understood that you were proposing a 
new generator.  I thought the bug was more about getting bootstrap to work.
Bootstrap failed at the time because there was no generator that worked.  The 
workaround indicated what was needed was a third generator (as MingW without 
bash in path is also a valid install method).

   It does seem that there is an issue with allowing make.exe to work.
  I think if you set CMAKE_MAKEPROGRAM to make.exe it should work.

Ok.
 A patch that found different make.exe or make-mingw and then tested them 
would not be rejected.   I still don't see how we can avoid having separate 
generators for MinGW and Msys, and I certainly don't think a third one 
would help reduce confusion.
I'm assuming that the Msys generator is intended for the results of the MSYS 
installer *.exe .  As such, I'd prefer to assume the current MSYS generator 
is known-good for that case.  My impression (please correct if inaccurate) is 
that it would be preferable to have the final patch augment the MSYS 
generator to discern which filepath convention is expected.


Further discussion looks like it belongs on the CMake-developers list.
Also, I think someone might have fixed the bootstrap issues with Msys at 
this point, but I am not sure... A lot has changed since 2008 when that bug 
was created...

Right, will recheck that before proceeding.


Both the MSYS Makefiles and MinGW Makefiles generators have worked
for me for a fairly recent version (20110802) of MinGW + MSYS
installed with the automatic installer.  For the latter case I renamed
sh.exe to something else to keep sh.exe off the PATH.  To answer the
original poster that rename (rather than manipulating the PATH)
allowed me to keep bash.exe and other useful MSYS tools used in the
PLplot test suite on the PATH.

N.B. these good results were for the wine version of Windows rather
than the Microsoft version, but I doubt something would work on the
wine platform that did not work on Microsoft Windows.  Of course,
there are still plenty of things that work on Microsoft Windows that
do not work on wine, but typically those differences (which continue
to be chased down and fixed by the wine developers) tend to be
important only for high-end applications as opposed to relatively
low-level build tools such CMake, MinGW, and MSYS.

Of course, the other principal issue with a Windows build environment
(whether wine or Microsoft) is the chain of library dependencies that
are often required for free and open software.  I am sure there is a
statement out there somewhere on the web detailing the exact MinGW
versions where the MinGW ABI has been changed, but I haven't found
such a statement so to be paranoid on that issue I tend to build all
dependencies from scratch using the same version of MinGW that I use
for my package build.

CMake helps with lots of those builds, but nevertheless those builds
take quite an effort for each free and open software project. Thus,
it's a real shame nobody has yet dealt with that issue by putting
together a full distribution based on MinGW + MSYS where you could be
sure the MinGW ABI is consistent for all libraries.

Before anybody answers with Cygwin my understanding from reading
http://www.mingw.org is the MinGW and MSYS developers forked their
development from Cygwin long ago where the M stands for minimalist
in the sense that they use Microsoft system libraries such as
MSVCRT.DLL where possible as opposed to using special third-party
system libraries written by Cygwin.  Therefore a MinGW + MSYS
distribution would be quite distinct from Cygwin and would also give
that distribution some much-needed competition.  It makes no sense to
me that Linux has 500+ free and open software distributions while
Windows only has one free and open software distribution.

Alan
__
Alan W

Re: [CMake] mingw vs MSYS makefiles

[Alan W. Irwin]

On 2012-02-23 16:02-0500 Bill Hoffman wrote:

Seems to me there are 
only two [MinGW/MSYS] cases regardless of how it was installed:


1. you have /bin/sh in your PATH and gmake runs commands via /bin/sh
2. you do not have /bin/sh in your PATH and gmake runs commands via the 
native windows shell.


To add to the confusion, modern MinGW and MSYS have _two_ different
make commands.  One is called MinGW/bin/mingw32-make.exe and is used
by the MinGW Makefiles generator while the other is called
MinGW/msys/1.0/bin/make.exe and is used by the MSYS Makefiles
generator.  I presume those two executables correspond to various
forks of gmake.  There may be some other reason why they are different
from one another, but one distinct possibility is that
mingw32-make.exe now completely ignores the existence of sh.exe
and exclusively uses the native windows shell.

Bill, have you done any recent testing of the MinGW Makefiles case
with MinGW/bin/mingw32-make.exe to see if it is still necessary that
sh.exe not be on the PATH?  If not, then the cmake test for sh.exe
not on the PATH could be replaced by a check that the MinGW
Makefiles generator finds and uses mingw32-make.exe while the MSYS
Makefiles generator find and uses make.exe.

As the original poster said, it is really nice to have MSYS on your
PATH even if you are using the MinGW Makefiles generator.  I work
around this issue by renaming sh.exe to something else, but that
workaround would not be necessary _if_ the existence of sh.exe on the
PATH no longer affects what mingw32-make.exe does.

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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine

[Alan W. Irwin]

On 2010-04-09 12:17-0400 David Cole wrote:


A real fix for this has been committed to the CVS repository for kwsys.
The change should appear in the CMake git repository shortly on 'master'...

Thanks to Clinton Stimpson for the patch.


cvs commit -m Patch to avoid short name usage where possible. Get the
actual case spelling of a file name on 'Windows' without converting to short
name and back again. Avoids bad behavior reported in
http://bugs.winehq.org/show_bug.cgi?id=22286 when using cmake under a
wine/msys/mingw installation on a Linux box. Thanks to Clinton Stimpson for
preparing the patch.

/cvsroot/KWSys/KWSys/SystemTools.cxx,v  --  SystemTools.cxx
new revision: 1.257; previous revision: 1.256


Hi David:

Sorry for the long delay in responding to you.  I am just now restarting
testing of MinGW (4.5.0) and CMake-2.8.1 under Wine (1.1.42).

I did find the patch at the patch link accessible from
http://cmake.org/gitweb?p=cmake.git;a=commit;h=018c13ff73d9b7b151cb77f7adcbbb7be27f49d3

I notice the following result after applying the patch

softw...@raven find -print0 -type f |xargs -0 grep -l shortPath
./Source/kwsys/SystemTools.cxx

Further investigation indicates bool SystemTools::GetShortPath is defined
that appears to be unused anywhere else in the source tree now that the
patch has been applied.  Therefore, shouldn't that method be removed?

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine

[Alan W. Irwin]

On 2010-06-10 16:20-0400 David Cole wrote:


softw...@raven find -print0 -type f |xargs -0 grep -l shortPath
./Source/kwsys/SystemTools.cxx


Wrong search.  Sorry about that noise!

If instead you search for GetShortPath there are lots of places in the CMake
source tree that still refers to that method.

softw...@raven find -print0 -type f |xargs -0 grep -l GetShortPath
./ChangeLog.txt
./Source/cmCTest.h
./Source/cmLocalVisualStudio6Generator.cxx
./Source/cmGlobalVisualStudio6Generator.cxx
./Source/cmSystemTools.cxx
./Source/cmGlobalVisualStudio7Generator.cxx
./Source/kwsys/SystemTools.cxx
./Source/kwsys/SystemTools.hxx.in
./Source/cmGlobalGenerator.cxx
./Source/cmCTest.cxx
./Source/cmGlobalVisualStudio10Generator.cxx
./Source/cmLocalGenerator.cxx
./Source/CTest/cmCTestMemCheckHandler.cxx
./Source/CTest/cmCTestTestHandler.cxx
./Source/CTest/cmCTestCoverageHandler.cxx
./Source/cmLocalUnixMakefileGenerator3.cxx

GetShortPath calls GetShortPathName.  From
http://bugs.winehq.org/show_bug.cgi?id=22286 it appears the point of Clint's
patch was to eliminate a specific and well-known hash collision on Wine
caused by GetShortPathName, but from all the on-going uses of GetShortPath
within CMake shown above, I am concerned there might be other wine name
collisions lurking about with cmake causing other issues (e.g., the wine issue
I mentioned before where part of the CMake log messages were not being sent to
the log file).  To address those potential issues, is
there a simple way to reduce or eliminate the use of GetShortPath from the
CMake code or else replace the call to GetShortPathName within GetShortPath
by something else?

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine

[Alan W. Irwin]

On 2010-06-10 16:20-0400 David Cole wrote:


On Thu, Jun 10, 2010 at 4:17 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca
wrote:
  On 2010-04-09 12:17-0400 David Cole wrote:

A real fix for this has been committed to the CVS
repository for kwsys.
The change should appear in the CMake git repository
shortly on 'master'...

Thanks to Clinton Stimpson for the patch.


cvs commit -m Patch to avoid short name usage where
possible. Get the
actual case spelling of a file name on 'Windows'
without converting to short
name and back again. Avoids bad behavior reported in
http://bugs.winehq.org/show_bug.cgi?id=22286 when
using cmake under a
wine/msys/mingw installation on a Linux box. Thanks
to Clinton Stimpson for
preparing the patch.

/cvsroot/KWSys/KWSys/SystemTools.cxx,v  -- 
SystemTools.cxx
new revision: 1.257; previous revision: 1.256


Hi David:

Sorry for the long delay in responding to you.  I am just now
restarting
testing of MinGW (4.5.0) and CMake-2.8.1 under Wine (1.1.42).

I did find the patch at the patch link accessible from
http://cmake.org/gitweb?p=cmake.git;a=commit;h=018c13ff73d9b7b151cb77f7adcb
bb7be27f49d3

I notice the following result after applying the patch

softw...@raven find -print0 -type f |xargs -0 grep -l shortPath
./Source/kwsys/SystemTools.cxx

Further investigation indicates bool SystemTools::GetShortPath is
defined
that appears to be unused anywhere else in the source tree now that
the
patch has been applied.  Therefore, shouldn't that method be removed?


kwsys code is shared among many, many projects. It appears in way more than
just CMake. So removing a function from any of its interfaces is really
probably not a very good idea. :-)


I didn't realize external projects used parts of CMake source code, but
your point is well taken in that case.

That leads to the obvious next question of why aren't those externally used
parts of CMake source code built as a library rather than (presumably)
repeating the compilation for every external project that needs to use the
source code for CMake?  I guess it wouldn't matter much for just a few such
external projects, but you say there are many.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine

[Alan W. Irwin]

 is not tolerated very well.  Of course, the differences I am seeing
could all be due to start up latency and different compiler versions used
for builds, and those factors would not affect games players.

To finish up this speed topic, I have a further question for the CMake
developers: what does the above CommandLineTest consist of?  If thousands of
instances of cmake are launched, then the large Wine latency for each
command that it launches is probably generating the timeout error.

Final questions for the CMake developers: How critical in general are the
above test failures?  My guess is the answer will be not too critical
(except for the known Fortran 95 issue) since CMake itself and all
components (except for Fortran 95) I have tested so far with PLplot seem to
build without issues. Does MinGW-4.5.0 (as opposed to some earlier version)
have a clean ctest result for the cmake build on a Microsoft Windows
platform?  Or do some of the above ctest errors on Wine show up on Microsoft
Windows as well?

I want to emphasize that I am not too discouraged by the above errors since
it is early days yet for Wine as a pure development platform.  The ctest
errors that did occur (aside from the Fortran one) seem not to be important
ones (at least from the perspective of building PLplot and cmake.) Despite
the slow speed MinGW (and also MinGW/MSYS) already seem usable (except for
Fortran 95) on Wine to test out Windows build-system issues on a free (as in
cost and also as in software freedom) Windows platform.  Helping to track
down and fix Windows build-system issues was my original motivation for
getting into this so I am pleased with these results so far, and there also
appears to be a lot of potential for expanding the use of pure Wine
development in ways not directly related to Windows build-system testing.
For example, in limited testing the pure Wine development method already
seems to work for building and testing Windows apps from Linux so it may
eventually replace cross-compilation as the method of choice for doing that.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.2 RC 1 ready for testing!

[Alan W. Irwin]

On 2010-06-14 11:24-0400 David Cole wrote:


I am happy to announce that CMake 2.8.2 has entered the release
candidate stage! You can find the source and binaries here:
http://www.cmake.org/files/v2.8/.

Following is the list of changes in this release. (If you notice
something missing please let me know and I will add it to the official
release when 2.8.2 is finalized.)


http://cmake.org/gitweb?p=cmake.git;a=commit;h=018c13ff73d9b7b151cb77f7adcbbb7be27f49d3

The patch mentioned there is necessary for the Wine platform and presumably
has been substantially tested in the two months since you made that change.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.2 RC 1 ready for testing!

[Alan W. Irwin]

On 2010-06-14 12:58-0400 Bill Hoffman wrote:


The patch mentioned there is necessary for the Wine platform and presumably
has been substantially tested in the two months since you made that change.



That change is in the release, just not mentioned.


Good.  That should make it much easier for me to convince others to try
CMake/MinGW/MSYS on Wine.



Pretty much everything in git next will end up in the release.


Does http://cmake.org/gitweb refer to git next or can it be used to
access that?

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for MinGW/MSYS/Wine

[Alan W. Irwin]

Hi Bill:

I suspect the questions below got lost in the stack of e-mail over last
weekend. Anyhow, I am still very much interested in the answers since all
questions concern possible limitations in the MinGW/MSYS/CMake/Wine
platform, and I am currently putting together a writeup of that platform in
Wiki form.

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); PLplot scientific plotting software
package (plplot.org); 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
__

-- Forwarded message --
Date: Fri, 11 Jun 2010 10:52:31 -0700 (PDT)
From: Alan W. Irwin ir...@beluga.phys.uvic.ca
To: Bill Hoffman bill.hoff...@kitware.com
Cc: cmake Mailing List cmake@cmake.org
Subject: Re: [CMake] CXX incorrectly includes CMakeFortranInformation.cmake for
MinGW/MSYS/Wine

On 2010-06-10 22:24-0400 Bill Hoffman wrote:


GetShortPath calls GetShortPathName. From
http://bugs.winehq.org/show_bug.cgi?id=22286 it appears the point of
Clint's
patch was to eliminate a specific and well-known hash collision on Wine
caused by GetShortPathName, but from all the on-going uses of GetShortPath
within CMake shown above, I am concerned there might be other wine name
collisions lurking about with cmake causing other issues (e.g., the wine
issue
I mentioned before where part of the CMake log messages were not being
sent to
the log file). To address those potential issues, is
there a simple way to reduce or eliminate the use of GetShortPath from the
CMake code or else replace the call to GetShortPathName within GetShortPath
by something else?

No, I don't think there is an easy way to get rid of these calls...


I am sure there are good reasons, but could you let me know why CMake needs to
call GetShortPathName (indirectly via GetShortPath) any more? I have no
Windows experience other than this (so far brief) foray into Wine, but I
thought long file names were now standard on Windows.



I suppose one thing you could try is do have an ifdef wine, and when you call 
GetShortPath make it a no-opp.  Paths with spaces will likely fail, but it 
would be a good way to see if this is causing other problems.


That is a good idea.

Since I am only using this particular CMake source tree for Wine,
I inserted this into the GetShortPath code:

  std::cerr  Aborting after call to SystemTools::GetShortPath with path =;
  std::cerr  path;
  exit(1);

My C++ skills are limited so I hope this is a reasonable way to exit the
code if there is any attempt to use GetShortPath.

Under Wine I built cmake with that change, and then used that version to
build cmake again (using the MinGW Makefiles generator) with no issues.

I then tried ctest under Wine for that cmake build as follows

wine ctest -j4  ctest.out

Some of the tests failed (which I also verified by running them singly).
For the Unhandled page fault ones below, they hung rather then ever
reaching the stage where the summary line was given.

Start  16: kwsys.testProcess-4
wine: Unhandled page fault on write access to 0x at address 0x4015e0 
(thread 001f), starting debugger...


Start  17: kwsys.testProcess-5
wine: Unhandled page fault on write access to 0x at address 0x4015e0 
(thread 0018), starting debugger...


 22/153 Test #22: CommandLineTest ..***Timeout 1500.34 sec
Start 114: CTestTestCrash
wine: Unhandled page fault on write access to 0x at address 0x4013da 
(thread 0036), starting debugger...


123/153 Test #121: CTestTestFailedSubmit-ftp ..***Failed
Required regular expression not found.Regex=[(Problems when submitting via
S*CP|Error message was: ([Cc]ould *n.t resolve host|[Cc]ould *n.t connect to
host|The requested URL returned error|libcurl was built with SSL disabled.
https: not supported)|Submission method .xmlrpc. not compiled into
CTest|Submission successful)
] 52.66 sec
[...]
151/153 Test #150: CMake.GetPrerequisites .***Exception: 
SegFault292.82 sec
152/153 Test #126: Fortran ***Failed  405.16 
sec


It does appear that none of these failures have anything to do with
GetShortPath if I aborted that possibility correctly above.

I don't know for sure, but my guess is the Fortran error is due to
https://sourceforge.net/tracker/?func=detailatid=102435aid=2981639group_id=2435
which is a complete showstopper for compiling Fortran 95 source code with
MinGW gfortran on Wine.

To help understand the above timeout error, my experience with the wine
development environment is it is quite sluggish compared to the Linux
development environment.  For example

Re: [CMake] CMake 2.8.2-rc2 ready for testing!

[Alan W. Irwin]

On 2010-06-16 19:04-0700 Alok Govil wrote:


Hi all,

I am unable to build using MinGW-W64, but chances are there would be some
configuration issues.

Here is how I am setup right now:

1.  Download latest automatic builds (W64 and W32) from here: 
http://mingw-w64.sourceforge.net/
2.  Removed prefixes:  For example, renamed file
x86_64-w64-mingw32-g++.exe in the bin folder to g++.exe.  Am I not
supposed to do this anymore?
3.  Added CMake 2.8.2 RC2 as well as one of W64 and W32 to the path.
4.  cmake . -G MinGW Makefiles  // This could be wrong for W64, but
fails for even W32.
 This step is where I get various errors from CMake.  It works fine with
normal MinGW.
5.  Then I usually call mingw32-make but that is not even there in
MinGW-W32 and MinGW-W64!!


Isn't that the complete issue?  My experience (under Wine, but the principle
is the same) is you must have mingw32-make.exe on your PATH in order for -G
MinGW Makefiles to work.  So you will have to be careful of dependencies,
but you should be able to download and unpack mingw32-make.exe from the
normal SF location for that (under mingw) while keeping the normal MinGW gcc
compilers off your PATH (since you want to use the different compilers,
MinGW-W32 and MinGW-W64).

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); PLplot scientific plotting software
package (plplot.org); 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



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



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



Follow this link to subscribe/unsubscribe:

http://www.cmake.org/mailman/listinfo/cmake___
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Choice of compilers

[Alan W. Irwin]

Hi Alok:

I have changed the subject line to something more appropriate.

On 2010-06-16 22:25-0700 Alok Govil wrote:



Alan wrote:

 Isn't that the complete issue? My experience (under Wine, but the
principle
 is the same) is you must have mingw32-make.exe on your PATH in order for
-G
 MinGW Makefiles to work. So you will have to be careful of dependencies,
 but you should be able to download and unpack mingw32-make.exe from the
 normal SF location for that (under mingw) while keeping the normal MinGW
gcc
 compilers off your PATH (since you want to use the different compilers,
 MinGW-W32 and MinGW-W64).

I did not realize that cmake calls mingw32-make.exe, since the user has to
call it explicitly after running cmake.  But I see now.  Cmake tries
compiling as a part of finding the compilation tools.


tries compiling is part of the story, but the CMake generator you choose
with the -G option also configures the build tool.  So Unix Makefiles
configures Makefiles under Linux that GNU make can understand, MinGW
Makefiles configures Makefiles under either Windows or Wine which
mingw-make.exe understands, etc.  That configuration fails if the build
tool (GNU make, mingw-make.exe, etc.) is not available.



Your suggestion worked, for both W32 and W64.  I used -G MinGW Makefiles
for both cases.


Good.



This also works with CMake 2.8 stable/release version.  So I still cannot
figure what's new in RC2 with respect to MinGW-W64.  Since it works, there
is no issue really.


That's good as well.  In fact that is pretty typical of CMake.  Normally,
new versions just work like the old.



Just like CMake is able to distinguish different versions of Visual Studio,
would it distinguish MinGW-32 with MinGW-64 also (which means either both
would be in path simultaneously, or neither would be, and cmake picks the
right one based on the generator specifed)?  Let me know if so, and I'll be
happy to test this.


I had never heard of those MinGW variants until you mentioned them, and it
appears CMake is not specifically aware of them either.  I presume that's
why you had to rename to gcc.exe (something CMake specifically recognizes)
to get them to work.  But that is a brute-force way to get CMake to
recognize a compiler with a different name.  I would forget the renaming,
and instead use CMAKE_LANG_COMPILER (e.g., CMAKE_C_COMPILER,
CMAKE_CXX_COMPILER, etc.) to allow you to choose which compiler (the 32-bit
variant or 64-bit variant) you want to use.  See the CMake documentation for
how to use CMAKE_LANG_COMPILER.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] An observation about CTest

[Alan W. Irwin]

Your remarks focus on old-fashioned macros so it is possible you are not
aware of functions? As far as I know, most or all macros can be replaced by
functions which do have the nice property of not polluting the global
namespace.  So newly developed build systems should use functions wherever
possible, and certainly for old CMake-based build systems I am associated
with I am trying to move to functions as time permits.

Here are some rough counts of functions and macros actually contained
in 2.8.x:

ir...@raven grep -i function cmake-2.8/Modules/*.cmake |grep -v '#' |wc -l
263
ir...@raven grep -i macro cmake-2.8/Modules/*.cmake |grep -v '#' |wc -l
337

Those numbers should be divided by roughly a factor of two (because of
ENDFUNCTION and ENDMACRO) to get approximate counts of functions and macros.

Clearly, the replacement of macros by functions is well on its way for
2.8.x, but the process is still far from completed.  Once it is complete,
however, the global namespace will be much less polluted.

Another namespace remark is that subdirectory variables do not pollute
the global namespace of their parent directories.

So the global namespace pollution issue is not as bad as you have outlined
and because of functions is steadily improving.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] An observation about CTest

[Alan W. Irwin]

On 2010-06-28 07:03+0200 Andreas Mohr wrote:


Hello,

On Sun, Jun 27, 2010 at 05:09:41PM -0400, cmake-requ...@cmake.org wrote:

Your remarks focus on old-fashioned macros so it is possible you are not
aware of functions? As far as I know, most or all macros can be replaced by
functions which do have the nice property of not polluting the global
namespace.  So newly developed build systems should use functions wherever
possible, and certainly for old CMake-based build systems I am associated
with I am trying to move to functions as time permits.


That's all fine and dandy (and you've written some nice prose about
it :), but I've just been reading man cmakecommands of Debian cmake
2.8.1-5(!) from top to bottom and bottom to top, and nowhere does it
mention _any_ underlying difference between macros and functions.


Look for scope within the documentation.  In particular in the set command
documentation you will find

If PARENT_SCOPE is present, the variable will be set in the scope
above the current scope.  Each new directory or function creates a new
scope.

Note macros are not mentioned there so there is a clear difference between
macros and functions that you were searching for.  From experience that last
sentence means that without PARENT_SCOPE (and without CACHE) variables set
in directories are only available to that directory and sub-directories.  I
therefore have assumed (and IIRC this was mentioned when functions was first
discussed on the list here) that without PARENT_SCOPE (and without CACHE),
variables set in functions are only available to that function (and
functions it calls?)

The above documentation assumes everybody knows what is meant by scope, but
an explicit paragraph about that somewhere in the documentation would be
worthwhile.  Also, I think there should be a sentence in the documentation
of macros that deprecates them in favor of functions (because of the known
scope issue with macros).

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Finding Python3

[Alan W. Irwin]

On 2010-07-18 12:07-0700 Branan Purvine-Riley wrote:


Unfortunately, I can't think of a way to get out of using hardcoded version
lists, since python is often in specific locations (or has a specific executable
name) based on its version number.


I haven't read through the new Find Python work up to now so my
apologies in advance if you do this already, but let me suggest what I
believe is the simplest versioning approach possible. I have two
underlying assumptions:

(1) http://public.kitware.com/Bug/view.php?id=10718 is fixed.  In my
view this bug has been the source of much CMake find trouble for a long
time, and I hope the CMake developers make it a high priority to fix
it for CMake-2.8.3.

(2) The user is smart enough to put the python executable that they
want to use first on their (super-)PATH.

Once those two assumptions are fulfilled, the rest is straightforward.

Use find_program with a list (this is the inescapable maintenance
issue) of the names of all possible python excutable names (with
python at the top of that list and then after that in descending
version order).  If assumption (1) is correct, the order of this list
of alternative names for the python executable only matters if various
versions of python all occur within the first directory on the
super-PATH that contains any python executable at all.

The find_program approach will work most of the time since the python
executable name will either be python or some versioned name that is
located in a unique directory high on the super-path
with no other versioned possibilites in
that same directory. However, sometimes you may have the case where
python refers to, say, /usr/bin/python2.6, but the version the user
wants is /usr/bin/python2.5, and you are not running Debian where you
can easily switch between the two using the update-alternatives
--config command.  Or the CMake developers may have trouble fixing bug
10718 in a timely manner. For that special case where CMake appears
unable to find the python executable the user wants, there should be a
CMake mechanism to allow the user to pick exactly the python
executable they want.

Once the python executable has been determined, its exact version can
be found by running, e.g.,

# Get the Python version.
  execute_process(
COMMAND
${PYTHON_EXECUTABLE} -c import sys; print sys.version.split()[0]
OUTPUT_VARIABLE PYTHON_version_output
OUTPUT_STRIP_TRAILING_WHITESPACE
)
  SET(PYTHON_VERSION ${PYTHON_version_output} CACHE STRING Python version)

(We use this approach currently in PLplot.)  One caveat is the result of
the above sometimes has trailing information that needs to be trimmed
off.  For example, on my current system the result is 2.6.5+.

Once you have determined the python version number triplet this way
from the python executable specified by the user, then enforcing
version consistency for everything else should become completely
straightforward with no further version lists to be maintained.

My $0.02.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Finding Python3

[Alan W. Irwin]

On 2010-07-20 00:51+0200 Michael Hertling wrote:


On 07/18/2010 10:14 PM, Alan W. Irwin wrote:

(1) http://public.kitware.com/Bug/view.php?id=10718 is fixed.  In my
view this bug has been the source of much CMake find trouble for a long
time, and I hope the CMake developers make it a high priority to fix
it for CMake-2.8.3.


Personally, I'm in doubt if 10718 should be considered as a bug. IMO,
the NAMES option of the find commands is meant to denote alternative
names of the file/path/program/library to be found but not different
versions. Instead, specifying different versions is a misuse of the
NAMES option, and that's the actual source of trouble with the find
commands in this regard. E.g., if you say

FIND_PROGRAM(PYTHON3_EXECUTABLE NAMES python3.1 python3.0 python3 ...)

you express that the version doesn't matter to you, so you can't
complain later that the interpreter's version doesn't match the
libraries' one as this means the version does matter after all.


Well, fixing 10718 means CMake will use the first directory in the
super-PATH with any of the specified NAMES which is what I think most
people would prefer rather than the present case where CMake searches
all directories in the super-PATH for the first name in NAMES, then
searchs all directories for the second name, etc.  So the fix would
reduce the importance of the order of the NAMES, and (in my opinion)
sort out many Find ills in CMake these days.

I think this fix is consistent with your idea that NAMES should
express (as much as possible) alternatives with as little as possible
precedence of one name over another. Of course, if more than one of
the NAMES appears in that first directory the order of NAMES will
matter.  Thus, it is always a good idea to place the generic name
(python) first in the list and also to have an option that allows the
user to specify the exact python interpreter (if the default order of
names in the first directory is not what the user desires.)


[...]
Of course, querying the interpreter is quite attractive for gathering
information, but you must be prepared for an interpreter being absent
or not able to run on your host system, so one of the challenges of a
generally usable FindPython.cmake is how to find the python libraries
without using an interpreter.


Good point.


For this reason I suggested an external
flag PYTHON_NATIVE the user can indicate with if the interpreter may
run to reveal the python installation's secrets.


Shouldn't the flag be reversed so the option is called something like
NO_PYTHON_INTERPRETER?  I am assuming that no python interpreter is the
rarer case so that condition should be indicated by the special option
rather than having a special option for indicating the more common case
where the python interpreter is present.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Finding Python3

[Alan W. Irwin]

On 2010-07-20 17:12+0200 Michael Hertling wrote:


On 07/20/2010 03:26 AM, Alan W. Irwin wrote:

On 2010-07-20 00:51+0200 Michael Hertling wrote:


On 07/18/2010 10:14 PM, Alan W. Irwin wrote:

(1) http://public.kitware.com/Bug/view.php?id=10718 is fixed.  In my
view this bug has been the source of much CMake find trouble for a long
time, and I hope the CMake developers make it a high priority to fix
it for CMake-2.8.3.



If I understand correctly, the intention of 10718 is to denote possibly
non-equivalent alternatives after NAMES and use the super-path to pick
out one of them.


Correct.  This issue has come up several times on the PLplot developer
list in several contexts (not only Python).  Without the fix, it
proves impossible to manipulate the super-PATH to allow CMake to find
anything later in the NAMES list (normally a lower version) if
something earlier (normally a higher version) exists anywhere in the
super-PATH on your system. The fix to 10718 is to swap the inner and
outer loops in the CMake code so super-PATH order takes precedence
over NAMES order.

I believe that solution of 10718 will make life easier for Find module
maintainers and developers.  Which is why I brought it up in
connection with this thread.  However, I don't want to
over-concentrate on this one matter at the expense of the rest of this
important topic which is how to improve the Python Find module.  So
that is probably enough about 10718 for now.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Finding Python3

[Alan W. Irwin]

On 2010-07-19 00:47+0200 Eric Noulard wrote:


import sys; print sys.version.split()[0] will not work with python 3 because
print is a function:


Hi Eric:

Thanks for that reminder about using the print function for python3
and also for giving me the hint about sys.version_info to avoid
trailing information after the version triplet.

To draw this subthread to a definite conclusion, here is what works
for me now to get python version for either python2 or python3.

softw...@raven python -c \
'import sys; print(%s.%s.%s % sys.version_info[0:3])'
2.6.5

softw...@raven python3 -c \
'import sys; print(%s.%s.%s % sys.version_info[0:3])'
3.1.2

So I would recommend this command form to determined the python
version corresponding to the found interpreter for CMake.

Thanks again for your help with this.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Finding Python3

[Alan W. Irwin]

On 2010-07-21 08:50-0700 Alan W. Irwin wrote:


To draw this subthread to a definite conclusion, here is what works
for me now to get python version for either python2 or python3.

softw...@raven python -c \
'import sys; print(%s.%s.%s % sys.version_info[0:3])'
2.6.5

softw...@raven python3 -c \
'import sys; print(%s.%s.%s % sys.version_info[0:3])'
3.1.2

So I would recommend this command form to determined the python
version corresponding to the found interpreter for CMake.


Hmm. It turns out you have to swap double and single quotes to get
this to work from cmake.  So here (subject to my mailer wrapping the
lines) is what PLplot uses now:

# Get the Python version.
execute_process(
  COMMAND
  ${PYTHON_EXECUTABLE} -c import sys; print('%s.%s.%s' % 
sys.version_info[0:3])
  OUTPUT_VARIABLE PYTHON_VERSION
  OUTPUT_STRIP_TRAILING_WHITESPACE
  )
message(STATUS PYTHON_VERSION = ${PYTHON_VERSION})

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Finding Python3

[Alan W. Irwin]

On 2010-07-22 03:09+0200 Michael Hertling wrote:


In summary, my point is: Even if the loops are swapped, we wouldn't get
a solution that works well in real-world scenarios so I doubt if it's
worth the effort [...].


Hi Michael:

I think find issues are a really important topic so I am glad you are
adding so much to the discussion.

Although I agree with much of what you say, in this particular case I
believe your above premise is too general, and you have therefore
drawn an incorrect conclusion.  PLplot and other software packages
with CMake-based build systems have run into a number of real-world
Find issues that would be solved if 10718 were fixed.  Obviously, this
fix does not deal with the same-directory case, but at least the fix
limits find issues to just that case alone, and I believe that
simplification is well worth having.

Assuming 10718 gets fixed, then one possibility for dealing with the
same-directory case is to simply publicize this is a well-known find
issue with current CMake find modules and leave it at that.  That
solution certainly has the merit of simplicity and only fails for
the rare case where an older version is desired that resides in the
same directory as a later version (assuming the NAMES are ordered from
newest to oldest version).


[...] one should
prefer to improve the find modules and get rid of those non-equivalent
alternatives after the NAMES option, in particular hardcoded version
lists, and freshly developed modules should use FIND_PACKAGES()'s
version interface right from the beginning.


This certainly sounds promising for dealing with the same-directory
case.  However, although the version interface appears in the usual
documentation, I cannot find a single example of a
config-fileVersion.cmake file.  Am I missing something or is there
no practical demonstration of the version interface for any Find
module included with CMake?

Until there is a practical demonstration of the version interface it
is hard to be sure this is the solution we should recommend for all
find modules. Therefore, would you be willing to create a simple
project demonstrating your idea and share it with this list?

The simple project I have in mind would consist of a single Python
find module (the usual boiler plate + three find commands) which did
essentially nothing but find the (versioned) python interpreter,
header file directory, and library under the version interface; the
accompanying file mentioned in the documentation to support the
version interface; and a single CMakeLists.txt file consisting of ~10
lines which specified the location of that find module (and version
interface support file); allowed the user the option of setting the
python version to anything they liked (e.g., nothing, 2, 2.5, 2.6, 3,
etc.); and used find_package to find and print out the appropriate
Python interpreter, header file directory, and library for the
user-specified version.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Finding Python3

[Alan W. Irwin]

-documentation telling users how to specify a particular version.
For example, FindQt4.cmake is a quite complex find module that already
does this, but most find modules (whether simple or complex) do not.
Once they conform to the above standard, then for at least the simple
ones the sentence would read something like the following:

quote
Most users should be satisfied with the default version of XXX that is
found.  However, if you need to find a specific version of XXX,
specify the path to the header files desired with the cached variable
XXX_INCLUDE_DIR and the full pathnname of the actual library desired
with the cached variable XXX_LIBRARY.
/quote

Of course, it would be the responsibility of the find module to make
sure that other found components were consistent with these
user-specified locations.

To summarize my feelings on these find inconvenience issues, there is
going to be no quick fix.  Instead, we need to plan a steady evolution
toward the desired goal of making it convenient for users to specify
the desired version using CMake find modules.  I agree with David that
the answer is not more additions to the find module API. Instead, he
has convinced me that cache variables are potentially an excellent way
for users to specify particular versions.  However, to make that
solution convenient it is essential to make sure that find modules
follow the above standard for predictable cache variable names
associated with find_path and find_library. Furthermore, the
recommended way to specify the exact version that you want should be
documented right at the top of the self-documentation for each find
module.  Finally, bug 10718 should also be fixed to make manipulating
the superpath a reliable method of specifying a particular version of
headers, libraries, etc., _for the case of a unique location for the
desired version_.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Cmake 2.8.2 Bug under windows

[Alan W. Irwin]

On 2010-08-12 17:36-0700 J Decker wrote:


To Reiterate steps

--

mkdir /test
touch /test/CMakeLists.txt
mkdir /build
cd /build

[cmake-gui /test] or [cmake -G MinGW Makefiles /test]
touch /test/CMakeLists.txt
make
(fails)


In the past I found a subdirectory of the source tree named test
interfered with the proper working of the test target on Linux.  So at
least in that context test was a reserved name for directories.  Of
course, that context is quite different than yours so it is a long
shot, but what happens if you use a different name than test for that
source directory?

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] D support

[Alan W. Irwin]

On 2010-08-13 23:30-0700 SK wrote:


Hello List,
I've taken an interested in D lately and in order to play around
there, of course I want CMake.  There was an effort in 2007 to support
D, since abandoned, but I'm trying to take up the cause.

The project is just getting off the ground here:
http://code.google.com/p/cmaked2/source/checkout.  At this point,
cmaked is only known to work for the dmd compiler in 32-bit Fedora 13.
I based D support on the C compiler support in the latest git
version.  Mostly just copying and tweaking without deep insight.


PLplot has also copied and tweaked an older D language support effort
for CMake.  It appears to work well for my Linux platform, but I don't
know how wide-spread the testing has been on other platforms.  In any
case, you may want to review what we have done with D language support
at
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/language_support/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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake OCaml

[Alan W. Irwin]

On 2010-08-25 16:32+0100 Magnus Therning wrote:


I've come to the conclusion that while CMake is a rather good build tool, it
isn't very well designed to add full support for slightly esoteric languages
and tool chains like OCaml.


I generally agree with that conclusion concerning CMake official
language support for both Ada and OCaml.  However, custom commands and
custom targets provide a good replacement for official language
support (see below).

For the Ada (gnat) case, gcc is used to compile object files (as well
as *.ali files, see below), and there is a powerful tool for checking
and building Ada executables called gnatmake.  So for the Ada case, I
was able to adapt (see Ada-related files in
cmake/modules/language_support/cmake in PLplot-5.9.6) the CMake
language support infrastructure to use gcc for the compiler and 
gnatmake for the linker, but it is not a completely satisfactory fit. 
For example, Ada Library Information files (*.ali) files are created

by the Ada compile step as well as the usual *.o files.  I believe
*.ali files could be treated by CMake in a spirit similar to what is
done for Fortran 95 module files, but in the Fortran case that support
is in the C++ code for CMake rather than in language support files.  I
personally feel that support of additional files created by the
compilation process should be generalized to be part of the language
support files rather than a detail added internally just for Fortran,
but I wouldn't know how to implement that so the current handling of
*.ali files is problematic.  The result is users of our CMake Ada
language support must specify a lot of options to help CMake find
dependencies and also repeat parts of the build to work around the
limitations.

I strongly believe that to move forward with official Ada language
support in CMake requires somebody with detailed knowledge of CMake
internals. Since I don't have such knowledge, I have asked CMake
developers in the past to take over this Ada language support project,
but there was no response to that request.  Note, I am stating that
just as a fact without complaining about it since I realize CMake
developers have a lot on their plates.  Also, I am grateful to both
Bill and Brad for giving me key support at various times to help me
get as far as I have done, but the limits of my CMake knowledge have
long since been reached so somebody else should step forward if Ada
support within CMake is to have a viable future.  If/when we are
forced to abandon this approach for PLplot's Ada bindings and
examples, the fallback will be to use CMake custom commands and custom
targets to keep track of the Ada-related files to be generated and
cleaned as well as the Ada-related CMake dependencies.  That approach
works well in the OCaml case, see below.

In the OCaml case there is also a powerful tool for building
executables called ocamlbuild (essentially an independent build system
for OCaml-related software).  As in the gnatmake case this command
might be adapted to use the CMake language support infrastructure (and
vice versa).  However, I didn't try that because I am sure from my Ada
experience that CMake internals would have to be changed to make this
work completely correctly.  Also, to get (partially) familiar with
ocamlbuild capabilities, we (PLplot developer Hezekiah M. Carty and
myself) first tried custom commands for building our ocaml bindings
and examples using ocamlbuild but the results were less than
satisfactory.  I don't remember the details, but I believe that both
dependency checking and cleaning up the huge number of different file
types that were generated was hard to implement in a satisfactory
manner.  These issues will have to be overcome if anybody wants to use
ocamlbuild as a basis for official CMake language support for ocaml.

Because of the limitations (some of which were probably our lack of
ocamlbuild knowledge) we decided to abandon the ocamlbuild approach
and replace it with CMake custom commands and dependencies to build
PLplot's ocaml bindings and examples. Those detailed custom commands
(9 of them to build our bindings in bindings/ocaml and 4 of them to
build our examples in examples/ocaml) and related custom targets are
probably too complicated to ever be supported with the CMake language
support infrastructure, but we do like the complete CMake dependency
control and generated file cleaning control this approach gives us,
and others may like our general approach as well for their own
CMake/OCaml projects if nobody is ever able to implement official
OCaml language support under CMake that is based on the ocamlbuild
command.

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); PLplot scientific plotting software
package (plplot.org

Re: [CMake] CMake OCaml

[Alan W. Irwin]

On 2010-08-25 17:50+0200 Eric Noulard wrote:


2010/8/25 Magnus Therning mag...@therning.org:

A while ago I started looking at using CMake to build OCaml projects.  As part
of that I put together some useful (but maybe not very beautiful) macros.
They are available on github[1].

I've come to the conclusion that while CMake is a rather good build tool, it
isn't very well designed to add full support for slightly esoteric languages
and tool chains like OCaml.


I'm no OCaml expert but I'd like to know how you decided to build
your OCaml project then?
using ocamlbuild? custom makefiles ?

May be you can give us here a the main 3 or so reasons
you think CMake cannot handle OCaml project building.

It may be useful for other not to go through the same path
you did.


Look at my post (which crossed yours) for some of the ocaml issues we
encountered in the PLplot project.  In short, the detailed
custom-command/custom-target approach works, but many different kinds
of build commands are involved (much more than the normal compile
and link) in an ocaml build so the detailed approach is currently a
bad fit to be supported with the current CMake language support
infrastructure which is based on the idea of one configurable command
to link a library and one configurable command to build an executable.
It is possible somebody with knowledge of the internals of CMake could
change things around so that the configurable commands to build
libraries could be a whole set of detailed custom commands and targets
specified at the language support level. If such general language
support became available, I would certainly use if for OCaml and be
strongly tempted to change Ada language support from one based on
gnatmake (currently with not very satisfactory results) to one based
on a detailed set of custom commands that do the equivalent to
gnatmake using CMake custom commands.

Do the CMake developers here like the idea of this type of
generalization of the CMake language support?

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake OCaml

[Alan W. Irwin]

Hi Eric:

On 2010-08-25 22:20+0200 Eric Noulard wrote:


[...]My ideas was that some languages:
   - OCaml   (ocamlbuild)
   - ADA  (gnatmake)
   - may Java too (ant/maven)

have already very efficient build tool with some history of usage too.
I don't know many Java developers who speaks makefile, most
of them speak Eclipse/Netbeans and many of them ant (http://ant.apache.org/)
what would be the advantage to go for CMake?


Good point.  Of course, these language-specific build tools are in a
different category than general build tools such as make, nmake, etc.
that warrent their own generators.



Most of those tools are already cross-platform and they are pretty
efficient (Ant for example is very handy and includes a plugins system
which makes it easy to extend for doing fancy things)
with a good user base.


To provide some background information, gnatmake is provided as part
of the gcc Ada compiler, and I know gnatmake already works on Linux
and Mac OS X. There is good potential for it to work on Windows
because MinGW-4.5.0 includes the gcc Ada compiler, but PLplot
developers havn't tested the CMake Ada language support on
MinGW/Windows yet. Currently, I don't know any other potentially
cross-platform tools to build Ada software, but I haven't looked very
hard for those since I completely concentrated on gnatmake when
implementing CMake language support for Ada.

I have no experience with ocamlbuild other than on Linux, but a
superficial google search indicates that people have been using it on
Windows so I guess we can claim it is cross-platform.  As far as I am
aware, our current detailed OCaml build for the bindings and examples
has only been tested on Linux, but since ocamlbuild uses these
detailed commands itself, it is probable this can be a true
cross-platform approach as well.  I may get a chance to test our
current detailed command approacn on wine shortly.


[...] CMake should know about
  sources (directories and files)
  dependencies
  targets

I may do something like:

find_delegate_builtool(Ant)

if (Ant_TOOL_FOUND)
  add_delegated_target(TARGETS JavaPlug1 JavaPlug2
  SOURCES  jsrc1 jsrc2 build1.xml build2.xml
  BUILD_COMMAND ${Ant_TOOL} all
  CHECKDEP_COMMAND ${Ant_TOOL} all
  CLEAN_COMMAND ${Ant_TOOL} clean
  GETOUTPUTS_COMMAND ${Ant_TOOL} getoutput)
endif(Ant_TOOL_FOUND)

the delegate build tool would be responsible for building targets
with BUILD_COMMAND and CHECKDEP_COMMAND for checking dependencies
SOURCES specifies the list of sources (inputs for the BUIDL TOOL).
GETOUTPUTS_COMMAND may be used by CMake to get the list
of may be file/dir produced by the build tool.
the CLEAN_COMMAND may be used to clean that part of the project.


Instead of creating an additional cmake command, I think a better
approach would be to extend the existing CMake language support
infrastructure so that it should be possible to choose Ant as one of
the compilers/linkers supported for the Java language.  Then
add_library and add_executable would just work for Antified
projects.  And similarly for other projects that might prefer non-Ant
build tools for java.

That language support infrastructure generalization should include the
possibility that library and executable builds can be done with more
than one command.  And have some way of controlling dependencies and
file cleaning for all files generated by those commands.  I believe
that would be sufficient in the OCaml case (whether using a detailed
build or using ocamlbuild) and also the Ada case (whether using a
detailed build or gnatmake).  From what you say above, it looks
possible that such a generalization would be sufficient in the Ant
case as well.

I should also say that my ideas are to help generate discussion and
food for thought but should have double quotes around them (as you
say) because I am not familiar with how the language support
infrastructure is implemented at the C++ level of the CMake code, and
I don't feel I have a really good overview of all the many different
Ada, OCaml, and Java build tools out there.  The fundamental principle
should be that CMake's language support infrastructure is generalized
well enough so that the user's choice of build tool for a particular
language is not limited by some C++-level language-support restriction
under 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); PLplot scientific plotting software
package (plplot.org); 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

Re: [CMake] CMake without C/C++ compiler check.

[Alan W. Irwin]

On 2010-08-30 13:11+0200 Giraudon Cyril wrote:


Hello,

I'd like to use CMake to build a fortran project (ifort) and
on my win64 machine, I have no C/C++ compiler.

CMake seems to check always  C/C++ compilers  and this makes errors.

So I'd like to know if there is any way to disable C/C++ compiler tests ?


project(projectname Fortran)

or

project(projectname NONE)
enable_language(Fortran)

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Problem with GNU compilers - difference between Windows and MinGW

[Alan W. Irwin]

I would definitely like the build system for the FreeEOS software
project to work properly on Windows.  I have no access to that
platform so I was very happy that Arjen was willing to test that build
on Windows for me. However, he cannot finish that effort until the
questions below are addressed so help with those questions would be
much appreciated.

I also have a further question.  Isn't it dangerous for
FindLAPACK.cmake and FindBLAS.cmake (for at least CMake 2.8.2 version)
to set CMAKE_FIND_LIBRARY_SUFFIXES?  That variable potentially has
far-reaching consequences so wouldn't it be better to save the old
value, set CMAKE_FIND_LIBRARY_SUFFIXES for the particular find that is
being done, then restore the old value? The only other Find module
that sets CMAKE_FIND_LIBRARY_SUFFIXES is FindBoost.cmake, but that
module is careful to save and restore that variable like I suggest
should be done with FindLAPACK.cmake and FindBLAS.cmake.

If there is agreement from the CMake developers that FindLAPACK.cmake
and FindBLAS.cmake should be changed to save and restore
CMAKE_FIND_LIBRARY_SUFFIXES, I will write up the appropriate bug
report.

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); PLplot scientific plotting software
package (plplot.org); 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
__

-- Forwarded message --
Date: Mon, 20 Sep 2010 13:48:38 +0200
From: Arjen Markus arjen.mar...@deltares.nl
To: cmake@cmake.org cmake@cmake.org
Subject: [CMake] Problem with GNU compilers - difference between Windows and
MinGW

Hello,

Alan Irwin and me ran into a rather peculiar problem concerning the
use of the GNU compiler suite on Windows. Here is the set-up:
- Alan's free_eos project uses the LAPACK and BLAS libraries.
- I tested his build system under Windows and to do that I first
  built BLAS and LAPACK from sources.
- To my surprise the free_eos project's build system failed to
  find the libblas.a and liblapack.a files that I had generated.
- I used the MinGW Makefiles generator in both cases.

Here is what I conclude from an analysis of what is going on:
- With the MinGW Makefiles generator, the GNU compilers are
  recognised first - which is what I wanted.
- I use the GNU compilers in an environment that does not state
  it is MinGW and so, find_library uses the Windows convention
  for naming libraries. So with in free_eos, CMake expects the
  files blas.lib and lapack.lib.
- The CMake configuration for the GNU compilers - ignoring the specifics
  of Windows - always uses the Linux convention for library names.
  So it produces libblas.a and liblapack.a.

I may be mistaken in the details, but this is definitely what it boils
down to. Shouldn't the MinGW Makefiles generator take care of these
two naming conventions?

Regards,

Arjen
___
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake for cygwin

[Alan W. Irwin]

On 2010-10-26 17:53-0400 Bill Hoffman wrote:

The policy mechanism might not be ideal but in a year or so, all of this 
would go away, and the meantime the patches you have to maintain for cygwin 
ports would become trivial.  The patch would basically have a set cmake 
version at the top.   I thought the command line option was a nice 
compromise.


Bill, as somebody associated with a software package (PLplot) which
already works on Cygwin, I think the policy mechanism is the ideal way
to handle this requested change.  I do believe the Cygwin packagers
when they say the change will make a lot more projects build without
issues on Cygwin, but it is also extremely likely their preferred
solution (breaking backwards compatibility for cmake) would also break
currently working builds (such as the PLplot one) on Cygwin.

I sympathize with the frustrations of the Cygwin packagers at the
slowness with which this issue has been dealt with, but OTOH, I am not
sure they completely understand the neat resolution of the issue that
you are now offering with a policy-based approach to the requested
change. Thus, I suggest you just go ahead and implement that preferred
solution without further frustrating delays. Then publish cookbook
instructions about the one-line change that needs to be made in the
top-level CMakeLists.txt file of each currently non-working Cygwin
project (but not the working ones like PLplot) in order for the new
policy to be recognized. Ideally, upstream projects that currently
don't build on Cygwin will adopt this solution, but if they are slow
in doing that, it should not be too difficult for the Cygwin packagers
to implement a sed (or whatever) script to do the required one-line
changes in the top-level CMakeLists.txt files for each package in an
automatic fashion.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] call already made makefile

[Alan W. Irwin]

On 2010-10-29 20:50-0700 mina adel wrote:



Hi All

I have an open source code that I use in my project. This open source code
already has Makefile coded for it.

I want to use cmake so that before it compile my project it first call the
cmake of these open source code, which will compile it to .la library.

..make?

Then using this library, it compile my code.


I assume from the context you mean make rather than cmake above.

To run make (or any command) at run-time, use the combination of
add_custom_command and add_custom_target.  Basically,
add_custom_command creates an OUTPUT file (say your library) at run
time, and add_custom_target file-depends on that file and creates a
CMake target corresponding to the custom command which you can add as
a dependency of your application target.  This insures make will be run (if
the library is not up to date) before your application is built.

Note the above is a reasonable interim measure to get you started, but
I predict that once you become more familiar with cmake you will find
that you will want to also build the library with cmake to completely
get rid of your autotools chains.  :-)

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); PLplot scientific plotting software
package (plplot.org); 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



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



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



Follow this link to subscribe/unsubscribe:

http://www.cmake.org/mailman/listinfo/cmake___
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Converting a large C++-Project to CMake

[Alan W. Irwin]

On 2010-10-30 13:54+0200 Benjamin King wrote:

Our build is taking ages (almost a three hours on the fastest of our servers) 
and it would be really painful if everybody needed to rebuild everything for 
himself in the morning.


Aren't you distributing your source code with some tool that preserves
the creation dates of source files? I think all of svn, rsync, tar, or
even cp -a do this.

If the above condition is met (no gratuitous changing of file dates
when copying source trees), then cmake configured builds are normally
very good about paying attention to target and file dependencies so
recompilations only occur for source code that has a later date than
the corresponding object code, for example.

To demonstrate this for yourself, run your configured build system
twice (e.g., run cmake-configured make VERBOSE=1 twice) without
changing any source code file.  The second run should take essentially
no time at all.  Then touch one of your source code files and run make
a third time.  You should see only the object file corresponding to
that source code being rebuilt.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Converting a large C++-Project to CMake

[Alan W. Irwin]

On 2010-10-31 13:48+0100 Benjamin King wrote:


Hi Alan!

Our build is taking ages (almost a three hours on the fastest of our 
servers) and it would be really painful if everybody needed to rebuild 
everything for himself in the morning.


Aren't you distributing your source code with some tool that preserves
the creation dates of source files? I think all of svn, rsync, tar, or
even cp -a do this.

Yes, we do use cvs and copy build trees with rsync -a/cp -a.

The problem is that because our builds take that long, nobody does a global 
cvs update very often, but rather only on the parts he is working on.


It's user nightly that does an automated fresh checkout every night and sees 
if everything is fitting together and passes the tests. That makes it more 
attractive to copy the nightly build to continue your own work, because there 
is some guarantee that it builds, passes the tests and incorporated the stuff 
from the other teams.




Hi Benjamin:

This sounds like you are describing dependency problems with your
current build system. That should be a prime motivation to implement a
complete CMake-based build system which allows you to specify all
dependencies between your software components with no gratuitious
rebuilding. With a properly implemented complete CMake-based build
system, your users would be controlling what gets rebuilt in a
flexible way depending on what they choose to cvs update.  That is the
ideal result and therefore a great selling point for CMake-based build
systems.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] call already made makefile

[Alan W. Irwin]

On 2010-11-04 11:58-0700 mina adel wrote:


Thank you so much for your help

I have another problem, I have successfully created all the 3rd-party libraries.
I used ADD_CUSTOM_COMMAND to call the makefiles that are provided using these 
libraries.

Now, I want to combine all these libraries to one library. I will link against 
this library
later.
I have searched google and cmake wiki. it seems that there is no straight 
forward way to do
that.

one suggested using ar command to combine the files.

what is the vest way to merge all these [make-built] libraries in one library.


Switch to using CMake to configure Makefiles rather than using
3rd-party generated Makefiles.  Once you have switched completely to
CMake, that gives you complete control of which source code files are
compiled into which libraries, i.e., you will have complete control of
the organization of your libraries.  For example, if you want to use
a giant library (not necessarily the best organization, by the way), then
accumulate a list of all the relevant source files then, e.g.,

add_library(giant_library ${giant_library_src_LIST})

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] call already made makefile

[Alan W. Irwin]

On 2010-11-04 16:29-0700 SK wrote:


On Sat, Oct 30, 2010 at 8:31 AM, Alan W. Irwin
ir...@beluga.phys.uvic.ca wrote:

On 2010-10-29 20:50-0700 mina adel wrote:



Hi All

I have an open source code that I use in my project. This open source code
already has Makefile coded for it.

I want to use cmake so that before it compile my project it first call the
cmake of these open source code, which will compile it to .la library.


..make?


Then using this library, it compile my code.


I assume from the context you mean make rather than cmake above.

To run make (or any command) at run-time, use the combination of
add_custom_command and add_custom_target.  Basically,
add_custom_command creates an OUTPUT file (say your library) at run
time, and add_custom_target file-depends on that file and creates a
CMake target corresponding to the custom command which you can add as
a dependency of your application target.  This insures make will be run (if
the library is not up to date) before your application is built.



No, this does not work when the external command is a make process.
The problem is that the output of add_custom_command() is a target
with it's own dependencies.


I don't understand your remark since the OUTPUT of add_custom_command
must refer to a file not a target, and there is a big distinction
between those two concepts in CMake.  That's why I emphasize when
a file is indicated and when a target is indicated below.


The external make process must always run
in order catch dependencies that only the external make knows about.
The only way to make sure the make process always runs is to use
add_custom_target(), but alas, add_custom_target does allow us to
specify an output.

See this thread from a few days ago: add_custom_command depends on
output from add_custom_target.

As far as I know, there is no satisfactory way to do use external
makefiles with CMake.  I'm all ears if anyone has suggestions.



In the past I have been able to use an external set of Makefiles with
no problems. However, I eventually took my own advice and replaced
that method with one that used cmake.  So I don't have any current
good examples, and my remarks below are from memory. However, I think
it should be completely straightforward to do what you like if you
read the cmake documentation for add_custom_command and
add_custom_target carefully.

Here is schematically what you have to do:

add_custom_command(
  OUTPUT full_path_to_generated_library
  COMMAND make
  WORKING_DIRECTORY full_path to where Makefile is located
  )

add_custom_target(
  extern_lib
  DEPENDS full_path_to_generated_library
  )

add_executable(myexecutable myexcutable.c)

target_link_libraries(myexecutable full_path_to_generated_library)

add_dependencies(myexecutable extern_lib)

In sum, target_link_libraries tells how to link the executable file
associated with the myexecutable target to the library _file_
full_path_to_generated_library, add_dependencies makes sure the
_custom target_ extern_lib is built before the _target_ myexecutable is
built, and the _file_ DEPENDS of add_custom_target makes sure the
custom make command is run every time there is an attempt to build the
myexecutable (and therefore extern_lib) target.

Please check my memory of the correct way to do this by using the
touch command.  For example, if you touch one of the source files for
the external library, then I believe with the above scenario if you
subsequently run make myexecutable, then the custom make command
should always be run (since it has no DEPENDS option), and therefore
the external library will automatically be rebuilt (assuming those
external Makefiles had done their dependencies properly), and
myexecutable relinked.

Of course, use make VERBOSE=1 to follow exactly what commands are
being run when testing file dependencies and associated target
dependencies with the touch command.  Also, I believe it ultimately
would be a good idea to replace all builds of external libraries with
CMake-based builds since that gives you the most control of your
library organization.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo

Re: [CMake] call already made makefile

[Alan W. Irwin]

On 2010-11-05 11:00-0700 SK wrote:


On Thu, Nov 4, 2010 at 9:23 PM, SK s...@metrokings.com wrote:

On Thu, Nov 4, 2010 at 6:09 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:

then the custom make command
should always be run (since it has no DEPENDS option),


Alan, you are absolutely right!!


No, sorry.  Only if the add_custom_command output does not exist as
other have mentioned too.  My build is so ridiculously complex I'm
fooling myself right and left.  Here's a small test case to show this.
Hopefully other suggestions on this thread will work.


cat external_makefile

bar : foo
   touch bar


cat CMakeLists.txt


CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT( makefile_test )

ADD_CUSTOM_COMMAND( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/bar
   COMMAND make -f ${CMAKE_CURRENT_SOURCE_DIR}/external_makefile
   COMMENT Running external makefile
   )

ADD_CUSTOM_TARGET( external_target ALL
   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/bar
   )


I confirm your conclusion.  So much for my memory of how to do this.
:-)

However, I found this even simpler test case works fine for me:

ir...@raven cat CMakeLists.txt 
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)

PROJECT( makefile_test NONE)

ADD_CUSTOM_TARGET( external_target ALL
  COMMAND make -f ${CMAKE_CURRENT_SOURCE_DIR}/external_makefile
  WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
  )

(I have used WORKING_DIRECTORY because I tested this with a separate
build directory).  Note also, the external make command complains (at
least on my Debian testing system) unless foo exists in
WORKING_DIRECTORY.

The external make command is run every time you run make VERBOSE=1
and does the right thing.  If foo exists in the WORKING_DIRECTORY it
touches bar the first time in WORKING_DIRECTORY.  After that first try
it doesn't touch bar unless you touch foo in the
WORKING_DIRECTORY.

I think you have previously rejected this simple scenario because it
didn't work for you.  If the above test works for you (as it should),
then probably your previous test of using add_custom_target without a
corresponding add_custom_command was obfuscated by some other error.

Of course, if you use this simple scenario to build an external
library, then you will need independent knowledge of
full_path_to_external_library and the correct working directory for
the external make command, but you needed that knowledge in any case
for my previous scenario with separate add_custom_command.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] call already made makefile

[Alan W. Irwin]

On 2010-11-05 14:12-0400 David Cole wrote:


On Fri, Nov 5, 2010 at 2:00 PM, SK s...@metrokings.com wrote:

On Thu, Nov 4, 2010 at 9:23 PM, SK s...@metrokings.com wrote:

On Thu, Nov 4, 2010 at 6:09 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:

then the custom make command
should always be run (since it has no DEPENDS option),


Alan, you are absolutely right!!


No, sorry.  Only if the add_custom_command output does not exist as
other have mentioned too.  My build is so ridiculously complex I'm
fooling myself right and left.  Here's a small test case to show this.
 Hopefully other suggestions on this thread will work.


cat external_makefile

bar : foo
       touch bar


cat CMakeLists.txt


CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT( makefile_test )

ADD_CUSTOM_COMMAND( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/bar
       COMMAND make -f ${CMAKE_CURRENT_SOURCE_DIR}/external_makefile
       COMMENT Running external makefile
       )

ADD_CUSTOM_TARGET( external_target ALL
       DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/bar
       )


After running cmake, we see

make

[ 0%] Running external makefile === Builds bar fine first time
[100%] Built target external_target

touch foo
make

[100%] Built target external_target === DOES NOT BUILD BAR!!

rm bar
make

[ 0%] Running external makefile === Builds bar only after delete
[100%] Built target external_target
___
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake





Change it to this:


ADD_CUSTOM_COMMAND( OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/NO_SUCH_FILE_AS_bar

...

ADD_CUSTOM_TARGET( external_target ALL
   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/NO_SUCH_FILE_AS_bar


Now, because NO_SUCH_FILE_AS_bar NEVER exists, ever... the command
will always run, because the custom target is always out of date.
Then, when your makefile actually runs, *it* will decide (hopefully
correctly) whether or not it needs to build 'bar'.

Non-obvious, I know. I struggled with this over and over while
developing ExternalProject... But it does work.


I agree the above idea should work, but dropping add_custom_command
completely and moving the COMMAND to add_custom_target instead (and
dropping all file DEPENDS for the custom target) is even a simpler way
to insure COMMAND gets executed every time the custom target is
built.  This situation is summarized in the documentation.

add_custom_target
   Add a target with no output so it will always be built.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] call already made makefile

[Alan W. Irwin]

On 2010-11-05 22:50-0700 SK wrote:


On Fri, Nov 5, 2010 at 1:04 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:

I agree the above idea should work, but dropping add_custom_command
completely and moving the COMMAND to add_custom_target instead (and
dropping all file DEPENDS for the custom target) is even a simpler way
to insure COMMAND gets executed every time the custom target is
built.


Yes it always runs, but there is no output from add_custom_target.


True.


When the external makefile produces an output needed by some larger
dependency chain, then add_custom_command is the only way.


You may be right for the general case.  However, note that since
OUTPUT is involved the dependency chain you are talking about must be a
file dependency chain that occurs as a result of a series of
add_custom_command or add_custom_target commands.  Note an important
limitation of such chains is those commands must appear in the same
CMakeLists.txt file.

Note also that according to my experiments your general conclusion
turns out not to be correct for the specific case of external
libraries.

To be specific, here are the two different scenarios we are discussing
for that case.

I.

add_custom_command(
  OUTPUT full_path_to_generated_library dummy
  COMMAND make
  WORKING_DIRECTORY full_path to where Makefile is located
  )

add_custom_target(
  extern_lib
  DEPENDS full_path_to_generated_library
  )

add_executable(myexecutable myexcutable.c)

target_link_libraries(myexecutable full_path_to_generated_library)

add_dependencies(myexecutable extern_lib)

II,

add_custom_target(
  extern_lib
  COMMAND make
  WORKING_DIRECTORY full_path to where Makefile is located
  )

add_executable(myexecutable myexcutable.c)

target_link_libraries(myexecutable full_path_to_generated_library)

add_dependencies(myexecutable extern_lib)

where the only difference between I and II is the
add_custom_command/add_custom_target pair of I is replaced with a
single add_custom_target with COMMAND specified in II.

My experiment consisted of touching the actual external library file
that is referred to for an existing project that used the
target_link_libraries command. That external library was built
completely separately (unlike the above two scenarios).  But the
result of touching that library was that my internal target (a library
in this case) got relinked.  So in that case, there seemed to be no
necessity at all that full_path_to_generated_library actually needed
to appear in an OUTPUT in order for the internal target to be
relinked. That is why I predict scenario II above should work with no
problems.

To explain my reasoning further, With II, every time one of the source
files of the externally generated library gets changed, then make
myexecutable should rebuild that library through the _target_
dependency between the myexecutable target and the extern_lib target.
Because that external library rebuild necessarily changes the file
full_path_to_generated_library, then myexecutable should be relinked
because (according to my experiements) target_link_libraries always
relinks whenever there is a change in the library file that is
referred to _regardless of the source of the change to that file_.

Of course, although the above logic seems compelling, it needs to be
verified by examples.  I am not in a good position to do that, but I
assume from your posts about the specific external library case you do
have an example of scenario I that does work properly for external
libraries or can soon put one together.  If you make the trivial
change to scenario II, does that example continue to work properly as
predicted by the above logic?

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] make test missing

[Alan W. Irwin]

On 2010-11-09 02:52+0100 Michael Hertling wrote:


On 11/08/2010 10:03 PM, Jochen Issing wrote:

Hi list,

I tried to add ctest to my project and did this by adding ENABLE_TESTING() and 
several ADD_TEST(...) to my CMakeLists.txt file.
The tests are run on executables, which are built inside a dedicated test 
directory in my project root and the execs show up in my Makefile.
After reading through some docs, I am told to call make test after building. 
However, no target named 'test' is available.


I.e. it doesn't show up in the listing of make help?


Here my question: Does my directory 'test' interfere with the 'test' rule or do 
I have to install the executables before testing or do I still miss something?


On *nix, I can see the following CMakeLists.txt work:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(TEST C)
ENABLE_TESTING()
FILE(MAKE_DIRECTORY ${CMAKE_SOURCE_DIR}/test ${CMAKE_BINARY_DIR}/test)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(
   main
   PROPERTIES
   RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/test
)
ADD_TEST(NAME main COMMAND main)

The output of make test - without installation - is:

Running tests...
Test project /home/hertling/work/cmake/issing/obj
   Start 1: main
1/1 Test #1: main .   Passed0.00 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) =   0.11 sec

So, I'd conclude the test directories' presence doesn't matter,
nor does the fact if an installation has already been performed.


In the past this mattered a lot so the PLplot project had to rename
our test source tree directory to plplot_test to avoid the clash with
the name of the test target.

It is possible your example above is not complicated
enough to trigger the clash.  For example, your test
subdirectories are just created, but you do not have an
add_subdirectory(test) command to actually run cmake within that
test subdirectory.

So I would suggest to the OP that they do rename their test directory
to something else because I am pretty sure that will solve the issue.
Until PLplot did that (for a much earlier version of CMake) make
test failed to work for us.

Alan





Maybe, you could post your CMakeLists.txt for further inspection.

Regards,

Michael


Anyhow, 'ctest -D Experimental' seems to do something :/

Also, I am not sure if I need to setup a Dashboard-Server to use testing at 
all. I suppose it's possible without a dashboard, but don't know how.
Thanks in advance!
Cheers,

- jochen
gpg: 1024D/013400C7

___
Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake



__
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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Merging a project from autoconf and GNUMakefiles

[Alan W. Irwin]

On 2010-11-16 09:35-0500 Torri, Stephen CIV NSWCDD, W15 wrote:


I am trying to merge a project that was using autoconf and GNUMakefiles. When 
you use automake you can build static libraries in sub directories and then 
link them together into one shared library in the end that was install. This is 
not possible with Visual Studio. In GNU Make for the project I can see that 
there are GNMakefiles in the subdirectories that build the object files where 
they are linked together in the top level GNUMakefile.

In projects I have done where I have had source files in subdirectories I could 
include all of them in a variable in the single CMakeLists.txt file in the top 
directory. This project has 1079 C++ and C files in a variety of 
subdirectories. The only way I can see to make a single shared library with 
CMake is to include all the source files into a single variable in the single 
CMakeLists.txt file like I do in my own projects.  So to do this same technique 
with this project seems unreasonable to ask these developers to adopt.

So I am wondering if I can set a single variable used across a variety of 
CMakeLists.txt files? So that way in subdirectoryA I can add files to a 
variable called SOURCES that I append files in from subdirectoryB. Therefore in 
the top level CMakeLists.txt file I can declare:

add_library ( target ${SOURCES} )
target_link_libraries ( target ${DEPENDENCY_LIBRARIES} )

In a similar way I can include those headers I want to install in all the 
subdirectories.


CMake deliberately reduces scope to help reduce side effects. But
there are ways to beat that for needs like yours.

You should look at the documentation of PARENT_SCOPE in the set
command.  It might be suitable for your needs, but a drawback is you
must have (I assume) an unbroken recursive chain of such set commands
to communicate data from some deep subdirectory to your top-level
directory, and I would think that is a pretty fragile structure
subject to hard-to-find bugs if some subdirectories are moved around
in the future. For my own similar needs, I far prefer setting a GLOBAL
property (see documentation of set_property(GLOBAL...[APPEND]...)).

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Problems with parallel builds

[Alan W. Irwin]

On 2010-11-18 07:18-0800 Denis Scherbakov wrote:


David,

Thank you for spending your time to resolve my problem.

Unfortunately you suggestion did not help.

Introduction of new custom targets in my case leads to the fact that
I have one custom target that depends on another custom target. I get:

gmake[3]: *** No rule to make target 'customTargetA', needed by 
'customTargetB'.  Stop.

And in this case it is not even a parallel build.

Now I remember that I already tried this custom-target trick about
a year ago and it failed with gmake error I specified above.

So CMake is not parallel build ready.
BTW, gmake -j4 targetA targetB also fails. You need to gmake -j4 targetA
and then gamake -j4 targetB to get correct results.


Denis:

I have been following this discussion with interest and assumed you
would quickly find the source of your parallel build issue.

I assure you cmake is parallel build ready, i.e., lots of
people including me use parallel builds with cmake with no problems
for quite complex builds. It is not completely trivial to set it up
right for a given complex project, but it can be done.

Since you are having problems with setting it up right for your
complex project, I suggest you try making the simplest example of your
issue: a generated one-line header and two simple libraries (each with
only a few lines of code) that depend upon it.  Then wrap that simple
example up in a tarball so others can verify the issue you are finding
(or make the fix to your simple example so that it works properly with
parallel builds).

The other big advantage of the simple example approach is that 99
times out of 100 (at least in my case) the simple example works fine
and it turns out the source of the problem is the implementation of
the logic of the simple example isn't done consistently in the complex
project (e.g., some third library you forgot about also depends on
your generated header) or there is some other CMake logic in
your complex project that needs changing to make your project
ready for parallel builds.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] How to apply the --as-needed linker flag?

[Alan W. Irwin]

I just discovered that many Linux distros these days use the
--as-needed Linux linker option by default.  At first glance that
option makes a lot of sense since it tends to reduce startup times.
But I guess there are some caveats as well which is probably why CMake
does not adopt this linker option by default for Linux builds.
However, I would at least like to try this option for my own Linux
builds without forcing it using target_link_libraries. Is it possible
to specify linker options such as --as-needed using environment
variables and/or -D options?

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to apply the --as-needed linker flag?

[Alan W. Irwin]

On 2010-11-28 06:39+0100 Michael Hertling wrote:


On 11/27/2010 06:45 PM, Alan W. Irwin wrote:

I just discovered that many Linux distros these days use the
--as-needed Linux linker option by default.  At first glance that
option makes a lot of sense since it tends to reduce startup times.
But I guess there are some caveats as well which is probably why CMake
does not adopt this linker option by default for Linux builds.
However, I would at least like to try this option for my own Linux
builds without forcing it using target_link_libraries. Is it possible
to specify linker options such as --as-needed using environment
variables and/or -D options?


On Linux, CMake takes account of the LDFLAGS environment variable
for the initial configuration of the build directory, so saying

LDFLAGS=-Wl,--as-needed cmake path/to/srcdir

enables --as-needed for this build directory - forever.


Thanks, Michael, that was exactly what I needed.  I was completely
unaware that environment variable worked for CMake despite many years
of using CMake on Linux.  Is the LDFLAGS environment variable
documented for CMake anywhere?  I couldn't find it in the
documentation you get with cmake --help-full, and it is also not
documented at http://www.cmake.org/Wiki/CMake_Useful_Variables. The
useful environment variables CXXFLAGS, CFLAGS, and FFLAGS that allow
you to specify general compiler flags in a convenient way are
undocumented as well, and that is a real shame.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Wiki: version compatibility matrix

[Alan W. Irwin]

On 2010-12-04 16:58+0100 Johannes Zarl wrote:


Hello,

The compatibility matrix for different versions of cmake is now complete and
awaits review: http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix

Apart from factual errors and things I might have missed, I am also interested
if someone has a better idea for embedding the comments: they make the tables
broader than they need to be. Also, the wiki warns that the page might be to
big for some browsers. Should the page be divided into subpages?

If no one objects, I will add a link to the main-page under Development
Topics by Wednesday next week (2010-12-08).


Wow! There is an enormous amount of detail there which should be quite
useful if reliable.  I suggest you comment on that page how you
obtained that detail so readers can judge for themselves how
trustworthy it is.  For example, if most of this was done using
automated scripts, then it would be nice if the source for those
scripts would be made available as well.

Out of curiosity I ran it through the validator at
http://validator.w3.org/.  The result was 13 errors. Ideally, the
error count should be zero showing complete compliance with web
standards.  Those 13 errors are probably due to issues in the software
used to generate the wiki page rather than something done by you.
Despite those errors, the page does appear to render well here
with konqueror.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake bug tracker discussion

[Alan W. Irwin]

On 2010-12-09 17:06-0500 David Cole wrote:


Hello CMake users and devs,

(And now for something completely different...)

Controversial questions:

- Should we eliminate the bug tracker entirely and just do all
discussion and patches on the mailing list? (Why have two sources of
information...?)

- Or, alternatively, should we eliminate the bulk of mailing list
traffic, and insist on issues in the bug tracker being the main
conversational forum for the whole community?

I'd like to have this discussion here publicly, to try to get a good
sense of varous community members attitudes and feelings.


I'll start the ball rolling by saying that, personally, I like the bug
tracker. I find it much easier to keep a list of issues organized and
accessible than I can with email filters and folders. But I still see
a need for both tools.



I am glad you brought this subject up because there is a real problem
engulfing CMake's bug tracker as we speak.  It appears from the
resolved category of CMake bugs on the bug tracker, that ~10 bugs were
resolved (not necessarily fixed) in November, but that same month saw
~50 new bugs reported (to the cmake-devel mailing list).  That ratio
of 5 new bugs for every one resolved means the CMake bug tracker is
rapidly being filled with unresolved issues with no hope of ever
resolving them unless some substantial changes are made.

Here are some ideas to help reduce that insanely unsustainable ratio
of five down to a sustainable unity.

1.  Reduce the number of new bug reports.

  a.  My guess is lots of those new bug reports are noise due to
  misunderstanding of how to use CMake (despite what I consider to
  be outstanding documentation). So reduce the numbers by strongly
  suggesting that all potential bugs should be discussed first on
  the mailing list (with [BUG?] in the subject line to draw
  attention to it) to make sure they really are bugs before
  writing up a bug report.

  b.  Avoid using the bug tracker whenever possible, e.g., quick and
  obvious fixes. I have experienced other organizations which
  demanded everything go to the bugtracker where posting to the
  bugtracker became the point rather than actually fixing bugs. In
  other words, bug trackers have been used by some organizations
  as an excuse for inaction on bugs!  This is clearly not the case
  with the CMake developers (I just this morning had one of my
  discussed bugs fixed without going through the bug tracker), but
  I feel strongly about that important pitfall of bugtrackers so I
  brought it up explicitly here. It should be emphasized that bug
  trackers can play an important role for the more difficult fixes
  that take a lot of experimentation and thought to get right, but
  in my view creating a bug report on a bug tracker has an obvious
  cost for the reporter and for the bug triage team afterward
  so should be avoided for the simple stuff.

2. Increase the resources you spend on resolving bugs in the bug
tracker.

  a.  More community involvement, e.g., encourage a community bugfix
  team whose principal job was to do the first-level bug triage
  such as investigating the questions of whether it is a
  well-posed bug report (e.g., is there enough information in the
  bug report), is the issue reproducible, and ultimately is it a
  real bug or not.  And if not, members of that team would have
  the power to close the bug as not a bug.

  b.  A modest increase in Kitware resources devoted to bug fixing.
  This is obviously a judgement call that is up to Kitware, but if
  I had a say in Kitware's allocation of resources, this is how I
  would argue for these additional resources. Kitware doesn't get
  direct money for their CMake development efforts, but CMake is
  an enormous boost to their reputation which presumably
  translates to more commercial success through their paid-for
  products.  The bottom line is ultimately it hurts Kitware's
  reputation if their CMake bugtracker is filled to the brim with
  unresolved issues so some increase in Kitware resources as well
  as encouraging community involvement is warranted to help deal
  with the current bad situation.

In sum, I agree with the others who have posted on this question that
you need both mailing-list discussion of all bugs and the bugtracker.
My additional ideas beyond that general idea are (1) you should
encourage mailing list discussion to make sure a CMake problem some
user is having is really due to a bug, and (b) make a conscious effort
to make quick fixes when those are warranted, and (c) encourage use of
the bug tracker only for the more difficult issues where there is
obviously no quick fix.

Alan
__
Alan W. Irwin

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

Programming

Re: [CMake] CMake bug tracker discussion

[Alan W. Irwin]

On 2010-12-09 19:23-0500 David Cole wrote:


On Thu, Dec 9, 2010 at 7:09 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:

On 2010-12-09 17:06-0500 David Cole wrote:


Hello CMake users and devs,

(And now for something completely different...)

Controversial questions:

- Should we eliminate the bug tracker entirely and just do all
discussion and patches on the mailing list? (Why have two sources of
information...?)

- Or, alternatively, should we eliminate the bulk of mailing list
traffic, and insist on issues in the bug tracker being the main
conversational forum for the whole community?

I'd like to have this discussion here publicly, to try to get a good
sense of varous community members attitudes and feelings.


I'll start the ball rolling by saying that, personally, I like the bug
tracker. I find it much easier to keep a list of issues organized and
accessible than I can with email filters and folders. But I still see
a need for both tools.



I am glad you brought this subject up because there is a real problem
engulfing CMake's bug tracker as we speak.  It appears from the
resolved category of CMake bugs on the bug tracker, that ~10 bugs were
resolved (not necessarily fixed) in November, but that same month saw
~50 new bugs reported (to the cmake-devel mailing list).  That ratio
of 5 new bugs for every one resolved means the CMake bug tracker is
rapidly being filled with unresolved issues with no hope of ever
resolving them unless some substantial changes are made.


A couple of points to alleviate (or at least reduce your concerns)
about this trend.

(1) It's not as bad as you think based on November alone. In the last
365 days, 589 bugs have been opened and 341 have been resolved. Net
increase in open bugs of 248 over the last year. So ratio of
new-bugs:resolved-bugs is actually about 1.7:1.


I am glad to hear the ratio averaged over this entire year is lower
than 5 although I would still argue (see below) that 1.7 is not
sustainable.



(2) Having spent much of my own time perusing bugs in the CMake bug
tracker, I can tell you that the 0.7 over the 1 that makes up that
1.7:1 ratio are noise or duplication or just not worth anyone's time.



I am not surprised by that large noise factor at all.  However, I do
believe those noise bug reports are worth someone's time in the sense
that they should be dealt with (closed) as quickly as possible. 
Otherwise, those trying to stay on top of the bug tracker by scanning

through the various unresolved bug reports will start getting turned
off by this noise, become less efficient, etc. That's why I argue
above that the ratio of new bugs to resolutions must be unity (or
ideally lower to start whittling away at the backlog) or else the
bugtracker is unsustainable in the long run.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake bug tracker discussion

[Alan W. Irwin]

On 2010-12-10 17:01+0100 Pau Garcia i Quiles wrote:


On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman bill.hoff...@kitware.com wrote:

I have a third idea that we have not yet tried:

What do people think of automatically closing bugs if they are not modified
for some period of time (say 6 months).   They can always be reopened if the
closed.   By closing them, it will notify those that have expressed interest
in the bug.  We could send the closed bugs to the cmake-developer list just
like the new ones.  That way all developers will know that they are being
closed.


It's a bad idea, IMHO.

If a user took the time to file a bug and CMake developers do nothing
in 6 months, closing it is the wrong thing to do.

The message you are sending to the bugreporter is I didn't care about
the bug you reported in 6 months, and now I will care even less. For
an example, see what I said yesterday about bug 8707: two years later,
a patch provided, still no action on Kitware's side.


I completely agree.  Time-based automatic bug closing is a bad idea.



On the other hand, on KDE, when we moved to KDE4, we closed almost all
KDE3-related bugs without checking if they had been fixed. It did not
made too much sense to keep bug reports around unless they were
feature requests.


That sounds like you would support version-based (as opposed to
time-based) bug report closing.

To be specific what would you think of a new bugtracker policy to
close all bugs automatically that were submitted for old versions of
CMake with the message, please reopen this bug if it still applies to
CMake-2.N? Such a policy seems reasonable to me (especially if the
old version cutoff is sufficiently in the past, e.g., close all bugs
relevant to CMake-2.N-2 when the 2.N series starts) and avoids the
implicit bad message to bug reporters of a time-based policy that we
both dislike so much.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Building a mega library after building smaller component libraries?

[Alan W. Irwin]

On 2010-12-13 18:13-0500 Clifford Yapp wrote:


Can anyone tell me what the best way is (without a whole lot of
rebuilding) to take several individual libraries and combine them into
a single large library?


It appears someone has already pointed you to the (lack of)
convenience library reference for CMake.  But beyond that I would
advise you think very carefully about your purpose.  Do you want to
build individual libraries or a giant library?  There should be no
need for both.

If individual, then there should be no need for the giant one since
any application that previously linked to the giant library could be
linked instead to the subset of individual libraries needed by that
application.  If your individual libraries have been factored on some
rational basis, then why would you want to lump those nicely factored
results together into a giant library?

On the other hand, if there is no logical rhyme nor reason to the way
your code has been factored into individual libraries (i.e., they
really are meant to be just grab-bag component parts to the giant
library), then don't bother building the individual libraries at all.
Instead, in each individual subdirectory where source code exists that
would normally be used to build the individual libraries, you can
append a list of full pathnames for the source code to a global
property.  At the end of processing all subdirectories, the result
will be a global property containing a list of the full pathnames of
all source files that you can use to build the giant library.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Maintainer for FindX11, FindOpenGL, and FindTCL (and friends)

[Alan W. Irwin]

On 2010-12-20 18:27-0500 Clifford Yapp wrote:


[In] the case of Tcl/Tk I would prefer to move back from the splitting up
of Tcl/Tk functionality to just FindTCL.cmake - the primary reason for
this is to avoid situations where there are multiple Tcl/Tk systems
installed and the tclsh search returns a tclsh executable that is not
the tclsh associated with the libraries of the Tcl selected by the
find_library logic.  It might be conceivable to put some constraint
logic in to make a find_package on one to conform to the results
already found by another, but that seems awfully forced.  By the same
token, there is no reason the tclsh and tclstub find files need to
march to the same drummer as the FindTCL.cmake file, although the
results might be somewhat surprising if they didn't.


I am interested in your post from the perspective of a long-time
Tcl and Tk find module user.

I agree that finding Tcl extensions such as Tk that are consistent
with the version of Tcl that is found is important.  We have run
across this issue with the CMake-based PLplot build system and would
welcome a solution.

I agree that the approach of using a giant Tcl + extensions find
module rather than separated find modules might be preferred because
it would keep all the version consistency enforcement logic contained
in one place, and there might be a good chance (see below) to keep the
cmake code compact by looping through the various extensions. Of
course, if you take that giant find module approach you will want to
give the user the chance to select which Tcl extensions (if any) he
wants to find, but so long as that extension selection functionality
is part of it, I can see no other objections to a giant find module
approach for Tcl and its extensions.

I would also advise writing the giant find module in a way that makes
it easy to add new find capability for extensions since such
extensions continue to be added to Tcl from time to time.  Ideally,
there would be a list of Tcl extensions and associated data that you
loop through to do all the standard find stuff for each extension so
that adding find capability of another Tcl extension would normally
require just adding another component name and associated data to the
extensions list. (I am thinking along the lines of a loop paradigm we
use a lot in the PLplot build system where the loop list consists of
elements which are themselves colon-separated to allow easy parsing of
all required data inside the loop, but you may have your own loop
paradigm you prefer to use instead.)

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Maintainer for FindX11, FindOpenGL, and FindTCL (and friends)

[Alan W. Irwin]

On 2010-12-20 21:08-0500 Clifford Yapp wrote:


If you are interested, I can send you a version of my FindTCL.cmake
once I get done reworking it to see if it would meet your needs.


Sure.  I would be glad to help test your work for our particular
Tcl/Tk/itcl/itk needs.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] how to ignore errors/keep going using cmake

[Alan W. Irwin]

On 2011-01-05 16:43-0800 Ekaterina Sanina wrote:


Hi,

I was wondering if it's possible to ignore errors and continue the build with 
cmake (for example if one wants to find out
how many failures the project has). Is there option similar to -i ( 
--ignore-errors) or -k (--keep-going) option of GNU
make?
I scanned the documentation and can't find any relevant option.  -i option 
doing something else (runs in wizard mode) and
-k option is ignored. You help is greatly appreciated.


I am not sure, but you may be confusing cmake with make.  At least for
the default Unix Makefiles generator on Linux systems, cmake
configures a bunch of (GNU) Makefiles.  You then run those with the
ordinary make command where you have access to the ordinary make -k
option.

My experience is cmake often tries to continue after an error occurs, but
almost always it is that first error (say caused by some screwup in a
CMakeLists.txt file) that is the most important one so ordinarily
I ignored the attempt to continue if it occurs.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] building gcc with cmake

[Alan W. Irwin]

On 2011-01-06 03:02- luxInteg wrote:


just curious,

but I wondering if anyone on list has ever built gcc with cmake.
(or  at least had a go)


I did it by hand years ago (1996 when I started with Linux and needed
to add g77 to the slackware version of gcc that I had at the time.) It
was pretty straightforward.  Basically, you iterated the build of the
C component until that converged, then added in all the other
languages for a last build of the complete collection of language
compilers.

If that continues to be the method, enshrining all those steps in a
CMakeLists.txt file would make a small amount of sense as an exercise
of your cmake skills, but you could do it with an ordinary bash script
as well, and I assume that is what is done now in any case.

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); PLplot scientific plotting software
package (plplot.org); 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

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

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

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake