Re: [cmake-developers] Shared libraries

[Chuck Atkins]

Hi Tony,

I expect what your seeing is likely the result of how MaraiaDBhas
specifically implemented their CMake build.  The only builtin CMake
variable to control this is BUILD_SHARED_LIBS, which when set to "ON"
changes the behavior of add_library(foo) to be add_library(foo SHARED),
instead of the default add_library(foo STATIC).  The other
BUILD_STATIC_LIBS and DISABLE_SHARED are variables are not builtin to CMake
and are part of however they have chosen to implement their build.

CMake builds are typically designed to produce a single configuration, i.e.
shared release or static debug, etc.  Often, however, because to have the
flexibility to do otherwise. projects will try to instead implement a build
that produces several configurations in a single pass.  It seems this is
what MariaDB has done and as such the variables to control it will be
unique and specific to that project and how they've decided to implement it.

------
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Thu, Aug 9, 2018 at 12:23 PM REIX, Tony  wrote:

> Hi,
>
>
> On AIX, when building MongoC 1.11, cmake 3.11.4 generates lib*.so files
> and lib*.a files which contain .o files.
>
> On AIX, we should get libraries lib*.a containing the lib*.so file.
>
> I've tried to use:
>
> -DBUILD_SHARED_LIBS=ON  \
> -DBUILD_STATIC_LIBS=OFF \
> -DCMAKE_C_CREATE_SHARED_LIBRARY=ON  \
> -DCMAKE_CXX_CREATE_SHARED_LIBRARY=ON
> and I see that, for MariaDB, someone has tried with:
>
> -DDISABLE_SHARED=OFF
>
>
> None seems to work.
>
>
> Which CMake variable should I use for asking CMAKE to generate shared
> libraries rather than static ones: lib*.a file containing .so files rather
> than .o files.
>
>
> Thanks
>
>
> Cordialement,
>
> Tony Reix
>
> tony.r...@atos.net
>
> ATOS / Bull SAS
> ATOS Expert
> IBM Coop Architect & Technical Leader
> Office : +33 (0) 4 76 29 72 67
> 1 rue de Provence - 38432 Échirolles - France
> www.atos.net
> <https://mail.ad.bull.net/owa/redir.aspx?C=PvphmPvCZkGrAgHVnWGsdMcDKgzl_dEIsM6rX0g4u4v8V81YffzBGkWrtQeAXNovd3ttkJL8JIc.=http%3a%2f%2fwww.atos.net%2f>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] how does target_compile_features() test the c++11 conformance?

[Chuck Atkins]

Hi Claus,

how does target_compile_features() test the c++11 conformance?
>

It doesn't.  The language features supported by different compilers and
thier various versions is basically a manually constructed whitelist since
testing for them at configure time is far too costly.  You can see the
details for msvc here in the internal compiler detection logic in the CMake
distribution: Modules/Compiler/MSVC-CXX-FeatureTests.cmake


 target_compile_features(${targetname} PRIVATE cxx_std_11) # OK
>
> But wenn I use this most features are missing:
>
> target_compile_features(${targetname} PRIVATE
>cxx_contextual_conversions  # OK
> ...

   #FIXME: missing features at MS VS12 2013:
> ...
>cxx_aggregate_default_initializers

...
>  )
>

The cxx_std_11 compile feature is a meta-feature.  Basically it tells CMake
to Use the compiler in C++11 mode if possible, and then the cmpiler will do
what it can.  This is effectively adding the -std=c++11 flag to gcc or
-std=c++1y for cxx_std_14.  The compiler may not support all the features
but CMake knows that it can at least support *some* so it will try to use
what it can.  MSVC is a bit of an oddball with compilers since you cant
actually control the language level (maybe with 2017 you can), i.e. you
can't explicitly instruct msvc to build in C++98 mode only.

The individual language features wre initially put in place due to the
half-broken C++11 implementations that thend to be available in many
compilers (as you're finding out).  However, over time as it's used more
that level of granularity is less and less useful.  Hence the addition of
the meta-features for language levels.  Several compilers that have
reecently added language standard support in CMake (IBM XL, Cray, PGI) are
now just using the meta-feature as the maintenace burdon for maintaining
the feature tables is too great with respect to the reward.

Hope that helps clarify the state of things.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Problems with external language support when there is a blank in CMAKE_MODULE_PATH

[Chuck Atkins]

>
> Hi Chuck (off list):
>

Hi Alan (on list)



> but the one above I completely missed.

...

> with the hint above I should be able to figure out
> all those remaining issues on my own


Excellent!  Glad to hear it.  Inconsistent path quoting is a common pitfal
when writing portable CMake code.  It bites all of us at one point or
another, even Brad sometimes.  Glad I could help.



> Or even better, don't blow away the current module path, jsut append to
>>> the front:
>>> list(INSERT CMAKE_MODULE_PATH 0 "${CMAKE_SOURCE_DIR}/cmake/Modules")
>>>
>>
> What is the use case you had in mind for not blowing away
> CMAKE_MODULE_PATH?  Does CMake itself sometimes set CMAKE_MODULE_PATH
> so blowing away this variable by setting it in the top-level
> CMakeLists.txt file (something that is done in all the CMake-based
> build systems I have helped to implement) could cause problems?


The typical use case is when your package is being used as a third party
library by somebody else.  There are many different ways that could be done
but for small dependencies, a typical approach is to just place the code in
a subdirectory and add it to an existing build with add_subdirectory.  In
this case, the calling project has set up the environment in a particular
way and your forcibly throwing it away.  There's other use cases for it but
it's typically good practice to make yourself work within an existing
environment rather than ignore the environment and create your own unless
you have a specific reason (other than I don't know what they're going to
do)


I wouldn't want to allow such freedom to users of software packages I am
> associated with since it implies a significant increase (more things
> that could possibly go wrong) in the support burden for each such
> project.


It's certainly up to you since it's your code but if you're distributing
source then somebody will just change it anyway if that's their use case.
Using the insert instead of set allows both uses cases; i.e. as a
standalone library or a third party library included by a larger CMake
project, so why limit it.

- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Problems with external language support when there is a blank in CMAKE_MODULE_PATH

[Chuck Atkins]

In addition to that in the Main CMakeLists.txt, make a similar change in
CMakeTestAdaCompiler.cmake.  Replace:
set(CMAKE_MODULE_PATH ${CMAKE_Ada_MODULES})
with:
list(INSERT CMAKE_MODULE_PATH 0 \"${CMAKE_Ada_MODULES}\")

The additional quoting here is because it's inside a file(WRITE ...)
command.  With both of those changes, I get:

source: ~/tmp/test_ada source
binary: ~/tmp/test_ada build
output:

[chuck.atkins@hal9000 test_ada build]$ cmake ../test_ada\ source
-- The C compiler identification is GNU 6.3.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- CMAKE_Ada_COMPILER_ID = GNU
-- Check for working /usr/bin/gnatmake compiler:
-- Check for working /usr/bin/gnatmake compiler:  -- works
-- CMAKE_Ada_COMPILER = /usr/bin/gnatgcc
-- GNAT_MAJOR_VERSION = 6
-- GNAT_VERSION = 6.3
-- Configuring done
-- Generating done
-- Build files have been written to: /home/
khq.kitware.com/chuck.atkins/tmp/test_ada build
[chuck.atkins@hal9000 test_ada build]$




------
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Thu, May 25, 2017 at 12:00 PM, Chuck Atkins <chuck.atk...@kitware.com>
wrote:

> Hi Alan,
>
> You're missing quotes so when CMake expands CMAKE_SOURCE_DIR then the
> space in the filename is interpreted as a list separator, no different than:
> set(my_list foo bar)
> What you want instead is:
> set(my_list "foo bar")
>
> Change:
> set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/Modules)
> To:
> set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules")
>
> Or even better, don't blow away the current module path, jut append to the
> front:
> list(INSERT CMAKE_MODULE_PATH 0 "${CMAKE_SOURCE_DIR}/cmake/Modules")
>
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Mon, May 22, 2017 at 3:58 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
> wrote:
>
>> So my guess is the measures that have been used so that a blank in the
>>> fullpath name works fine for CMake language support files that are
>>> installed by CMake have not been extended to the case where
>>> CMAKE_MODULE_PATH must be used to find the language support files.
>>>
>>
>> I forgot to mention that the PLplot project also uses CMAKE_MODULE_PATH
>> to find the find modules we have implemented. That use case works
>> without issues when CMAKE_MODULE_PATH has a blank in the full pathname.
>> So such a blank only appears to be an issue when CMAKE_MODULE_PATH
>> is used to find language support files.
>>
>> Alan
>>
>> __
>> Alan W. Irwin
>>
>> Astronomical research affiliation with Department of Physics and
>> Astronomy,
>> University of Victoria (astrowww.phys.uvic.ca).
>>
>> Programming affiliations with the FreeEOS equation-of-state
>> implementation for stellar interiors (freeeos.sf.net); the Time
>> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
>> software package (plplot.sf.net); the libLASi project
>> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
>> and the Linux Brochure Project (lbproject.sf.net).
>> __
>>
>> Linux-powered Science
>> __
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake-developers
>>
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Problems with external language support when there is a blank in CMAKE_MODULE_PATH

[Chuck Atkins]

Hi Alan,

You're missing quotes so when CMake expands CMAKE_SOURCE_DIR then the space
in the filename is interpreted as a list separator, no different than:
set(my_list foo bar)
What you want instead is:
set(my_list "foo bar")

Change:
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/Modules)
To:
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules")

Or even better, don't blow away the current module path, jut append to the
front:
list(INSERT CMAKE_MODULE_PATH 0 "${CMAKE_SOURCE_DIR}/cmake/Modules")


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Mon, May 22, 2017 at 3:58 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca>
wrote:

> So my guess is the measures that have been used so that a blank in the
>> fullpath name works fine for CMake language support files that are
>> installed by CMake have not been extended to the case where
>> CMAKE_MODULE_PATH must be used to find the language support files.
>>
>
> I forgot to mention that the PLplot project also uses CMAKE_MODULE_PATH
> to find the find modules we have implemented. That use case works
> without issues when CMAKE_MODULE_PATH has a blank in the full pathname.
> So such a blank only appears to be an issue when CMAKE_MODULE_PATH
> is used to find language support files.
>
> Alan
>
> __
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Proposed Feature: automatic search prefixes for find modules

[Chuck Atkins]

Brad and I discussed this a few years ago but nothing really came of it.
Working through several find modules today, I saw many common patterns for
this and realized it should be pretty easy to implement, so here it is:

Allow the variables ENV{PackageName_ROOT} and PackageName_ROOT to be used
as initial search prefixes for al find_{file,path,library,program} commands
executed from within a find module.

https://gitlab.kitware.com/cmake/cmake/merge_requests/796

Specifying the search prefix is a very common pattern, especially when the
utility is not setup in your path, and prevents the need to explicitly set
the location of all the various headers and libraries for a module when you
can just specify a prefix to use.

Thoughts? Good Idea?  Bad idea?  Good, but do it differently?  Undecided?

Thanks
- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Some info about AIX needed

[Chuck Atkins]

Hi Gregor,
Please try to keep these sort of conversations on the dev list to ensure
that others can benefit from or contribute to the discussion as well.

I just checked on the AIX 7.2 dashboard machine.  Here's the output from
all possible uname switches described in the manpage:
uname -a
AIX power8-aix 2 7 00FA74164C00

uname -x
AIX power8-aix 4201911884 2 7 00FA74164C00

uname -F
8B646080

uname -f
8B646083

uname -l
4201911884

uname -L
3 p3-power8-aix

uname -m
00FA74164C00

uname -M
IBM,8284-22A

uname -n
power8-aix

uname -p
powerpc

uname -r
2

uname -s
AIX

uname -u
IBM,02217416W

uname -v
7

uname -W
0

Attached is the cmake --system-information output from that same machine
using the CMake nightly build build with the IBM XL compiler 13.1.3:
[atkins3@power8-aix My_Tests]$ ./CMake_IBM-13.1.3/CMake-build/bin/cmake
--version
cmake version 3.8.20170327-gc4c307

CMake suite maintained and supported by Kitware (kitware.com/cmake).
[atkins3@power8-aix My_Tests]$

- Chuck


On Tue, Mar 28, 2017 at 4:32 PM, Gregor Jasny  wrote:

> On 3/28/17 10:08 PM, Gregor Jasny wrote:
> > Could you please run the following on you AIX box?
> >
> > uname -s ; uname -v ; uname -r
>
> Maybe also
>
> cmake --system-information aix.txt and attach the output.
>
> Thanks,
> Gregor
>
Avoid ctest truncation of output: CTEST_FULL_OUTPUT

=== MAIN VARIABLES

CMAKE_STATIC_LIBRARY_PREFIX == "lib"
CMAKE_STATIC_LIBRARY_SUFFIX == ".a"
CMAKE_SHARED_LIBRARY_PREFIX == "lib"
CMAKE_SHARED_LIBRARY_SUFFIX == ".so"
CMAKE_SHARED_MODULE_PREFIX == "lib"
CMAKE_SHARED_MODULE_SUFFIX == ".so"


CMAKE_DL_LIBS == "-lld"
CMAKE_LIBRARY_PATH_FLAG == "-L"
CMAKE_LINK_LIBRARY_FLAG == "-l"
CMAKE_SKIP_RPATH == "NO"
CMAKE_SYSTEM_INFO_FILE == "Platform/AIX"
CMAKE_SYSTEM_NAME == "AIX"
CMAKE_SYSTEM == "AIX-2"
CMAKE_CXX_COMPILER == "/usr/bin/c++"
CMAKE_C_COMPILER == "/usr/bin/gcc"
CMAKE_COMPILER_IS_GNUCC == "1"
CMAKE_COMPILER_IS_GNUCXX == "1"

// C shared library flag
CMAKE_SHARED_LIBRARY_C_FLAGS == "-fPIC"
CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS == "-shared -Wl,-G,-bnoipath"
CMAKE_SHARED_LIBRARY_LINK_FLAGS == ""
CMAKE_SHARED_LIBRARY_RUNTIME_FLAG == ""
CMAKE_SHARED_LIBRARY_RUNTIME_FLAG_SEP == ""
CMAKE_SHARED_LIBRARY_LINK_STATIC_C_FLAGS == ""
CMAKE_SHARED_LIBRARY_LINK_DYNAMIC_C_FLAGS == ""

// C shared module flags
CMAKE_SHARED_MODULE_C_FLAGS  == "-fPIC"
CMAKE_SHARED_MODULE_CREATE_C_FLAGS == "-shared -Wl,-G,-bnoipath"
CMAKE_SHARED_MODULE_LINK_STATIC_C_FLAGS == ""
CMAKE_SHARED_MODULE_LINK_DYNAMIC_C_FLAGS == ""

// C exe flags
CMAKE_EXE_LINK_STATIC_C_FLAGS == ""
CMAKE_EXE_LINK_DYNAMIC_C_FLAGS == ""

// CXX shared library flags
CMAKE_SHARED_LIBRARY_CREATE_CXX_FLAGS == "-shared -Wl,-G,-bnoipath"
CMAKE_SHARED_LIBRARY_CXX_FLAGS == "-fPIC"
CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS == "-Wl,-bexpall"
CMAKE_SHARED_LIBRARY_RUNTIME_CXX_FLAG == "-Wl,-blibpath:"
CMAKE_SHARED_LIBRARY_RUNTIME_CXX_FLAG_SEP == ":"
CMAKE_SHARED_LIBRARY_LINK_STATIC_CXX_FLAGS == ""
CMAKE_SHARED_LIBRARY_LINK_DYNAMIC_CXX_FLAGS == ""

// CXX shared module flags
CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS == "-shared -Wl,-G,-bnoipath"
CMAKE_SHARED_MODULE_CXX_FLAGS == "-fPIC"
CMAKE_SHARED_MODULE_LINK_STATIC_CXX_FLAGS == ""
CMAKE_SHARED_MODULE_LINK_DYNAMIC_CXX_FLAGS == ""

// CXX exe flags
CMAKE_EXE_LINK_STATIC_CXX_FLAGS == ""
CMAKE_EXE_LINK_DYNAMIC_CXX_FLAGS == ""

CMAKE_USER_MAKE_RULES_OVERRIDE == ""
CMAKE_VERBOSE_MAKEFILE == "FALSE"
CMAKE_BUILD_TYPE == ""
CMAKE_CXX_FLAGS == ""
CMAKE_CXX_FLAGS_DEBUG == "-g"
CMAKE_CXX_FLAGS_MINSIZEREL == "-Os -DNDEBUG"
CMAKE_CXX_FLAGS_RELEASE == "-O3 -DNDEBUG"
CMAKE_CXX_FLAGS_RELWITHDEBINFO == "-O2 -g -DNDEBUG"

CMAKE_C_FLAGS == ""
CMAKE_C_FLAGS_DEBUG == "-g"
CMAKE_C_FLAGS_MINSIZEREL == "-Os -DNDEBUG"
CMAKE_C_FLAGS_RELEASE == "-O3 -DNDEBUG"
CMAKE_C_FLAGS_RELWITHDEBINFO == "-O2 -g -DNDEBUG"

// build rules
CMAKE_CXX_CREATE_SHARED_LIBRARY == " 
   
  -o 
  "
CMAKE_CXX_CREATE_SHARED_MODULE == " 
   
  -o 
  "
CMAKE_C_CREATE_SHARED_LIBRARY == " 
   
  -o  
 "
CMAKE_C_CREATE_SHARED_MODULE == " 
   
  -o  
 "
CMAKE_CXX_CREATE_STATIC_LIBRARY == ""
CMAKE_C_CREATE_STATIC_LIBRARY == ""
CMAKE_CXX_COMPILE_OBJECT == " 
-o  -c "
CMAKE_C_COMPILE_OBJECT == "-o 
   -c "
CMAKE_C_LINK_EXECUTABLE == "   
   -o  "
CMAKE_CXX_LINK_EXECUTABLE == "   
-o  "

=
=== VARIABLES
=
CMAKE_AR "/usr/bin/ar"
CMAKE_AR "/usr/bin/ar"
CMAKE_BASE_NAME "g++"
CMAKE_BINARY_DIR "/home/atkins3/Dashboards/My_Tests/__cmake_systeminformation"
CMAKE_BUILD_TOOL "/usr/bin/gmake"
CMAKE_BUILD_TYPE ""
CMAKE_C11_COMPILE_FEATURES "c_std_11;c_static_assert"
CMAKE_C11_EXTENSION_COMPILE_OPTION "-std=gnu11"
CMAKE_C11_STANDARD_COMPILE_OPTION "-std=c11"
CMAKE_C90_COMPILE_FEATURES "c_std_90;c_function_prototypes"
CMAKE_C90_EXTENSION_COMPILE_OPTION "-std=gnu90"

Re: [cmake-developers] error install FAST with cmake

[Chuck Atkins]

Hi Soumaia,

It looks like your issues are not related to CMake but to the FAST project
it'self.  I see you're already in contact with the user community on their
mailing lists,
https://lists.gforge.inria.fr/pipermail/nossi-tddft-users/2017-February/06.html.
Please continue to work through the issue with the FAST project's
developers there as these are not issues with CMake.

- Chuck

On Thu, Feb 23, 2017 at 4:11 PM, Soumaia Djaadi via cmake-developers <
cmake-developers@cmake.org> wrote:

> Hi all
> I want install FAST code with some software (siesta-4.0, cmake-3.7, intel
> fortran parallel studio 2017, gsl-2.2) but i have this problem when run
> make command :
> 
> ..
>   Scanning dependencies of target myfit
> [ 73%] Building CXX object src/CMakeFiles/myfit.dir/LorentzFit.cpp.o
> /home/ilaf/Desktop/FAST-1-1/src/LorentzFit.cpp(219): error: class
> "gsl_multifit_fdfsolver" has no member "J"
> gsl_multifit_covar (s->J, 0.0, covar);
>^
>
> compilation aborted for /home/ilaf/Desktop/FAST-1-1/src/LorentzFit.cpp
> (code 2)
> src/CMakeFiles/myfit.dir/build.make:62: recipe for target
> 'src/CMakeFiles/myfit.dir/LorentzFit.cpp.o' failed
> make[2]: *** [src/CMakeFiles/myfit.dir/LorentzFit.cpp.o] Error 2
> CMakeFiles/Makefile2:1053: recipe for target
> 'src/CMakeFiles/myfit.dir/all' failed
> make[1]: *** [src/CMakeFiles/myfit.dir/all] Error 2
> Makefile:160: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> ..
> how can solve this problem ?can any one help me ?
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] how to use cmake3.7 for building fast code in fedora 24

[Chuck Atkins]

Hi Soumaia,
The compilers are not yet in your search path so CMake can't find them.
You need to setup the intel compiler's environment first with: source
/opt/intel/bin/compilervars.sh intel64 , then CMake should be able to find
your compiler.



--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Thu, Feb 16, 2017 at 5:42 AM, Soumaia Djaadi via cmake-developers <
cmake-developers@cmake.org> wrote:

> I want to install FAST (Fast Absorption Simulation by TDDFT) code but I
> faced some problems. I use for this  Cmake 3.7 and siesta-4.0, and the
> Intel 17.X compilers, my system is linux fedora 24. FAST code is freely
> available at https://gforge.inria.fr/frs/?group_id=1179
> This is the problem:
> [ilaf@localhost Desktop]tar xzf FAST−1−1.tar.gz
> [ilaf@localhostDesktop] cd FAST-1-1/
> [ilaf@localhost FAST-1-1]mkdir build
> [ilaf@localhostFAST−1−1]cd build/
> [ilaf@localhost build]$ CC=icc FC=ifort CXX=icpc cmake -
> DSIESTA_XC_DIR=/home/ilaf/Desktop/siesta-4.0/Obj/SiestaXC ../ CMake Error
> at /usr/local/share/cmake- 3.7/Modules/CMakeDetermineCCompiler.cmake:48
> (message): Could not find compiler set in environment variable CC:
> icc. Call Stack (most recent call first): CMakeLists.txt:47 (PROJECT)
> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage CMake Error:
> CMAKE_CXX_COMPILER not set, after EnableLanguage -- Configuring incomplete,
> errors occurred! See also "/home/ilaf/Desktop/FAST-1-1/
> build/CMakeFiles/CMakeOutput.log". [ilaf@localhost build]$
> Can any one help me ?
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Building CMake system libraries

[Chuck Atkins]

Shouldn't we  be able to accomplish the same same thing with just the
CMAKE_USE_SYSTEM_FOO
variable as a cache entry?  I ran into this when trying to build CMake
master and I want to use all system libraries but librhash.  Given the
current implementation, there's a number of configurations that cause no
way to actually set this with the user-facing option.  Typically I'd do
-DCMAKE_USE_SYSTEM_LIBRARIES=ON -DCMAKE_USE_SYSTEM_LIBRHASH=OFF but the
user-facing option has no meaning because internally the
CMAKE_USE_SYSTEM_LIBRARY_RHASH
variable, initialized by
CMAKE_USE_SYSTEM_LIBRARIES force overrides anything I try to set for it.

--
Chuck Atkins


On Wed, Dec 7, 2016 at 10:33 AM, Brad King <brad.k...@kitware.com> wrote:

> On 12/07/2016 10:02 AM, Chuck Atkins wrote:
> > I'm trying to understand why there's both CMAKE_USE_SYSTEM_LIBRARY_FOO
> > and CMAKE_USE_SYSTEM_FOO when it seems that the user-facing option
> > CMAKE_USE_SYSTEM_FOO isn't usually settable.
>
> This is for interaction with the bootstrap script.  Options to that
> come in as cache entries that set the default for the user-facing
> options IIRC.
>
> -Brad
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Security in CMake

[Chuck Atkins]

Hi Egor,
Is this intended to run on Linux?  If so, I think you're FAR better off
leveraging an existing security framework like SELinux, since it's actually
designed from the ground up to enforce these types of controls.  You could
define a label that you place on the executables run by the package manager
and then enforce whatever restrictions and controls you feel are
appropriate. This will let you do things like block network access got the
specific CMake executable used by the package system.  It allows the CMake
scripts to leverage all the available language and command features but
deny, ant a system level, actions you deem unsafe or harmful.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
<%28518%29%20881-1183>

On Sun, Aug 21, 2016 at 2:02 PM, Egor Pugin <egor.pu...@gmail.com> wrote:

> > What is the attack you want to stop? What are bad scripts and commands
> in this context?
>
> I wrote them in the first message. For example,
> - any cmake commands that use COMMAND keyword (execute_process(COMMAND
> ...), add_custom_{command|target}(...) etc. This will deny any user
> scripts, programs (wget, curl, rm, ...).
> - download commands (CMake's builtin curl) - they can fill the drives
> with trash.
>
> > CMake runs lots of commands all the time. Most can be changed by a user,
> many are changed by the generator based on environment and whatnot. Any of
> these may be bad commands -- based on configuration.
>
> Yes, and it should deny only stuff above in small CMakeLists.txt part
> that will be protected with some other commands or policies.
>
> > But if CMake gets a secure mode for your generator and if that is merged
> upstream, then I need to know about that when reading or writing
> CMakeLists.txt.
>
> For the moment I'm just asking about possibility of implementation of
> these features. Any decision will go from CMake guys, not from me. So,
> you shouldn't ask me about it. :)
>
> > Generated code is safe only as long as you very tightly control the
> environment CMake runs in.
>
> I don't care what is around, what is in user env. This is his
> responsibility. I'm just worrying for my parts of CMake stuff.
>
> On 21 August 2016 at 20:43, Tobias Hunger <tobias.hun...@gmail.com> wrote:
> > Hi Egor,
> >
> > Am 21.08.2016 12:34 schrieb "Egor Pugin" <egor.pu...@gmail.com>:
> >>
> >> > What are the attack scenarios you want to defend against? What should
> >> > not be possible in your system that currently is in CMake?
> >>
> >> At least downloading or executing bad scripts and commands.
> >
> > What is the attack you want to stop? What are bad scripts and commands in
> > this context?
> >
> > CMake runs lots of commands all the time. Most can be changed by a user,
> > many are changed by the generator based on environment and whatnot. Any
> of
> > these may be bad commands -- based on configuration.
> >
> > Downloading can be done using internal commands or by running e.g. wget
> or
> > curl, both of which are pretty widely available on developer machines.
> >
> >> > That forces me to keep more state in my head when reading
> CMakeLists.txt
> >> > files.
> >>
> >> CMake files are generated in my system. That's what I mean when I said
> >> 'based on CMake'.
> >
> > Sure. But if CMake gets a secure mode for your generator and if that is
> > merged upstream, then I need to know about that when reading or writing
> > CMakeLists.txt.
> >
> >> It's like compiler compiler like yacc, bison, lex, flex. They are
> >> producing output not for human readers, but for computer parsers.
> >> And that's why generated code is safe and insertions from users are not.
> >
> > Generated code is safe only as long as you very tightly control the
> > environment CMake runs in.
> >
> >> Also in the most cases there's no any insertions at all, so it's rare
> >> case.
> >
> > I'm sure you know what you are doing:)
> >
> > Best regards,
> > Tobias
>
>
>
> --
> Egor Pugin
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware

Re: [cmake-developers] Possibly an obscure bug

[Chuck Atkins]

This isn't a bug but more of a weird side effect of having your executable
named the same as an include file and adding the destination directory for
the executable in the include path.  The same thing would happen if your
executable was named foo and you had "#include ".  By setting
CMAKE_INCLUDE_CURRENT_DIR to on then CMake is adding
-I/path/to/source/blink and -I/path/to/build/blink to the compile line.
The default destination for the list executable also happens to be
/path/to/build/blink.  The second time around, the list executable from the
first run is in the include path, thus #include  picks up the
executable instead of the C++ header.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] cmFileCommand: sort list of files from glob command

[Chuck Atkins]

>
> I'd like to express my concerns about the proposed change. CMake strongly
> discourages using `file(GLOB)` to find source files, since file additions
> then do not automatically trigger a buildsystem regeneration.
>

I second this.  The intent of the patch is to address an issue that is only
present when using a practice explicitly not recommended in CMake
documentation:

https://cmake.org/cmake/help/v3.5/command/file.html
Note: We do not recommend using GLOB to collect a list of source files from
your source tree. If no CMakeLists.txt file changes when a source is added
or removed then the generated build system cannot know when to ask CMake to
regenerate.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] FindBoost does not detect absence of header file

[Chuck Atkins]

I guess it doesn't really matter but for the libraries that don't have a
single include header, should you be using these instead:

   - container/container_fwd.hpp
   - exception/all.hpp
   - filesystem.hpp
   - math_fwd.hpp (instead of math/quaternion.hpp)
   - system/config.hpp
   - type_erasure/config.hpp

They're "common" or "central" headers for the libraries instead of specific
headers.

- Chuck

On Wed, May 11, 2016 at 10:38 AM,  wrote:

> On 2016-04-12 11:22, Joachim Wuttke wrote:
>
>> FindBoost does not detect absence of header files.
>>
>> To be specific: Run the following under cmake version 3.5.1:
>>
>> set(Boost_NO_BOOST_CMAKE ON) # prevent shortcut
>> set(Boost_USE_STATIC_LIBS OFF)
>> set(Boost_USE_MULTITHREADED ON)
>> set(Boost_USE_STATIC_RUNTIME OFF)
>> add_definitions(-DBOOST_ALL_DYN_LINK) # line is needed for MSVC
>> #add_definitions(-DBOOST_LIB_DIAGNOSTIC) # shows during compilation
>> auto-linked libraries
>> if(WIN32)
>> set(boost_libraries_required date_time chrono program_options zlib
>> bzip2 iostreams system filesystem regex thread)
>> else()
>> set(boost_libraries_required date_time chrono program_options
>> iostreams system filesystem regex thread)
>> endif()
>> find_package(Boost 1.48.0 COMPONENTS ${boost_libraries_required} REQUIRED)
>> message(STATUS "--> Boost_INCLUDE_DIRS: ${Boost_INCLUDE_DIRS}")
>> message(STATUS "Boost_LIBRARY_DIRS: ${Boost_LIBRARY_DIRS}")
>> message(STATUS "Boost_LIBRARIES: ${Boost_LIBRARIES}")
>>
>> It will pass, even if files like /usr/include/boost/date_time.hpp  are
>> removed
>> from the system.
>>
>
> Attached is a patch to add this extra checking.
>
> For each library component, there is a corresponding header which has been
> present in all versions of boost to date which provide the library; the
> list used to validate this is also attached.  I have also validated that
> each component works with find_package for Boost 1.58 and 1.60.
>
> If your system contains both the libraries and headers, then FindBoost
> will behave exactly as before.  But if you have the libraries without the
> headers, FindBoost will now fail, rather than passing and then having the
> build subsequently fail when it tries to use the nonexistent headers.  So
> it's essentially adding an additional header check per component, which
> will identify situations where the user has an incomplete Boost
> installation e.g. no all the -dev packages are installed.
>
> I can merge this into next for testing, but if anyone wanted to have an
> initial play with it to verify that it's still functional and that the
> approach is sound, I can wait off for now.
>
>
> Regards,
> Roger
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] RFC: LLVM community CMake documentation

[Chuck Atkins]

Hi Chris,

This is great!  I do have a suggestion that perhaps Brad could weigh in on
(may disagree).  Since your already looking at a reasonably recent minimum
requirement in your examples (3.2) and discussing bumping the minimum up to
3.4.3 even, I think it would be worthwhile to let even some of the simple
examples show some of the newer language features and syntax.  For example,
in your lists of lists example, you currently have:

foreach(list_name ${list_of_lists})
  foreach(value ${${list_name}})
message(${value})
  endforeach()
endforeach()

which has been valid CMake syntax since the days of yore, but you could
show the newer syntax instead that uses the list variables directly instead
of de-referencing them:

foreach(list_name IN LISTS list_of_lists)
  foreach(value IN LISTS ${list_name})
message(${value})
  endforeach()
endforeach()

It's of course a preference for how you want to document and use CMake in
llvm but it might be good to get users started right off the bat with "new"
cmake.


- Chuck

On Wed, Apr 27, 2016 at 4:39 PM, Chris Bieneman 
wrote:

> Hello cmake-developers,
>
> Earlier this year the LLVM community finished migrating to CMake as our
> one and only build system. One of the lingering things on my to-do list to
> help this transition is to write some basic documentation for the CMake
> language to help LLVM developers get a feel for the language.
>
> I’ve attached the working draft of my documentation, and would greatly
> appreciate any feedback from members of the CMake community. While it is
> not my goal to be a definitive source, I would like to be as accurate as I
> can be.
>
> Thank you,
> -Chris
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] find_program HINTS no longer preferred over PATH (was: HINTS not correctly handled in find_program)

[Chuck Atkins]

>From what I can tell, the search order is still preserved as expected.

[chuck.atkins@hal9000 testdir]$ cat TestFindProgram.cmake
set(CMAKE_PREFIX_PATH
  "/FOODIR_CMAKE_PREFIX_PATH1;/FOODIR_CMAKE_PREFIX_PATH2"
 CACHE STRING "" FORCE)
set(CMAKE_PROGRAM_PATH
  "/FOODIR_CMAKE_PROGRAM_PATH1;/FOODIR_CMAKE_PROGRAM_PATH2"
   CACHE STRING "" FORCE)
set(CMAKE_APPBUNDLE_PATH
  "/FOODIR_CMAKE_APPBUNDLE_PATH1;/FOODIR_CMAKE_APPBUNDLE_PATH2"
   CACHE STRING "" FORCE)

set(ENV{CMAKE_PREFIX_PATH}
  "/FOODIR_ENV_CMAKE_PREFIX_PATH1:/FOODIR_ENV_CMAKE_PREFIX_PATH2"
  )
set(ENV{CMAKE_PROGRAM_PATH}
  "/FOODIR_ENV_CMAKE_PROGRAM_PATH1:/FOODIR_ENV_CMAKE_PROGRAM_PATH2"
  )
set(ENV{CMAKE_APPBUNDLE_PATH}
  "/FOODIR_ENV_CMAKE_APPBUNDLE_PATH1:/FOODIR_ENV_CMAKE_APPBUNDLE_PATH2"
  )

set(ENV{PATH} "/FOODIR_ENV_PATH1:/FOODIR_ENV_PATH2")

set(CMAKE_SYSTEM_PREFIX_PATH
  "/FOODIR_CMAKE_SYSTEM_PREFIX_PATH1;/FOODIR_CMAKE_SYSTEM_PREFIX_PATH2"
  CACHE STRING "" FORCE)
set(CMAKE_SYSTEM_PROGRAM_PATH
  "/FOODIR_CMAKE_SYSTEM_PROGRAM_PATH1;/FOODIR_CMAKE_SYSTEM_PROGRAM_PATH2"
  CACHE STRING "" FORCE)
set(CMAKE_SYSTEM_APPBUNDLE_PATH

"/FOODIR_CMAKE_SYSTEM_APPBUNDLE_PATH1;/FOODIR_CMAKE_SYSTEM_APPBUNDLE_PATH2"
  CACHE STRING "" FORCE)

find_program(FOO foo.bin
  HINTS /FOODIR_FP_HINTS1 /FOODIR_FP_HINTS2
  PATHS /FOODIR_FP_PATHS1 /FOODIR_FP_PATHS2)

[chuck.atkins@hal9000 testdir]$

By setting each possible location to FOODIR_LOCATIONNAME1 and
FOODIR_LOCATIONMAME2, strace make sit easy to see whats searched for in
what order:

[chuck.atkins@hal9000 testdir]$ strace cmake -P TestFindProgram.cmake 2>&1
| sed -n 's|^[^"]*"\([^"]*foo.bin\)".*|\1|p'
foo.bin
/FOODIR_CMAKE_PREFIX_PATH1/bin/foo.bin
/FOODIR_CMAKE_PREFIX_PATH1/sbin/foo.bin
/FOODIR_CMAKE_PREFIX_PATH1/foo.bin
/FOODIR_CMAKE_PREFIX_PATH2/bin/foo.bin
/FOODIR_CMAKE_PREFIX_PATH2/sbin/foo.bin
/FOODIR_CMAKE_PREFIX_PATH2/foo.bin
/FOODIR_CMAKE_PROGRAM_PATH1/foo.bin
/FOODIR_CMAKE_PROGRAM_PATH2/foo.bin
/FOODIR_CMAKE_APPBUNDLE_PATH1/foo.bin
/FOODIR_CMAKE_APPBUNDLE_PATH2/foo.bin
/FOODIR_ENV_CMAKE_PREFIX_PATH1/bin/foo.bin
/FOODIR_ENV_CMAKE_PREFIX_PATH1/sbin/foo.bin
/FOODIR_ENV_CMAKE_PREFIX_PATH1/foo.bin
/FOODIR_ENV_CMAKE_PREFIX_PATH2/bin/foo.bin
/FOODIR_ENV_CMAKE_PREFIX_PATH2/sbin/foo.bin
/FOODIR_ENV_CMAKE_PREFIX_PATH2/foo.bin
/FOODIR_ENV_CMAKE_PROGRAM_PATH1/foo.bin
/FOODIR_ENV_CMAKE_PROGRAM_PATH2/foo.bin
/FOODIR_ENV_CMAKE_APPBUNDLE_PATH1/foo.bin
/FOODIR_ENV_CMAKE_APPBUNDLE_PATH2/foo.bin
/FOODIR_FP_HINTS1/foo.bin
/FOODIR_FP_HINTS2/foo.bin
/FOODIR_ENV_PATH1/foo.bin
/FOODIR_ENV_PATH2/foo.bin
/FOODIR_CMAKE_SYSTEM_PREFIX_PATH1/bin/foo.bin
/FOODIR_CMAKE_SYSTEM_PREFIX_PATH1/sbin/foo.bin
/FOODIR_CMAKE_SYSTEM_PREFIX_PATH1/foo.bin
/FOODIR_CMAKE_SYSTEM_PREFIX_PATH2/bin/foo.bin
/FOODIR_CMAKE_SYSTEM_PREFIX_PATH2/sbin/foo.bin
/FOODIR_CMAKE_SYSTEM_PREFIX_PATH2/foo.bin
/FOODIR_CMAKE_SYSTEM_PROGRAM_PATH1/foo.bin
/FOODIR_CMAKE_SYSTEM_PROGRAM_PATH2/foo.bin
/FOODIR_CMAKE_SYSTEM_APPBUNDLE_PATH1/foo.bin
/FOODIR_CMAKE_SYSTEM_APPBUNDLE_PATH2/foo.bin
/FOODIR_FP_PATHS1/foo.bin
/FOODIR_FP_PATHS2/foo.bin
[chuck.atkins@hal9000 testdir]$

>From this, it looks like the find_program(... HINTS ...) are still searched
before ENV{PATH}:

/FOODIR_FP_HINTS1/foo.bin
/FOODIR_FP_HINTS2/foo.bin
/FOODIR_ENV_PATH1/foo.bin
/FOODIR_ENV_PATH2/foo.bin


- Chuck

On Wed, Sep 9, 2015 at 11:01 AM, Brad King  wrote:

> On 09/03/2015 03:51 AM, CHEVRIER, Marc wrote:
> > 1. Build phase. Under find_program.BUG/build, use CMakeLists.txt to
> prepare runtime part
> > 2. Test phase. Under find_program.BUG/runtime, use CMakeLists.txt to
> show the bug.
>
> Thanks, Marc.
>
> Chuck, this was regressed by your changes in CMake 3.2:
>
>  Merge topic 'refactor-search-path-construction'
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dd89506c
>
> Please revise the logic to preserve the documented behavior:
>
>  http://www.cmake.org/cmake/help/v3.3/command/find_program.html
>
> HINTS should be preferred before ENV{PATH}.  Please also add
> appropriate test cases (e.g. Tests/RunCMake/find_program) and
> also check the behavior for other find_* commands.
>
> Thanks,
> -Brad
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] New policy to address rdynamic

[Chuck Atkins]

So, from what I can tell, the Visual Studio generator and Xcode generator
don't even use the CMAKE_SHARED_LIBRARY_LINK__FLAGS.  I know it's the
generators and not platforms since my tests pass on these platforms with
Makefile and Ninja generators but fail with Visual Studio and Xcode
generators.  Is this common to all multi-config generators or just these
two? I'm trying to determine under which circumstances the policy is even
applicable.

- Chuck

On Wed, Aug 26, 2015 at 6:30 PM, Chuck Atkins <chuck.atk...@kitware.com>
wrote:

> Maybe
>>
>>  [TARGET_PROPERTIES   [ ]... ]
>>
>> makes sense instead?
>>
>> That would allow setting ANDROID_API, WIN32_EXECUTABLE etc.
>>
>
> Good idea!  I actually do like that better, but it's outside the scope of
> this change.  For now I'll remove the ENABLE_EXPORTS but still propagate
> the policy and then push a separate branch to add the TARGET_PROPERTIES
> argument.
>
> Thanks
> - Chuck
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] New policy to address rdynamic

[Chuck Atkins]

I've implemented a new policy, CMP0065, to restrict the addition of
CMAKE_SHARED_LIBRARY_LINK_LANG_FLAGS to executables to only when the
ENABLE_EXPORTS target property is set.  This should allow us to preserve
backwards compatibility in the places it breaks existing binaries but allow
us to remove it by default for newer projects.

See stage/restrict-shlib-link-flags-to-enable-exports

The motivator behind this is to get closer to easily supporting fully
static binaries..  Any feedback would be appreciated.

- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] New policy to address rdynamic

[Chuck Atkins]

 Maybe

  [TARGET_PROPERTIES prop1 value1 [prop1 value1]... ]

 makes sense instead?

 That would allow setting ANDROID_API, WIN32_EXECUTABLE etc.


Good idea!  I actually do like that better, but it's outside the scope of
this change.  For now I'll remove the ENABLE_EXPORTS but still propagate
the policy and then push a separate branch to add the TARGET_PROPERTIES
argument.

Thanks
- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] problem installing cmake 3.3.1 on CentOS release 6.6 cluster

[Chuck Atkins]

Hi Adrian,


 I have encountered problems installing cmake 3.3.1 on our CentOS release
 6.6 cluster.  It builds fine but when I come to install I get this error:

 file INSTALL cannot copy file ... (this is for the copyright file).


I wasn't able to reproduce this error.  Using CentOS 6.6:

[chuck.atkins@urras v3.3.1]$ cat /etc/redhat-release
CentOS release 6.6 (Final)
[chuck.atkins@urras v3.3.1]$ CC=/usr/bin/gcc CXX=/usr/bin/g++
FC=/usr/bin/gfortran ../../source/v3.3.1/bootstrap --parallel=16
--prefix=${HOME}/Code/CMake/install/v3.3.1
[chuck.atkins@urras v3.3.1]$ make -j16
...
[100%] Built target ctest
[chuck.atkins@urras v3.3.1]$ make install
...
-- Installing:
/home/local/KHQ/chuck.atkins/Code/CMake/install/v3.3.1/share/cmake-3.3/completions/ctest
[chuck.atkins@urras v3.3.1]$



 Note, I'm using gcc 4.8.0


While not really part of your question it is worth noting, when building in
multi-compiler environments, you usually want to build CMake with the
system compiler, i.e., /usr/bin/gcc and /usr/bin/g++, since that will
determine the runtime dependencies of CMake, which in this case is gcc/g++
4.4.  Regardless of what you build CMake with, it can use and generate
build files for any supported compiler of you choosing.  So, in other
words, if you build it with the system GCC, you can then load the gcc/4.8.0
module (or however you choose it in your cluster's environment), and run
the built-with-system-compiler cmake to configure and generate projects for
your currently loaded environment.



 but some of the system tools and libraries are quite old.


If you don't specify explicitly, then CMake will use it's own versions of
dependencies and statically link them into bin/cmake so that shouldn't be a
problem.


I am install into a user directory that I have the correct permissions
 to install in.  It does create the file but the file is empty and the
 install terminates.
 ...
 Any idea what's going wrong with the build/install?


Is the location you are trying to install it to on a network file system
(i.e. NFS, Lustre, GPFS, PANFS, etc.)?  If so, network file systems are
often obtusely problematic for builds and installs due to the various low
level timing and synchronization problems associated with them.  If you
have access to a local file system on the node you are compiling and
installing on (maybe some place in /tmp, or /dev/shm), try to use that for
the build and install, then just copy the resulting installation folder to
the final destination on the network file system.

- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] problem installing cmake 3.3.1 on CentOS release 6.6 cluster

[Chuck Atkins]

Instead of an install, try to run make package.  This will create
cmake-3.3.1-Linux-x86_64.tar.gz that you should be able to extract anywhere
you want to install it to.

- Chuck

On Wed, Aug 19, 2015 at 11:59 AM, Adrian Jackson adri...@epcc.ed.ac.uk
wrote:

 Hi Chuck,

 Thanks for the response, yes it is installing into a network file
 system.  I can happily build and install it into /tmp but then if I copy
 it across to the directory I want it in then a whole bunch of links and
 references don't point to the correct place and the seems to screw
 things up.

 chers

 adrianj

 --
 The University of Edinburgh is a charitable body, registered in
 Scotland, with registration number SC005336.


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] HP-UX and static link flags for C shared libs

[Chuck Atkins]

Regarding branch stage/add-link-search-static-properties-defaults

When working on a recent branch to allow default initialization of the
target properties LINK_SEARCH_(START|END)_STATIC with a corresponding
CMAKE_* variable, I encountered what I believe to be a bug in how the HP-UX
toolchains are getting used.  When merging for testing, the HP-UX
dashboards bombed out:
https://open.cdash.org/viewTest.php?onlyfailedbuildid=3947999 .  The
repeated error is:

[ 17%] Linking C shared library impl/libtestExe2libImp.sl
cc: warning 901: unknown option: `-a': use +help for online documentation.
cc: warning 1913: `default' does not exist or cannot be read
ld: I/O error, file default: No such file or directory

From looking in the Platform/HP-UX.cmake file, the cause of this looks to
be:

# Initialize C and CXX link type selection flags.  These flags are# used
when building a shared library, shared module, or executable# that links to
other libraries to select whether to use the static or# shared versions of
the libraries.  *Note that C modules and shared# libs are built using ld
directly so we leave off the -Wl, portion.*



*foreach(type SHARED_LIBRARY SHARED_MODULE)
set(CMAKE_${type}_LINK_STATIC_C_FLAGS -a archive)
set(CMAKE_${type}_LINK_DYNAMIC_C_FLAGS -a default)endforeach()*
foreach(type EXE)
  set(CMAKE_${type}_LINK_STATIC_C_FLAGS -Wl,-a,archive)
  set(CMAKE_${type}_LINK_DYNAMIC_C_FLAGS -Wl,-a,default)
endforeach()
foreach(type SHARED_LIBRARY SHARED_MODULE EXE)
  set(CMAKE_${type}_LINK_STATIC_CXX_FLAGS -Wl,-a,archive)
  set(CMAKE_${type}_LINK_DYNAMIC_CXX_FLAGS -Wl,-a,default)
endforeach()

The comment explains that the linker is used directly for C shared
libraries but for C executables and C++ executables, shared libraries, and
modules, the compiler is used to invoke the linker.  Hence for C shared
libs, -a archive, instead of -Wl,-a archive.  Based of the error message
though, it looks like the C compiler is getting
used as the linker for shared libs and not the linker directly.  So, I ask
you HP-UX devs, which one of the following would be the appropriate fix:

   1. Assume that using the C compiler as the linker is correct so fix the
   documentation and just set the C link flags to use -Wl,-a instead of -a
   2. Assume that the docs in the HP-UX platform file are correct and make
   CMake start using the linker directly for C shared libs
   3. Something else not described by 1 or 2

Thanks for the input

- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] HP-UX and static link flags for C shared libs

[Chuck Atkins]

  the C compiler is getting used as the linker for shared libs

 It looks like this has been the case since CMake 2.8.7:


Easy then.  I'll just fix it to use -Wl,-a like all the others.  Thanks.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] HP-UX and static link flags for C shared libs

[Chuck Atkins]

A related question is whether those are even the correct flags for the
CMAKE_${type}_LINK_DYNAMIC_${lang}_FLAGS.  According to the compiler
reference manual, -Wl,-a,default will search for shared first, then use
static if the shared lib is not present.  Changing this to -Wl,-a,shared
will make the search use shared libraries exclusively, which is how all the
other platforms work.  It's outside the scope of this branch but should it
be changed in a separate branch?

- Chuck

On Mon, Aug 10, 2015 at 12:00 PM, Chuck Atkins chuck.atk...@kitware.com
wrote:

  the C compiler is getting used as the linker for shared libs

 It looks like this has been the case since CMake 2.8.7:


 Easy then.  I'll just fix it to use -Wl,-a like all the others.  Thanks.


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] malware?

[Chuck Atkins]

Hi David,

I just checked the cmake.org download and was able to verify the following:

cmake-3.2.3-Darwin-x86_64.dmg - 27949121 Bytes - MD5
97c26048e9b3e242951bb5b1ff88da9e
cmake-3.3.0-Darwin-x86_64.dmg - 22628082 Bytes - MD5
232ae38586f3e6b665f9b7ac281167a0

I checked from both inside and outside Kitware's network as to verify
internal and external were the same.  Are these the same for the files you
downloaded from cmake.org?  Can you try to download from a different
machine to verify it's not a local problem?

Thanks


- Chuck

On Fri, Jul 24, 2015 at 1:04 AM, David Powell d...@telus.net wrote:

 hi

 I downloaded cmake an hour ago from cmake.org and found myself with an
 unwanted piece of software called “advanced mac cleaner”, an app that was
 hard to get rid of. I’m not certain it came from your site but it happened
 at the same time and I can’t think of any other explanation..  The download
 file from cmake.org (supposedly the latest stable dmg for mac) was much
 bigger (30MB) than the cmake file I subsequently downloaded from github.

 --

 Powered by www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] malware?

[Chuck Atkins]

 If you're trying to detect imposter binaries, don't use md5.


Fair enough, it was more force of habit than anything.  Regardless, the
file size seems way off



 I get the following for my cmake download:

 $ shasum -a 256 /Users/sean/Downloads/cmake-3.3.0-Darwin-x86_64.dmg
 0282d6f139f5292c2bb9b3d600df6b7db242d8f53c4ab8d1e6ddff76402e0eab
 /Users/sean/Downloads/cmake-3.3.0-Darwin-x86_64.dmg


Confirmed:

[chuck.atkins@hal9000 tmp]$ shasum -a 256 cmake-3.3.0-Darwin-x86_64.dmg
0282d6f139f5292c2bb9b3d600df6b7db242d8f53c4ab8d1e6ddff76402e0eab
cmake-3.3.0-Darwin-x86_64.dmg
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] New module FindLibDl

[Chuck Atkins]

Hi Roger,


 However, do I still need to independently check for dlfcn.h?

How do I know that I have a working dlopen?


dlopen defined in dlfcn.h is part of POSIX so generally if you're on a *nix
system then you can rely on it being there.  The associated library,
however, is a different story, hence CMAKE_DL_LIBS.  So then your code
would be:

- Begin fooUnix.c -
...
#include dlfcn.h
...
void foo()
{
  void *dl = dlopen(...);
  ...
}
...
- End fooUnix.c -

- Begin CMakeLists.txt -
...
if(UNIX)
   add_library(FooLib fooUnix.c)
  if(CMAKE_DL_LIBS)
target_link_libraries(FooLib ${CMAKE_DL_LIBS})
  endif()
endif()
...
- End CMakeLists.txt -

which is actually overkill since you could avoid the if(CMAKE_DL_LIBS)
check entirely since passing an empty library list to target_link_libraries
is still valid.


- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] ProcessUNIX and ANSI != POSIX

[Chuck Atkins]

I've added an extra configure check in KWSys for ProcessUNIX.c to test for
the required POSIX function sigaction.  Previously the build would
mysteriously fail if it's not available (if building in strict ANSI mode,
for instance); now at least the failure will be at configure time and for
reasonably clear reasons.

http://review.source.kitware.com/#/c/18065/

- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] GCC HPPA linker errors

[Chuck Atkins]

While the dashboard may be red today from the curl update, it looks like
this branch has cleared the linker issue and now pioneer and voyager are
happily green together.
On Nov 6, 2014 7:24 PM, David Cole via cmake-developers 
cmake-developers@cmake.org wrote:

These are the earliest CDash results available for CMake:
http://open.cdash.org/index.php?project=CMakedate=2014-07-09

(they're discarded after 120 days...)

On Thu, Nov 6, 2014 at 5:27 PM, Rolf Eike Beer e...@sf-mail.de wrote:

 Am Donnerstag, 6. November 2014, 12:44:12 schrieb Brad King:
  On 11/06/2014 12:00 PM, Chuck Atkins wrote:
   I added an HP-UX block and adjusted the logic to be a bit more
   consistent with the other determine system blocks
 
  Looks good to me, assuming the test for parisc on hpux is correct.

 Chuck, you could try looking back into June/July to see what the HP-UX
 machine
 reported (hpux11.detec). On the other hand the check now only matches
 machines
 that are not Itanium, which is in theory 2 architectures, but I don't think
 that anyone can get CMake to work on an HP-UX m68k machine ;)
 --

 Powered by www.kitware.com

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

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

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

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

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



--

Powered by www.kitware.com

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] GCC HPPA linker errors

[Chuck Atkins]

Hi Eike,

So, it seems that voyager has no issue, only pioneer, which I'm just taking
as coincidence from differences in various binary sizes.  However, from
looking at the error log, the link line for cmake shows:

/usr/bin/c++ -Wnon-virtual-dtor -Wcast-align -Wchar-subscripts -Wall -W
-Wshadow -Wpointer-arith -Wformat-security -Wundef -g
CMakeFiles/cmake.dir/cmakemain.cxx.o CMakeFiles/cmake.dir/cmcmd.cxx.o -o
../bin/cmake -rdynamic libCMakeLib.a kwsys/libcmsys.a
../Utilities/cmexpat/libcmexpat.a
../Utilities/cmlibarchive/libarchive/libcmlibarchive.a
../Utilities/cmliblzma/libcmliblzma.a ../Utilities/cmbzip2/libcmbzip2.a
../Utilities/cmcompress/libcmcompress.a ../Utilities/cmcurl/libcmcurl.a
../Utilities/cmzlib/libcmzlib.a -ldl

which doesn't show the addition of the -mlong-calls flag.  This is a bit
perplexing as it would seem to imply that some how the if conditions are
not being satisfied.  On pioneer, does cmake --system-information show the
expected value for CMAKE_SYSTEM_PROCESSOR, CMAKE_C_COMPILER_ID, and
CMAKE_CXX_COMPILER_ID, i.e. parisc, GNU, and GNU ?


- Chuck

On Wed, Nov 5, 2014 at 11:55 AM, Rolf Eike Beer e...@sf-mail.de wrote:

 Am Mittwoch, 5. November 2014, 10:38:14 schrieben Sie:
  So, it seems nothing changed.  Looking at the log though, it looks like
 the
  flags aren't even getting used.  Can you check the output of uname with
  it's various options?  I suspect the result might not be exactly
 parisc.

 voyager ~ # uname -a
 Linux voyager 3.16.1 #1 Tue Sep 2 17:27:07 CEST 2014 parisc PA8600
 (PCX-W+) 9000/785/C3600 GNU/Linux
 voyager ~ # uname -m
 parisc

 --

 Powered by www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] GCC HPPA linker errors

[Chuck Atkins]

Aha!  I'll change it to MATCHES instead of STREQUALS and that should do it
since technically the issue is with both 32 and 64 bit architectures, it
just might not have shown up yet on both.  Perhaps the build name for the
dashboard should be HPPA64 then instead HPPA32?

- Chuck

On Thu, Nov 6, 2014 at 10:54 AM, Rolf Eike Beer e...@sf-mail.de wrote:

 Am Donnerstag, 6. November 2014, 10:37:25 schrieb Chuck Atkins:
  Hi Eike,
 
  So, it seems that voyager has no issue, only pioneer, which I'm just
 taking
  as coincidence from differences in various binary sizes.  However, from
  looking at the error log, the link line for cmake shows:
 
  /usr/bin/c++ -Wnon-virtual-dtor -Wcast-align -Wchar-subscripts -Wall -W
  -Wshadow -Wpointer-arith -Wformat-security -Wundef -g
  CMakeFiles/cmake.dir/cmakemain.cxx.o CMakeFiles/cmake.dir/cmcmd.cxx.o -o
  ../bin/cmake -rdynamic libCMakeLib.a kwsys/libcmsys.a
  ../Utilities/cmexpat/libcmexpat.a
  ../Utilities/cmlibarchive/libarchive/libcmlibarchive.a
  ../Utilities/cmliblzma/libcmliblzma.a ../Utilities/cmbzip2/libcmbzip2.a
  ../Utilities/cmcompress/libcmcompress.a ../Utilities/cmcurl/libcmcurl.a
  ../Utilities/cmzlib/libcmzlib.a -ldl
 
  which doesn't show the addition of the -mlong-calls flag.  This is a bit
  perplexing as it would seem to imply that some how the if conditions are
  not being satisfied.  On pioneer, does cmake --system-information show
 the
  expected value for CMAKE_SYSTEM_PROCESSOR, CMAKE_C_COMPILER_ID, and
  CMAKE_CXX_COMPILER_ID, i.e. parisc, GNU, and GNU ?

 It says parisc64. I obviously never properly checked that when playing
 with my
 workaround code.

 Eike
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] GCC HPPA linker errors

[Chuck Atkins]

 I hate MATCHES ;) at least make it MATCHES ^parisc.


A  reasonable compromise.

The branch has been updated, merged, squashed, and remerged to next.  We'll
see what happens tonight.

- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] GCC HPPA linker errors

[Chuck Atkins]

Rats!  I keep forgetting about the bootstrap.  I added an HP-UX block and
adjusted the logic to be a bit more consistent with the other determine
system blocks by moving the parisc determination out on it's own.  How's
this?

# Determine whether this is HP-UX
if echo ${cmake_system} | grep HP-UX /dev/null 21; then
  cmake_system_hpux=true
else
  cmake_system_hpux=false
fi

# Determine whether this is Linux
if echo ${cmake_system} | grep Linux /dev/null 21; then
  cmake_system_linux=true
else
  cmake_system_linux=false
fi

# Determine whether this is a PA-RISC machine
if ${cmake_system_linux}; then
  if uname -m | grep parisc /dev/null 21; then
cmake_machine_parisc=true
  else
cmake_machine_parisc=false
  fi
elif ${cmake_system_hpux}; then
  if uname -m | grep ia64 /dev/null 21; then
cmake_machine_parisc=false
  else
cmake_machine_parisc=true
  fi
fi





- Chuck

On Thu, Nov 6, 2014 at 11:27 AM, Brad King brad.k...@kitware.com wrote:

 On 11/06/2014 11:22 AM, Chuck Atkins wrote:
  The branch has been updated, merged, squashed, and remerged to next

 Thanks.  This hunk:

  # Determine whether this is Linux
  if echo ${cmake_system} | grep Linux /dev/null 21; then
cmake_system_linux=true
# find out if it is a HP PA-RISC machine
if uname -m | grep parisc /dev/null 21; then
  cmake_machine_parisc=true
else
  cmake_machine_parisc=false
fi
  else
cmake_system_linux=false
cmake_machine_parisc=false
  fi

 Now sets an unused 'cmake_system_linux' variable and will never
 set 'cmake_machine_parisc' on non-Linux systems.  Isn't the goal
 for this to work on HP-UX too?

 -Brad


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] GCC HPPA linker errors

[Chuck Atkins]

So, it seems nothing changed.  Looking at the log though, it looks like the
flags aren't even getting used.  Can you check the output of uname with
it's various options?  I suspect the result might not be exactly parisc.

- Chuck

On Tue, Nov 4, 2014 at 4:27 PM, Chuck Atkins chuck.atk...@kitware.com
wrote:

 just a matter of taste if this will be narrowed to Linux or not. In any
 case
 please try if you can just drop the existing workarounds. The best would
 probably to just replace their set() with yours and see if it works. If it
 does you can remove the if(Linux) and only match for the processor.


 I didn't realize the -Wl,--unique=.text._* was trying to address the same
 problem!  I'll try this as a replacement tonight and we'll see if it cleans
 it up.


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] GCC HPPA linker errors

[Chuck Atkins]

stage/fix-gcc-hppa

Add -mlong-calls for gcc on HPPA.  Merged to next for testing.

- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] GCC HPPA linker errors

[Chuck Atkins]

 Please make sure you also add these to bootstrap.sh.


Will do.



 And please see the very end of
 CompileFlags.cmake where we already added workarounds for HPPA. Until now
 we
 have not seen the problem on HP-UX, so this has been restricted to Linux
 until
 now.


I considered putting it in there but from what I can tell, the issue is
specific to GCC code generation for PA-RISC, regardless of OS, and is
unrelated to Linux.  Would you be able to verify whether or not this is
needed on PA-RISC HP-UX with GCC v4+?  I only have access to an ia64 HP-UX
environment.

- Chuck


- Chuck

On Tue, Nov 4, 2014 at 3:50 PM, Rolf Eike Beer e...@sf-mail.de wrote:

 Am Dienstag, 4. November 2014, 11:27:24 schrieb Chuck Atkins:
  stage/fix-gcc-hppa
 
  Add -mlong-calls for gcc on HPPA.  Merged to next for testing.

 Sorry,

 saw this mail only after I mailed you privately because I looked into the
 commit log first. For general consumption, here are the relevant parts
 again:

 Please make sure you also add these to bootstrap. And please see the very
 end
 of CompileFlags.cmake where we already added workarounds for HPPA, those
 are
 also in bootstrap. Until now we have not seen the problem on HP-UX, so this
 has been restricted to Linux until now.

 Greetings,

 Eike
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] GCC HPPA linker errors

[Chuck Atkins]

 just a matter of taste if this will be narrowed to Linux or not. In any
 case
 please try if you can just drop the existing workarounds. The best would
 probably to just replace their set() with yours and see if it works. If it
 does you can remove the if(Linux) and only match for the processor.


I didn't realize the -Wl,--unique=.text._* was trying to address the same
problem!  I'll try this as a replacement tonight and we'll see if it cleans
it up.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling

[Chuck Atkins]

Merged:

c752f8f165e9b8db7bc645cc55301277cd7773be Merge topic 'find-boost-no-reroot'


- Chuck

On Sun, Oct 26, 2014 at 12:18 AM, Chuck Atkins chuck.atk...@kitware.com
wrote:

 Guillaume,

 Nice patch!  Good detail in the commit message.  I make a few minor tweaks
 for typos and tense, but other than that, it's good.  Pushed to stage as
 'find-boost-no-reroot' and merged to next for testing.  We'll keep an eye
 on the dashboards and fix as needed but I don't anticipate any issues.

 Thanks for the patch!
 - Chuck

 On Thu, Oct 23, 2014 at 4:09 AM, Guillaume Papin 
 guillaume.pa...@parrot.com wrote:

  Please find the patch attached to this email.
 Let me know if anything is wrong.

 Best,
 Guillaume


 On 10/16/2014 05:09 PM, Chuck Atkins wrote:

  Guillaume,

  Please see CONTRIBUTING.rst in the top level of the CMake source tree.
 If you can please create and post a patch against cmake master then I'll
 work on getting it merged into cmake next.  Thanks for the bug fix!

  - Chuck

 On Thu, Oct 16, 2014 at 10:32 AM, Chuck Atkins chuck.atk...@kitware.com
 wrote:

  This looks like a reasonable way to accomplish this right now.  The
 underlying prioblem is that ther's no way to specify which path types get
 re-rooted and which don't.  Ideally you'd want to be able to specify in the
 toolchain for something like this that all paths operate in ONLY mode
 except HINTS, which you would want to place in NEVER mode.  I'm currently
 working on just such a feature but in the meantime, forcing it like this in
 the FindBoost module looks reasonable.





-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling

[Chuck Atkins]

Guillaume,

Nice patch!  Good detail in the commit message.  I make a few minor tweaks
for typos and tense, but other than that, it's good.  Pushed to stage as
'find-boost-no-reroot' and merged to next for testing.  We'll keep an eye
on the dashboards and fix as needed but I don't anticipate any issues.

Thanks for the patch!
- Chuck

On Thu, Oct 23, 2014 at 4:09 AM, Guillaume Papin guillaume.pa...@parrot.com
 wrote:

  Please find the patch attached to this email.
 Let me know if anything is wrong.

 Best,
 Guillaume


 On 10/16/2014 05:09 PM, Chuck Atkins wrote:

  Guillaume,

  Please see CONTRIBUTING.rst in the top level of the CMake source tree.
 If you can please create and post a patch against cmake master then I'll
 work on getting it merged into cmake next.  Thanks for the bug fix!

  - Chuck

 On Thu, Oct 16, 2014 at 10:32 AM, Chuck Atkins chuck.atk...@kitware.com
 wrote:

  This looks like a reasonable way to accomplish this right now.  The
 underlying prioblem is that ther's no way to specify which path types get
 re-rooted and which don't.  Ideally you'd want to be able to specify in the
 toolchain for something like this that all paths operate in ONLY mode
 except HINTS, which you would want to place in NEVER mode.  I'm currently
 working on just such a feature but in the meantime, forcing it like this in
 the FindBoost module looks reasonable.




-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling

[Chuck Atkins]

This looks like a reasonable way to accomplish this right now.  The
underlying prioblem is that ther's no way to specify which path types get
re-rooted and which don't.  Ideally you'd want to be able to specify in the
toolchain for something like this that all paths operate in ONLY mode
except HINTS, which you would want to place in NEVER mode.  I'm currently
working on just such a feature but in the meantime, forcing it like this in
the FindBoost module looks reasonable.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling

[Chuck Atkins]

Guillaume,

Please see CONTRIBUTING.rst in the top level of the CMake source tree.  If
you can please create and post a patch against cmake master then I'll work
on getting it merged into cmake next.  Thanks for the bug fix!

- Chuck

On Thu, Oct 16, 2014 at 10:32 AM, Chuck Atkins chuck.atk...@kitware.com
wrote:

 This looks like a reasonable way to accomplish this right now.  The
 underlying prioblem is that ther's no way to specify which path types get
 re-rooted and which don't.  Ideally you'd want to be able to specify in the
 toolchain for something like this that all paths operate in ONLY mode
 except HINTS, which you would want to place in NEVER mode.  I'm currently
 working on just such a feature but in the meantime, forcing it like this in
 the FindBoost module looks reasonable.


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindBoost.cmake cannot find some libraries when cross-compiling

[Chuck Atkins]

Can you post your toolchain file as well?  Does it set any of the
CMAKE_FIND_ROOT_PATHG_MODE_{INCLUDE,PROGRAM,LIBRARY,PACKAGE} variables to
anything?

- Chuck

On Wed, Oct 15, 2014 at 10:04 AM, Guillaume Papin 
guillaume.pa...@parrot.com wrote:

 Hello CMake developers,

 I have a cross-compiled version of Boost and some other libraries under
 ~/my-project/CrossThirdPartyPrefix.

 I invoke CMake with a CMAKE_TOOLCHAIN_FILE and also I sets
 CMAKE_FIND_ROOT_PATH
 to the directory where my cross-compiled Boost is installed.

 cmake
 -DCMAKE_TOOLCHAIN_FILE=$HOME/my-project/plateforms/arm-toolchain.cmake \
 -DCMAKE_FIND_ROOT_PATH=$HOME/my-project/CrossThirdPartyPrefix \
 ~/my-projects/src/

 But I have an error when using FindBoost.cmake:

 In my project's CMakeLists.txt:
 find_package(Boost 1.53.0 REQUIRED COMPONENTS atomic thread system)

 The error:
  CMake Error at .../share/cmake-3.0/Modules/FindBoost.cmake:1179
 (message):
Unable to find the requested Boost libraries.

Boost version: 1.55.0

Boost include path:
~/myproject/CrossThirdPartyPrefix/include


Could not find the following Boost libraries:

boost_thread
boost_system

Some (but not all) of the required Boost libraries were found.  You
 may
need to install these additional Boost libraries.  Alternatively,
 set
BOOST_LIBRARYDIR to the directory containing Boost libraries or
 BOOST_ROOT
to the location of Boost.


 So the first component library (atomic) is found but not the other ones.

 Looking at the code, when the first library is found, Boost_LIBRARY_DIR is
 set
 to the directory that contains the library and then change the further
 calls of
 find_library to use Boost_LIBRARY_DIR as the unique HINTS, and with the
 NO_DEFAULT_PATH options set.

 macro(_Boost_FIND_LIBRARY var)
   find_library(${var} ${ARGN})

   if(${var})
 # If this is the first library found then save Boost_LIBRARY_DIR.
 if(NOT Boost_LIBRARY_DIR)
   get_filename_component(_dir ${${var}} PATH)
   set(Boost_LIBRARY_DIR ${_dir} CACHE PATH Boost library
 directory FORCE)
 endif()
   elseif(_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT)
 # Try component-specific hints but do not save Boost_LIBRARY_DIR.
 find_library(${var} HINTS
 ${_Boost_FIND_LIBRARY_HINTS_FOR_COMPONENT} ${ARGN})
   endif()

   # If Boost_LIBRARY_DIR is known then search only there.
   if(Boost_LIBRARY_DIR)
 set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR}
 NO_DEFAULT_PATH)
   endif()
 endmacro()

 *
 https://github.com/Kitware/CMake/blob/1b3495d32e1523648da08e138482a654f8765333/Modules/FindBoost.cmake#L322-L325

 The issue is that, when using CMAKE_FIND_ROOT_PATH, the Boost_LIBRARY_DIR
 of the
 host (~/myproject/CrossThirdPartyPrefix/lib/ in my case), will be expanded
 against the root paths.

 To find my libraries I can apply the following fix but I'm not sure if
 it's the
 right solution or not.

 diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
 index 3642b3e..aad6575 100644
 --- a/Modules/FindBoost.cmake
 +++ b/Modules/FindBoost.cmake
 @@ -321,7 +321,7 @@ macro(_Boost_FIND_LIBRARY var)

# If Boost_LIBRARY_DIR is known then search only there.
if(Boost_LIBRARY_DIR)
 -set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR}
 NO_DEFAULT_PATH)
 +set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR}
 NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH)
endif()
  endmacro()

 @@ -855,7 +855,7 @@ if(_Boost_CHANGE_LIBDIR AND NOT
 _Boost_LIBRARY_DIR_CHANGED)
  endif()

  if(Boost_LIBRARY_DIR)
 -  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH)
 +  set(_boost_LIBRARY_SEARCH_DIRS ${Boost_LIBRARY_DIR} NO_DEFAULT_PATH
 NO_CMAKE_FIND_ROOT_PATH)
  else()
set(_boost_LIBRARY_SEARCH_DIRS )
if(BOOST_LIBRARYDIR)


 What I'm wondering is, whether or not Boost_LIBRARY_DIR should be a path
 on the target or on the host?

 Right now, the workaround I have that doesn't require to modify
 FindBoost.cmake
 is to set Boost_LIBRARY_DIR to /lib/, which will be expanded against the
 CMAKE_FIND_ROOT_PATH.

 By the way, I'm a happy CMake user, thanks for all the work!
 Guillaume
 --

 Powered by www.kitware.com

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

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

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

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

 Follow this link to subscribe/unsubscribe:
 

[cmake-developers] Proposed Feature: Selective search path re-rooting

[Chuck Atkins]

Following the topic branch to separately maintain each type of search path,
I'm working on adding a feature for cross-compiling to separately control
how each type of search path gets re-rooted. Currently, the options
CMAKE_FIND_ROOT_PATH_MODE_{INCLUDE_LIBRARY_PROGRAM} can be set to ONLY,
NEVER, or BOTH.  This takes effect for all search paths, both CMake
determined and user-specifies (through HINTS and PATHS options).  Before
putting the time and effort into implementing the feature this way, I
wanted to get some feedback on the design first:

My approach to control the path types independently is to allow the
variable to be specified as either a single mode, applying to all paths, or
a named list of the form PATH_TYPE1 MODE1 PATH_TYPE2_MODE2... much in the
way that properties are specified.  The following search path groups can be
specified:

   - CMAKE_PATH
   - CMAKE_ENVIRONMENT_PATH
   - USER_HINTS_PATH
   - SYSTEM_ENVIRONMENT_PATH
   - CMAKE_SYSTEM_PATH
   - USER_GUESS_PATH

In addition to each search path type, there will also be defined path
groups:

   - ALL - All search paths
   - DEFAULT
  - CMAKE_PATH
  - CMAKE_ENVIRONMENT_PATH
  - SYSTEM_ENVIRONMENT_PATH
  - CMAKE_SYSTEM_PATH
   - USER - User hints and user guess paths

If one had:

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ALL ONLY HINTS NEVER)

Then the following modes would be set:

   - find_program: All search paths set to never
   - find_library: user hints would never be re-rooted and all others would
   operate in ONLY mode.
   - find_file: All search paths set to BOTH mode since that's the default
   behavior.


- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Preparing for CMake 3.1.0-rc1

[Chuck Atkins]

Are we still on a stage freeze until the release, or is it just a hold on
stage/next?

I ask because I've got a non-trivial branch to push to the stage for review
that re-factors how search paths are constructed for find* commands.

- Chuck

On Tue, Oct 7, 2014 at 10:43 AM, Brad King brad.k...@kitware.com wrote:

 On 10/03/2014 08:27 AM, Brad King wrote:
  In preparation for the first 3.1 release candidate I will feature-
  freeze master as of 2014-10-09.  As of now there are several open
  topics in 'next' that we should try to land in master by then, but
  please refrain from adding non-trivial changes in the meantime.

 In order to get the dashboard cleaned up for final merges to
 'master' before the release, please refrain from merging any
 changes other than dashboard fixes and documentation updates
 to 'next'.

 Thanks,
 -Brad

 --

 Powered by www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Preparing for CMake 3.1.0-rc1

[Chuck Atkins]

Great, thanks!

- Chuck

On Thu, Oct 9, 2014 at 2:32 PM, Brad King brad.k...@kitware.com wrote:

 On 10/09/2014 02:27 PM, Chuck Atkins wrote:
  I've got a non-trivial branch to push to the stage for review

 You can push it for review but please do not merge to 'next' yet.

 Thanks,
 -Brad


-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Refactoring search path construction

[Chuck Atkins]

I've just pushed a branch to the stage for review:
refactor-search-path-construction , not merged to next due to the current
release hold.

Just a head's up, it's rather invasive.  It's a re-factoring of how search
paths get constructed for find* commands.  Up until now, search paths have
been incrementally constructed with the composite search path being the
only result.  This separates and constructs each class of search path
separately and combines them together afterwards.

This branch is a pre-cursor for new features that can manipulate groups of
search paths with leaving others untouched.

- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Refactoring search path construction

[Chuck Atkins]

Just to clarify, this does *NOT* change the search order.

- Chuck

On Thu, Oct 9, 2014 at 2:45 PM, Chuck Atkins chuck.atk...@kitware.com
wrote:

 I've just pushed a branch to the stage for review:
 refactor-search-path-construction , not merged to next due to the current
 release hold.

 Just a head's up, it's rather invasive.  It's a re-factoring of how search
 paths get constructed for find* commands.  Up until now, search paths have
 been incrementally constructed with the composite search path being the
 only result.  This separates and constructs each class of search path
 separately and combines them together afterwards.

 This branch is a pre-cursor for new features that can manipulate groups of
 search paths with leaving others untouched.

 - Chuck

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Support of codesign

[Chuck Atkins]

 Maybe it shouldn't even be a CPack thing. Maybe it should be an
 install time step so that all CPack generators will contains signed
 binaries if codesign is used...


I know this is a bit after the fact and I'm jumping in here pretty late,
but...

It would be nice to have package signing as a general top level CPack
feature.  Most supported package formats support some form of signing, rpm
and deb with gpg keys, apple bundles, dmgs, nsis installers, etc.  Could
this be done as a generic CPack variable, CPACK_PACKAGE_SIGNING_KEY, for
example, and then if set, then each CPack generator would use it
accordingly?

Just a thought, not to derail this current patch though.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] stage/compact-status-log

[Chuck Atkins]

I like the idea of reducing the extra-verbose output, and maybe I'm missing
something here but could this possibly be done with a much simpler
approach?  It seems the way these double messages happen is with the
following CMake code:

message(STATUS Doing something)
# Do some stuff
message(STATUS Doing something - Result)

Couldn't the same thing be achieved in a platform agnostic way by adding a
NOENDL option (or something similar) to the message command?  Then you
could achieve the same result with:

message(STATUS Doing something NOENDL)
# Do some stuff
message(STATUS  - Result)

Just a bit of logic to add the NOENDL option and then another to omit the
message prefix if the previous call used NOENDL.  It seems this could
achieve the compact log result, do it in a platform agnostic way, and also
provide the useful feature to the message command for users.  It would be a
two-step process: first, enhance the message command, second, update the
various .cmake files in Sources/Modules to leverage the new syntax.

Just my 2 cents.

- Chuck

On Wed, Sep 24, 2014 at 8:36 AM, Brad King brad.k...@kitware.com wrote:

 On 09/24/2014 08:02 AM, Adam Strzelecki wrote:
  cmThread utility class

 Introducing threads is exactly the too much infrastructure
 to which I was referring in my previous response.  I'm sorry
 to reject all the effort you put into the threads approach so
 far, but I did say this earlier.

  cmake emits simply too much (redundant) information.

 IIRC the original reason for having separate

-- Looking for iconv.h
-- Looking for iconv.h - Found

 lines is that the first one prints what is about to be
 done in case something happens (e.g. crash) that prevents
 the second output from ever showing up.  That helps a lot
 in tracking down the problem.  If another thread buffers
 the first message then it might not show up at all.  The
 terminal escape codes approach does not have that problem.

 The same de-dup you do in the threaded filter could be done
 with a shell alias that pipes 'cmake' output through a sed
 script or something to de-dup it.  That would handle local
 interactive terminal use of cmake without any upstream
 changes.

 -Brad

 --

 Powered by www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] stage/compact-status-log

[Chuck Atkins]

 What happens if something else occurs in between that prints
 a message?  Do we tolerate

  -- Doing something-- Unrelated Message
  - Result

 instead of

  -- Doing something
  -- Unrelated Message
  -- Doing something - Result


Sure, why not?  There's no requirement to use the NOENDL, it would just be
an additional option.   The places where this happens is most in the
Modules/* code for system introspection.  If the code path allows for
extensive messaging in between status messages, then just don't use the
NOENDL option.  It would be entirely optional and up to whomever is writing
the CMake code whether or not to use it.  We could easily use it in most of
the system introspection modules without worry though.



 Also the approach needs to work in ccmake where only one
 status line is shown at a time.


Sure it would.  Nothing monumental would need to change though.  It
currently output's every message separately, but it could just output the
current message append to the previous message and then when an endline is
found then clear the append message buffer.

I'm not saying it should be done this way, just offering an alternate
approach that might be more flexible.  The details and tests would still
need to be worked out.
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Changing the regex used for INFO strings

[Chuck Atkins]

stage/use-consistent-regex-for-info-strings

The change seems minor enough but the impact if it breaks something is
substantial so I wanted to get a second set of eyes on this.  I set out to
fix the non-working ABI detection for craycc and crayCC, which turned out
was because the cray compiler will often generate *lots* of INFO: strings
itself, which were getting through the strings regex.  Since all binary
info strings that CMake extracts for system and compiler info should have
the same format, it seemed appropriate to have a consistent regex used in
all the various places that INFO: strings are extracted from compiled
binaries.

- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] How to get a nightly build process going.

[Chuck Atkins]

It seems so.  I was thrown off by the multiple levels of indirection
happening since the actual values in the OPTIONAL_INCLUDES end up as
foo1;foo2-NOTFOUND;bar.  I was thinking that if(VARNAME) would only work
if the value of VARNAME was actually VARNAME-NOTFOUND but that's not the
case, it works so long as -NOTFOUND is a suffix.

- Chuck


On Tue, Sep 2, 2014 at 1:37 AM, Rolf Eike Beer e...@sf-mail.de wrote:

 Am Montag, 1. September 2014, 14:35:41 schrieb Chuck Atkins:
  Back on topic...
 
   Solaris 10 + SolarisStudio
   http://open.cdash.org/buildSummary.php?buildid=3470493
   No build failures, 4 test failures
  
   Solaris 10 + GCC (from OpenCSW)
   http://open.cdash.org/buildSummary.php?buildid=3470687
   No build failures, 5 test failures
 
  I dug more into the test failures.  3 of the failures were due to a
 borked
  mercurial install on the machine, i.e. not a cmake problem but a system
  problem, which has since been fixed.  Another was a FindGTK2 bug, which I
  just pushed a fix to next for.

 Isn't if (D) enough there instead of the MATCHES?

 Eike
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] How to get a nightly build process going.

[Chuck Atkins]

Back on topic...


 Solaris 10 + SolarisStudio
 http://open.cdash.org/buildSummary.php?buildid=3470493
 No build failures, 4 test failures

 Solaris 10 + GCC (from OpenCSW)
 http://open.cdash.org/buildSummary.php?buildid=3470687
 No build failures, 5 test failures


I dug more into the test failures.  3 of the failures were due to a borked
mercurial install on the machine, i.e. not a cmake problem but a system
problem, which has since been fixed.  Another was a FindGTK2 bug, which I
just pushed a fix to next for.  Given the _Bool fix and GTK2 fix, all tests
should pass for nightly next on Solaris + suncc, and 1 failure for Solaris
+ GCC.

So once you get your nightly submissions set up, I would expect a clean
Solaris Studio build and test and a clean GCC build with 1 test failure.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] How to get a nightly build process going.

[Chuck Atkins]

   I've got a UltraSPARC III machine with Solaris 10 that I just checked.

 Still chugging along I bet.


Some days yes, some days no.  The PSU shorted out and filled the server
room w/ smoke a few years ago.  It was slated for the trash but it seemed
like a shame to toss a neat old RISC box so I re-wired a scrap Dell PSU
onto the connector of the fried Sun PSU and that's kept it going for the
past 2 years.  Far from reliable though.



  Try applying the attached patch if you're using SolarisStudio to fix the
 build problem.

 Ah yes .. that chestnut.  I have seen this in gettext also


It was a leftover from the cmakeify of liblzma.  It's actually not a
GCC-ism but a badly behaved suncc.  It seems that suncc on Solaris
intrinsically defines the type _Bool versus requiring stdbool.h.
Interestingly, suncc on Linux x64 doesn't.  The patch checks to see if it's
intrinsically defined to prevent redefinition.


I have tons, literally, of weird hardware around me. Including a few
 from the late 90's that are still running and that includes a DEC
 AlphaServer
 4100 series. Not sure what to do with that.


A shame.  Alpha and PA-RISC have gone the way of the DoDo bird, i.e. long
since EOL'd architectures. It's tough to justify even the power cost of
keeping those running these days.


  However Sparc servers both old and new I have. Well, newish anyways.


Solaris 10 and 11 would be ideal, but whatever platform you can contribute
would be great!



 A big fat binary over 146MB in size. Staggering.


The re-distributable binaries are so huge because of static linking of
dependencies and included debug information. Dynamic linking and aggressive
LTO with dead code elimination would shrink the size *considerably* but
result in far less portable binaries, so not so suitable for redistribution.



 I will say that I do have a cmake binary however its test results are
 not pretty:


cmake --version will tell you what version you have.  2.8.4 or greater
should work for the dashboard builds.  If you use OpenCSW for 3rd party
packages then you can install the CSWcmake package to get 2.8.12, easily
new enough to drive the dashboard.  If you want to build from source
instead though, then you can see from last night's nightly dashboard:

Solaris 10 + SolarisStudio
http://open.cdash.org/buildSummary.php?buildid=3470493
No build failures, 4 test failures

Solaris 10 + GCC (from OpenCSW)
http://open.cdash.org/buildSummary.php?buildid=3470687
No build failures, 5 test failures

This is for the staging/next branch, which meant it should be in master
soon.

As for setting up the nightly build, you should be able to bootstrap and
build the current master with gcc.  Even if there's still some test
failures, you can use that cmake to drive the nightly build.

- Chuck
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] How to get a nightly build process going.

[Chuck Atkins]

Hi dev,

I've got a UltraSPARC III machine with Solaris 10 that I just checked.
From what I can tell, gcc has no build errors and currently the only
Solaris Studio build error is in liblzma.  Try applying the attached patch
if you're using SolarisStudio to fix the build problem.  In the mean time
I'll get it merged in and take a look at the tests.

Unfortunately my Solaris system is very old and flaky and is known to have
hardware die on a regular basis so we can't rely on it for a nightly
build.  If you can get a nightly dashboard set up it would be very helpful
so we can know right away when issues come up.


- Chuck
From 2b04ad61c583652c8755edeb3d7eb82c6b8f7bf7 Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Sat, 30 Aug 2014 16:51:28 -0400
Subject: [PATCH] Added a missing config check for _Bool in liblzma

---
 Utilities/cmliblzma/CMakeLists.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Utilities/cmliblzma/CMakeLists.txt b/Utilities/cmliblzma/CMakeLists.txt
index 856e41e..23549c5 100644
--- a/Utilities/cmliblzma/CMakeLists.txt
+++ b/Utilities/cmliblzma/CMakeLists.txt
@@ -26,11 +26,15 @@ CHECK_INCLUDE_FILE(byteswap.h HAVE_BYTESWAP_H)
 CHECK_INCLUDE_FILE(inttypes.h HAVE_INTTYPES_H)
 CHECK_INCLUDE_FILE(limits.h HAVE_LIMITS_H)
 CHECK_INCLUDE_FILE(memory.h HAVE_MEMORY_H)
-CHECK_INCLUDE_FILE(stdbool.h HAVE_STDBOOL_H)
 CHECK_INCLUDE_FILE(strings.h HAVE_STRINGS_H)
 CHECK_INCLUDE_FILE(string.h HAVE_STRING_H)
 CHECK_INCLUDE_FILE(sys/sysctl.h HAVE_SYS_SYSCTL_H)
 
+CHECK_INCLUDE_FILE(stdbool.h HAVE_STDBOOL_H)
+if(NOT HAVE_STDBOOL_H)
+  CHECK_TYPE_SIZE(_Bool _BOOL)
+endif()
+
 CHECK_C_SOURCE_COMPILES (
   #includebyteswap.h\nint main(void){bswap_16(0);return 0;}
   HAVE_BSWAP_16)
-- 
1.9.3

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Add a new SYSTEM_ONLY mode for CMAKE_FIND_ROOT_PATH

[Chuck Atkins]

I was trying to avoid the code duplication but I definitely see your
point.  I'll refactor.

- Chuck


On Wed, Aug 20, 2014 at 8:55 AM, Brad King brad.k...@kitware.com wrote:

 On 08/19/2014 05:43 PM, Chuck Atkins wrote:
  The new hybrid mode allows the default search location to be
  re-rooted and any user specified paths to be untouched.

 This looks useful.  However, the current implementation appears
 to change the order in which each kind of path is generated.
 The order is very important and cannot be changed.

 Instead you'll have to refactor the path generation to store
 a boolean with each value that indicates whether it is to be
 re-rooted or not.  Or, re-arrange the generation to construct
 separate lists of paths from each source first, and then
 combine them while re-rooting some.

 Thanks,
 -Brad

 --

 Powered by www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Add a new SYSTEM_ONLY mode for CMAKE_FIND_ROOT_PATH

[Chuck Atkins]

The branch has been updated on the stage to retain search path order.

- Chuck


On Wed, Aug 20, 2014 at 9:10 AM, Chuck Atkins chuck.atk...@kitware.com
wrote:

 I was trying to avoid the code duplication but I definitely see your
 point.  I'll refactor.

 - Chuck


 On Wed, Aug 20, 2014 at 8:55 AM, Brad King brad.k...@kitware.com wrote:

 On 08/19/2014 05:43 PM, Chuck Atkins wrote:
  The new hybrid mode allows the default search location to be
  re-rooted and any user specified paths to be untouched.

 This looks useful.  However, the current implementation appears
 to change the order in which each kind of path is generated.
 The order is very important and cannot be changed.

 Instead you'll have to refactor the path generation to store
 a boolean with each value that indicates whether it is to be
 re-rooted or not.  Or, re-arrange the generation to construct
 separate lists of paths from each source first, and then
 combine them while re-rooting some.

 Thanks,
 -Brad

 --

 Powered by www.kitware.com

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

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

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

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

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



-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] New platform file for Cray Compute Node Linux

[Chuck Atkins]

Yep, I had a few other tweaks as well but I didn't want to bombard the list
with a series of tweaks.  I just got access to a newer XC30 and things
start to break on there since the new environment modules use different
variable names, things like that.  It needs a little more before it will
work universally on a generic Cray but I think it's close.  I'll wait until
I get it working on the XC30 as well before I push it.

- Chuck


On Sun, Aug 17, 2014 at 4:57 AM, Rolf Eike Beer e...@sf-mail.de wrote:

 Chuck Atkins wrote:
  Updated to allow for static and shared libs (yes, you can use shared libs
  on a cray).  The expectation is that your toolchain file will have the
  appropriate logic to deal with this.  Something like:
 
  set(CMAKE_SYSTEM_NAME ComputeNodeLinux)
  ...
  if(DEFINED ENV{CRAYPE_LINK_TYPE} AND
 $ENV{CRAYPE_LINK_TYPE} EQUALS dynamic)
set(_CRAY_LINK_OPTS -dynamic)

 This looks wrong. There is no EQUALS operator in if, and EQUAL is for
 comparing numbers. You probably just meant something like

 if(ENV{CRAYPE_LINK_TYPE} STREQUAL dynamic)

 Eike
 --
 --

 Powered by www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] New module FindXerces

[Chuck Atkins]

Hey Roger, thanks for the contribution!  A couple of points on find_module
convention, most of which you can find in
http://cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#modules.
Not all find modules currently shipped have been updated for these best
practices but new modules should try to stick to them.

   - Xerces_INCLUDE_DIR should be used to control the cache search but not
   as a final output variable.  Use Xerces_INCLUDE_DIRS.  This helps with some
   consistency since some libs may have only 1 include directory and others
   have several.  This way all find modules produce a Foo_INCLUDE_DIRS
   variable instead of some producing _DIR and others producing _DIRS
   - Xerces_LIBRARY_DIR is not actually used and should be removed from
   documentation.
   - Use Xerces_INCLUDE_DIR and Xerces_LIBRARY as the find_path and
   find_library variables.  After successfully passing the
   FIND_PACKAGE_HANDLE_STANDARD_ARGS, then set the _INCLUDE_DIRS and
   _LIBRARIES variables accordingly.
   - Try to stick with either all mixed-case or all uppercase variable
   names.  No need to mix Xerces_FOO with XERCES_FOO.  In this case, keeping
   with all mixed case would be appropriate.
   - Don't delete the version variable afterwards, it's good have set by
   the find module as an output variable Xerces_VERSION.


- Chuck


On Sat, Aug 16, 2014 at 6:48 AM, Roger Leigh rle...@codelibre.net wrote:

 Hi,

 Attached is a patch to add support for Apache Xerces-C++.
 This project is quite an old one, and doesn't have any
 support for cmake at present.  This will allow cmake
 projects to use current and older Xerces releases.


 Regards,
 Roger

 --
   .''`.  Roger Leigh
  : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
  `. `'   schroot and sbuild
 http://alioth.debian.org/projects/buildd-tools
`-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083
 E800

 --

 Powered by www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] New platform file for Cray Compute Node Linux

[Chuck Atkins]

I realized the toolchain stuff won't work because the platform file will
override it.  Here's v3 of the patch with *fixed* shared/static lib
searching.  I'll leave it be for now in regards to further updates to the
patch pending further feedback.

- Chuck


On Thu, Aug 14, 2014 at 7:41 PM, Chuck Atkins chuck.atk...@kitware.com
wrote:

 Updated to allow for static and shared libs (yes, you can use shared libs
 on a cray).  The expectation is that your toolchain file will have the
 appropriate logic to deal with this.  Something like:

 set(CMAKE_SYSTEM_NAME ComputeNodeLinux)
 ...
 if(DEFINED ENV{CRAYPE_LINK_TYPE} AND
$ENV{CRAYPE_LINK_TYPE} EQUALS dynamic)
   set(_CRAY_LINK_OPTS -dynamic)
 else()
   # The default behavior if not specified is explicit static-only linkage
   set(_CRAY_LINK_OPTS -static)

   # If we're using static linking then make sure that CMake explicitly
   # only looks for static libraries
   set(CMAKE_FIND_LIBRARY_SUFFIXES .a)
 endif()
 ...
 set(CMAKE_C_FLAGS   ... ${_CRAY_LINK} CACHE STRING  FORCE)
 set(CMAKE_CXX_FLAGS ... ${_CRAY_LINK} CACHE STRING  FORCE)
 set(CMAKE_Fortran_FLAGS ... ${_CRAY_LINK} CACHE STRING  FORCE)




 - Chuck


 On Thu, Aug 14, 2014 at 6:46 PM, Chuck Atkins chuck.atk...@kitware.com
 wrote:

 I've been using CMake on Cray's quite a bit lately and some of the cross
 compilation leaves a bit to be desired.  No particular capability is really
 missing but the foo of getting things to build and work seems to be
 rather dispersed across various individuals and corners of the internet.
 I'd like to start pooling some of this together to be shipped with CMake.

 For starters, I'd like to add a Platform file for the cross compilation
 target of ComputeNodeLinux.  While it's not entirely different from running
 Linux natively, some assumptions from native host Linux build environments
 aren't valid and building for it explicitly needs search paths defined by
 the Cray environment modules.  It's also distinctly different from the
 commonly used Catamount (which is very far removed from the currently used
 OS). Attached is a patch for a new Platform file that uses information from
 the loaded environment modules on the login nodes to define it's
 appropriate path and version info.  I've been using this successfully on
 Garnet (an XE6) and Titan (an XK7).

 - Chuck



From dfc0493671d4df34f22e380af4642fe5ad4c6596 Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Thu, 14 Aug 2014 18:30:01 -0400
Subject: [PATCH] Add a platform file for cross-compiling to Cray Compute Node
 Linux

This platform module is designed t be used with the Cray Programming
Environment.  Esentially this means that it will get it's various
options and settings through variables loaded in environment modules
used on modern Crays.
---
 Modules/Platform/ComputeNodeLinux.cmake | 45 +
 1 file changed, 45 insertions(+)
 create mode 100644 Modules/Platform/ComputeNodeLinux.cmake

diff --git a/Modules/Platform/ComputeNodeLinux.cmake b/Modules/Platform/ComputeNodeLinux.cmake
new file mode 100644
index 000..a7f5a3b
--- /dev/null
+++ b/Modules/Platform/ComputeNodeLinux.cmake
@@ -0,0 +1,45 @@
+# Compute Node Linux doesn't quite work the same as native Linux so all of this
+# needs to be custom.  We use the variables defined through Cray's environment
+# modules to set up the right paths for things.
+
+if(NOT CMAKE_SYSTEM_VERSION)
+  if(NOT DEFINED ENV{XTOS_VERSION})
+message(FATAL_ERROR The CMAKE_SYSTEM_VERSION variable is not set and the XTOS_VERSION environment variable is not defined.  The ComputeNodeLinux CMake platform module either requires it to be manually set or the XTOS_VERSION environment variable to be available. This usually means that the necessary PrgEnv-* module is not loaded)
+  else()
+set(CMAKE_SYSTEM_VERSION $ENV{XTOS_VERSION})
+  endif()
+endif()
+
+set(CMAKE_SHARED_LIBRARY_PREFIX lib)
+set(CMAKE_SHARED_LIBRARY_SUFFIX .so)
+set(CMAKE_STATIC_LIBRARY_PREFIX lib)
+set(CMAKE_STATIC_LIBRARY_SUFFIX .a)
+
+set(CMAKE_FIND_LIBRARY_PREFIXES lib)
+
+# Normally this sort of logic would belong in the toolchain file but the
+# order things get loaded in cause anything set here to override the toolchain
+# so we'll explicitly check for static compiler options in order to specify
+# whether or not the platform will support it
+if($ENV{CRAYPE_LINK_TYPE} STREQUAL dynamic)
+  set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS TRUE)
+  set(CMAKE_FIND_LIBRARY_SUFFIXES .so .a)
+else()
+  set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE)
+  set(CMAKE_FIND_LIBRARY_SUFFIXES .a)
+endif()
+
+# Make sure we have the appropriate environment loaded
+if(NOT DEFINED ENV{SYSROOT_DIR})
+  message(FATAL_ERROR The SYSROOT_DIR environment variable is not defined but the ComputeNodeLinux CMake platform module requires it. This usually means that the necessary PrgEnv-* module is not loaded)
+endif()
+
+# Set up system search paths

[cmake-developers] New platform file for Cray Compute Node Linux

[Chuck Atkins]

I've been using CMake on Cray's quite a bit lately and some of the cross
compilation leaves a bit to be desired.  No particular capability is really
missing but the foo of getting things to build and work seems to be
rather dispersed across various individuals and corners of the internet.
I'd like to start pooling some of this together to be shipped with CMake.

For starters, I'd like to add a Platform file for the cross compilation
target of ComputeNodeLinux.  While it's not entirely different from running
Linux natively, some assumptions from native host Linux build environments
aren't valid and building for it explicitly needs search paths defined by
the Cray environment modules.  It's also distinctly different from the
commonly used Catamount (which is very far removed from the currently used
OS). Attached is a patch for a new Platform file that uses information from
the loaded environment modules on the login nodes to define it's
appropriate path and version info.  I've been using this successfully on
Garnet (an XE6) and Titan (an XK7).

- Chuck
From 980483bbc2e0040273f9c7fa8df3c6bf61bba311 Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Thu, 14 Aug 2014 18:30:01 -0400
Subject: [PATCH] Add a platform file for cross-compiling to Cray Compute Node
 Linux

This platform module is designed t be used with the Cray Programming
Environment.  Esentially this means that it will get it's various
options and settings through variables loaded in environment modules
used on modern Crays.
---
 Modules/Platform/ComputeNodeLinux.cmake | 33 +
 1 file changed, 33 insertions(+)
 create mode 100644 Modules/Platform/ComputeNodeLinux.cmake

diff --git a/Modules/Platform/ComputeNodeLinux.cmake b/Modules/Platform/ComputeNodeLinux.cmake
new file mode 100644
index 000..58fbcd5
--- /dev/null
+++ b/Modules/Platform/ComputeNodeLinux.cmake
@@ -0,0 +1,33 @@
+# Compute Node Linux doesn't quite work the same as native Linux so all of this
+# needs to be custom.  We use the variables defined through Cray's environment
+# modules to set up the right paths for things.
+
+if(NOT CMAKE_SYSTEM_VERSION)
+  if(NOT DEFINED ENV{XTOS_VERSION})
+message(FATAL_ERROR The CMAKE_SYSTEM_VERSION variable is not set and the XTOS_VERSION environment variable is not defined.  The ComputeNodeLinux CMake platform module either requires it to be manually set or the XTOS_VERSION environment variable to be available. This usually means that the necessary PrgEnv-* module is not loaded)
+  else()
+set(CMAKE_SYSTEM_VERSION $ENV{XTOS_VERSION})
+  endif()
+endif()
+
+# Compute Node Linux does support shared libraries, it's just seldom used
+set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS TRUE)
+set(CMAKE_SHARED_LIBRARY_PREFIX lib)
+set(CMAKE_SHARED_LIBRARY_SUFFIX .so)
+set(CMAKE_STATIC_LIBRARY_PREFIX lib)
+set(CMAKE_STATIC_LIBRARY_SUFFIX .a)
+
+# Make sure we have the appropriate environment loaded
+if(NOT DEFINED ENV{SYSROOT_DIR})
+  message(FATAL_ERROR The SYSROOT_DIR environment variable is not defined but the ComputeNodeLinux CMake platform module requires it. This usually means that the necessary PrgEnv-* module is not loaded)
+endif()
+
+# Set up system search paths that CMake will use to look for libraries and
+# include files.  These will be the standard UNIX search paths but rooted
+# in the SYSROOT of the computes nodes.
+include(Platform/UnixPaths)
+set(CMAKE_FIND_ROOT_PATH $ENV{SYSROOT_DIR})
+set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
+set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
+set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
+set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
-- 
1.9.3

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] New platform file for Cray Compute Node Linux

[Chuck Atkins]

Updated to allow for static and shared libs (yes, you can use shared libs
on a cray).  The expectation is that your toolchain file will have the
appropriate logic to deal with this.  Something like:

set(CMAKE_SYSTEM_NAME ComputeNodeLinux)
...
if(DEFINED ENV{CRAYPE_LINK_TYPE} AND
   $ENV{CRAYPE_LINK_TYPE} EQUALS dynamic)
  set(_CRAY_LINK_OPTS -dynamic)
else()
  # The default behavior if not specified is explicit static-only linkage
  set(_CRAY_LINK_OPTS -static)

  # If we're using static linking then make sure that CMake explicitly
  # only looks for static libraries
  set(CMAKE_FIND_LIBRARY_SUFFIXES .a)
endif()
...
set(CMAKE_C_FLAGS   ... ${_CRAY_LINK} CACHE STRING  FORCE)
set(CMAKE_CXX_FLAGS ... ${_CRAY_LINK} CACHE STRING  FORCE)
set(CMAKE_Fortran_FLAGS ... ${_CRAY_LINK} CACHE STRING  FORCE)




- Chuck


On Thu, Aug 14, 2014 at 6:46 PM, Chuck Atkins chuck.atk...@kitware.com
wrote:

 I've been using CMake on Cray's quite a bit lately and some of the cross
 compilation leaves a bit to be desired.  No particular capability is really
 missing but the foo of getting things to build and work seems to be
 rather dispersed across various individuals and corners of the internet.
 I'd like to start pooling some of this together to be shipped with CMake.

 For starters, I'd like to add a Platform file for the cross compilation
 target of ComputeNodeLinux.  While it's not entirely different from running
 Linux natively, some assumptions from native host Linux build environments
 aren't valid and building for it explicitly needs search paths defined by
 the Cray environment modules.  It's also distinctly different from the
 commonly used Catamount (which is very far removed from the currently used
 OS). Attached is a patch for a new Platform file that uses information from
 the loaded environment modules on the login nodes to define it's
 appropriate path and version info.  I've been using this successfully on
 Garnet (an XE6) and Titan (an XK7).

 - Chuck

From f386ceb9f1f35c873ce34420bc5d143868c6e8d6 Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Thu, 14 Aug 2014 18:30:01 -0400
Subject: [PATCH] Add a platform file for cross-compiling to Cray Compute Node
 Linux

This platform module is designed t be used with the Cray Programming
Environment.  Esentially this means that it will get it's various
options and settings through variables loaded in environment modules
used on modern Crays.
---
 Modules/Platform/ComputeNodeLinux.cmake | 36 +
 1 file changed, 36 insertions(+)
 create mode 100644 Modules/Platform/ComputeNodeLinux.cmake

diff --git a/Modules/Platform/ComputeNodeLinux.cmake b/Modules/Platform/ComputeNodeLinux.cmake
new file mode 100644
index 000..ae6aa94
--- /dev/null
+++ b/Modules/Platform/ComputeNodeLinux.cmake
@@ -0,0 +1,36 @@
+# Compute Node Linux doesn't quite work the same as native Linux so all of this
+# needs to be custom.  We use the variables defined through Cray's environment
+# modules to set up the right paths for things.
+
+if(NOT CMAKE_SYSTEM_VERSION)
+  if(NOT DEFINED ENV{XTOS_VERSION})
+message(FATAL_ERROR The CMAKE_SYSTEM_VERSION variable is not set and the XTOS_VERSION environment variable is not defined.  The ComputeNodeLinux CMake platform module either requires it to be manually set or the XTOS_VERSION environment variable to be available. This usually means that the necessary PrgEnv-* module is not loaded)
+  else()
+set(CMAKE_SYSTEM_VERSION $ENV{XTOS_VERSION})
+  endif()
+endif()
+
+# Contrary to popular belief, you can use shared libraries on a Cray
+set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS TRUE)
+set(CMAKE_SHARED_LIBRARY_PREFIX lib)
+set(CMAKE_SHARED_LIBRARY_SUFFIX .so)
+set(CMAKE_STATIC_LIBRARY_PREFIX lib)
+set(CMAKE_STATIC_LIBRARY_SUFFIX .a)
+
+set(CMAKE_FIND_LIBRARY_PREFIXES lib)
+set(CMAKE_FIND_LIBRARY_SUFFIXES .so .a)
+
+# Make sure we have the appropriate environment loaded
+if(NOT DEFINED ENV{SYSROOT_DIR})
+  message(FATAL_ERROR The SYSROOT_DIR environment variable is not defined but the ComputeNodeLinux CMake platform module requires it. This usually means that the necessary PrgEnv-* module is not loaded)
+endif()
+
+# Set up system search paths that CMake will use to look for libraries and
+# include files.  These will be the standard UNIX search paths but rooted
+# in the SYSROOT of the computes nodes.
+include(Platform/UnixPaths)
+set(CMAKE_FIND_ROOT_PATH $ENV{SYSROOT_DIR})
+set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
+set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
+set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
+set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
-- 
1.9.3

-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] [PATCH] Fix broken PGI builds for liblzma.

[Chuck Atkins]

  +#if defined(__STDC_VERSION__)  (__STDC_VERSION__  199901L)  \

 Did you mean = 199901L here rather than ?


I did, that was a typo.


On 08/01/2014 02:22 PM, Chuck Atkins wrote:
  I noticed the recent merge of liblzma broke the PGI compiler.

 It is not surprising that there is lingering C99 code because
 the library implementation was ported from C99 to C89/90 for
 inclusion in CMake.


Not only that but the line in question was being protected from MSVC, not
C99.  Given that it was ported though, I'd say the better fix would be to
remove the C99 version entirely and always use the C89 version without the
static array dimensions.  See updated patch.
From 4c33d91f999b9030b4666be2f94d7a86c8da8527 Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Fri, 1 Aug 2014 13:56:41 -0400
Subject: [PATCH] Fix broken PGI builds for liblzma.

- sha265.c is using some C99 specific features, in particular static
array dimensions in a function parameter array (see section 6.7.5-7
of the C99 spec).  A #ifndef check was in place to prevent compilation
under MSVC but it actually needs to check for C99 compliance instead.
Also, even though the PGI C compiler reports to be fully C99 compliant,
it still fails.

- CHECK_SYMBOL_EXISTS is used to determine the presense of bswap
functions from byteswap.h.  Most compilers re-dedefine the bswap_N
functions as a __bswap_N function implemented by the compiler.  Since
bswap_N is usually defined as a macro then it's mere presence passes
the check.  Some versions of the PGI compiler though have shipped
broken headers for byteswap.h, in particular 11.3 for x64 linux
provides byteswap.h but is missing an associated bits/byteswap.h which
causes some of the bswap_N macros to be defined but broken and unusable.
The bswap_N checks have been converted to CHECK_SOURCE_COMPILES to
ensure that the bswap_N calls are actually usable and not just merely
defined.
---
 Utilities/cmliblzma/CMakeLists.txt |   12 +---
 Utilities/cmliblzma/liblzma/check/sha256.c |4 +++-
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/Utilities/cmliblzma/CMakeLists.txt b/Utilities/cmliblzma/CMakeLists.txt
index fc50dbe..856e41e 100644
--- a/Utilities/cmliblzma/CMakeLists.txt
+++ b/Utilities/cmliblzma/CMakeLists.txt
@@ -31,9 +31,15 @@ CHECK_INCLUDE_FILE(strings.h HAVE_STRINGS_H)
 CHECK_INCLUDE_FILE(string.h HAVE_STRING_H)
 CHECK_INCLUDE_FILE(sys/sysctl.h HAVE_SYS_SYSCTL_H)
 
-CHECK_SYMBOL_EXISTS(bswap_16 byteswap.h HAVE_BSWAP_16)
-CHECK_SYMBOL_EXISTS(bswap_32 byteswap.h HAVE_BSWAP_32)
-CHECK_SYMBOL_EXISTS(bswap_64 byteswap.h HAVE_BSWAP_64)
+CHECK_C_SOURCE_COMPILES (
+  #includebyteswap.h\nint main(void){bswap_16(0);return 0;}
+  HAVE_BSWAP_16)
+CHECK_C_SOURCE_COMPILES (
+  #includebyteswap.h\nint main(void){bswap_32(0);return 0;}
+  HAVE_BSWAP_32)
+CHECK_C_SOURCE_COMPILES (
+  #includebyteswap.h\nint main(void){bswap_64(0);return 0;}
+  HAVE_BSWAP_64)
 
 TEST_BIG_ENDIAN(WORDS_BIGENDIAN)
 
diff --git a/Utilities/cmliblzma/liblzma/check/sha256.c b/Utilities/cmliblzma/liblzma/check/sha256.c
index b09ccbf..f1d3337 100644
--- a/Utilities/cmliblzma/liblzma/check/sha256.c
+++ b/Utilities/cmliblzma/liblzma/check/sha256.c
@@ -80,7 +80,9 @@ static const uint32_t SHA256_K[64] = {
 
 
 static void
-#ifndef _MSC_VER
+#if defined(__STDC_VERSION__)  (__STDC_VERSION__  199901L)  \
+   !defined(__PGIC__)
+/* Even though int foo[static 3] is valid C99, the PGI compiler still breaks */
 transform(uint32_t state[static 8], const uint32_t data[static 16])
 #else
 transform(uint32_t state[], const uint32_t data[])
-- 
1.7.4.1

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [PATCH] Fix broken PGI builds for liblzma.

[Chuck Atkins]

I noticed the recent merge of liblzma broke the PGI compiler.  The attached
patch should address the issues:

PGC-S-0037-Syntax error: Recovery attempted by deleting keyword static
(/home/chuck/Code/cmake/source/Utilities/cmliblzma/liblzma/check/sha256.c:
84)

Once that's fixed, then the 32-bit build works but the 64-bit build is
still broken with:

../Utilities/cmliblzma/libcmliblzma.a(sha256.c.o): In function
`lzma_sha256_finish':
/home/chuck/Code/cmake/source/Utilities/cmliblzma/liblzma/check/sha256.c:196:
undefined reference to `__bswap_64'

The patch should address both issues with explanations as to why.


- Chuck
From 4c33d91f999b9030b4666be2f94d7a86c8da8527 Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Fri, 1 Aug 2014 13:56:41 -0400
Subject: [PATCH] Fix broken PGI builds for liblzma.

- sha265.c is using some C99 specific features, in particular static
array dimensions in a function parameter array (see section 6.7.5-7
of the C99 spec).  A #ifndef check was in place to prevent compilation
under MSVC but it actually needs to check for C99 compliance instead.
Also, even though the PGI C compiler reports to be fully C99 compliant,
it still fails.

- CHECK_SYMBOL_EXISTS is used to determine the presense of bswap
functions from byteswap.h.  Most compilers re-dedefine the bswap_N
functions as a __bswap_N function implemented by the compiler.  Since
bswap_N is usually defined as a macro then it's mere presence passes
the check.  Some versions of the PGI compiler though have shipped
broken headers for byteswap.h, in particular 11.3 for x64 linux
provides byteswap.h but is missing an associated bits/byteswap.h which
causes some of the bswap_N macros to be defined but broken and unusable.
The bswap_N checks have been converted to CHECK_SOURCE_COMPILES to
ensure that the bswap_N calls are actually usable and not just merely
defined.
---
 Utilities/cmliblzma/CMakeLists.txt |   12 +---
 Utilities/cmliblzma/liblzma/check/sha256.c |4 +++-
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/Utilities/cmliblzma/CMakeLists.txt b/Utilities/cmliblzma/CMakeLists.txt
index fc50dbe..856e41e 100644
--- a/Utilities/cmliblzma/CMakeLists.txt
+++ b/Utilities/cmliblzma/CMakeLists.txt
@@ -31,9 +31,15 @@ CHECK_INCLUDE_FILE(strings.h HAVE_STRINGS_H)
 CHECK_INCLUDE_FILE(string.h HAVE_STRING_H)
 CHECK_INCLUDE_FILE(sys/sysctl.h HAVE_SYS_SYSCTL_H)
 
-CHECK_SYMBOL_EXISTS(bswap_16 byteswap.h HAVE_BSWAP_16)
-CHECK_SYMBOL_EXISTS(bswap_32 byteswap.h HAVE_BSWAP_32)
-CHECK_SYMBOL_EXISTS(bswap_64 byteswap.h HAVE_BSWAP_64)
+CHECK_C_SOURCE_COMPILES (
+  #includebyteswap.h\nint main(void){bswap_16(0);return 0;}
+  HAVE_BSWAP_16)
+CHECK_C_SOURCE_COMPILES (
+  #includebyteswap.h\nint main(void){bswap_32(0);return 0;}
+  HAVE_BSWAP_32)
+CHECK_C_SOURCE_COMPILES (
+  #includebyteswap.h\nint main(void){bswap_64(0);return 0;}
+  HAVE_BSWAP_64)
 
 TEST_BIG_ENDIAN(WORDS_BIGENDIAN)
 
diff --git a/Utilities/cmliblzma/liblzma/check/sha256.c b/Utilities/cmliblzma/liblzma/check/sha256.c
index b09ccbf..f1d3337 100644
--- a/Utilities/cmliblzma/liblzma/check/sha256.c
+++ b/Utilities/cmliblzma/liblzma/check/sha256.c
@@ -80,7 +80,9 @@ static const uint32_t SHA256_K[64] = {
 
 
 static void
-#ifndef _MSC_VER
+#if defined(__STDC_VERSION__)  (__STDC_VERSION__  199901L)  \
+   !defined(__PGIC__)
+/* Even though int foo[static 3] is valid C99, the PGI compiler still breaks */
 transform(uint32_t state[static 8], const uint32_t data[static 16])
 #else
 transform(uint32_t state[], const uint32_t data[])
-- 
1.7.4.1

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Fix broken PGI builds for liblzma.

[Chuck Atkins]

It should be noted that the patch is really a set of workaround for PGI
compiler being broken and  less to do with the code itself.  If desired, I
could refactor the #if C99 test to  use a CHECK_SOURCE_COMPILES at the
CMake level instead.

- Chuck


On Fri, Aug 1, 2014 at 2:22 PM, Chuck Atkins chuck.atk...@kitware.com
wrote:

 I noticed the recent merge of liblzma broke the PGI compiler.  The
 attached patch should address the issues:

 PGC-S-0037-Syntax error: Recovery attempted by deleting keyword static
 (/home/chuck/Code/cmake/source/Utilities/cmliblzma/liblzma/check/sha256.c:
 84)

 Once that's fixed, then the 32-bit build works but the 64-bit build is
 still broken with:

 ../Utilities/cmliblzma/libcmliblzma.a(sha256.c.o): In function
 `lzma_sha256_finish':
 /home/chuck/Code/cmake/source/Utilities/cmliblzma/liblzma/check/sha256.c:196:
 undefined reference to `__bswap_64'

 The patch should address both issues with explanations as to why.


 - Chuck

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Fix broken PGI builds for liblzma.

[Chuck Atkins]

On Fri, Aug 1, 2014 at 2:43 PM, C. Bergström cbergst...@pathscale.com
wrote:

 I'm not intimately following this issue, but I can get you access to
 pathcc/pathCC to see if we work on this as well.


I've got an older ekopath 4.0.9 and 4.0.10 install that you gave us a while
back when I was setting up some LAPACK testing.  The build was fine without
this patch so no issues there.  It would be nice to get an updated version
though going on a nightly dashboard.  Let's discuss further off-list.



 (C99 doesn't work correctly on some of the older linux) So while c99
 is claimed to be supported - it was in fact broken. SLES10 is one example I
 know 1st hand - there are others as well.


In this particular case it's a C99 language feature not library or include
issue so I wouldn't expect the OS version to matter but I suppose could.
We've seen similar issues with trying to use AVX instructions on RHEL5.
MAny compilers will detect the CPU as supporting it and try to generate the
code but the kernel doesn't support the instructions and will segfault so
we need to explicitly disable AVX optimizations on RHEL5.


feature/functional tests imho are always preferred vs #if..


If the if C99 tests are actually reliable and I could trust that C99
would work then I'd rather since it really bogs down the configure time.
That being said though, in this case it seems to not be since
__STDC_VERSION__ is getting set to 199901L by the compiler but clearly not
all C99 features are working.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Learning from the source

[Chuck Atkins]

Hi Ingwie,

It depends on what exactly you're referring to.  If you mean calls to
find_library and find_path, those usually have a set of known directories
and patterns that they search for.  However, if you're referring to the
configure time checks line CHECK_INCLUDE_FILE and related functions, those
are implemented through try-compiles.  Basically, if you want to check if a
header foo.h exists, then a dummy C program just containing the #include
foo.h directive and a sub main is generated, and then compiled.  If the
compile is successful, then the header is found.  If it failed, then it
wasn't.  This is essentially the same approach taken for library and
function existence checking.  You can see the details of how it's
implemented by looking in your cmake installation in the Modules folder and
look at the Check*.cmake files.  You can also find the source templates
used for the try-compiles in the same folder, i.e. CheckIncludeFile.cxx.in,
etc.

- Chuck


On Sun, Apr 13, 2014 at 11:40 PM, Kevin Ingwersen ingwie2...@googlemail.com
 wrote:

 Hello everyone! This is my first post here, so hopefuly you can understand
 me - because I am not a native english speaker! :)

 As the title suggests, I wish to learn one thing or another. Currently, I
 am working on a project that has a good bunch of dependencies. They all
 originate from different build systems - Autotools, GYP, CMake - and are
 therefore pretty individual. So I have searched for a build system that
 works cross-platform and has a nice syntax that makes things look clean.
 Turns out I found one, forked it, and customized it.

 But now I am stuck at the configuration part. The program can very nicely
 track dependencies and build properly. However, it has only partial
 integration for configuring (generating config.h’s for example) - and that
 is what I wish to implement. Since CMake supports things as checking for
 includes, libraries, and functions, i wanted to ask how CMake is doing this.

 The reason why I ended up asking here is plain simple:
 - GYP has no configuration part at all.
 - Autotools looks to me like I am reading some raw certificate… AKA. I
 just can’t wrap my head around it.

 Here are some references, if you need them.
 - The fork of the build system in question:
 https://github.com/IngwiePhoenix/build
 - The project in question: https://github.com/Deskshell-Core/PhoenixEngine

 Hopefully I am right here to learn more about the rather complex task of
 probing a system for things! ^-^

 Kind regards, Ingwie.
 --

 Powered by www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Adding custom namespaces to FindBoost

[Chuck Atkins]

Given the complicated nature of FindBoost and it's many many use cases, I'd
like to run this by the list for inclusion in to the FindBoost.cmake
module.  First let me preface this with the note that this patch maintains
100% backwards compatibility and will default to the current behaviour.
That being said, here's the patch.

Justification:
Often when using a private copy of boost you'll want to extract a small
subset and build it with a custom namespace instead of boost::.  This
generally involves a different name for the libraries as well.  This is
usually to remove any symbol conflicts either with external dependencies
also built with boost or with being used as a dependency in something else
that needs it's own version of boost.  Luckiliy, the boost distribution
contains a tool, bcp, to do all of this for you.  It will extract a subset
of boost, change it's namespace to one you specify, and rename the
libraries it builds accordingly.

Patch description:
The FindBoost module currently assumes all boost libraries will be named
boost_foo and currently will not find these renamed libraries.  This patch
ds a Boost_NAMESPACE option to allo myboost_foo to be found instead.

Patch attached

- Chuck
From cfc0008206155c5244c205c3f77bba911c109b6c Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Wed, 12 Feb 2014 15:33:46 -0500
Subject: [PATCH] Add suport for custom namespaces in FindBoost.

This patch defaults to existing behavior and does NOT break backwards
compatibility. When building boost with an alternate namespace the libraries
generated will have a different naming convention. This is often done to
ensure no symbol conflicts with external libries built against a different
version of boost. If the namespace used is myprivateboost:: instad of
boost:: then the libraries built will be myprivateboost_foo instead of
boost_foo. This patch add an option to specify a custom namespace used to
alter the library names that get searched for.
---
 Modules/FindBoost.cmake | 62 +
 1 file changed, 37 insertions(+), 25 deletions(-)

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 945694d..a57e12c 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -99,6 +99,9 @@
 #   Boost_THREADAPI  - Suffix for thread component library name,
 #  such as pthread or win32.  Names with
 #  and without this suffix will both be tried.
+#   Boost_NAMESPACE  - Alternate namespace used to build boost with
+#  e.g. if set to myboost, will search for
+#  myboost_thread instead of boost_thread.
 #
 # Other variables one may set to control this module are::
 #
@@ -736,10 +739,24 @@ else()
 endif()
 
 # 
+#  Prefix initialization
+# 
+
+set(Boost_LIB_PREFIX )
+if ( WIN32 AND Boost_USE_STATIC_LIBS AND NOT CYGWIN)
+  set(Boost_LIB_PREFIX lib)
+endif()
+
+if ( NOT Boost_NAMESPACE )
+  set(Boost_NAMESPACE boost)
+endif()
+
+# 
 #  Suffix initialization and compiler suffix detection.
 # 
 
 set(_Boost_VARS_NAME
+  Boost_NAMESPACE
   Boost_COMPILER
   Boost_THREADAPI
   Boost_USE_DEBUG_PYTHON
@@ -752,11 +769,6 @@ set(_Boost_VARS_NAME
 _Boost_CHANGE_DETECT(_Boost_CHANGE_LIBNAME ${_Boost_VARS_NAME})
 
 # Setting some more suffixes for the library
-set(Boost_LIB_PREFIX )
-if ( WIN32 AND Boost_USE_STATIC_LIBS AND NOT CYGWIN)
-  set(Boost_LIB_PREFIX lib)
-endif()
-
 if (Boost_COMPILER)
   set(_boost_COMPILER ${Boost_COMPILER})
   if(Boost_DEBUG)
@@ -966,18 +978,18 @@ foreach(COMPONENT ${Boost_FIND_COMPONENTS})
   # Find RELEASE libraries
   #
   set(_boost_RELEASE_NAMES
-${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}-${Boost_LIB_VERSION}
-${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}
-${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}-${Boost_LIB_VERSION}
-${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}
-${Boost_LIB_PREFIX}boost_${COMPONENT} )
+${Boost_LIB_PREFIX}${Boost_NAMESPACE}_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}-${Boost_LIB_VERSION}
+${Boost_LIB_PREFIX}${Boost_NAMESPACE}_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}
+${Boost_LIB_PREFIX}${Boost_NAMESPACE}_${COMPONENT}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG}-${Boost_LIB_VERSION}
+${Boost_LIB_PREFIX}${Boost_NAMESPACE}_${COMPONENT}${_boost_MULTITHREADED}${_boost_RELEASE_ABI_TAG

Re: [cmake-developers] Ninja Issues with dependencies

[Chuck Atkins]

Yep.  That fixed it.  Thanks!

Chuck Atkins
RD Engineer, Kitware, Inc.

-- Mathematicians are tools for turning coffee grounds into formulas.,
Paul Erdos


2012/3/14 Nicolas Desprès nicolas.desp...@gmail.com

 Try with this branch:
 https://github.com/polrop/ninja/tree/depfile-parser-accept-tilde
 I think that should fix your problem.

 On Wed, Mar 14, 2012 at 7:58 PM, Chuck Atkins chuck.atk...@kitware.com
 wrote:
  Just to clarify with more information:
 
  cmake: d2d492f492a8a6082345e439a9c15418f0d483db
  - This is the head of the branch that was merged into next
 
  ninja: fdec96f54e92d2990ebf1ba5434b317d3d8ad49d
  - Tues, Mar. 13
 
 
  Chuck Atkins
  RD Engineer, Kitware, Inc.
  (518) 371-3971 x603
  chuck.atk...@kitware.com
 
 
  -- Mathematicians are tools for turning coffee grounds into formulas.,
  Paul Erdos
 
 
  On Wed, Mar 14, 2012 at 2:00 PM, Chuck Atkins chuck.atk...@kitware.com
  wrote:
 
  I'm trying to build a fairly large project (VXL, 4000 make targets) with
  cmake+Ninja and I'm experiencing some strange issues:
 
  1.  I configure the project with 'cmake -G Ninja'.  Everything works
  great.
  2.  Build the project with 'ninja'.  Everything builds just fine (and
 VERY
  fast I might add, nice job Ninja guys)
  3.  Rebuild with 'ninja', BREAK:
  Recompacting log...
  ninja: ERROR: expected depfile
  'v3p/Qv/CMakeFiles/Qv.dir/Templates/vcl_vector+QvNode~-.o.d' to mention
  'v3p/Qv/CMakeFiles/Qv.dir/Templates/vcl_vector+QvNode~-.o', got
  'v3p/Qv/CMakeFiles/Qv.dir/Templates/vcl_vector+QvNode'
 
  I can only re-build if I clean first with 'ninja -t clean'.  And yes,
 the
  filenames are correct.  There are some files named
 vcl_vector+QvNode~-.cxx
  (The result of some auto-code generating scripts).  Could it be that the
  odd-ball characters in the filenames are breaking some regex
 somewhere?  Not
  sureif the issue would be in ninja itself or in the cmake-ninja
 integration.
 
  Thanks
 
  Chuck Atkins
  RD Engineer, Kitware, Inc.
 
  -- Mathematicians are tools for turning coffee grounds into formulas.,
  Paul Erdos
 
 
 
  --
 
  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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers



 --
 Nicolas Desprès

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers