[CMake] CMake, OpenBSD, and system libraries

[Chuck Atkins]

I'm trying to set up a nightly build for CMake on OpenBSD and I'm getting
some linker issues.  When I configure CMake to use it's internal versions of
curl, expat, and libz, then everything builds.  It does, however, fail the
X11 test because of a linker error:

http://www.cdash.org/CDash/testDetails.php?test=43846434build=534940

[100%] Building C object CMakeFiles/UseX11.dir/X11.c.o
Linking C executable UseX11
/usr/X11R6/lib/libSM.so.8.0: warning: strcpy() is almost always misused,
please use strlcpy()
/usr/X11R6/lib/libICE.so.9.0: warning: strcat() is almost always misused,
please use strlcat()
/usr/X11R6/lib/libSM.so.8.0: warning: sprintf() is often misused, please use
snprintf()
/usr/bin/ld: warning: libICE.so.9.0, needed by /usr/X11R6/lib/libSM.so.8.0,
not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libXau.so.9.0, needed by
/usr/X11R6/lib/libX11.so.11.2, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libXdmcp.so.9.0, needed by
/usr/X11R6/lib/libX11.so.11.2, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libX11.so.11.2, needed by
/usr/X11R6/lib/libXext.so.10.0, not found (try using -rpath or -rpath-link)
/usr/X11R6/lib/libX11.so.11.2: undefined reference to `XdmcpWrap'
/usr/X11R6/lib/libX11.so.11.2: undefined reference to `XauGetBestAuthByAddr'
/usr/X11R6/lib/libX11.so.11.2: undefined reference to `XauDisposeAuth'
collect2: ld returned 1 exit status
gmake[2]: *** [UseX11] Error 1
gmake[1]: *** [CMakeFiles/UseX11.dir/all] Error 2
gmake: *** [all] Error 2

But when I try to configure cmake using the system libraries for curl,
expat, and libz, then I get similar linker errors for the cmake build
itself:

http://www.cdash.org/CDash/buildSummary.php?buildid=534978

/usr/bin/ld: warning: libintl.so.4.0, needed by
/usr/local/lib/libcurl.so.13.2, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libiconv.so.6.0, needed by
/usr/local/lib/libcurl.so.13.2, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libidn.so.16.30, needed by
/usr/local/lib/libcurl.so.13.2, not found (try using -rpath or -rpath-link)
/usr/local/lib/libcurl.so.13.2: undefined reference to `tld_strerror'
/usr/local/lib/libcurl.so.13.2: undefined reference to
`stringprep_check_version'
/usr/local/lib/libcurl.so.13.2: undefined reference to `idn_free'
/usr/local/lib/libcurl.so.13.2: undefined reference to `idna_strerror'
/usr/local/lib/libcurl.so.13.2: undefined reference to
`idna_to_unicode_lzlz'
/usr/local/lib/libcurl.so.13.2: undefined reference to
`stringprep_locale_charset'
/usr/local/lib/libcurl.so.13.2: undefined reference to `idna_to_ascii_lz'
/usr/local/lib/libcurl.so.13.2: undefined reference to `tld_check_lz'
collect2: ld returned 1 exit status
gmake[2]: *** [bin/DumpDocumentation] Error 1
gmake[1]: *** [Source/CMakeFiles/DumpDocumentation.dir/all] Error 2



Chuck Atkins
RD Engineer
Kitware, Inc.
(518) 371-3971 x603

-- 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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] FIND_LIBRARY in FindBoost finds wrong library

[Chuck Atkins]

With multiple versions installed, setting the BOOST_ROOT variable will force
the FindBoost module to search the desired location first.  Turning the loop
inside out wouldn't really solve the problem when multiple libraries are
searched for (date_time, thread).  The problem arises when multiple versions
are available with different capabilities.  For example:  boost installed in
/usr/local has all the libraries available but the one installed in
/home/myuser/projects/boost-1.41.0 might only have a partial subset of the
libraries available, say only date_time and thread for example.  Since the
FindBoost module searches the BOOST_ROOT path in addition to the other
paths,  a conflict could arise where the module finds something like:

/home/myuser/projects/boost-1.41.0/lib/libboost_date_time-mt.so
/home/myuser/projects/boost-1.41.0/lib/libboost_thread-mt.so
/usr/local/lib/libboost_filesystem-mt.so
/usr/local/lib/libboost_python-mt.so

This mix and match is definitely not desired.  It almost seems like if the
BOOST_ROOT variable is set then that should get used exclusively as the
search path and not just appended to the front.

Thoughts?

Chuck Atkins


On Fri, Mar 19, 2010 at 7:12 AM, Marcel Loose lo...@astron.nl wrote:

 Hi Michael,

 That still doesn't answer my question about turning that loop inside
 out.

 A quick grep in the CMake Modules directory showed me that there are at
 least a dozen other FindXXX scripts that use multiple NAMES with a
 FIND_XXX() commands. I haven't checked how they handle default (system)
 paths, but I guess these might be erratic as well, when multiple
 versions of a package exists with libraries named slightly different.

 Best regards,
 Marcel Loose.

 On Fri, 2010-03-19 at 06:50 -0400, Philip Lowman wrote:
  Someone could add an option to FindBoost that will simply exclude the
  system paths from the search.  This has never been implied by setting
  BOOST_ROOT.  As long as the unversioned library names are being
  searched for with find_library they are likely going to be found.
  Currently the onus is on the user to double check what FindBoost
  discovers.
 
   On Mar 19, 2010 4:56 AM, Marcel Loose lo...@astron.nl wrote:
  
   Well, in my case, the library name was not even that specific.
   It found /usr/lib/libboost_date_time-mt.so
   before /home/loose/boost/boost-1.40.0/lib/libboost_date_time.so,
   simply
   because libboost_date_time-mt.so is searched for in *all* paths
   before
   libboost_date_time.so.
  
   Anyway, I still think this is (also) a CMake issue. IMHO it would
   make
   sense to turn the loop in cmFindLibraryCommand::FindNormalLibrary()
   inside out. What's your opinion?
  
   Best regards,
   Marcel Loose.
  
  
   On Thu, 2010-03-18 at 10:05 -0400, Michael Jackson wrote:  I
   thought there was now an option the b...
  
 


 ___
 Powered by www.kitware.com

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

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

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

___
Powered by www.kitware.com

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

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

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

Re: [CMake] how can I filter compiler warnings?

[Chuck Atkins]

What compiler / platform are you using?



On Mon, May 10, 2010 at 9:53 AM, Kevin Burge kevin.bu...@systemware.comwrote:

  Any ideas on how to do this kind of supression?  I'm thinking now I just
 need to write a cc/c++ script that cmake will find first, that actually
 does the filtering.  I never could figure out a way to forcefully indicate
 the compiler that didn't break things.


 On 05/07/2010 12:47 PM, Chuck Atkins wrote:

 What exactly do you mean by filter?  Do you want to suppress the
 warnings?


 On Fri, May 7, 2010 at 1:29 PM, Kevin Burge kevin.bu...@systemware.comwrote:

 I need to be able to filter warnings out of the compilation output from
 specific files:

 /usr/include/pthread.h, line 990.27: 1506-450 (I) Obsolete
 non-prototype-style function declaration.
 /usr/include/pthread.h, line 1049.42: 1506-450 (I) Obsolete
 non-prototype-style function declaration.
 /usr/include/pthread.h, line 1050.42: 1506-450 (I) Obsolete
 non-prototype-style function declaration

 On our old build system, we replaced cc with a ruby script that filtered
 the output.  I never did figure out the way to do this with cmake.  I'd
 rather have cmake filter it if it can.

 Please let me know if there's a way to do this.

 Thank you,
 Kevin Burge

 ___
 Powered by www.kitware.com

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

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

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



___
Powered by www.kitware.com

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

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

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

Re: [CMake] how can I filter compiler warnings?

[Chuck Atkins]

These are really the kind of warnings that you want to disable with a
compiler flag but it will be specific for the given compiler.  Which
platforms do you see the warning on?  The error message looks like an xl
compiler warning.  Do you see it on other platforms as well?



On Mon, May 10, 2010 at 11:06 AM, Kevin Burge kevin.bu...@systemware.comwrote:

  My apologies: Solaris (gcc 412), AIX (xlC 9), Windows (MSVC8 - i.e. Visual
 Studio 2005 w/ nmake), Linux (several different gcc releases)


 On 05/10/2010 10:04 AM, Chuck Atkins wrote:

 What compiler / platform are you using?



 On Mon, May 10, 2010 at 9:53 AM, Kevin Burge 
 kevin.bu...@systemware.comwrote:

 Any ideas on how to do this kind of supression?  I'm thinking now I just
 need to write a cc/c++ script that cmake will find first, that actually
 does the filtering.  I never could figure out a way to forcefully indicate
 the compiler that didn't break things.


 On 05/07/2010 12:47 PM, Chuck Atkins wrote:

 What exactly do you mean by filter?  Do you want to suppress the
 warnings?


 On Fri, May 7, 2010 at 1:29 PM, Kevin Burge kevin.bu...@systemware.comwrote:

 I need to be able to filter warnings out of the compilation output from
 specific files:

 /usr/include/pthread.h, line 990.27: 1506-450 (I) Obsolete
 non-prototype-style function declaration.
 /usr/include/pthread.h, line 1049.42: 1506-450 (I) Obsolete
 non-prototype-style function declaration.
 /usr/include/pthread.h, line 1050.42: 1506-450 (I) Obsolete
 non-prototype-style function declaration

 On our old build system, we replaced cc with a ruby script that filtered
 the output.  I never did figure out the way to do this with cmake.  I'd
 rather have cmake filter it if it can.

 Please let me know if there's a way to do this.

 Thank you,
 Kevin Burge

 ___
 Powered by www.kitware.com

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

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

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




___
Powered by www.kitware.com

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

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

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

Re: [CMake] Linking error with VS2005

[Chuck Atkins]

Does the problem happen in both Debug and Release builds?

Visual C++ has a well known problem of mixing debug and release libraries
together.  My suspicion is that you have some dependant libraries that are
only built in Debug or only built in Release.  With Visual C++ it is
important that all libraries and dependencies as well as the project code
it's self be built in the same Build Configuration (Debug or Release).
Mixing the two will often give rise to problems such as these.

Chuck Atkins


-- Mathematicians are tools for turning coffee grounds into formulas.,
Paul Erdos


On Fri, May 21, 2010 at 8:01 AM, Daanen Vincent daa...@koelis.com wrote:

 Dear Cmake users,

 I'm facing to a problem I can't resolve.
 I'm developping on a windows XP SP3 box with Visual Studio 2005.

 I have a project using itk which compile fine.
 For  some reason, I try to use cmake to generate the same project and I
 got linker error (conflict between msvcrtd.lib and libcmtd.lib)

 - I check that the librairies are declared in the same order in both
 project
 and it's ok
 - Try to ignore either msvcrtd.lib or libcmtd.lib but I does not work :
 other linker errors appear.

 I could not find what is specifically added by cmake so that the
 cmake-generated project fails to build the binray whereas the
 manually-generated project file succeeds...

 Is there someone who could help me ?

 Thanks

  Vince

 ___
 Powered by www.kitware.com

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

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

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

___
Powered by www.kitware.com

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

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

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

Re: [CMake] How to determine the compiler used outside of cmake

[Chuck Atkins]

Instead of overriding the compiler in the CMakeLists.txt to a specific
compiler version, why not guide CMake's compiler detection from the outside
and have CMake choose the one you want?  For instance, since you're
already using a wrapper to drive the CMAKe build, you could call cmake with
cmake -DCMAKE_C_COMPILER=/usr/bin/gcc44
-DCMAKE_CXX_COMPILER=/usr/bin/g++44 ... or inside your wrapper script, you
could export the CC and CXX environment variables.  This will allow your
CMake build to be clean and portable while abstracting the configuration
specific to your particular environment to the wrapper script you're
already using.  You could also look at using pre-defined cache files to
prime a collection of commonly used settings.  Using a pre-defined cache
file has actually turned out to be a good solution for my group here when
we had to maintain a hand-full of commonly used build configurations.  The
cache files just look like:

---
set(OPTION1 ON CACHE BOOL Doc for Option 1)
set(OPTION2 /path/to/foo CACHE FILEPATH Doc for Option 2)
set(CMAKE_CXX_COMPILER /usr/bin/g++44 CACHE FILEPATH CXX Compiler)
...
---

And then you can instruct CMake to pre-load it's cache values via:
cmake -C /path/to/settings.cmake /path/to/source

A common use case for us is to have a particular set of options that are
set specifically for RHEL5 and another set when building for RHEL6.  It's
then often convenient to keep these in the repo with the rest of the code.

Just a though
- Chuck


On Thu, May 2, 2013 at 3:35 PM, Miller, Frank fmil...@sjm.com wrote:

  Update. The reason I didn’t have CMAKE_CXX_COMPILER in my cache is
 because I was doing a

 ** **

   set(CMAKE_CXX_COMPILER /usr/bin/g++44 )

 ** **

 at the top of my root CMakeLists.txt. That preempts the set( CACHE ) call
 that project() does. My bad.

 ** **

 Frank 

 ** **

 *From:* cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] *On
 Behalf Of *Miller, Frank
 *Sent:* Thursday, May 02, 2013 9:51 AM
 *To:* m.hergar...@euphoria-it.nl
 *Cc:* cmake@cmake.org
 *Subject:* Re: [CMake] How to determine the compiler used outside of cmake
 

 ** **

 Interesting. I am running a very recent version (2.8.10.20130415) built
 from git. Perhaps the handling of CMAKE_CXX_COMPILER has changed recently.
 

 ** **

 I can’t believe I didn’t think to manually put it in the cache. That will
 work for me. Thanks.

 ** **

 As for the bigger problem I am solving... I have a wrapper script that
 drives the build. This is done to emulate a legacy build system and add
 some nice-to-haves. For example, the user can call the script from their
 source tree and it will call cmake/ninja in the proper binary tree. The
 default compiler to be used is hard coded into the CMakeLists.txt and I
 would like to have the script detect when the compiler changes and do a
 reconfigure automatically.

 ** **

 Now that I’m explaining the larger problem, I think I will have to put
 extra information in the cache to detect when the user manually overrides
 the default compiler. So I probably would have come around to your
 suggestion on my own.

 ** **

 Thanks again,

 ** **

 Frank

 ** **

 *From:* m.hergarden 
 [mailto:m.hergar...@euphoria-it.nlm.hergar...@euphoria-it.nl]

 *Sent:* Thursday, May 02, 2013 12:16 AM
 *To:* Miller, Frank
 *Cc:* cmake@cmake.org
 *Subject:* Re: [CMake] How to determine the compiler used outside of cmake
 

 ** **

 The compiler does show up in my cache:
 CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++, but that doesn't solve your issue.
 What is the bigger problem you are solving? If you really really need it
 in the cache, you can always write a variable yourself to make sure it's
 there.

 Regards,
 Micha

 On 05/01/2013 09:56 PM, Miller, Frank wrote:

  Greetings,

  

 Given a configured build tree, I would like to determine the c++ compiler
 used without reconfiguring. I expected the CMAKE_CXX_COMPILER variable
 would be in the CMakeCache.txt but I was wrong. I tried to run a simple
 cmake script with ‘cmake -P’ and print the value of CMAKE_CXX_COMPILER but
 that does not work. I found the value in
 ‘CMakeFiles/2.8.10.20130415/CMakeCXXCompiler.cmake’, so I have a
 workaround, but that smells like the wrong solution. Does anyone know of a
 better way?

  

 Thanks as always,

  

 Frank

  

  


 This communication, including any attachments, may contain information
 that is proprietary, privileged, confidential or legally exempt from
 disclosure. If you are not a named addressee, you are hereby notified that
 you are not authorized to read, print, retain a copy of or disseminate any
 portion of this communication without the consent of the sender and that
 doing so may be unlawful. If you have received this communication in error,
 please immediately notify the sender via return e-mail and delete it from
 your system.

 

 --

 ** **

 Powered by www.kitware.com

 ** **

 

Re: [CMake] install TARGETS given unknown argument EXPORT. with cmake 2.8.9

[Chuck Atkins]

Hi David,

What does your install(...) line look like so we can try to help you debug
the issue?

- Chuck


On Wed, Feb 12, 2014 at 4:09 PM, david.hag...@gmail.com wrote:

 I am trying to set up component registration as per

 http://www.cmake.org/Wiki/CMake/Tutorials/Packaging

 but when I run Cmake I get the error

   install TARGETS given unknown argument EXPORT.


 While I've found many hits on Google with that error string, none that I
 have found have any resolution on what to do about it. Is the tutorial
 page in error?

 --

 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://www.cmake.org/mailman/listinfo/cmake

-- 

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] install TARGETS given unknown argument EXPORT. with cmake 2.8.9

[Chuck Atkins]

David,

Indeed it should.  Thanks for catching that!  I've updated the wiki page
with the correct order of arguments.

- Chuck

On Fri, Feb 21, 2014 at 11:25 AM, david.hag...@gmail.com wrote:


  The order of arguments is wrong.
 
  Move the 'EXPORT foo-targets' to just after 'TARGETS foo'.
 

 That fixed the issue. Shouldn't the WIKI be fixed so the example is
 correct?

 --

 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://www.cmake.org/mailman/listinfo/cmake

-- 

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake project patterns / examples

[Chuck Atkins]

Just put all the build commands in the top level cmake file.

Definitely an anti-pattern.  As you mentioned, it definitely doesn't
scale.  The problem with even doing this for a simple project is that it
builds this behavior for people trying to learn cmake through simple
examples.  This very very quickly turns in to a 3k line top level
CMakeLists.txt  for even moderately sized projects.  I would really
discourage this one as don't do it ever because of the bad behaviours it
builds early on.

- Chuck

On Tue, Jun 3, 2014 at 1:22 PM, Iosif Neitzke iosif.neitzke+cm...@gmail.com
 wrote:

 Great to see these examples with pros and cons.

 I believe the staticlibs-include example [0] pattern, though mentioned
 in Mastering CMake [1], generally is deprecated in favor of
 add_subdirectory with CMakeLists.txt at each level for self-contained
 projects.

 [0]
 https://github.com/toomuchatonce/cmake-examples/tree/master/staticlibs-include

 [1] Mastering CMake, 6th Edition, Chapter 7: Converting Existing
 Systems to CMake, Source Code Directory Structures, page 116

 On Mon, Jun 2, 2014 at 5:23 PM, Adam Boseley adam707b...@gmail.com
 wrote:
 
  There's a lot of legacy examples around the web but not too many using
 the
  newer features.  What is the current best practise?
 
  Here's some simple examples
 
 https://github.com/toomuchatonce/cmake-examples/wiki/cmake-patterns-and-examples
 
  Are these patterns or anti-patterns?
 
  Regards,
  Adam
 
  --
 
  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://www.cmake.org/mailman/listinfo/cmake
 --

 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://www.cmake.org/mailman/listinfo/cmake

-- 

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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Fails for Solaris

[Chuck Atkins]

Amos,

I just tried on a Sun Blade 1500 running Solaris 10 8/11 with an UltraSPARC
IIIi using SolarisStudio 12.2 and 12.3.  Both were able to configure and
build successfully using both the bootstrap, /path/to/source/bootstrap 
gmake, and and cmake, cmake /path/to/source  gmake, so it can be done:

-
CMake 3.0.0, Copyright 2000-2014 Kitware, Inc.
C compiler on this system is: /opt/solarisstudio12.3/bin/suncc
C++ compiler on this system is: /opt/solarisstudio12.3/bin/sunCC
Makefile processor on this system is: gmake
/opt/solarisstudio12.3/bin/sunCC is not GNU compiler
...
/opt/solarisstudio12.3/bin/sunCC has ANSI for scoping
-
gmake: `cmake' is up to date.
loading initial cache file
/export/home/local/KHQ/chuck.atkins/Code/CMake/build/v3.0.0/sunpro_bootstrap/Bootstrap.cmk/InitialCacheFlags.cmake
-- Configuring done
-- Generating done
-- Build files have been written to:
/export/home/local/KHQ/chuck.atkins/Code/CMake/build/v3.0.0/sunpro_bootstrap
-
CMake has bootstrapped.  Now run gmake.

That being said however, this is clearly not working for you.  What
particular versions of compilers and Solaris are you using?  Are you using
the 3.0.0 tarball or are you using a git checkout of a specific hash?


- Chuck


On Tue, Jul 15, 2014 at 1:06 PM, Amos a.go...@gmail.com wrote:

 No matter if I use GNU or workshop compilers, the initial config fails:

 CC supports member templates
 CC has standard template specialization syntax
 CC has argument dependent lookup
 CC has struct stat with st_mtim member
 CC has ios::binary openmode
 CC has ANSI for scoping
 -
 gmake: 'cmake' is up to date.
 loading initial cache file
 /usr/soft/that/cmake-3.0.0/src/default/sparcv9_sun_solaris2.10/Bootstrap.cmk/InitialCacheFlags.cmake
 -- Using system-installed BZIP2
 -- Using system-installed ZLIB
 CMake Error: File
 /usr/soft/that/cmake-3.0.0/src/default/sparcv9_sun_solaris2.10/Tests/.NoDartCoverage
 does not exist.
 CMake Error at CMakeLists.txt:161 (configure_file):
   configure_file Problem configuring file
 Call Stack (most recent call first):
   CMakeLists.txt:527 (CMAKE_SETUP_TESTING)


 --

 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

-- 

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

Re: [CMake] Fails for Solaris

[Chuck Atkins]

Hi Amos,

Although I'm ure it's *possible*, I'd be surprised if changing the compiler
made any difference.  A few questions would help narrow down the issue:

   - Which source are you building from?  Is it the 3.0.0 release tgz or is
   it a particular git hash?
   - Are you doing an in-source build (not recommended) or an out-of-source
   build (recommended)?
   - What's the exact build command you're using?

Thanks
- Chuck


On Wed, Jul 16, 2014 at 7:37 PM, Amos a.go...@gmail.com wrote:

 Thanks for the reply.

 I tried with both gcc-4.8.3 and Studio 12.1.  Maybe I'll try updating
 SolarisStudio.




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

 Amos,

 I just tried on a Sun Blade 1500 running Solaris 10 8/11 with an
 UltraSPARC IIIi using SolarisStudio 12.2 and 12.3.  Both were able to
 configure and build successfully using both the bootstrap, 
 /path/to/source/bootstrap
  gmake, and and cmake, cmake /path/to/source  gmake, so it can be
 done:

 -
 CMake 3.0.0, Copyright 2000-2014 Kitware, Inc.
 C compiler on this system is: /opt/solarisstudio12.3/bin/suncc
 C++ compiler on this system is: /opt/solarisstudio12.3/bin/sunCC
 Makefile processor on this system is: gmake
 /opt/solarisstudio12.3/bin/sunCC is not GNU compiler
 ...
 /opt/solarisstudio12.3/bin/sunCC has ANSI for scoping

 -
 gmake: `cmake' is up to date.
 loading initial cache file
 /export/home/local/KHQ/chuck.atkins/Code/CMake/build/v3.0.0/sunpro_bootstrap/Bootstrap.cmk/InitialCacheFlags.cmake
 -- Configuring done
 -- Generating done
 -- Build files have been written to:
 /export/home/local/KHQ/chuck.atkins/Code/CMake/build/v3.0.0/sunpro_bootstrap
 -
 CMake has bootstrapped.  Now run gmake.

 That being said however, this is clearly not working for you.  What
 particular versions of compilers and Solaris are you using?  Are you using
 the 3.0.0 tarball or are you using a git checkout of a specific hash?


 - Chuck


 On Tue, Jul 15, 2014 at 1:06 PM, Amos a.go...@gmail.com wrote:

  No matter if I use GNU or workshop compilers, the initial config fails:

 CC supports member templates
 CC has standard template specialization syntax
 CC has argument dependent lookup
 CC has struct stat with st_mtim member
 CC has ios::binary openmode
 CC has ANSI for scoping
 -
 gmake: 'cmake' is up to date.
 loading initial cache file
 /usr/soft/that/cmake-3.0.0/src/default/sparcv9_sun_solaris2.10/Bootstrap.cmk/InitialCacheFlags.cmake
 -- Using system-installed BZIP2
 -- Using system-installed ZLIB
 CMake Error: File
 /usr/soft/that/cmake-3.0.0/src/default/sparcv9_sun_solaris2.10/Tests/.NoDartCoverage
 does not exist.
 CMake Error at CMakeLists.txt:161 (configure_file):
   configure_file Problem configuring file
 Call Stack (most recent call first):
   CMakeLists.txt:527 (CMAKE_SETUP_TESTING)


 --

 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




-- 

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

Re: [CMake] CMAKE changing Visual Studio Settings

[Chuck Atkins]

Hi Joseph,

On Mon, Jul 21, 2014 at 4:51 PM, Joseph Rosensweig jrose...@gmail.com
wrote:

 ...

in my CMAKE I have places where I do things like if(CMAKE_BUILD_TYPE
 STREQUAL Debug) then do this else do that.


This is the sort of logic best achieved through generator expressions.  How
to do it specifically really depends.  Generator expressions are used all
over CMake in various different contexts so how to apply them depends on
what exactly you are trying to achieve.



 i.e. my CXX Flags will change based on the CMAKE_BUILD_TYPE ... What am I
 missing?


This is actually much simpler than the general case.  CMake has specific
compiler flags for all builds, release, debug, release with debug info, and
minimum size release.  They can be set / ammended with:

# Flags that get applied to all builds
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} /My /EXTRA /COMPILER /FLAGS)

# Flags that only apply to debug builds
set(CMAKE_CXX_FLAGS_DEBUG ${CMAKE_CXX_FLAGS_DEBUG} /ADDITIONAL /DEBUG
/ONLY /FLAGS)

# Flags that only apply to release builds
set(CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} /ADDITIONAL
/RELEASE /ONLY /FLAGS)

The resulting compiler flags that get used are a combination of the general
CMAKE_CXX_FLAGS and CMAKE_CXX_FLAGS for the current selected build
configuration.

Back to the first issue though, what other types of build-type specific
logic are you trying to achieve?  There may be a better / easier way.
-- 

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

Re: [CMake] How to set Look for CMakeDetermineLang.cmake here

[Chuck Atkins]

Hi David,

You can add to the search path CMake uses by appending to the
CMAKE_MODULE_PATH variable.  In your case, you'll probably want to set it
before the project command to make sure it's present for you're entire
project.  For example:

In your project, you create CMake directory where you would place
additional *.cmake files, such as your language files,or maybe even custom
Find modules.  Then in your top level CMakeLists file, you would have:

cmake_minimum_required(VERSION 2.8.12)
list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/CMake)
project(MyAwesomeProject)

Now anytime CMake searches for any sort of *.cmake file, it will also
search the CMake folder in your source tree.

Hope that helps.
- Chuck


On Mon, Jul 21, 2014 at 7:32 PM, David Zemon da...@zemon.name wrote:

 I am attempting to build an easy-to-use build system for an embedded
 system. This chip uses .dat, .spin, .cogc, and .ecogc files along with .S,
 .c, and .cpp. I've added the necessary language files to my project path
 which will enable cogc (I'll get to the other file types eventually) and
 they work great, but it requires manually linking or copying the files out
 of the project directory and into CMake's installation path. Is there some
 way to tell CMake that it should look for these files in a custom path?

 Thanks,
 David
 --

 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

-- 

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

Re: [CMake] Fwd: set_target_properties and language specific COMPILE_FLAGS

[Chuck Atkins]

Hi Nick,

You could split your target in to two object libraries that combine into a
singe real library:

add_library(foo_f OBJECT ${FOO_F_SOURCES})
# set necessary compile flags specific to the Fortran components
# on the foo_f target

add_library(foo_c OBJECT ${FOO_C_SOURCES})
# set necessary compile flags specific to the C components
# on the foo_c target

# Combine into a real library
add_library(foo $TARGET_OBJECTS:foo_f $TARGET_OBJECTS:foo_c)

See http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library

- Chuck


On Fri, Aug 1, 2014 at 12:54 PM, Nicolas Bock nicolasb...@gmail.com wrote:

 Hi,

 I am building a library containing Fortran and C sources. I would like
 to add language specific compile flags without affecting the global
 compile flags:

 set_target_properties( foo PROPERTIES C_FLAGS -fopenmp Fortran_FLAGS
 -openmp )

 However, it seems there is only COMPILE_FLAGS which presumably affects
 both languages.

 Thanks already,

 nick
 --

 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

-- 

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

Re: [CMake] Help cmake First project

[Chuck Atkins]

Hi Rodrigo,

It looks like you are probably missing some source files in your
executable.  Is protpred-Gromacs-NSGA2.c the only piece of code that gets
built for the executable?  If not, you'll need to make sure that all the
necessary source files get either built into the executable or build as a
separate library and linked into the executable.  Also, you can simply your
CMakeLists.txt and clean it up a bit by leaving out the
${2pg_cartesian_SOURCE_DIR} in most commands since CMake looks in the
current directory of the CMakeLists.txt file by default for most of its
functions:

include_directories(include)
add_executable(protpred-Gromacs-NSGA2 src/protpred-Gromacs-NSGA2.c)
install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin)


- Chuck


On Mon, Aug 4, 2014 at 10:26 AM, Rodrigo Faccioli 
rodrigo.facci...@gmail.com wrote:

 Hi,

 I'm trying to use cmake in my project. In fact, it is my first time using
 cmake.

 My CmakeList file is below. You can see it is very simple because I'm
 trying to compile a binary.

 cmake_minimum_required(VERSION 2.8)

 project(2pg_cartesian)
 set(PROJECT_VERSION 1.0)

 include_directories(${2pg_cartesian_SOURCE_DIR}/include)

 add_executable(protpred-Gromacs-NSGA2
 ${2pg_cartesian_SOURCE_DIR}/src/protpred-Gromacs-NSGA2.c)

 install(TARGETS protpred-Gromacs-NSGA2 DESTINATION bin)

 When I run cmake .. I receive  Build files have been written to:
 /home/faccioli/Downloads/2pg_cartesian/build. I understand that all is
 ok.

 faccioli@faccioli:~/Downloads/2pg_cartesian/build$ cmake ..
 -- The C compiler identification is GNU 4.7.2
 -- The CXX compiler identification is GNU 4.7.2
 -- Check for working C compiler: /usr/bin/gcc
 -- Check for working C compiler: /usr/bin/gcc -- works
 -- Detecting C compiler ABI info
 -- Detecting C compiler ABI info - done
 -- Check for working CXX compiler: /usr/bin/c++
 -- Check for working CXX compiler: /usr/bin/c++ -- works
 -- Detecting CXX compiler ABI info
 -- Detecting CXX compiler ABI info - done
 -- Configuring done
 -- Generating done
 -- Build files have been written to:
 /home/faccioli/Downloads/2pg_cartesian/build
 faccioli@faccioli:~/Downloads/2pg_cartesian/build$

 However, when I run make, I receive an error message as below:

 faccioli@faccioli:~/Downloads/2pg_cartesian/build$ make
 Scanning dependencies of target protpred-Gromacs-NSGA2
 [100%] Building C object
 CMakeFiles/protpred-Gromacs-NSGA2.dir/src/protpred-Gromacs-NSGA2.c.o
 Linking C executable protpred-Gromacs-NSGA2
 CMakeFiles/protpred-Gromacs-NSGA2.dir/src/protpred-Gromacs-NSGA2.c.o: In
 function `main':
 protpred-Gromacs-NSGA2.c:(.text+0x1e): undefined reference to `display_msg'
 protpred-Gromacs-NSGA2.c:(.text+0x3e): undefined reference to
 `load_parameters_from_file'
 protpred-Gromacs-NSGA2.c:(.text+0x58): undefined reference to `ea_nsga2'
 protpred-Gromacs-NSGA2.c:(.text+0x64): undefined reference to `fatal_error'
 protpred-Gromacs-NSGA2.c:(.text+0x73): undefined reference to
 `deAllocateload_parameters'
 protpred-Gromacs-NSGA2.c:(.text+0x7d): undefined reference to `display_msg'
 collect2: error: ld returned 1 exit status
 make[2]: ** [protpred-Gromacs-NSGA2] Erro 1
 make[1]: ** [CMakeFiles/protpred-Gromacs-NSGA2.dir/all] Erro 2
 make: ** [all] Erro 2
 faccioli@faccioli:~/Downloads/2pg_cartesian/build$

 Could you help me understand how can I fix this problem?

 I appreciate any help.

 Best regards,

 --
 Rodrigo Antonio Faccioli, Ph.D
 Development Software for Structural Bioinformatics
 Barao de Maua University
 University of Sao Paulo
 Lindedin - br.linkedin.com/pub/rodrigo-antonio-faccioli/7/589/a5/
 Curriculum Lattes - http://lattes.cnpq.br/1025157978990218

 --

 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

-- 

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

Re: [CMake] Help cmake First project

[Chuck Atkins]

Are these actually C++ files?  If so then they should really have a C++
extension (like .cp or .cxx).  It may be a good idea in general since other
build tools may run in to the same sort of issue of assuming they are C
files.  A few other tips: first, by placing all your source files in a list
variable you can simplify things by operating on the entire list at once
for most commands.  For instance:

set(2PG_SOURCES
  src/LoadConfig.cpp
  ...
  src/random_algorithm.c
)
set_source_files_property(${2PG_SOURCES} PROPERTIES LANGUAGE CXX)
add_library(2PG STATIC ${2PG_SOURCES})

Also, since you're targeting windows as well, This isn't an issue yet but
something to consider:  If you decide to switch to a shared library instead
of static, then you will need to install that as well and shared libs on
windows end up with both a resulting .lib and .dll file.  When installing,
you can instruct CMake to place them in different locations with:

install(TARGETS 2PG_lib protpred-Gromacs-NSGA2 ...
protpred-Gromacs-Sort_Method_Files_by_Front_Dominance
  RUNTIME DESTINATION bin
  LIBRARY DESTINATION lib
  ARCHIVE DESTINATION lib/static
)

This will make sure that all executables and dll's go into the runtime
location, all shared link libraries (.lib) go into the library location,
and all static libraries (also.lib) go into the archive location.

- Chuck


On Mon, Aug 11, 2014 at 4:01 PM, Rodrigo Faccioli 
rodrigo.facci...@gmail.com wrote:

 Hi,

 Angeliki, thanks your comments.

 I used properties because my old makefile was written to use g++ despite
 my files have suffix .c. I understood that cmake tried to compile my files
 using gcc instead of g++.

 I removed my set compiler flags. Moreover, I have finished to compile all
 programs of my project using cmake. My newer CMakeLists.txt is below and
 works fine. Now I will try to compile my project for Visual Studio 10. Any
 tips for this new work, I am thankful.

 cmake_minimum_required(VERSION 2.8)

 # project Information
 project(2pg_cartesian)
 set(PROJECT_VERSION 1.0)


 #Set CXX compiler for all files below
 set_source_files_properties(include/LoadConfig.h PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/protpred-Gromacs-NSGA2.c  PROPERTIES
 LANGUAGE CXX )
 set_source_files_properties(src/protpred-Gromacs-Dominance.c  PROPERTIES
 LANGUAGE CXX )
 set_source_files_properties(src/protpred-Gromacs-Front.c  PROPERTIES
 LANGUAGE CXX )
 set_source_files_properties(src/protpred-Gromacs-MC_Metropolis.c
  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/protpred-Gromacs-Mono.c  PROPERTIES
 LANGUAGE CXX )
 set_source_files_properties(src/protpred-Gromacs-Random_Algorithm.c
  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/protpred-Gromacs-Sort_Method_Files_by_Front_Dominance.c
  PROPERTIES LANGUAGE CXX )
  set_source_files_properties(src/LoadConfig.cpp  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/ea_mono.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/topology.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/pdbio.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/protein.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/futil.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/pdbatom.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/messages.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/topologyio.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/topologylib.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/randomlib.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/vector_math.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/string_owner.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/math_owner.c   PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/osutil.c   PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/load_parameters.c  PROPERTIES LANGUAGE CXX
 )
 set_source_files_properties(src/objective.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/aminoacids.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/aminoacids_io.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/populationio.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/rotation.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/solution.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/gromacs_objectives.c  PROPERTIES LANGUAGE
 CXX )
 set_source_files_properties(src/solutionio.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/algorithms.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/ea_nsga2.c  PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/dominance.c PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/owner_file_analysis.c PROPERTIES LANGUAGE
 CXX )
 set_source_files_properties(src/mc_metropolis.c PROPERTIES LANGUAGE CXX )
 set_source_files_properties(src/random_algorithm.c PROPERTIES 

Re: [CMake] Switching between i386, i586 and i686

[Chuck Atkins]

Hi Amul,

The -march flag doesn't automatically get set by CMake since it tends to be
highly system specific; you'll need to explicitly add it to your
CMAKE_{C,CXX,Fortran}_FLAGS variables if you want it used.  The
CMAKE_SYSTEM_PROCESSOR variable is usually used only for packaging to
determine output file names and in cross compiling.

- Chuck


On Tue, Aug 26, 2014 at 2:23 PM, Amul Shah amul.s...@fisglobal.com wrote:

 My host machine is RedHat 6 i686. I was wondering how I could direct CMake
 to set -march to either i386 or i586 without manually setting -march=. I
 tried changing CMAKE_SYSTEM_PROCESSOR, but that did not work.

 thanks,
 Amul

 _
 The information contained in this message is proprietary and/or
 confidential. If you are not the intended recipient, please: (i) delete the
 message and all copies; (ii) do not disclose, distribute or use the message
 in any manner; and (iii) notify the sender immediately. In addition, please
 be aware that any message addressed to our domain is subject to archiving
 and review by persons other than the intended recipient. Thank you.
 --

 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

-- 

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

Re: [CMake] Autotools-cmake: Are these checks really needed anymore?

[Chuck Atkins]

On Sat, Aug 30, 2014 at 10:30 AM, Rolf Eike Beer e...@sf-mail.de wrote:

  # Checks for typedefs, structures, and compiler characteristics.
  #AC_C_CONST
  #AC_C_INLINE
 ...
  #AC_TYPE_SIZE_T
 ...

 #AC_C_RESTRICT
  #AC_C_VOLATILE


These should be generally safe to assume


 #AC_STRUCT_TM
  #AC_HEADER_TIME


Unless you're targeting embedded systems and / or microcontrollors then you
shouldn't have a problem with these either, even still there's a good
chance you'd have it.


 #AC_TYPE_INT16_T
  #AC_TYPE_INT32_T
  #AC_TYPE_INT64_T
  #AC_TYPE_INT8_T
  #AC_TYPE_UINT16_T
  #AC_TYPE_UINT32_T
  #AC_TYPE_UINT64_T
  #AC_TYPE_UINT8_T

 This is basically is there a usable stdint.h or cstdint. The latter
 you
 will find in newer versions of MSVC and everything else that understands
 recent
 C++, the former in every compiler supporting at least a decent level of
 C99,
 which _excludes_ MSVC for policy reasons that even MS will probably find
 hard
 to explain. So you usually don't check for these types but for the header.


Ugh, this is definitely one of those irritating Windows-isms. cstdint is
guaranteed available in C++11, so if you require that then most of this
goes away. stdint.h, as Rolf mentioned, wasn't available until VS2010, so
if you can place that as a requirement then you're all set. You can
restrict this in your top level cmake with something like this:

if(MSVC_VERSION LESS 1700)
  message(FATAL_ERROR Only Visual C++ 2010 or greater is supported)
endif()

However, if you do have to support older MSVC versions then this is a
problem and you will need to either redefine the types or include your own
stdint.h (bringing the header is usally easier), a commonly used one by
numerous projects for porting unix - windows can be found here:
https://code.google.com/p/msinttypes/source/browse/trunk/stdint.h.
-- 

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

Re: [CMake] Merge VS: Use full path to sources to allow deeper trees with VS = 10 fix to release

[Chuck Atkins]

 The next major release will likely be CMake 3.1 -- and the fix you've
 found will be in that release automatically, as it will be based on
 'master' when it is created.


Related, it should also include support for extended length paths at the
cmake level.  This converts paths to the special
\\?\D:\foo1\...\foo90\...\fooetc.\bar syntax for cmake filesystem commands
like rmdir, delete, etc., which lets Windows operate on paths up to 32k in
length.  It's yet to be tested though as to whether or not the extended
length path syntax can work inside generators.
-- 

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

Re: [CMake] set(a b); set(b c); if(a STREQUAL b OR a STREQUAL c) ...

[Chuck Atkins]

Hi Clark

The expression inside the if statement has it's variables dereferenced
before evaluating and the non-variables are treated as constant
expressions.  In this case, a resolves to b, b resolves to c, and c is
not a variable so it's treated as the constant expression c.  Thus

if(a STREQUAL b OR a STREQUAL c)

gets evaluated as

if( (b STREQUAL c) OR (b STREQUAL c) )

which is clearly false.  Hope that helps.

- 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

Re: [CMake] set(a b); set(b c); if(a STREQUAL b OR a STREQUAL c) ...

[Chuck Atkins]

 But is there a way to check if the value of the variable a equals to b
or c?

Directly:
if(a STREQUAL b OR a STREQUAL c)

But its a bit clumsy.  Better would be to match a regex:
if(a MATCHES ^(b|c)$)
-- 

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

Re: [CMake] set(a b); set(b c); if(a STREQUAL b OR a STREQUAL c) ...

[Chuck Atkins]

  Command `if(a MATCHES ...)` has the same flaw: `if(variable|string
 MATCHES regex)`:
 ..
 set(MYSTRING B)
 set(A MYSTRING)
 if(${A} MATCHES ^MYSTRING$)
   # do *not* go here even A is MYSTRING (use *variable* MYSTRING)
 endif()


This should work without dereferencing A, i.e.:

if(A MATCHES ^MYSTRING$)
  # Bingo
endif()
-- 

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

Re: [CMake] Ctest building with Multiple Processors

[Chuck Atkins]

 Actually my interpretation of the manual says that the _tests_ will be run
 in parallel. What I want is the _Build_ to be run in parallel.


Indeed that is just the parallel test execution.  Parallel build is usually
generator specific, controlled through CTEST_BUILD_FLAGS.  For example: if
you're using Unix Makefiles:

...
set(CTEST_SITE wopr.kitwarein.com)
set(CTEST_BUILD_NAME Fedora20_Intel-2013-SP1-U3)
set(CTEST_BUILD_CONFIGURATION Release)
set(CTEST_CMAKE_GENERATOR Unix Makefiles)
*set(CTEST_BUILD_FLAGS -j8)*
...

This will call make -j8 for the build instead of just make.  If using
the ninja generator, the build will be parallel by default, or you can
specify a -j flag to override that number.  Visual Studio gets a bit
tricky though since you can paralleling at both the target and file level
so if not careful, you can end up with N^2 build processes.  What generator
are you using?
-- 

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

Re: [CMake] Ctest building with Multiple Processors

[Chuck Atkins]

The easiest option with visual studio is to use the /mp compiler flag by
setting it in the CFLAGS and CXXFLAGS environment variables in your ctest
script.  This will parallelize each target across all CPUs.  Target-level
parallelism may or may not also happen since that's dependent on your local
configuration and VS version; Older versions used devenv.exe to drive the
build, in which case it's target-level parallelism is only configurable
through the IDE, where as newer VS versions can be driven with MSBuild
directly and use the /maxcpucount:N switch in the CTEST_BUILD_FLAGS.

Unfortunately on Windows and VS builds there's not really a simple answer.

- Chuck


On Fri, Sep 5, 2014 at 11:09 AM, Michael Jackson 
mike.jack...@bluequartz.net wrote:

 What generator? All of them of course. I am trying to setup our build
 bots on several environments including OS X, Linux and Windows. I have
 ninja built and installed on the Windows machine. I would _prefer_ to use
 Visual Studio and ninja so that we have a sanity check to make sure both
 types of project files can be built correctly, configured, build and the
 software packaged. We are eventually going to try to get nightlies of our
 software going also.

 Thanks
 Mike Jackson
 dream3d.bluequartz.net
 github.com/dream3d/dream3d

 On Sep 5, 2014, at 9:33 AM, Chuck Atkins chuck.atk...@kitware.com wrote:

 
  Actually my interpretation of the manual says that the _tests_ will be
 run in parallel. What I want is the _Build_ to be run in parallel.
 
  Indeed that is just the parallel test execution.  Parallel build is
 usually generator specific, controlled through CTEST_BUILD_FLAGS.  For
 example: if you're using Unix Makefiles:
 
  ...
  set(CTEST_SITE wopr.kitwarein.com)
  set(CTEST_BUILD_NAME Fedora20_Intel-2013-SP1-U3)
  set(CTEST_BUILD_CONFIGURATION Release)
  set(CTEST_CMAKE_GENERATOR Unix Makefiles)
  set(CTEST_BUILD_FLAGS -j8)
  ...
 
  This will call make -j8 for the build instead of just make.  If
 using the ninja generator, the build will be parallel by default, or you
 can specify a -j flag to override that number.  Visual Studio gets a bit
 tricky though since you can paralleling at both the target and file level
 so if not careful, you can end up with N^2 build processes.  What generator
 are you using?
  --
 
  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

 --

 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

-- 

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

Re: [CMake] Link step more than once

[Chuck Atkins]

Sounds like what you want is an object library,
http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library:

set(FOO_SOURCES
  Foo1.cxx
  Bar2.cxx
  FooBar3.cxx
)
add_library(FooObjLib OBJECT ${FOO_SOURCES})

add_executable(A $TARGET_OBJECTS:FooObjLib)
set_target_properties(A PROPERTIES LINK_FLAGS /Special /Flags /For /A)

add_executable(B $TARGET_OBJECTS:FooObjLib)
set_target_properties(B PROPERTIES LINK_FLAGS /Special /Flags /For /B)


- Chuck

On Thu, Sep 11, 2014 at 2:09 PM, fungos fun...@gmail.com wrote:

 Ok, but will this _recompile_ the sources for each target? We must use the
 same generated object files for the two outputs, the only difference must
 be the linker flags.

 On Thu, Sep 11, 2014 at 1:20 PM, Robert Maynard 
 robert.mayn...@kitware.com wrote:

 Generally the easiest way is to have two targets that share the same
 source files but have different linker flags.

 On Thu, Sep 11, 2014 at 12:53 PM, fungos fun...@gmail.com wrote:
  Yes, we can say that.. in reality I need two outputs for a single
 target,
  but these outputs are generated almost exactly with just 2 different
 linker
  flags removed.
 
 
  On Thu, Sep 11, 2014 at 11:31 AM, Robert Maynard
  robert.mayn...@kitware.com wrote:
 
  Are you trying to generate two different libraries from the same
 target?
 
  On Thu, Sep 11, 2014 at 10:45 AM, fungos fun...@gmail.com wrote:
   Hi,
  
   How can I create two linker steps with different flags for the same
   target
   at the same build?
  
   Example:
  
 target: X
   link: linker.exe libs_for_a linker_flags_for_a -o A/X.bin
   link: linker.exe libs_for_b linker_flags_for_b -o B/X.bin
  
   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
 
 
 
 
  --
  Animal Liberation Front
  http://www.animal-liberation.com/




 --
 Animal Liberation Front
 http://www.animal-liberation.com/

 --

 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

-- 

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

Re: [CMake] FW: Parallel GNU make issue

[Chuck Atkins]

Hi Gary,

Do you see either of these two warning messages show up:

warning: -jN forced in submake: disabling jobserver mode.
or
warning: jobserver unavailable: using -j1. Add `+' to parent make rule.

These warnings often accompany the forced serialization of a parallel make
build, although usually they show up regardless of the launch method, i.e.
ctests vs manual make.  These warnings are often indicative of a particular
problem in super-build scenarios..

- Chuck

On Thu, Sep 11, 2014 at 2:29 PM, Hennigan, Gary L glhe...@sandia.gov
wrote:

  I have a strange, and very frustrating, problem. I have a pretty large
 piece of software that I build nightly as part of regression testing of my
 own software. All of the software uses CMake and I use a ctest script, via
 “ctest –S [script file]”, for my nightly regression testing . As I stated,
 this is a pretty large collection of software but during development it’s
 not a huge issue because the build is quite parallelizable via GNU make’s
 “-j N” option. On my nightly test platform, a 64-core machine, I can build
 the whole thing in about an hour.  A nice manageable amount of time for a
 nightly regression test. Unfortunately when I run the build process via
 ctest something is causing the parallel make to fail and I’m lucky if the
 build takes under 15 hours. Barely practical for a nightly test.

 I’m not sure how to find out what’s going on. After the ctest build I can
 go into the build directory, do a “make clean” and then a “make –j 12”, for
 example, and the build flies. Of course I can build the software entirely
 outside of ctest and it too flies. Only when the build happens as part of
 ctest does it seem to revert to, essentially, a “make –j 1” and slow to a
 crawl.

 I can look at the process tree, via “ps –ef”, during the ctest build and I
 see the root invocation of gmake and it’s fine. For example, it typically
 looks something like:

   PID  PPID  C STIME TTY  TIME CMD
  6141  6283 96 11:41 pts/000:24:40 ctest -VV -S ctest_nightly.cmake
 -DPROCESSORCOUNT=12
  8032  6141  0 11:42 pts/000:00:00 /usr/bin/gmake -i *-j 12*
  8035  8032  0 11:42 pts/000:00:00 /usr/bin/gmake -f
 CMakeFiles/Makefile2 all
   851  8035  0 11:52 pts/000:00:00 /usr/bin/gmake -f
 packages/ml/src/CMakeFiles/ml.dir/build.make
 27797  8035  0 11:46 pts/000:00:00 /usr/bin/gmake -f
 packages/moocho/src/CMakeFiles/moocho.dir/build.make

 You can see that the parent make, PID 8032 which is started via ctest (PID
 6141), has the appropriate flag, “-j 12”, but at this point in the build
 it’s compiling one file at a time. Another odd thing is that I think the
 build starts out fine, invoking multiple file compilations simultaneously,
 but after a couple of minutes it reverts to essentially the “make –j 1”
 behavior. It’s like the GNU make jobserver is failing, but I’m not getting
 any error messages from GNU make to that affect.

 If anyone has any suggestions on how I can figure this out I’d appreciate
 it.

 Apologies for the lengthy explanation. I’ve been pulling my hair out
 trying to figure out how to solve this issue.

 Thanks in advance,
 Gary



 --

 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

-- 

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

Re: [CMake] Specifying different compilers for subsets of a project

[Chuck Atkins]

Hi George,


 The obvious way to compile front-end tools is to create another directory,
 e.g., front-end-build and run cmake therein to re-configure and build
 with a front-end compiler.


 However, since only a relatively small subset of the files needs to be
 compiled for the front-end, it is desirable to do this within the same build


This is a common case that occurs when cross compiling where certain
targets are used to generate files used in the rest of the build.  Using
different build directories is the typical way, but you can reduce the host
build as much a possible by creating a BuildTools or CrossTools custom
target with depends only on the targets needing to be build on the host
system. This way, you can build only the subset needed on the host and in
the cross-build, just point the host build directory.  This is how both VTK
and ParaView do it.

Trying to specify multiple compilers isn't so straight forward.  Consider
the entire platform that goes in to cross compiling: you have the entire
build toolset, but then you also have the entire find infrastructure that
needs to look in different places for includes and libraries.  There's an
entire stack of variables, tools, and settings that are needed to build on
a given platform and you would basically need a whole duplicate set
generated from a secondary configure run to make it work in the general
case.  This is what is effectively happening anyways in the two-builds
scenario.

- 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

Re: [CMake] FIND_PATH() search custom path first

[Chuck Atkins]

Hi George, Jakub,


   NO_DEFAULT_PATH

   NO_CMAKE_ENVIRONMENT_PATH

   NO_CMAKE_PATH

   NO_SYSTEM_ENVIRONMENT_PATH

   NO_CMAKE_SYSTEM_PATH


The options specified are redundant.  NO_DEFAULT_PATH implies the later 4.
If you just specify NO_DEFAULT_PATH then only HINTS and user guess paths
(those specified by the PATH argument) will be checked.



NO_CMAKE_FIND_ROOT_PATH


This is specific to cross compiling, and usually isn't needed unless that's
your situation.

A particularly effective and commonly used pattern is to build up the
options to the find call in a variable.  The FindBoost module does this
very thing to restrict it's component search to all the same directory.
The idea is that if you have a specific location that you know your file
should be found in when set, then something like this could work:

set(FOO_FIND_OPTS)
if(FOO_DIR)
  set(FOO_FIND_OPTS HINTS ${FOO_DIR} NO_DEFAULT_PATH
NO_CMAKE_FIND_ROOT_PATH)
endif()
find_library(FOO_LIBRARY MyFooLib ${FOO_FIND_OPTS})

This way, if FOO_DIR is set, then it will only look there.  However, if
it's not, then FOO_FIND_OPTS is empty and the standard search will happen.

- 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

Re: [CMake] find_package

[Chuck Atkins]

Hi Matt,

1) (... set boost_root ...)
 2) FIND_PACKAGE(Boost 1.57 COMPONENTS log thread filesystem system)


If you're using CMake = 3.0, then there's a Boost_NAMESPACE variable you
can set that will cause the find module look for mangled library names line
myboostnamespace_datetime instead of boost_datetime.  You can generate a
source tree with an alternate namespace using the boost bcp tool.  I know
that doesn't seem to be your issue at the moment but it could help in
making sure your system boost doesn't get found.



 3) (... build boost if it Boost_FOUND is 0)


Unrelated to your issue, but in general, when testing boolean variables in
CMake, it's best to treat them as a true/false value instead of integers or
strings.  So instead of if(Boost_FOUND EQUAL 0), use if(NOT
Boost_FOUND).  The reasoning is that there are many different ways to
create true/false boolean values in cmake. For example, a false boolean
value can be represented as NO, 0, FALSE, OFF, , etc. By just letting the
variable act as a boolean, it streamlines the code needing to deal with it.



 4) FIND_PACKAGE(Boost 1.57 REQUIRED COMPONENTS log thread filesystem
 system)


From what I can tell, it doesn't look like you set an updated BOOST_ROOT to
the install prefix of the newly built boost, i.e. ${APT_BOOST_BIN}.
Without that, it's just going to look in the same places as before.

Also try setting Boost_DEBUG=ON before the find package calls.  This will
output some additional debugging information for the find module regarding
what and where it's actually searching for.
-- 

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

Re: [CMake] Linking error after having found a package

[Chuck Atkins]

Hi Cedric,

FIND_PACKAGE(BLAS)
 FIND_PACKAGE(LAPACK)

 # I should test with BLAS_FOUND and LAPACK_FOUND here but that's not the
 problem


If they're actually required then you can skip the additional check by
calling:

FIND_PACKAGE(BLAS REQUIRED)
FIND_PACKAGE(LAPACK REQUIRED)

This will cause the configure step to fail if not found


LIST(GET BLAS_LIBRARIES 0 BLAS_LIB)
 LIST(GET LAPACK_LIBRARIES 0 LAPACK_LIB)

...
 As explained in FindBLAS.cmake and Find.LAPACK.cmake, BLAS_LIBRARIES and
 LAPACK_LIBRARIES are lists containing paths to these libraries.
 I get the first entry in each of these lists and try to link with these
 entries (/usr/lib/libf77blas.so, /usr/lib/liblapack.so).


You really should be using the _LIBRARIES variables instead it contains the
link dependencies as well.  For shared libraries, this is less of an issue
since the dependencies  will transitively propogate accordingly, but if you
want to link it statically, then you'll need those extra libraries.
Basically, the FOO_LIBRARIES variable should be used as is, if possible,
for FIND_PACKAGE(FOO)


TARGET_LINK_LIBRARY(myexe ${LAPACK_LIB}$ ${BLAS_LIB}$)


As Eric already pointed out, the extra trailing $ needs to go

- 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

Re: [CMake] Changes to CMAKE_CXX_FLAGS_RELEASE not reflected in GUI

[Chuck Atkins]

 Is this the intended behavior?


Yes.  The GUI is essentially an editor for the CMake cache.  These
variables are persistent with global scope.  As such, only the cache values
are reflected in the GUI.  When you set the CMAKE_CXX_FLAGS_RELEASE with
this form of the set command, you are changing it's value in the current
scope, but not in the cache, hence no updated value in the GUI.



 Is there a way to specify additional
 release build flags in CMakeLists.txt and have them reflected in the
 GUI?


You can update the cache entry with the alternate signature for set:

set(CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} -xHost CACHE
STRING Flags used by the compiler during release builds. FORCE)

The FORCE option is necessary to change an existing cache entry.  See
details for setting cache values here:
http://www.cmake.org/cmake/help/v3.3/command/set.html


Thank you for your recommendations!


You're welcome :-)

- 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

Re: [CMake] linking hared libraries

[Chuck Atkins]

>
> On Mon, Oct 19, 2015 at 8:43 PM, Owen Alanzo Hogarth
>  wrote:
> > Also you said the PROJECT() should only be defined once, but shouldn't
> each
> > cmakelists.txt contain a project() or else cmake complains at me.
>
>
> According to the last paragraph of:
>
> https://cmake.org/cmake/help/v3.0/command/project.html
>
> you only need a PROJECT () in the top-level CMakeLists.txt...
>

While this is true, you only need it called once at the top level, there
are use cases where you see multiple calls to project() in aa given tree.
Usually this is in the case of adding independent third party libraries.
For example, imagine a source tree like:

/CMakeLists.txt
/src/CMakeLists.txt
/src/file1.cxx
/src/file2.cxx
/thirdparty/CMakeLists.txt
/thirdparty/libfoo/CMakeLists.txt
/thirdparty/libfoo/foo.h
/thirdparty/libfoo/foo.cxx
/thirdparty/libbar/CMakeLists.txt
/thirdparty/libbar/bar.h
/thirdparty/libbar/bar.cxx

Here, you may have project() called in /CMakeLists.txt,
/thirdparty/libfoo/CMakeLists.txt, and /thirdparty/libbar/CMakeLists.txt.
This would mean that libfoo and libbar are are independent projects that
can be built on their own, outside of the top level project.  This is
generally discouraged nowadays and is replaced by using ExternalProject but
prior to that module it was a common way to create a "superbuild" of many
CMake-based dependencies.  You still see it's use in many projects that
have been around a long time, i.e. VTK, ITK, etc.  It's even how CMake
itself manages building it's own version of it's dependencies (liblzma,
libcurl, libarchive, etc.).
-- 

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

Re: [CMake] No-op command?

[Chuck Atkins]

>
> if(CMAKE_SYSTEM_NAME STREQUAL "Windows")
>> else()
>>... do something ...
>> endif()
>>
>
While you may need the empty if condition for something else, in this use
case specifically you could just as easily avoid the empty conditional
block and negate the expression with:

if(NOT CMAKE_SYSTEM_NAME MATCHES "Windows")
  ... do something ...
endif()

- 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

Re: [CMake] CMake + MPI

[Chuck Atkins]

>
> The only exception to that (which I am aware of) is if you are on a CRAY
> system where the MPI (and BLAS and LAPACK) are baked into the compiler
> wrappers (cc, ftn, etc). In those situations, you actually do not want to
> run find_package(MPI) or it will throw errors.
>

Not true.  The FindMPI.cmake module performs the appropriate introspection
to check if your primary compiler wraps accordingly.  For example, on a
Cray XC30, with the PrgEnv-pgi and cray-mpich modules loaded:

p02064@swan:~/Code/tmp/build> cat ../source/CMakeLists.txt
cmake_minimum_required(VERSION 3.3)
project(TestMPI C CXX)

find_package(MPI REQUIRED)

add_executable(test-mpi-c test-mpi.c)
target_include_directories(test-mpi-c PRIVATE ${MPI_C_INCLUDE_PATH})
target_link_libraries(test-mpi-c ${MPI_C_LIBRARIES})

add_executable(test-mpi-cxx test-mpi.cxx)
target_include_directories(test-mpi-cxx PRIVATE ${MPI_CXX_INCLUDE_PATH})
target_link_libraries(test-mpi-cxx ${MPI_CXX_LIBRARIES})
p02064@swan:~/Code/tmp/build>

p02064@swan:~/Code/tmp/build> cmake ../source
-- The C compiler identification is PGI 15.7.0
-- The CXX compiler identification is PGI 15.7.0
-- Check for working C compiler: /opt/cray/craype/2.4.1/bin/cc
-- Check for working C compiler: /opt/cray/craype/2.4.1/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /opt/cray/craype/2.4.1/bin/CC
-- Check for working CXX compiler: /opt/cray/craype/2.4.1/bin/CC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found MPI_C: /opt/cray/craype/2.4.1/bin/cc
-- Found MPI_CXX: /opt/cray/craype/2.4.1/bin/CC
-- Configuring done
-- Generating done
-- Build files have been written to: /home/users/p02064/Code/tmp/build
p02064@swan:~/Code/tmp/build>

p02064@swan:~/Code/tmp/build> grep '^MPI_.*' CMakeCache.txt | grep -v
INTERNAL
MPI_CXX_COMPILER:STRING=/opt/cray/craype/2.4.1/bin/CC
MPI_CXX_COMPILE_FLAGS:STRING=
MPI_CXX_INCLUDE_PATH:STRING=
MPI_CXX_LIBRARIES:STRING=
MPI_CXX_LINK_FLAGS:STRING=
MPI_CXX_NO_INTERROGATE:STRING=/opt/cray/craype/2.4.1/bin/CC
MPI_C_COMPILER:STRING=/opt/cray/craype/2.4.1/bin/cc
MPI_C_COMPILE_FLAGS:STRING=
MPI_C_INCLUDE_PATH:STRING=
MPI_C_LIBRARIES:STRING=
MPI_C_LINK_FLAGS:STRING=
MPI_C_NO_INTERROGATE:STRING=/opt/cray/craype/2.4.1/bin/cc
MPI_EXTRA_LIBRARY:STRING=MPI_EXTRA_LIBRARY-NOTFOUND
MPI_LIBRARY:FILEPATH=MPI_LIBRARY-NOTFOUND
p02064@swan:~/Code/tmp/build>

p02064@swan:~/Code/tmp/build> make
[ 25%] Building C object CMakeFiles/test-mpi-c.dir/test-mpi.c.o
[ 50%] Linking C executable test-mpi-c
[ 50%] Built target test-mpi-c
[ 75%] Building CXX object CMakeFiles/test-mpi-cxx.dir/test-mpi.cxx.o
[100%] Linking CXX executable test-mpi-cxx
[100%] Built target test-mpi-cxx
p02064@swan:~/Code/tmp/build>

As you can see from the resulting cache, the FindMPI module knows how to
act accordingly even when mpi libraries are folded into the regular
compiler.
-- 

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

Re: [CMake] Is there a way to disable adding extra libraries at the end of a link line?

[Chuck Atkins]

The error itself I believe is a side effect of CMake trying to operate
assuming it's using normal Linux, which makes some assumptions regarding
shared runtime libraries for libc, position independent code, etc.  The
default behaviour of the Cray compiler wrappers, however, is to create
fully static executables, which CMake has a bit of difficulty with using
the defaault Linux platform.  This behaviour of the wrappers can be changed
by setting the env var CRAYPE_LINK_TYPE=dynamic, but really the right way
is to use the CrayLinuxEnvironment platform file which puts CMake into
cross-compiling mode for the Cray-specific link environment instead of
generic Linux and tests for static, shared, implicit link and include dirs,
implicit libraries, etc.

- Chuck

On Fri, Dec 18, 2015 at 11:12 AM, JR Cary  wrote:

> Working on a just delivered Cray I am again challenged by the way that
> CMake adds libraries to the end of the link line that I did not specify.
>
> The Cray requires use of the compiler wrappers.  After adding the
> appropriate libraries (hdf5, z) to my target, the link line is
>
> /opt/cray/craype/2.4.2/bin/CC   -DMPICH_IGNORE_CXX_SEEK -std=c++11 -O3
> -DNDEBUG -msse2   CMakeFiles/io.dir/io.cxx.o  -o io
> -L/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib  ../libtxio.a
> ../../txstreams/libtxstreams.a
> /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a -Wl,-Bstatic -lz
> -Wl,-Bdynamic /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a
> -Wl,-Bstatic -lz -Wl,-Bdynamic
> -Wl,-rpath,/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib
>
> and the link fails with
>
> ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in
> `/usr/lib/../lib64/libc.a(strcmp.o)' can not be used when making an
> executable; recompile with -fPIE and relink with -pie
>
> Now I believe that Cray has the appropriate libraries in its compiler
> wrapper, because
> if I just link without all the additions:
>
> /opt/cray/craype/2.4.2/bin/CC   -DMPICH_IGNORE_CXX_SEEK -std=c++11 -O3
> -DNDEBUG -msse2   CMakeFiles/io.dir/io.cxx.o  -o io
> -L/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib  ../libtxio.a
> ../../txstreams/libtxstreams.a
> /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a  -lz
>
> it all just works.
>
> Is there a way to tell cmake not to append
> "-Wl,-Bdynamic /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a
> -Wl,-Bstatic -lz -Wl,-Bdynamic
> -Wl,-rpath,/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib"
> to the link line and not to insert -Wl,-Bstatic in front of -lz
> ?
>
> ThxJohn Cary
>
> --
>
> 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
>
-- 

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

Re: [CMake] add_custom_command, POST_BUILD

[Chuck Atkins]

Could you just make the tests run in the post-build of the test?

add_library(Foo Foo.cxx)

add_executable(FooTest FooTest.cxx)
target_link_libraries(FooTest Foo)

add_custom_command(TARGET FooTest POST_BUILD
  COMMAND $ $
)

That way the the test is run as part of it's build.


- Chuck

On Wed, Jun 1, 2016 at 11:46 AM, Vladimir Chebotarev <
vladimir.chebota...@gmail.com> wrote:

> Hi there.
>
> At the moment one can add a command executing after a build of a target
> using:
> add_custom_command(... POST_BUILD...)
>
> However if the command have a dependencies which build after the target,
> there is practically no way to specify it.
>
> Simple case: we have a library and tests for it. E.g. I want them to run
> in POST_BUILD of a library. But, tests already depends on the library so I
> can't make them built before it.
>
> There are few possible solutions to that:
> 1) add possibility to set dependencies for add_custom_command in
> POST_BUILD mode;
> 2) add possibility to populate list of targets if we have specified ones
> in list.
>
> Or maybe correct me if I miss something.
>
> Kind regards, Vladimir.
>
> --
>
> 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
>
-- 

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

Re: [CMake] How do you handle recursive dependencies in CMake

[Chuck Atkins]

If the projects are each providing their own Config.cmake file then you
probably will want to use those instead of Find modules.  Instead of using
the Foo_Bar_LIBRARIES variable though, try using the actual imported
targets from the config files.  Those should have the appropriate
dependency information. If you're not sure what they are you should be able
to dig through the provided Config.cmake and Targets.cmake files for FooBar
and see which targets are created bu "add_library(FooBar::Foo ...
IMPORTED)".

- Chuck

On Wed, Jun 8, 2016 at 11:31 AM, Sven Baars <s.ba...@rug.nl> wrote:

> In my case all projects provide their own FooBarConfig.cmake, but not a
> FindFooBar.cmake. For this reason I wanted to use those, because I thought
> it saves me the effort of writing a lot of FindFooBar.cmake files, and it
> also seemed like the right way to do it, because it provides things like
> FooBar_LIBRARIES, which is what I need. The reason I said that I create my
> own FooBarConfig.cmake, is because I want to use CMake properly in my own
> project, so I also want to provide a FoorBarConfig.cmake file for my users.
> So even if the projects I use don't do everything properly, I still want to
> do it properly myself. The problem in this case is that I'm not sure what
> the proper way is. If the FoorBarConfig.cmake file is not enough to handle
> the dependencies I encounter, should I provide a FindFooBar.cmake file or
> something, instead of just the FooBarConfig.cmake? And meanwhile also write
> a FindFooBar.cmake file for all my dependencies?
>
> Another reason why this seems odd to me, is because if N different
> projects use FooBar, then also possibly N different versions of
> FindFooBar.cmake are created by all the different projects (I have actually
> already seen this a lot). That is the case, because the FindFooBar.cmake
> file is not provided by the FooBar project, unlike the FooBarConfig.cmake.
>
> Cheers,
> Sven
>
>
> On 06/08/2016 03:11 PM, Chuck Atkins wrote:
>
> The FooBarConfig.cmake is something that should be generated by FooBar's
> build.   The reason you don't get absolute paths for the "libraries" from a
> package config file is that they're not actually libraries but imported
> targets.  The imported target let's you treat "foo" as though it were a
> library built by your project.  It then has the appropriate target
> properties set on it ti define the full path to it's library, etc.  That
> being said, if you're manually creating the FooBarConfig.cmake that's not
> really the right approach.  If the FooBar buil;d doesn't actually generate
> it's own FooBarConfig.cmake file then you'll want to create you're own
> FindFooBar.cmake.  A bare bones find module that creates an imported target
> would look something like this:
>
> if(NOT FooBar_FOUND AND NOT TARGET FooBar::FooBar)
>   find_path(FooBar_INCLUDE_DIR FooBar.h)
>   find_library(FooBar_LIBRARY FooBar)
>
>   include(FindPackageHandleStandardArgs)
>   find_package_handle_standard_args(FooBar
> FOUND_VAR FooBar_FOUND
> REQUIRED_VARS FooBar_INCLUDE_DIR FooBar_LIBRARY
>   )
> endif()
>
> if(FooBar_FOUND AND NOT TARGET FooBar::FooBar)
>   add_library(FooBar::FooBar UNKNOWN IMPORTED)
>   set_target_properties(FooBar::FooBar PROPERTIES
> IMPORTED_LOCATION ${FooBar_LIBRARY}
> INTERFACE_INCLUDE_DIRECTORIES ${FooBar_INCLUDE_DIR}
>   )
> endif()
>
> Then in your project you can use:
>
> find_package(FooBar)
> add_library(MyLib supercoolfiles.cxx)
> target_libkLibraries(MyLib FooBar::FooBar)
>
> Where this starts to get really helpful in your situation is if you have
> an imported target for A, B, and C, then you can create the appropriate
> dependencies.  Say, for example, you have a FindA.cmake that follows the
> pattern above and generates an A::A target.  Then in your FindB.cmake you
> can have:
>
> if(NOT B_FOUND AND NOT TARGET B::B)
>   find_path(B_INCLUDE_DIR B.h)
>   find_library(B_LIBRARY B)
>
>   include(FindPackageHandleStandardArgs)
>   find_package_handle_standard_args(B
> FOUND_VAR B_FOUND
> REQUIRED_VARS B_INCLUDE_DIR B_LIBRARY
>   )
>
>
>
>
> *  find_package(A QUIET)   if(A_FOUND) set(B_Extra_Deps A::A)
> endif()*
> endif()
>
> if(B_FOUND AND NOT TARGET B::B)
>   add_library(B::B UNKNOWN IMPORTED)
>   set_target_properties(B::B PROPERTIES
> IMPORTED_LOCATION ${B_LIBRARY}
> INTERFACE_INCLUDE_DIRECTORIES ${B_INCLUDE_DIR}
>   )
>
>
>
>
> *  if(B_Extra_Deps) set_target_properties(B::B PROPERTIES
> INTERFACE_LINK_LIBRARIES ${B_Extra_Deps} )   endif()*
> endif()
>
> and similarly for FindC.cmake.  Since A::A, B::B, and C::C are actual
> proper CMake targe

Re: [CMake] How do you handle recursive dependencies in CMake

[Chuck Atkins]

The FooBarConfig.cmake is something that should be generated by FooBar's
build.   The reason you don't get absolute paths for the "libraries" from a
package config file is that they're not actually libraries but imported
targets.  The imported target let's you treat "foo" as though it were a
library built by your project.  It then has the appropriate target
properties set on it ti define the full path to it's library, etc.  That
being said, if you're manually creating the FooBarConfig.cmake that's not
really the right approach.  If the FooBar buil;d doesn't actually generate
it's own FooBarConfig.cmake file then you'll want to create you're own
FindFooBar.cmake.  A bare bones find module that creates an imported target
would look something like this:

if(NOT FooBar_FOUND AND NOT TARGET FooBar::FooBar)
  find_path(FooBar_INCLUDE_DIR FooBar.h)
  find_library(FooBar_LIBRARY FooBar)

  include(FindPackageHandleStandardArgs)
  find_package_handle_standard_args(FooBar
FOUND_VAR FooBar_FOUND
REQUIRED_VARS FooBar_INCLUDE_DIR FooBar_LIBRARY
  )
endif()

if(FooBar_FOUND AND NOT TARGET FooBar::FooBar)
  add_library(FooBar::FooBar UNKNOWN IMPORTED)
  set_target_properties(FooBar::FooBar PROPERTIES
IMPORTED_LOCATION ${FooBar_LIBRARY}
INTERFACE_INCLUDE_DIRECTORIES ${FooBar_INCLUDE_DIR}
  )
endif()

Then in your project you can use:

find_package(FooBar)
add_library(MyLib supercoolfiles.cxx)
target_libkLibraries(MyLib FooBar::FooBar)

Where this starts to get really helpful in your situation is if you have an
imported target for A, B, and C, then you can create the appropriate
dependencies.  Say, for example, you have a FindA.cmake that follows the
pattern above and generates an A::A target.  Then in your FindB.cmake you
can have:

if(NOT B_FOUND AND NOT TARGET B::B)
  find_path(B_INCLUDE_DIR B.h)
  find_library(B_LIBRARY B)

  include(FindPackageHandleStandardArgs)
  find_package_handle_standard_args(B
FOUND_VAR B_FOUND
REQUIRED_VARS B_INCLUDE_DIR B_LIBRARY
  )




*  find_package(A QUIET)  if(A_FOUND)set(B_Extra_Deps A::A)  endif()*
endif()

if(B_FOUND AND NOT TARGET B::B)
  add_library(B::B UNKNOWN IMPORTED)
  set_target_properties(B::B PROPERTIES
IMPORTED_LOCATION ${B_LIBRARY}
INTERFACE_INCLUDE_DIRECTORIES ${B_INCLUDE_DIR}
  )




*  if(B_Extra_Deps)set_target_properties(B::B PROPERTIES
INTERFACE_LINK_LIBRARIES ${B_Extra_Deps})  endif()*
endif()

and similarly for FindC.cmake.  Since A::A, B::B, and C::C are actual
proper CMake targets and not just library files then they carry with them
associated target dependency information.  In CMake vernacular we refer
this as "target usage requirements" since the target caries with it all the
necessary information for something to actually use it, whether that's just
extra link libraries or also extra include directories and compile
definitions needed.  The Package::Target naming convention is the idea that
each package has it's own namespace where you may define multiple targets.
-- 

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

Re: [CMake] Provide configuration settings for users

[Chuck Atkins]

Hi Cedric,

It sounds like creating a package config file is exactly what you need.
When installed, a user will be able to consume your project with
"find_package(Foo)".  That will locate and read the package config file
which will create an imported target Foo::Foo.  This imported target will
cary with it all of the necessary link dependency information.

See https://cmake.org/cmake/help/v3.6/manual/cmake-packages.7.html for more
details.

- Chuck

On Tue, Jun 14, 2016 at 6:28 AM, Cedric Doucet 
wrote:

>
> Hello,
>
> is there a native way to provide configuration settings for the users of a
> software?
>
> For example, I develop a software which depends on several 3rd party
> libraries which are automatically downloaded and installed with the
> ExternalProject module.
> My CMake configuration scripts are written so as to handle these 3rd party
> libraries.
> During installation of the software, header files and libraries are copied
> to the destination directory but (of course) without their 3rd party
> dependencies.
>
> Therefore, if a user wants to use my software, he has to handle these 3rd
> party libraries during compilation and linking steps.
> Depending on the skills of the user, it may be difficult to achieve it.
>
> I would like to know if there exists a native way of providing sufficient
> configuration information so that users do not have to handle these
> libraries.
> For the moment, I provide a CMakeLists template but I wonder if it's the
> best possible solution.
>
> Best regards,
>
> Cédric Doucet
>
> --
>
> 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
>
-- 

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

Re: [CMake] cpack ppc64le rhel7.2 CPACK_RPM_PACKAGE_ARCHITECTURE

[Chuck Atkins]

I was able to verify, btw, that Fedora 19 + Power8 outputs ppc64le for
uname -m so I assume it works correctly on EL7 as well.  Testead via an IBM
machine hosted at the OSU Open Source Lab that we can access and use for
testing.

- Chuck

On Wed, Jun 8, 2016 at 10:33 AM, M Kelly  wrote:

> Domen Vrankar  writes:
>
> >
> > > The strange thing is that CMAKE_HOST_SYSTEM_PROCESSOR (outputed by
> cmake
> > > --system-information) uses the same "uname -m"
> > > see Modules/CMakeDetermineSystem.cmake.
> > >
> > > So there is something odd to have one right and the other wrong...
> >
> > In that case it's quite possible that CPACK_RPM_PACKAGE_ARCHITECTURE
> > is already set to x86_64 somewhere in cmake list which overrides the
> > default.
> >
> > Regards,
> > Domen
>
> Hi,
>
> I do think somewhere we are forcing CPACK_RPM_PACKAGE_ARCHITECTURE to
> x86_64
> I will find that and fix.
>
> thanks,
> mark
>
>
> --
>
> 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
>
-- 

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

Re: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug

[Chuck Atkins]

>
>[eschnigma@manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug"
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
>

This is definitely the reason for no debug symbols.  If the compiler is
unknown then CMake won't know the right flags to pass to generate debug
info.  The more important question though is why the compiler can't be
identified.  What compiler is being used?  Can check with /usr/bin/c++
--version ?
-- 

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

Re: [CMake] No debugging symbols found when using -DCMAKE_BUILD_TYPE=Debug

[Chuck Atkins]

Interesting.  It seems CMake is having trouble identifying GCC in 6.1.1.
Do you have a 5.x compiler available?  If so does it work with that?  That
would help narrow it down to a gcc6 issue vs something about how Manjaro
packages compilers.

- Chuck

On Wed, Jun 1, 2016 at 10:49 AM, Esch Nigma <eschni...@openmailbox.org>
wrote:

> The standard choice is c++
>
>
>
> [eschnigma@manjaro ~]$ c++ --version
> c++ (GCC) 6.1.1 20160501
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> But I've tried enforcing g++ as such:
>
>
>
> -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc
> -DCMAKE_CXX_COMPILER:STRING=/usr/bin/g++
>
>
>
> And that has the same results.
>
>
>
> Version:
>
>
>
> [eschnigma@manjaro ~]$ g++ --version
> g++ (GCC) 6.1.1 20160501
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> On Wednesday, June 1, 2016 10:05:21 AM EEST Chuck Atkins wrote:
>
>[eschnigma@manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug"
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
>
>
> This is definitely the reason for no debug symbols.  If the compiler is
> unknown then CMake won't know the right flags to pass to generate debug
> info.  The more important question though is why the compiler can't be
> identified.  What compiler is being used?  Can check with /usr/bin/c++
> --version ?
>
>
>
-- 

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

Re: [CMake] How to hundle gcc link options(like whole-archive, --allow-multiple-definition) in CMake？

[Chuck Atkins]

Hi Chao,

You want to let CMake to as much of the work for you as possible.  You're
still trying to explicitly pass the path to the library file to
target_link_libraries.  If you look at the line:

target_link_library(exe1 "-Wl, --whole-archive ../sub_dir1/liblib1.a
--no-whole-archive")

there's no CMake target name so CMake can't know about the dependency.
However, if you use the target name instead:

top_dir/CMakeLists.txt:
cmake_minimum_required(VERSION 3.0)
project(foo)
add_subdirectory(sub_dir2)
add_subdirectory(sub_dir1)

top_dir/sub_dir1/CMakeLists.txt
add_library(L1 1.c)

top_dit/sub_dir2/CMakeLists.txt
add_executable(exe1 main.c)
target_link_libraries(exe1 "-Wl,--whole-archive" *L1*
"-Wl,--no-whole-archive")

Notice how in the target_link_libraries line for exe1, the link options are
separate instead of 1 big string combining them all and the actual CMake
target name, L1, is used instead of the output file libL1.a.  You can see
the resulting output is what you want:

$ make VERBOSE=1
...
[100%] Linking C executable exe1
...
/usr/bin/cc CMakeFiles/exe1.dir/main.c.o  -o exe1 -rdynamic
*-Wl,--whole-archive
../sub_dir1/libL1.a -Wl,--no-whole-archive*

Generally speaking, always use target names in a CMakeLists.txt instead of
the actual output file.  There are a few situations where you may need the
actual file name but they are uncommon and even then you would do it
through target properties and generator expressions rather than hard code
the library file name.

- Chuck

On Mon, May 30, 2016 at 8:35 AM, Chaos Zhang  wrote:

> Hi, all,
>
> Thanks for taking your time to review my email. I have a demo project and
> it's structure like as below:
>
> top_dir
> CMakeLists.txt
> sub_dir1
> CMakeLists.txt
> sub_dir2
> CMakeLists.txt
>
> top_dir/sub_dir1/CMakeLists.txt used to build `lib1` by using
> `add_library(lib1 ...)`,
> top_dir/sub_dir2/CMakeLists.txt used to build `exe1` with linking lib1 by
> `target_link_library(exe1 lib1)`.
> And the content of top_dir/CMakeLists.txt is as below:
>
> add_subdirectory(sub_dir2)
> add_subdirectory(sub_dir1)
>
> Normally, when build target exe1, cmake will check dependency so `lib1`
> will
> be built before building exe1. The problem is I am transfering an existed
> makefile project into CMake, and there are many gcc link options, like
> "whole-archive ... no-whole-archive, allow-mutiple-definition", if use like
> `target_link_library(exe1 "-Wl, --whole-archive ../sub_dir1/liblib1.a
> --no-whole-archive")`(The form like this, and this may not work, it just a
> e.g.), cmake seem don't built `lib1` any more. Is there any way i can use
> target_link_library like `target_link_library(exe1 "-Wl, --whole-archive
> ../sub_dir1/liblib1.a")` and cmake link dependency checking still work, or
> other way i can transfer these gcc link options into cmake?
>
> Thanks a lot,
> Chao
>
>
>
> --
> View this message in context:
> http://cmake.3232098.n2.nabble.com/How-to-hundle-gcc-link-options-like-whole-archive-allow-multiple-definition-in-CMake-tp7593563.html
> Sent from the CMake mailing list archive at Nabble.com.
> --
>
> 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
>
-- 

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

Re: [CMake] Finding libxml2 when building llvm/clang

[Chuck Atkins]

You could try to force libxml to be ignored by CMake so it will think it
wasn't found and use the fallback configuration:

cmake ... -DLIBXML2_LIBRARIES=IGNORE ...

- Chuck

On Tue, Jun 14, 2016 at 8:28 PM, Edward Diener <
eldlistmaili...@tropicsoft.com> wrote:

> Building llvm/clang from source involves using CMake. I am building
> llvm/clang from source on Windows using CMake 3.5.2. I am not a clang
> developer, just a clang user. Similarly I just use CMake rather than
> understand or write CMakeLists.txt files.
>
> I reported a problem to clang where building a 32-bit version of clang
> succeeds but building a 64-bit version of clang fails with xml link errors.
> I have A 32-bit libxml2 binary in my path from gnuwin32, but not a 64-bit
> binary of libxml2 in my path.
>
> I was told by clang developers that one of the tools which clang builds
> uses xml and libxml2 if it is available, otherwise uses some other
> technology for the tool. The suggestion was that the problem I am
> encountering is that of CMake; that CMake does not recognize that the
> libxml2 which I have is the 32-bit version and instead thinks that it is
> the 64-bit version and therefore attempts erroneously to use it in the
> 64-bit build of clang.
>
> Does anybody know what might be happening here ? I do not create the
> CMakeLists.txt files used by llvm/clang so I do not know how the use of
> libxml2 can be optionally specified in them.
>
> --
>
> 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
>
-- 

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

Re: [CMake] find_library

[Chuck Atkins]

Hi Vania,

 find_library(SYSC_LIB systemc PATHS "${SYSTEMC_PATH}"
>   PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>

In this first call, SYSTEMC_PATH is being dereferenced as a CMake
variable.  This works because in your invocation of CMake:

cmake -G "Unix Makefiles" -DSYSTEMC_PATH=$HOME/systemc-2.3.1/
>

You define the CMake variable with -D on the command line

 However, in your second call

>  find_library(SYSC_LIB systemc PATHS ENV SYSTEMC_PATH
>   PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>

the PATHS ENV SYSTEMC_PATH arguments specify that SYSTEMC_PATH be
dereferenced as an environment variable, not a CMake variable.  This is
equivalent to PATHS "$ENV{SYSTEMC_PATH}"
-- 

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

Re: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

[Chuck Atkins]

Hi Thibault,

Can you post your toolchain file?

- Chuck

On Tue, Feb 9, 2016 at 9:10 AM, Thibault Genessay 
wrote:

> Hi,
>
> I'm a long time user of CMake (and huge fan of it) but newly registered on
> this list, so please forgive me if I have missed something regarding the
> new 3.5 series.
>
> I use CMake with the GCC ARM Embedded compiler (
> https://launchpad.net/gcc-arm-embedded) to cross-compile my project
> (Windows host, STM32 target, MinGW binutils). Like many users (all?) I had
> to create a toolchain file because CMake doesn't support this
> compiler/setup out of the box. I have taken inspiration from the many
> Google hits and had a working setup until 3.5. This setup relied on the
> CMAKE_FORCE__COMPILER macros.
>
> I installed 3.5 and the build broke, CMake complaining that this macro was
> deprecated and should not be used because of the many improvements on the
> compiler detection side. OK, so I removed the offending lines, simply
> setting the CMAKE_C_COMPILER variable to the compiler's executable ... and
> suddenly I remember why I did use this FORCE hack in the first place: CMake
> tells me my compiler is broken because it cannot compile a test program
> (undefined symbol: _exit). This is somehow correct, as I compile for bare
> metal and I am providing the _exit function in my code. This is a
> misunderstanding the CMAKE_FORCE_C_COMPILER works around by simply saying
> "believe me, this compiler works".
>
> Now I am left without many options: I can't use the FORCE hack, and I
> can't convince CMake my compiler is OK. I am very open to redesign my
> toolchain file, or use a stock one from CMake, or whatever this takes, but
> I simply do not know how to proceed. Actually, I feel my current toolchain
> file, although functional, is not "clean" but never had enough time to do
> it. Now that it's a blocking issue, I do have time :)
>
> I rolled back to 3.4 and things work so I'm safe for now. But I would be
> very glad if somebody knew more about this specific problem, or this
> compiler, or toolchain file writing in general. I would love to write a
> "stock" toolchain file for this compiler but I simply do not know enough
> (nor I can find enough up-to-date documentation).
>
> Thanks for reading,
> Cheers
>
> Thibault
>
>
>
>
>
> --
>
> 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
>
-- 

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

Re: [CMake] How to pass a configuration file to CMake?

[Chuck Atkins]

Hi Cedric,

The option can be a bit confusing.  The cache file you pass is actually a
CMake script that sets cache variables, rather than the cache variables as
seen in CMakeCache.txt.  So you would actually want your cache file to
contain:

set(CMAKE_BUILD_TYPE Debug CACHE STRING "Choose the type of build")
set(CMAKE_INSTALL_PREFIX /home/me/there CACHE PATH "Install path prefix,
prepended onto install directories.")
set(CMAKE_CXX_COMPILER /usr/local/gcc/4.9.3/g++ CACHE FILEPATH "CXX
Compiler")


- Chuck

On Thu, Jan 21, 2016 at 9:43 AM, Cedric Doucet 
wrote:

>
>
> Hello,
>
> I do not manage to pass a configuration file to cmake.
>
> I type 'cmake -C ../config.cmake'
>
> where config.cmake belongs to the parent directory and contains these
> lines:
>
> set(ENABLE_DOWNLOAD True CACHE BOOL)
> set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH)
>
> I get the following error message but I don't understand why:
>
> loading initial cache file ../config.cmake
> CMake Error at /local/cdoucet/simol/config.cmake:1 (set):
>   set given invalid arguments for CACHE mode.
>
>
> CMake Error at /local/cdoucet/simol/config.cmake:2 (set):
>   set given invalid arguments for CACHE mode.
>
>
> CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is a
> file, not a directory.
>
>
> Do you know how to solve this problem?
>
> - Cedric Doucet  a écrit :
> >
>
> Hi Peter!
>
> Thank you very much!
> It seems to be exactly what I want. :)
> I will try to use it.
>
> Cédric
>
> --
>
> *De: *"Petr Kmoch" 
> *À: *"Cedric Doucet" 
> *Cc: *cmake@cmake.org
> *Envoyé: *Lundi 21 Décembre 2015 13:25:53
> *Objet: *Re: [CMake] How to pass a configuration file to CMake?
>
> Hi Cedric.
>
> I have never used it myself, but I believe you're looking for CMake's
> command-line option '-C ':
> https://cmake.org/cmake/help/latest/manual/cmake.1.html
>
> Petr
>
> On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet 
> wrote:
>
>>
>> Hello,
>>
>> I would like to know if it's possible to pass a configuration file to
>> CMake.
>> I have to pass a lot of information to CMake and the resulting command
>> line is very long to type.
>> Would it be possible to create a file containing all needed definitions
>> and pass it to CMake?
>>
>> For exemple, instead of typing
>>
>> cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D
>> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>
>> would it be possible to create a file containing
>>
>> CMAKE_BUILD_TYPE=Debug
>> CMAKE_INSTALL_PREFIX=/home/me/there
>> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>
>> and pass it to CMake?
>>
>> Cédric
>>
>> --
>>
>> >
>>
>> > 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
>>
>
>
> >
>
>
>
>
> --
>
> 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
>
-- 

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

Re: [CMake] How to pass a configuration file to CMake?

[Chuck Atkins]

CMake strongly encourages the use of separate source and build directories
(unlike autotools).  So, try something like this:

mkdir build
cd build
cmake -C /path/to/SuperCoolCacheFile.cmake /path/to/source


- Chuck

On Thu, Jan 21, 2016 at 10:10 AM, Cedric Doucet 
wrote:

>
>
> Hi Petr,
>
> thank you very much for your answer!
>
> Indeed, comment string arguments seem to be mandatory.
> I modified my configuration file like this:
>
> set(ENABLE_DOWNLOAD True CACHE BOOL "Automatic installation of third-party
> libraries")
> set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "Root of GCC")
>
> Now, I get the following error message:
>
> CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is a
> file, not a directory.
>
> I am quite surprised about this message because I thought a file was
> required to the command 'cmake -C'.
>
> Do you have any idea of what I am doing wrong here?
>
> - Petr Kmoch  a écrit :
> >
> Hi Cedric.
>
> I believe the comment string argument is mandatory in a set(... CACHE), so
> it should be something like this:
>
> set(ENABLE_DOWNLOAD True CACHE BOOL "Should download be enabled")
> set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "Path to root
> directory of GCC installation")
>
> Petr
>
>
> On Thu, Jan 21, 2016 at 3:43 PM, Cedric Doucet 
> wrote:
>
>>
>>
>> Hello,
>>
>> I do not manage to pass a configuration file to cmake.
>>
>> I type 'cmake -C ../config.cmake'
>>
>> where config.cmake belongs to the parent directory and contains these
>> lines:
>>
>> set(ENABLE_DOWNLOAD True CACHE BOOL)
>> set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH)
>>
>> I get the following error message but I don't understand why:
>>
>> loading initial cache file ../config.cmake
>> CMake Error at /local/cdoucet/simol/config.cmake:1 (set):
>>   set given invalid arguments for CACHE mode.
>>
>>
>> CMake Error at /local/cdoucet/simol/config.cmake:2 (set):
>>   set given invalid arguments for CACHE mode.
>>
>>
>> CMake Error: The source directory "/local/cdoucet/simol/config.cmake" is
>> a file, not a directory.
>>
>>
>> Do you know how to solve this problem?
>>
>> - Cedric Doucet  a écrit :
>> >
>>
>> Hi Peter!
>>
>> Thank you very much!
>> It seems to be exactly what I want. :)
>> I will try to use it.
>>
>> Cédric
>>
>> --
>>
>> *De: *"Petr Kmoch" 
>> *À: *"Cedric Doucet" 
>> *Cc: *cmake@cmake.org
>> *Envoyé: *Lundi 21 Décembre 2015 13:25:53
>> *Objet: *Re: [CMake] How to pass a configuration file to CMake?
>>
>> Hi Cedric.
>>
>> I have never used it myself, but I believe you're looking for CMake's
>> command-line option '-C ':
>> https://cmake.org/cmake/help/latest/manual/cmake.1.html
>>
>> Petr
>>
>> On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet 
>> wrote:
>>
>>>
>>> Hello,
>>>
>>> I would like to know if it's possible to pass a configuration file to
>>> CMake.
>>> I have to pass a lot of information to CMake and the resulting command
>>> line is very long to type.
>>> Would it be possible to create a file containing all needed definitions
>>> and pass it to CMake?
>>>
>>> For exemple, instead of typing
>>>
>>> cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there
>>> -D CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>>
>>> would it be possible to create a file containing
>>>
>>> CMAKE_BUILD_TYPE=Debug
>>> CMAKE_INSTALL_PREFIX=/home/me/there
>>> CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++
>>>
>>> and pass it to CMake?
>>>
>>> Cédric
>>>
>>> --
>>>
>>> >
>>>
>>> > 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
>>>
>>
>>
>> >
>>
>>
>>
>>
>> --
>>
>> >
>>
>> > 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 

Re: [CMake] CMake:question of the time when the command will happen in add_custom_command(...)

[Chuck Atkins]

Hi Chao,

You can see this more clearly if you do a "make VERBOSE=1" :

[chuck.atkins@hal9000 build]$ make VERBOSE=1
...
[ 50%] Building C object CMakeFiles/main.dir/main.c.o
/usr/bin/cc -o CMakeFiles/main.dir/main.c.o   -c
/home/chuck.atkins/Code/tmp/source/main.c
[100%] Linking C executable main

*echo This\ is\ pre\ build\ This is pre build *
/usr/bin/cmake -E cmake_link_script CMakeFiles/main.dir/link.txt --verbose=1
*/usr/bin/cc CMakeFiles/main.dir/main.c.o  -o main -rdynamic *

*echo This\ is\ post\ buildThis is post build*
make[2]: Leaving directory '/home/chuck.atkins/Code/tmp/build'
[100%] Built target main
make[1]: Leaving directory '/home/chuck.atkins/Code/tmp/build'
/usr/bin/cmake -E cmake_progress_start
/home/chuck.atkins/Code/tmp/build/CMakeFiles 0
[chuck.atkins@hal9000 build]$

Here you can see the order of command execution is PRE_BUILD -> Link ->
POST_BUILD

- Chuck

On Fri, Apr 22, 2016 at 5:53 AM, Chaos Zhang  wrote:

> Sorry for i just know reply by email and thinks for your help again. :-)
>
>
> Petr Kmoch wrote
> > No, it is indeed compiled and linked just fine. What I meant is:
> >
> > Without any custom commands, the build process conceptually looks like
> > this:
> >
> > buildMain() {
> >   compile_object_files();
> >   link_main_binary();
> >
> >   message("Built target main");
> > }
> >
> > With a post-build custom command:
> >
> > buildMain() {
> >   compile_object_files();
> >   link_main_binary();
> >   post_build_command();
> >
> >   message("Built target main");
> > }
> >
> > The custom command becomes a part of the entire process of "Building
> > target," that's why the "Built target" message appears after the command
> > runs.
> >
> > BTW, please keep the mailing list in copy when replying.
> >
> > Petr
> >
> > On 22 April 2016 at 10:02, Chaos Zhang 
>
> > zcsd2012@
>
> >  wrote:
> >
> >> So what you mean is the target have not been complied and linked after i
> >> introduce
> >> custom commands into this target right? Do i understand right?
> >>
> >> Thanks a lot for your generous help. :-)
> >>
> >> 2016-04-22 16:38 GMT+08:00 Petr Kmoch 
>
> > petr.kmoch@
>
> > :
> >>
> >>> Hi,
> >>>
> >>> the reason is that the post-build command is actually a part of
> building
> >>> "main the target." Once you introduce custom commands into a target,
> >>> building it includes them all, and not just compiling the object files
> >>> and
> >>> linking the binary. You will notice that the "Linking C exectuable
> main"
> >>> line came before the post-build message, so it did happen in the
> correct
> >>> order.
> >>>
> >>> Petr
> >>>
> >>> On 22 April 2016 at 06:25, Chaos Zhang 
>
> > zcsd2012@
>
> >  wrote:
> >>>
>  Hi all,
> 
>  I have some trouble when i use PRE_BUILD | PRE_LINK | POST_BUILD in
>  command
>  "add_custom_command(...)". When i use POST_BUILD, i found the command
>  will
>  execute before target had been built, like this:
> 
>  1 [root@VM_33_35_centos build]# make
>  2 Scanning dependencies of target main
>  3 [100%] Building C object CMakeFiles/main.dir/main.c.o
>  4 Linking C executable main
>  5 This is pre build
>  6 This is post build
>  7 [100%] Built target main
> 
>  In my CMakeLists.txt, the content is:
>   1 cmake_minimum_required(VERSION 2.8)
>   2 add_executable(main main.c)
>   3 add_custom_command(TARGET main
>   4 PRE_BUILD
>   5 COMMAND echo "This is pre build "
>   6 )
>   7 add_custom_command(TARGET main
>   8 POST_BUILD
>   9 COMMAND echo "This is post build"
>   10 )
> 
>  Why the command echo "This is post build" in 8 line(CMakeLists.txt)
> did
>  not
>  execute after [100%] Built target main in 7 line(Linux command)?
> 
> 
> 
> 
>  --
>  View this message in context:
> 
> http://cmake.3232098.n2.nabble.com/CMake-question-of-the-time-when-the-command-will-happen-in-add-custom-command-tp7593314.html
>  Sent from the CMake mailing list archive at Nabble.com.
>  --
> 
>  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
> 
> >>>
> >>>
> >>
> >
> > --
> >
> > Powered by www.kitware.com
> >
> > Please 

Re: [CMake] How to link shared lib on windows (visual studio 2014).

[Chuck Atkins]

May others have mentioned the various different ways to address generating
import libraries.  One thing that will help with the "can't find .dll"
issue is to change the default location that various components end up.
With Windows shared libraries, you have both a runtime component (.dll) and
a link time component (.lib).  Setting the following at the top of your
CMakeLists.txt:

if(NOT CMAKE_RUNTIME_OUTPUT_DIRECTORY)
  set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/bin")
endif()
if(NOT CMAKE_LIBRARY_OUTPUT_DIRECTORY)
  set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/lib")
endif()
if(NOT CMAKE_ARCHIVE_OUTPUT_DIRECTORY)
  set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/lib")
endif()

This is a common pattern to place near the beginning of a top-level
CMakeLists.txt after the project(...) copmmand.  What this does is make
sure that all runtime components end up in the bin directory, including
both .exe's and .dll's, and that all link-time components, including .so's
and .a's in Linux and .lib's on Windows, end up in the the lib directory.
This way when you run your executable on Windows, their necessary runtime
components live next to them.  It also consolidates all your build products
into one place instead of leaving them scattered across the various
sub-directories of the build folder.

- Chuck

On Tue, Apr 26, 2016 at 9:22 AM, Chaos Zhang  wrote:

> Hi, all,
>
> Thanks for your sincerely help, and i understand it clearly now. ( ^_^ )
>
> Best regards,
> Chao
>
>
> J. Caleb Wherry wrote
> > (Shameless plug ahead)
> >
> > If you want to see a working example of what I said above, you can check
> > out my ExampleCMakeProject:
> >
> > https://github.com/calebwherry/example-cmake-project
> >
> > It is currently being built and tested on TravisCI (Linux + Mac [GGC5 and
> > Clang3.7]) and Appveyor (Windows [VS2015]) and provides a simple example
> > of
> > how to write/structure CMake for cross-platform C/C++ projects. You can
> > ignore the python wrapper if you want, it just makes working with the
> > CMake
> > exe and system builds easier (calculates core counts, creates directories
> > for build, nicer CLI options, etc) since I find the options to CMake to
> be
> > very... verbose.
> >
> > The POST_BUILD example is here:
> >
> >
> https://github.com/calebwherry/example-cmake-project/blob/master/src/app/test-app/CMakeLists.txt
> >
> > If you really are looking to get a one-off project working, Decker's
> > recommendation about PATH modification is easiest. It's just not
> something
> > I think is viable in the long run and doesn't work as an actual solution
> > to
> > the problem if you are trying to solve it for many projects.
> >
> > -Caleb
> >
> > On Mon, Apr 25, 2016 at 9:01 PM, Chaos Zhang 
>
> > zcsd2012@
>
> >  wrote:
> >
> >> Hi,
> >>
> >> I faced this problem when i try built a shared lib  and linked it on
> >> windows. The structure of my project as below:
> >> -test_dir/
> >>  -sub_hello/
> >>CMakeLists.txt
> >>hello.c
> >>  -top/
> >>main.c
> >>CMakeLists.txt
> >>  CMakeLists.txt
> >>
> >> The content of each file:
> >> ①test_dir/CMakeLists.txt:
> >> PROJECT(TESTLIB)
> >> add_subdirectory(sub_hello sub_hello)
> >> add_subdirectory(top top)
> >>
> >> ②test_dir/sub_hello/CMakeLists.txt:
> >> message("message from sub_hello")
> >> add_library(hello_lib  SHARED hello.c)
> >>
> >> ③test_dir/top/CMakeLists.txt:
> >> include_directories(../sub_hello)
> >> add_executable(main main.c)
> >> target_link_libraries(main hello_lib)
> >>
> >> ④test_dir/sub_hello/hello.c：
> >> #include
> > 
> >> void HelloFunc()
> >> {
> >> printf("###hello###\n");
> >> }
> >>
> >> ⑤test_dir/top/main.c:
> >> int main()
> >> {
> >> HelloFunc();
> >> return 0;
> >> }
> >>
> >> After i cmake this project, generated .sln and .proj files, then i built
> >> it
> >> and i get an error in vs:
> >>
> >> Error   LNK1104 can't open file "..\sub_hello\Debug\hello_lib.lib"
> >>
> >> In folder ..\sub_hello\Debug\ , there was not a hello_lib.lib existed.
> >> Then i look thorough and found a solution:
> >>
> >> Add "set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS YES)" in file
> >> test_dir/sub_hello/hello.c
> >>
> >> Then i built this solution again, this time it success, and
> hello_lib.lib
> >> and main.exe was generated. But when i try to run main.exe, an error
> >> occured: "lose hello_lib.dll". And i moved hello_lib.dll into the folder
> >> of
> >> main.exe, and it worked well.
> >>
> >> There are two questions i could not figure out:
> >> ①Is this "..\sub_hello\Debug\hello_lib.lib" associates with
> >> "..\sub_hello\Debug\hello_lib.dll"? For windows can not use .dll
> >> directly,
> >> and use a .lib to record the .dll's  entrance and location.
> >> ②How to solve the problem of main.exe can not find .dll file.
> >>
> >> Best regards,
> >> Chao Zhang
> >>
> >>
> >>
> >>
> >>
> >> --
> >> View this message in 

Re: [CMake] project command not working, when used via macro (from an included file)

[Chuck Atkins]

Perhaps I spoke to hastily.  It seems the unsupported configuration is if
project(...) is actually called from an include file, which makes sense
given various scoping issues.  Give that, what you have should work fine.
What doesn't work as expected?  It seems to work just fine when I try it
from a macro defined in an include file.  Also, what version of CMake are
you using so I can try to reproduce your configuration more closely?

- Chuck

On Wed, Apr 27, 2016 at 10:09 AM, aj neu <ajn...@gmail.com> wrote:

> Ok thanks.
> But it is unfortunate, since it means that really great macros, such as
> project_guarded
> (see http://stackoverflow.com/a/33100078)
> cannot be used everywhere, as a substitute for project.
>
>
>
> On Tue, Apr 26, 2016 at 8:04 PM, Chuck Atkins <chuck.atk...@kitware.com>
> wrote:
>
>> ajneu,
>>
>> The call to project(...) needs to be explicit.  See
>> https://cmake.org/cmake/help/v3.5/command/project.html:
>>
>> The top-level CMakeLists.txt file for a project must contain a literal,
>> direct call to the project()
>> <https://cmake.org/cmake/help/v3.5/command/project.html#command:project>
>> command; loading one through the include()
>> <https://cmake.org/cmake/help/v3.5/command/include.html#command:include>
>> command is not sufficient.
>>
>> - Chuck
>>
>> On Tue, Apr 26, 2016 at 1:57 PM, aj neu <ajn...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> when calling `project`
>>> ...as seen here
>>> ...
>>> https://github.com/ajneu/cmake_project_via_macro/blob/5972c7362e11fdbaa09d9defe8cca2dcea79e606/CMakeLists.txt#L33
>>> everything is ok.
>>>
>>>
>>> BUT when calling `project` via a macro (that was included)
>>> ... as seen here
>>> ...
>>> https://github.com/ajneu/cmake_project_via_macro/blob/master/CMakeLists.txt#L33
>>> the behaviour is not as expected.
>>>
>>> Why?
>>>
>>> (Details are here: https://github.com/ajneu/cmake_project_via_macro)
>>>
>>>
>>> Is this a bug?
>>>
>>> Thanks
>>> ajneu
>>>
>>>
>>>
>
-- 

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

Re: [CMake] Is there a better way to retrieve content from a remote zip file?

[Chuck Atkins]

This looks well suited to ExternalProject.  Just give it an empty configure
and build steps and then have the install step perform the copy:

include(ExternalProject)

if(CMAKE_SIZEOF_VOID_P EQUAL 8)
  set(3rdParty_SUBDIR x64)
else()
  set(3rdParty_SUBDIR x86)
endif()

ExternalProject_Add( 3rdParty
  URL http://download.osgvisual.org/3rdParty_VS2013_v120_x86_x64_V9_small.7z
  URL_MD5 c9294a16b39783cba8c4c55df182b24b
  BUILD_IN_SOURCE 1
  CONFIGURE_COMMAND ""
  BUILD_COMMAND ""
  INSTALL_COMMAND ${CMAKE_COMMAND} -E copy_directory ${3rdParty_SUBDIR}/
${CMAKE_INSTALL_PREFIX}
)

This created a "3rdParty" target that should do everything you need and
only if necessary.

- Chuck

On Thu, Apr 28, 2016 at 11:19 AM, Lee Butler  wrote:

> I am looking for a better way to do something than having a sequence of
> "if (NOT EXISTS)" statements.  My package being built depends on some
> external libraries and headers, that are available in a zip file on an
> external website.  So for example:  zlib.h,zlib.dll and zlib.lib are (along
> with other stuff) in 3rdParty.zip available from a remote URL.  I don't
> want to build these things, I want to fetch the zip file, unpack it and
> copy the relevant portions into place only as needed.
>
> At the moment I have the code below, which feels "unclean" on so many
> levels:
>
> if (NOT EXISTS "${CMAKE_INSTALL_PREFIX}/include/zlib.h")
>   if (NOT EXISTS "${CMAKE_CURRENT_BINARY_DIR}/3rdParty_x86_x64")
> if (NOT EXISTS
> "${CMAKE_CURRENT_BINARY_DIR}/3rdParty_VS2013_v120_x86_x64_V9_small.7z")
>MESSAGE(STATUS "Downloading 3rdParty")
>file(DOWNLOAD
> http://download.osgvisual.org/3rdParty_VS2013_v120_x86_x64_V9_small.7z
> "${CMAKE_CURRENT_BINARY_DIR}/3rdParty_VS2013_v120_x86_x64_V9_small.7z"
> SHOW_PROGRESS)
> endif()
>
> message(STATUS "expanding 3rdParty Archive")
> execute_process( COMMAND ${CMAKE_COMMAND} -E tar xzf
> "${CMAKE_CURRENT_BINARY_DIR}/3rdParty_VS2013_v120_x86_x64_V9_small.7z" )
>   endif()
>   foreach(dir bin data include lib ssl)
> file(RENAME "${CMAKE_CURRENT_BINARY_DIR}/3rdParty_x86_x64/x64/${dir}"
> "${CMAKE_INSTALL_PREFIX}/${dir}")
>   endforeach(dir)
>   file(REMOVE_RECURSE "${CMAKE_CURRENT_BINARY_DIR}/3rdParty_x86_x64")
> endif()
>
> This has the property of fetching the 7z file, extracting the contents and
> leaving the 7z file around for later rebuilds.  I hope there is a cleaner
> way of saying the same thing.  BTW, I would be just as happy putting
> "products" from the zip file in the current build destinations instead of
> the install destinations.
> --
>
> 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
>
-- 

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

Re: [CMake] project command not working, when used via macro (from an included file)

[Chuck Atkins]

ajneu,

The call to project(...) needs to be explicit.  See
https://cmake.org/cmake/help/v3.5/command/project.html:

The top-level CMakeLists.txt file for a project must contain a literal,
direct call to the project()

command; loading one through the include()

command is not sufficient.

- Chuck

On Tue, Apr 26, 2016 at 1:57 PM, aj neu  wrote:

> Hi,
>
> when calling `project`
> ...as seen here
> ...
> https://github.com/ajneu/cmake_project_via_macro/blob/5972c7362e11fdbaa09d9defe8cca2dcea79e606/CMakeLists.txt#L33
> everything is ok.
>
>
> BUT when calling `project` via a macro (that was included)
> ... as seen here
> ...
> https://github.com/ajneu/cmake_project_via_macro/blob/master/CMakeLists.txt#L33
> the behaviour is not as expected.
>
> Why?
>
> (Details are here: https://github.com/ajneu/cmake_project_via_macro)
>
>
> Is this a bug?
>
> Thanks
> ajneu
>
>
> --
>
> 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
>
-- 

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

Re: [CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly

[Chuck Atkins]

> -rpath


 RPATHs are automatically added by CMake to executables so they can use
libraries from the build tree.



> -whole-archive
>

whole-archive is definitely trickier since you shouldn't be applying it to
the entire executable but instead wrapping individual libraries with it.
Conveniently, you can pass link options directly with
target_link_libraries.  So you could have:

# Just an example, find_library calls should really be isolated to separate
find modules
find_library(FOO_LIBRARY foo)
set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY} -Wl,--no-whole-archive")

add_executable(hello main.c)
target_link_libraries(hello ${FOO_LIBRARY})


>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello")
>

CMAKE_EXE_LINKER_FLAGS should work for other more general cases that aren't
tied to specific libraries.  The problem with your example is likely not
using an absolute path for -L since the compilation is actually taking
place in a nested work directory somewhere.
-- 

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

Re: [CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly

[Chuck Atkins]

If you know the full path to the library then I'd suggest using it as
/path/to/foo/libfoo.a (or .so if it's shared) instead of -L/path/to/foo
-lfoo.  CMake will adjust the flags to -L and -l if needed but the
preference is always to use the full library path.

- Chuck

On Mon, May 23, 2016 at 2:23 AM, Chaos Zhang <zcsd2...@gmail.com> wrote:

> Thanks a lot! `set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY}
> -Wl,--no-whole-archive")` worked when the content of ${FOO_LIBRARY} look
> like `-Ldir -llib`, if just use lib name as the content of ${FOO_LIBRARY},
> error while occur.
>
> Chuck Atkins wrote
> >> -rpath
> >
> >
> >  RPATHs are automatically added by CMake to executables so they can use
> > libraries from the build tree.
> >
> >
> >
> >> -whole-archive
> >>
> >
> > whole-archive is definitely trickier since you shouldn't be applying it
> to
> > the entire executable but instead wrapping individual libraries with it.
> > Conveniently, you can pass link options directly with
> > target_link_libraries.  So you could have:
> >
> > # Just an example, find_library calls should really be isolated to
> > separate
> > find modules
> > find_library(FOO_LIBRARY foo)
> > set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY}
> > -Wl,--no-whole-archive")
> >
> > add_executable(hello main.c)
> > target_link_libraries(hello ${FOO_LIBRARY})
> >
> >
> >>> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello")
> >>
> >
> > CMAKE_EXE_LINKER_FLAGS should work for other more general cases that
> > aren't
> > tied to specific libraries.  The problem with your example is likely not
> > using an absolute path for -L since the compilation is actually taking
> > place in a nested work directory somewhere.
> >
> > --
> >
> > 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
>
>
>
>
>
> --
> View this message in context:
> http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495p7593518.html
> Sent from the CMake mailing list archive at Nabble.com.
> --
>
> 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
>
-- 

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

Re: [CMake] How to use 'CMAKE_EXE_LINKER_FLAGS' correctly

[Chuck Atkins]

Is there a reason to not use target_link_libraries here? For the purposes
of your example there's no reason to be using CMAKE_EXE_LINKER_FLAGS.  What
are you actually trying to accomplish? Because there is almost certainly a
better way to achieve your desired result than via CMAKE_EXE_LINKER_FLAGS.

- Chuck

On Fri, May 20, 2016 at 4:28 AM, Chaos Zhang  wrote:

> Hi, all,
>
> I try to use some gcc link option and libs(except libs link by
> target_link_libraries(...)), i researched and try to use
> 'CMAKE_EXE_LINKER_FLAGS' in a simple project, as below:
> in dir, there are 5 files:
>
> -hello.h
> -hello.c
> -main.c
> -hello.o
> -libhello.a
>
> hello.o was compiled by hello.c(gcc -c hello.c) and libhello.a contained
> hello.o. And other 3 files content:
> 1.In hello.h:
>
> void hello();
>
> 2.In hello.c:
>
> #include
> void hello()
> {
> printf("hello\n");
> }
>
> 3.In main.c:
>
> #include "hello.h"
> void main()
> {
>hello();
> }
>
> When i used gcc -o main main.c libhello.a, the exe file: main generated,
> and
> it work well.
> Then i write a CMakeLists.txt, the content as below:
>
> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L . -lhello")
> add_executable(main main.c)
>
> When i cmake this project, an error occurred: main.c:undefined
> reference to 'hello'.
>
> Since i wil add a complicated link option and would not conflict with  libs
> link by target_link_libraries(...), i should figure out how to use
> 'CMAKE_EXE_LINKER_FLAGS' or other ways, could you please give me some
> advices? :-)
>
> Thanks,
> Chao
>
>
>
> --
> View this message in context:
> http://cmake.3232098.n2.nabble.com/How-to-use-CMAKE-EXE-LINKER-FLAGS-correctly-tp7593495.html
> Sent from the CMake mailing list archive at Nabble.com.
> --
>
> 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
>
-- 

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

Re: [CMake] Idomatic cmake: Supporting gcc, icc, and clang with custom flags for each?

[Chuck Atkins]

Hi TCW,

A typical approach for this is in the top level CMakeLists.txt to have:

include(CompilerFlags)

And then you can isolate the detection and specialization logic in a
separate CompilerFlags.cmake:

if(CMAKE_COMPILER_IS_GNUC)
  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --gcc-options")
elseif(CMAKE_C_COMPILER_ID MATCHES "Intel")
  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --icc-options")
elseif(CMAKE_C_COMPILER_ID MATCHES "PGI)
  set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --pgcc-options")
elseif(MSVC)
  if(MSVC_VERSION GREATER_THAN 1700)
...
  elseif(...)
...
  endif()
endif()

And then similarly for C++.


- Chuck

On Tue, May 17, 2016 at 1:49 AM, TCW via CMake  wrote:

> Hello all,
>
> On linux, what's the correct way to support building with several
> different C compilers, each with some extra compiler-specifc flags for
> Debug and Release modes?  (Eventually I'll need to add Visual Studio on
> Windows too. )
>
> For now, I'm following what's mentioned in the cmake FAQ and using
> CXX=/blah cmake, etc.
>
> (From:
> https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F)
>
> But this is getting quite cumbersome as I'm experimenting with different
> flags for each compiler, and I'd rather avoid polluting my fairly clean
> CMakeLists file with a bunch of if/else branches to set flags.
>
> In the cmake manual I see reference to a -DCMAKE_TOOLCHAIN_FILE option,
> but this seems designed for embedded cross-compile scenarios.  (Is that
> right?)
>
> (From: https://cmake.org/cmake/help/v3.0/manual/cmake-toolchains.7.html)
>
> Basically, I'd like to succinctly choose among a set of (slightly)
> customized compiler choices.
>
> For modern cmake usage what is the correct method?  Can anybody point me
> to a well done example for a simple case like this?
>
> Thank you!
> tcw
>
> --
>
> 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
>
-- 

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

Re: [CMake] Error if CMAKE_SYSTEM_NAME is placed wrongly

[Chuck Atkins]

> when I place set(CMAKE_SYSTEM_NAME Generic) after cmake_minimum_required()
> and project() and set(VERSION_MAYOR/MINOR),
>

CMAKE_SYSTEM_NAME really shouldn't be in a CMakeLists.txt file at all.  It
should instead be in a stand alone toolchain file defining your various
cross-compiling requirements and then passed to cmake with
-DCMAKE_TOOLCHAIN_FILE=/path/to/Toolchain.cmake.  CMake has certain rules
for when the toolchain file get's loaded very early on and processed to
make sure that the subsequent processing of the CMakeLists.txt is done with
the appropriate platform and compiler information set.

- 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

Re: [CMake] [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

Re: [CMake] CMake: how to use 'for cyclic sentence' in command add_custom_command(...)

[Chuck Atkins]

Hi Chao,


> I was using 'for cyclic sentence' in command add_custom_command(...), the
> content of the CMakeLists.txt as below:
> add_custom_command(TARGET temp_target
> POST_BUILD
> COMMAND for x in a b c\;
> do echo $x \;
> done\;)
>

The $x is getting parsed by the makefile so you need to escape it with the
$ makefile escape sequence.  Try:

add_custom_command(TARGET temp_target
POST_BUILD
COMMAND for x in a b c\;
do echo $$x \;
done\;)

You can see the difference in a make VERBOSE=1 :

[100%] Linking C static library libtemp_target.a
/home/khq.kitware.com/chuck.atkins/Code/CMake/build/master-release/bin/cmake
-P CMakeFiles/temp_target.dir/cmake_clean_target.cmake
/home/khq.kitware.com/chuck.atkins/Code/CMake/build/master-release/bin/cmake
-E cmake_link_script CMakeFiles/temp_target.dir/link.txt --verbose=1
/usr/bin/ar qc libtemp_target.a  CMakeFiles/temp_target.dir/foo.c.o
/usr/bin/ranlib libtemp_target.a
*for x in a b c; do echo  ; done;*



make[2]: Leaving directory '/home/khq.kitware.com/chuck.atkins/tmp/bld'

Now becomes:

[100%] Linking C static library libtemp_target.a
/home/khq.kitware.com/chuck.atkins/Code/CMake/build/master-release/bin/cmake
-P CMakeFiles/temp_target.dir/cmake_clean_target.cmake
/home/khq.kitware.com/chuck.atkins/Code/CMake/build/master-release/bin/cmake
-E cmake_link_script CMakeFiles/temp_target.dir/link.txt --verbose=1
/usr/bin/ar qc libtemp_target.a  CMakeFiles/temp_target.dir/foo.c.o
/usr/bin/ranlib libtemp_target.a



*for x in a b c; do echo $x ; done;abc*
make[2]: Leaving directory '/home/khq.kitware.com/chuck.atkins/tmp/bld'

- 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

Re: [CMake] How to add dependency relations between libs and executable

[Chuck Atkins]

> cmake, the old top layer project is proj_a, which at the same layer with
> proj_b and proj_c, if I add an extra top layer as the root you mentioned,

the generated make file structure will be changed, top layer make file

will be root instead of proj_a.
>
> Is there any way to add the dependency at proj_a level?
>

If you want proj_a, proj_b, and proj_c to all be built by the same make
command, then it makes sense to have a top level organization that
encompasses them all.  Also, if proj_a, proj_b and proj_c don't make sense
on their own and only when paired with each-other, then I would take the
"project(...)" command out of each of them and only leave the top level.
Basically, anything that has a project(...) command can be configured and
built all on it's own without the rest of the tree.  In this case, it may
make sense to keep b and c as independent projects but a as not since it
needs b and c.  So for example, similar to Anatoly's example:

*folder*
CMakeLists.txt:
project(root)
add_subdirectory(proj_b)
add_subdirectory(proj_c)
add_subdirectory(proj_a)

*folder/proj_a*
CMakeLists.txt:
add_executable(*A *main.cpp)
target_link_libraries(*A B C*)

*folder/proj_b*
CMakeLists.txt:
project(proj_b)
add_library(B proj_b.cpp)

*folder/proj_c*
CMakeLists.txt:
project(proj_c)
add_library(*C *proj_c.cpp)


With this structure, you can configure and build just project b or c:

$ mkdir build_c
$ cd build_c
$ cmake /path/to/folder/proj_c
...
$ make
...

You end up with libC.a .  Similarly, you could do that for proj_b and get
libB.a.  Or, if you configure the top level project instead:

$ mkdir build_all
$ cd build_all
$ cmake /path/to/folder
...
$ make
Scanning dependencies of target B
[ 16%] Building CXX object proj_b/CMakeFiles/B.dir/proj_b.o
[ 33%] Linking CXX static library libB.a
[ 33%] Built target B
Scanning dependencies of target C
[ 50%] Building CXX object proj_c/CMakeFiles/C.dir/proj_c.o
[ 66%] Linking CXX static library libC.a
[ 66%] Built target C
Scanning dependencies of target A
[ 83%] Building CXX object proj_a/CMakeFiles/A.dir/main.o
[100%] Linking CXX executable A
[100%] Built target A
$

You end up with proj_b/libB.a, proj_c/libC.a, and proj_a/A which is linked
with libB.a and libC.a.  You can also do a parallel make with make
-j(whatever) adn the generated dependencies will make sure that targets and
individual files are built in the right order.  Technically speaking, you
don't *need* to have a CMakeLists.txt at each level and you could put it
all in to one top level CMakeLists.txt but it's generally considered poor
CMake code to do so.  A good rule of thumb is to have a CMakeLsits.txt file
at each level that a target (i.e. a library or executable) is built and a
top level CMakeLists.txt to tie it all together.  This is the same sort of
approach you see with autoconf where it's typical to have a Makefile.am at
each level.
-- 

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

Re: [CMake] CMake: how to use 'for cyclic sentence' in command add_custom_command(...)

[Chuck Atkins]

Hi Chao,
As Konstantin alluded to, trying to pass "srtingified" shell scripting
through the layers of cmake and makefile escaping is bound to be fraught
with problems.  The necessary escaping will very quickly become
unmaintainable.  You're really best suited to place these in a separate
shell script (or cmake script to make it os-portable) and just call the
script from add_custom_command.
Hi Mr. Atkins,

Thanks a lot for your reply, and it worked well and help me a lot, there
still are some confusions about "for cyclic sentence".
I have tested some other case as below:
add_custom_target(temp_target ALL)
add_custom_command(TARGET temp_target
   POST_BUILD
   COMMAND
   if [ "$(dir_name)" = "test_dir" ]\;
   then
echo $(dir_name)\;
 for x in $$\(cat
$(file_name).txt\)\;
do echo $$x \;
echo $(file_name)\;
   done\;
   fi)
 Confusions:
1. I should use $$x in "for cyclic sentence", but i can not use $$(x) or
$$\(x\). And i can use "$$\(cat $(file_name).txt\)" and it worked well.
Even it worked when i use "$$x"(withdouble quote ).
2. When i make makefile, i use "make dir_name=test_dir
file_name=test_file", and i can get the value of dir_name and file_name by
use $(dir_name), $(file_name).

Thanks again for your help,
Chao Zhang

2016-04-19 22:20 GMT+08:00 Chuck Atkins <chuck.atk...@kitware.com>:

> Hi Chao,
>
>
>> I was using 'for cyclic sentence' in command add_custom_command(...), the
>> content of the CMakeLists.txt as below:
>> add_custom_command(TARGET temp_target
>> POST_BUILD
>> COMMAND for x in a b c\;
>> do echo $x \;
>> done\;)
>>
>
> The $x is getting parsed by the makefile so you need to escape it with the
> $ makefile escape sequence.  Try:
>
> add_custom_command(TARGET temp_target
> POST_BUILD
> COMMAND for x in a b c\;
> do echo $$x \;
> done\;)
>
> You can see the difference in a make VERBOSE=1 :
>
> [100%] Linking C static library libtemp_target.a
> /home/
> khq.kitware.com/chuck.atkins/Code/CMake/build/master-release/bin/cmake -P
> CMakeFiles/temp_target.dir/cmake_clean_target.cmake
> /home/
> khq.kitware.com/chuck.atkins/Code/CMake/build/master-release/bin/cmake -E
> cmake_link_script CMakeFiles/temp_target.dir/link.txt --verbose=1
> /usr/bin/ar qc libtemp_target.a  CMakeFiles/temp_target.dir/foo.c.o
> /usr/bin/ranlib libtemp_target.a
> *for x in a b c; do echo  ; done;*
>
>
>
> make[2]: Leaving directory '/home/khq.kitware.com/chuck.atkins/tmp/bld'
>
> Now becomes:
>
> [100%] Linking C static library libtemp_target.a
> /home/
> khq.kitware.com/chuck.atkins/Code/CMake/build/master-release/bin/cmake -P
> CMakeFiles/temp_target.dir/cmake_clean_target.cmake
> /home/
> khq.kitware.com/chuck.atkins/Code/CMake/build/master-release/bin/cmake -E
> cmake_link_script CMakeFiles/temp_target.dir/link.txt --verbose=1
> /usr/bin/ar qc libtemp_target.a  CMakeFiles/temp_target.dir/foo.c.o
> /usr/bin/ranlib libtemp_target.a
>
>
>
> *for x in a b c; do echo $x ; done;abc*
> make[2]: Leaving directory '/home/khq.kitware.com/chuck.atkins/tmp/bld'
>
> - 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

Re: [CMake] How to add dependency relations between libs and executable

[Chuck Atkins]

> So for this parallel project structure, an upper level cmakelist used to
> organize and setup relationship with lib A, B, C right?
>

Correct.  The top level CMakeLists.txt lets A B and C all build under a
single configuration.


One more question is, if use the upper level cmake list, lib_B , lib_C can
> be invoked directly without import in proj_a?
>

If you configure the top level project, you can always invoke make on only
the B or C targets via "make A" or "make B".  However, by having the
"project' command in the CMakeLists.txt for proj_b and proj_c, then those
can also be treated as fully independent projects of their own, meaning
they can either be configured by themselves or as a part of the top-level.

- 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

Re: [CMake] How to add dependency relations between libs and executable

[Chuck Atkins]

> in your proj_a example, when target_link_librairies invoke Lib B directly
> which generated in another project b, how does proj_a recognize it



> I think the reason is proj_a, b, c are all the sub directories of
> project root, if no root layer, B can not be invoked in proj_a, right?
>

That's correct.  In the example I gave, while proj_a, proj_b, and proj_c
are all sub-directories of the root level, only the root level, proj_b and
proj_c CMakeLists.txt files contain a separate project(...) command, which
meas that proj_b and proj_c can be configured and used independently but
proj_a cannot and needs to be configured from the root level where the B
and C targets are, in addition to their own separate projects, both
contained in the root level project(...) where A can see them.

- 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

Re: [CMake] CMake Reports Incorrect HDF5 Libraries on OS X after 3.6.0 Upgrade

[Chuck Atkins]

Hi Brennan,

We also just got the Homebrew cmake formula updated to explicitly include
the patch.  See https://github.com/Homebrew/homebrew-core/pull/2968

- Chuck

On Wed, Jul 13, 2016 at 11:10 PM, Breannan Smith 
wrote:

> Rad, I can verify that the issue is resolved in the git repo if anyone
> else is running into the bug. Thanks!
>
> On Tue, Jul 12, 2016 at 5:12 AM, Robert Maynard
>  wrote:
> > Hi Breannan,
> >
> > You can track the status of the fix at
> > https://gitlab.kitware.com/cmake/cmake/merge_requests/34
> >
> > On Mon, Jul 11, 2016 at 8:52 AM, Robert Maynard
> >  wrote:
> >> Hi Breannan,
> >>
> >> I am able to reproduce this and will start digging into why this is
> occurring.
> >>
> >> On Sun, Jul 10, 2016 at 6:34 PM, Breannan Smith <
> smithbrean...@gmail.com> wrote:
> >>> After upgrading to CMake 3.6.0 from 3.5.2, CMake fails to find HDF5 on
> OS X.
> >>>
> >>> With 3.5.2, find_package(HDF5 REQUIRED COMPONENTS C) reports the
> >>> following for HDF5_LIBRARIES. Note the presences of libhdf5.dylib, in
> >>> this list:
> >>>
> >>>
> /usr/local/Cellar/hdf5/1.8.16_1/lib/libhdf5.dylib;/usr/local/opt/szip/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib
> >>>
> >>> With 3.6.0, the same find_package command gives the following
> >>> HDF5_LIBRARIES. Notice that libhdf5.dylib is not even present:
> >>>
> >>>
> /usr/local/lib/libsz.dylib;/usr/lib/libz.dylib;/usr/lib/libdl.dylib;/usr/lib/libm.dylib
> >>>
> >>> The contents of the HDF5_LIBRARIES and HDF5_C_LIBRARIES are the same
> >>> under 3.6.0. Interestingly, the FindHDF5.cmake module does not report
> >>> a failure under 3.6.0 even though it fails to locate the HDF5 library.
> >>>
> >>> I did not see any changes to FindHDF5.cmake listed under the 3.6
> >>> release notes [1], but diffing the module files there were extensive
> >>> edits made.
> >>>
> >>> Has anyone else run into this issue or found a fix? Thank you!
> >>>
> >>> [1] https://cmake.org/cmake/help/v3.6/release/3.6.html
> >>> --
> >>>
> >>> 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
> --
>
> 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
>
-- 

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

Re: [CMake] custom build

[Chuck Atkins]

Hi Lev,

However, the target builds only if I explicitly say 'make foo_sqlite'. So
> far
> so good. Is there any way I can make it build if I just say 'make'?
>

See the add_custom_target documentation for the ALL option,
https://cmake.org/cmake/help/v3.6/command/add_custom_target.html


And, there are more then one sqlite database to build, how can I make the
> rule to be generic? Can I say *.sql, *.sqlite?
>

The problem with using wild cards is that they won't be sensitive to make
detecting file changes.  For example, if you add a new file then CMake
won't automatically re-run because the *.sql statement hasn't changed.  You
should also be able to replace the separate custom_target and
custom_command with a single custom_target:

add_custom_target(foo ALL sqlite3 -init foo.sql foo.sqlite)

You could also wrap the call in a macro for convience:

macro(add_sqlite_target name)
  add_custom_target(${name} ALL sqlite3 -init
${CMAKE_CURRENT_SOURCE_DIR}/${name}.sql
${CMAKE_CURRENT_BINARY_DIR}/${name}.sqlite BYPRODUCTS
${CMAKE_CURRENT_BINARY_DIR}/${name}.sqlite SOURCES ${name}.sql)
endmacro()

add_sqlite_target(fooA)
add_sqlite_target(fooB)
add_sqlite_target(fooC)
add_sqlite_target(fooD)

Note the addition of BYPRODUCTS and SOURCES.  This adds additional
dependency information if you decided to either a) make other targets that
consume the database or b) have other targets that produce the source code.

- 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

Re: [CMake] FindLibXml2.cmake: rename "LIBXML2_DEFINITIONS"

[Chuck Atkins]

Hi Yaron,


I think it should b renamed to "LIBXML2_COMPILE_FLAGS".
>

Xxx_DEFINITIONS is one of the standard variable names for a given
FindXxx.cmake find module, see
https://cmake.org/cmake/help/v3.6/manual/cmake-developer.7.html#standard-variable-names
.



> If u wish, I can submit a patch.
>

Thank you for the enthusiasm!   If you would like to improve on the
FindLibXML2 module, which really hasn't been touched in several years aside
from formatting changes, rather than mess with the varible names I would
instead suggest you look at creating an imported target for what get's
found.  That would certainly help bring the find module up to more modern
CMake conventions and would be greatly 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

Re: [CMake] Does Makefile generated by CMake support make -jN?

[Chuck Atkins]

>
> Thanks for your analysis for me Andrew. I can't use "-j" options, i think
> the

reason is the project i dealed with is not parallel. Thus when i use "make
> -jN", it couldn't work correctly every time. Obviously it caused by the
> Makefile generated by CMake, so i wonder if there are some CMake options to
> use CPU effectively.


This usually means missing dependencies the CMakeLists.txt files.  Because
of this you get unpredictable results when compiling in parallel.  Check
your dependencies on targets, link lines, and source files and make sure
they are all correct and not missing anything.



> Because i found when i use already exist Makefile, just
> use "make", it used about 480% CPU.


The Makefile is probably explicitly adding a fixed number of -j options.
CMake will not do this and instead rely on the user to call make with their
desired appropriate level of parallelism.



> And when i use CMake generated Makefile, it just uesd about 96% CPU. The
> "hardware acceleration" i said means how to
> CPU more effectively in CMake.
>

-jN is as good as it gets for make.  That being said, you can always try a
different generator, like Ninja, which tends to have quite a bit better
build times in parallel.

First things first though, you need to get your dependency problem squared
away.  That's the underlying cause of why your parallel builds with -j are
unpredictable.
-- 

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

Re: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux)

[Chuck Atkins]

FWIW, we've moved to CentOS 6 for the binaries we package and distribute
for ParaView.  It's about the oldest widely deployed Linux distro that's
still actively supported (EL5 is EOL'd and most deployments have long since
moved to 6 or 7).  it's binaries are compatible with virtually all current
Linux distros.  It also has newer compilers available (gcc 5.3 through the
devtoolset-4 package) that can build C++11 binaries compatible with the
older systems.

- Chuck

On Fri, Feb 3, 2017 at 3:46 PM, Alexander Neundorf 
wrote:

> On 2017 M02 2, Thu 20:07:29 CET you wrote:
> > Hi Gonzalo,
> >
> > Using the dockcross/manylinux-x64 docker image should allow to build you
> > project out-of-the-box.
> > It is based on Centos5, include recent gcc, CMake, Git, etc ...
> >
> > See https://github.com/dockcross/dockcross
> >
> > In a nutshell,
> >
> > # Pull image
> > docker pull dockcross/manylinux-x64
> >
> > # Generate helper script
> > docker run --rm dockcross/manylinux-x64 > dockcross-manylinux-x64
> > chmod +x ./dockcross-manylinux-x64
> > mv ./dockcross-manylinux-x64 ~/bin/
> >
> > # Build your project
> > cd /path/to/src
> > dockcross cmake -Bbuild -H. -GNinja
> >
> >
> > The directory build will then contain the build tree of your project
> > compiled using gcc provided by the Centos5 image and link against an old
> > glibc.
>
> when docker starts, you are usually root in the container, and if then
> something is built, the files belong to root, and not the user as which
> you are
> logged in.
> How do you handle that ?
> I just found a hackish way (a shell script which sets up a user with the
> same
> numerical ID) to have the same user ID in the container as on the host
> system.
> Is there a better way ?
>
> Alex
>
> --
>
> 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
>
-- 

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

Re: [CMake] cmake 3.7.2 centos 7 :: kwsys.testSystemTools (Failed)

[Chuck Atkins]

Hi Adrian,

I'd suggest taking the issue up with the package maintainer.  The upstream
source for CMake 3.7.2 configures, builds, and passes all tests on EL7 so
the problem seems to lie in how the RPM SPEC file is driving the build.

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

On Thu, Feb 16, 2017 at 3:32 AM, Adrian Sevcenco <adrian.sevce...@cern.ch>
wrote:

> On 02/15/2017 09:04 PM, Chuck Atkins wrote:
>
>> Hi Adrian,
>>
> Hi! and thank you for looking into this problem!
>
>
> So, would this imply that cmake is not supported on EL7 because gcc
>> does not support cxx11 ?
>>
>>
>> That's not really what's happening.  CMake is testing the C compiler to
>> determine whether or not it supports C11 features and the C++ compiler
>> to see if it supports C++11.  The error messages are expected in many of
>> the test cases.  Here it's jsut checking to see if what it knows about
>> the features supported by the specific version of GCC line up correctly
>> with reality.  i.e. CMake thinks that gcc 4.8.2 supports certain
>> features so it tests them to make sure.  So it's not saying that CMake
>> isn't supported, just that the 1 specific test failed for some reason.
>>
>
>
>>
>>
>> So, does anyone have any idea what is the latest 3.x version that
>> can be built on centos 7?
>>
>>
>> All that being said, I wasn't able to reproduce the error with the
>> current 3.7.2 release:
>>
>> [chuck.atkins@deepthought v3.7.2]$ lsb_release -d
>> Description:CentOS Linux release 7.3.1611 (Core)
>> [chuck.atkins@deepthought v3.7.2]$ gcc --version
>> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>> ...
>> [chuck.atkins@deepthought v3.7.2]$ ../../source/v3.7.2/bootstrap
>> --parallel=28
>> ...
>> CMake has bootstrapped.  Now run gmake.
>> [chuck.atkins@deepthought v3.7.2]$ make -j28
>> ...
>> 100%] Built target ctest
>> [chuck.atkins@deepthought v3.7.2]$ ./bin/ctest -j 28
>> ...
>> 100% tests passed, 0 tests failed out of 431
>>
>> Label Time Summary:
>> Label1=   0.51 sec (1 test)
>> Label2=   0.51 sec (1 test)
>>
>> Total Test time (real) = 247.03 sec
>> [chuck.atkins@deepthought v3.7.2]$
>>
>> What specific versionof EL7 are you running and which version of GCC?
>>
> the standard ones :
> lsb_release -d
> Description:CentOS Linux release 7.3.1611 (Core)
>
> gcc --version
> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>
> i try to create cmake rpm based on the spec of
> cmake-3.6.2-6.fc25.src.rpm
> from which i removed most of the patches (i just want an rpm for centos 7)
> and used source of 3.7.2
>
> Thank you!!
> Adrian
>
>
>
>
>
>
>
-- 

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

Re: [CMake] Default CMAKE_C_FLAGS value by OS

[Chuck Atkins]

Hi YC,


> cmake version on fedora 25: 3.6.2
>

Fedora is specifically patching CMake in the RPM spec file to reduce the
gcc flag from O3 to O2 so it's the distributuion's packaging making that
change, not CMake itself.  If you download and build the source from
cmake.org then you'll get O3 as default for gcc release builds.

That being said, I do think we should revisit the use of O3 by default
given the safety issues surounding 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

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

[Chuck Atkins]

Hi Soumaia,
Please keep conversations on the mailing list so others can benefit from it
as well.  Also, I've moved this over to the CMake Users list at
cmake@cmake.org as it's a more appropriate place for this than that
developers list.


can you help me please how can i do this setup ?
>

All you should need to do is source the setup script as I described here:

source /opt/intel/bin/compilervars.sh intel64
>

That should place the compilers in the search path for your current shell.

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

Re: [CMake] cmake 3.7.2 centos 7 :: kwsys.testSystemTools (Failed)

[Chuck Atkins]

Hi Adrian,

So, would this imply that cmake is not supported on EL7 because gcc does
> not support cxx11 ?
>

That's not really what's happening.  CMake is testing the C compiler to
determine whether or not it supports C11 features and the C++ compiler to
see if it supports C++11.  The error messages are expected in many of the
test cases.  Here it's jsut checking to see if what it knows about the
features supported by the specific version of GCC line up correctly with
reality.  i.e. CMake thinks that gcc 4.8.2 supports certain features so it
tests them to make sure.  So it's not saying that CMake isn't supported,
just that the 1 specific test failed for some reason.



> So, does anyone have any idea what is the latest 3.x version that can be
> built on centos 7?
>

All that being said, I wasn't able to reproduce the error with the current
3.7.2 release:

[chuck.atkins@deepthought v3.7.2]$ lsb_release -d
Description:CentOS Linux release 7.3.1611 (Core)
[chuck.atkins@deepthought v3.7.2]$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
...
[chuck.atkins@deepthought v3.7.2]$ ../../source/v3.7.2/bootstrap
--parallel=28
...
CMake has bootstrapped.  Now run gmake.
[chuck.atkins@deepthought v3.7.2]$ make -j28
...
100%] Built target ctest
[chuck.atkins@deepthought v3.7.2]$ ./bin/ctest -j 28
...
100% tests passed, 0 tests failed out of 431

Label Time Summary:
Label1=   0.51 sec (1 test)
Label2=   0.51 sec (1 test)

Total Test time (real) = 247.03 sec
[chuck.atkins@deepthought v3.7.2]$

What specific versionof EL7 are you running and which version of GCC?

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

Re: [CMake] latest cmake 3.6.1 building in AIX can not find symbol `.w32attrset`

[Chuck Atkins]

Hi Zeson,
We do have a nightly build on AIX with both GCC and IBM XL.  It does build
correctly using curses instead ncurses, as you mention, but the machine we
use doesn't have ncurses on it, only curses, so it doesn't have this
problem of accidentally finding the wrong curses library. When configuring
your build, try adding -DCURSES_NCURSES_LIBRARY=IGNORE to prevent
FindCurses from picking the wrong one.

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

On Fri, Aug 19, 2016 at 5:14 AM, Zeson Wu <westion...@gmail.com> wrote:

> /usr/bin/g++-Wl,-bnoipath -Wl,-brtl CMakeFiles/ccmake.dir/CursesDi
>> alog/cmCursesOptionsWidget.cxx.o 
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesBoolWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesCacheEntryComposite.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesDummyWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesFilePathWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesForm.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesLabelWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesLongMessageForm.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesMainForm.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesPathWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesStringWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/cmCursesWidget.cxx.o
>> CMakeFiles/ccmake.dir/CursesDialog/ccmake.cxx.o  -o ../bin/ccmake
>> -Wl,-bexpall libCMakeLib.a CursesDialog/form/libcmForm.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/lib/libcmcurl.a
>> ../Utilities/cmzlib/libcmzlib.a -lld ../Utilities/cmjsoncpp/libcmjsoncpp.a
>> */usr/lib/libncurses.a* /opt/freeware/lib/gcc/powerpc-
>> ibm-aix7.1.0.0/4.9.2/libgcc_eh.a /opt/freeware/lib/gcc/powerpc-
>> ibm-aix7.1.0.0/4.9.2/libgcc_eh.a -Wl,-blibpath:/opt/freeware/li
>> b/gcc/powerpc-ibm-aix7.1.0.0/4.9.2:/opt/freeware/lib:/usr/lib:/lib
>> ld: 0711-317 ERROR: Undefined symbol: .w32attrset
>> ld: 0711-317 ERROR: Undefined symbol: .w32insch
>> ld: 0711-317 ERROR: Undefined symbol: .w32addch
>> ld: 0711-317 ERROR: Undefined symbol: .w32attron
>> ld: 0711-317 ERROR: Undefined symbol: .w32attroff
>> ld: 0711-317 ERROR: Undefined symbol: .initscr32
>> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
>> information.
>> collect2: error: ld returned 8 exit status
>>
>>
> In AIX, it links with */usr/lib/libncurses.a* library which does not have
> such symbol. It should be */usr/lib/libcurses.a*. In AIX, it uses 
> */usr/include/curses.h
> *and can not find ncurses.h in /usr/include. It must be something wrong
> with* Modules/FindCurses.cmake*.
>
> --
> Zeson
>
> --
>
> 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
>
-- 

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

Re: [CMake] Correct way to use ARMCC (Files in Modules/Compiler/ARMCC*)

[Chuck Atkins]

>
> 1. Toolchain needs to be in a separate file
>

Yes, that is certainly best practice and makes the rest of the
cross-compiling infrastructure just work better.



> 2.  That file needs to be called before the project line of your
> CMakeLists.txt
>

You actually shouldn't be "calling" it at all.  You specify it with cmake
-DCMAKE_TOOLCHAIN_FILE=/path/to/MyARMStuff.cmake ...[other cmake options]
/path/to/source.  CMake then explicitly processes the toolchain file in a
few different places but handles when to do this internally.  Basically you
write your CMakeLists.txt without worrying much about cross-compiling and
you specify the toolcain file to let CMake deal with the cross-compile
aspect.
-- 

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

Re: [CMake] FindMPI

[Chuck Atkins]

Hi Zaak,

When using CMake, it's generally best to use the actual compiler rather
than any compiler wrappers (with Cray being the exception).  Given that,
set the CC, CXX, and FC environment variables to the actual compilers you
want to use and then the MPI_{C,CXX,Fortan}_COMPILER CMake variables the
MPI wrappers.  FindMPI will then interrogate the MPI wrappers to extract
the appropriate include and link options.

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


On Mon, Nov 28, 2016 at 9:58 AM, Chuck Atkins <chuck.atk...@kitware.com>
wrote:

> Pass the following CMake options at configure time:
>
> -DMPI_C_COMPILER=/path/to/mpicc
> -DMPI_CXX_COMPILER=/path/to/mpiCC
> -DMPI_Fortran_COMPILER=/path/to/mpif90
>
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
>
>
> On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman <zbeek...@gmail.com> wrote:
>
>> Hi,
>>
>> I want to be able to pass FC=mpif90 (or FC=$(which mpif90)) and CC=mpicc
>> etc. OR also be able to pass a compiler and use FindMPI to add link,
>> compile and include flags. I'm encountering an issue when my MPI
>> implementation is not on my PATH, I want CMake to be able to look in an
>> additional location (our build script can download and build MPICH and by
>> default installs it in user space) and also resolve where mpif90 is coming
>> from and look there too.
>>
>> Whats the correct way to pass HINTS or PATHS to FindMPI? i.e., how do I
>> specify additional locations to search?
>>
>> Using `find_package` with HINTS and PATHS means that it doesn't use
>> FindMPI. I also tried setting CMAKE_SYSTEM PREFIX_PATH, but I think that's
>> a cache variable set early, so it's not having an effect.
>>
>> It would be great if FindMPI used the realpath of mpif90 etc when passed
>> as $FC.
>>
>> TIA
>>
>> --
>>
>> 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
>>
>
>
-- 

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

Re: [CMake] FindMPI

[Chuck Atkins]

Pass the following CMake options at configure time:

-DMPI_C_COMPILER=/path/to/mpicc
-DMPI_CXX_COMPILER=/path/to/mpiCC
-DMPI_Fortran_COMPILER=/path/to/mpif90

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


On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman <zbeek...@gmail.com> wrote:

> Hi,
>
> I want to be able to pass FC=mpif90 (or FC=$(which mpif90)) and CC=mpicc
> etc. OR also be able to pass a compiler and use FindMPI to add link,
> compile and include flags. I'm encountering an issue when my MPI
> implementation is not on my PATH, I want CMake to be able to look in an
> additional location (our build script can download and build MPICH and by
> default installs it in user space) and also resolve where mpif90 is coming
> from and look there too.
>
> Whats the correct way to pass HINTS or PATHS to FindMPI? i.e., how do I
> specify additional locations to search?
>
> Using `find_package` with HINTS and PATHS means that it doesn't use
> FindMPI. I also tried setting CMAKE_SYSTEM PREFIX_PATH, but I think that's
> a cache variable set early, so it's not having an effect.
>
> It would be great if FindMPI used the realpath of mpif90 etc when passed
> as $FC.
>
> TIA
>
> --
>
> 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
>
-- 

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

Re: [CMake] FindMPI

[Chuck Atkins]

Hi Zaak,

Sorry for the first mail being so abrupt, I didn't mean to hit "send" so
soon.



> I took a look at the FindMPI CMake module, and it seems as though you can
> set MPI_HOME to a list of directories to search.
>

That's also another way of doing it, which would probably be easier than
what I iniitially suggested; the former has just become my own habbit since
MPI_HOME isn't always set.  MPI_HOME is used as a hint to search for
mpiexec.  If mpiexec is found, it then uses it's location as a basis for
locating the compiler wrappers.

That being said, if using MPI through an environment module (as is the
typical use case) then FindMPI should "just work" as the wrappers generally
end up in the path when the appropriate MPI module is loaded.  If you need
to point to an entirely external MPI not part of your environment at all
though, then using the MPI_HOME env var or MPI__COMPILER CMake vars
is the way to do it.



> Would KitWare accept a pull request or a patch that expands the
> documentation of FindMPI
>

Of course :-).  Expanding the "Usage" section in FindMPI to include using
the MPI_HOME environment variable would be a good place for that.



> and/or adds some clearer additional features to the call signature (like
> HINTS and PATHS)?
>

Could you clarify what you mean by this?  To which call signature?


- 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

Re: [CMake] Building CMake without Curl

[Chuck Atkins]

Hi Jayesh,

CMake includes internal versions of all the dependencies it needs to
build.  You have the option of using an external system-supplied version
but it's certainly not required.  Without OpenSSL you'll just have a cmake
that can't use https, certainly not the end of the world.  The default
configuration of the ./bootstrap command should be using internal versions
of all of CMake's dependencies.  Is that causing problems for you?


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


On Wed, Nov 2, 2016 at 1:08 PM, Jayesh Badwaik <pub...@jayeshbadwaik.in>
wrote:

> Hi,
>
> Is there a way to build CMake without curl? I am currently in an
> environment
> where I have no openssl-dev packages nor libcurl-dev packages. So, if I
> want
> to build CMake, I will need to build openssl-dev myself which I do not
> want to
> do.
>
> I can ask my sysadmin for the packages, but I was wondering if there is
> another method. A follow up question would be, if this is not possible,
> why is
> libcurl essential to Cmake?
>
>
> --
> Cheers
> Jayesh Badwaik
> https://www.jayeshbadwaik.in
> --
>
> 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
>
-- 

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

Re: [CMake] Building CMake without Curl

[Chuck Atkins]

It looks like you're using an existing configuration already set to use
system installed libraries.  Try from a clean source tree and an
out-of-source (the recommend way to do all cmake things) build directory.
Using the 3.6.2 tarball, I get:

$ tar -xvf cmake-3.6.2.tar.gz
... lots of tar output ...
$ mkdir cmake-3.6.2-build
$ cd cmake-3.6.2-build
$ ../cmake-3.6.2/bootstrap --prefix=../cmake-3.6.2-install
-
CMake 3.6.2, Copyright 2000-2016 Kitware, Inc.
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++
Makefile processor on this system is: gmake
g++ is GNU compiler
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has stl wstring
-
... lots of compile output ...
loading initial cache file /home/khq.kitware.com/chuck.
atkins/Code/CMake/source/cmake-3.6.2-build/Bootstrap.
cmk/InitialCacheFlags.cmake
-- The C compiler identification is GNU 6.2.1
-- The CXX compiler identification is GNU 6.2.1
... lots of cmake output ...
-
CMake has bootstrapped.  Now run gmake.
$


At this point, if you run "make help" then you'll get a list of available
targets.  In there, amongst others, you will see cmzlib, cmcurl, cmbzip2,
cmliblzma, cmlibarchive, cmexpat, and cmjsoncpp.  These are CMake's
internal copies of the dependencies.  When bootstrap is run with
--system-libs then system versions of those dependencies will be used
instead and the previously mentioned cm targets will not exist in
the make help output.



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


On Thu, Nov 3, 2016 at 10:47 AM, Jayesh Badwaik <pub...@jayeshbadwaik.in>
wrote:

> > CMake includes internal versions of all the dependencies it needs to
> > build.  You have the option of using an external system-supplied version
> > but it's certainly not required.  Without OpenSSL you'll just have a
> cmake
> > that can't use https, certainly not the end of the world.  The default
> > configuration of the ./bootstrap command should be using internal
> versions
> > of all of CMake's dependencies.  Is that causing problems for you?
>
> Yes. The bootstrap command runs successfully, but after that it advises me
> to
> run gmake, which fails. I've attached the errors of the bootstrap command
> and
> the gmake command in this mail.
>
> --
> Cheers
> Jayesh Badwaik
> https://www.jayeshbadwaik.in
>
-- 

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

Re: [CMake] [SOLVED] RE: Crosscompilation woes

[Chuck Atkins]

In VTK and ParaView we use a manual two-step build.  The first pass
configures a host build of the cross-compile utilities and the second pass
configures a target build with a toolchain file, which requires you tell it
where the host tools are.  So the build process looks like this:

mkdir build_host
cd build_host
cmake -DBUILD_CROSSTOOLS=ON /path/to/source
make
cd ..
mkdir build_target
cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/tolchain.cmake
-DFOO_CROSSTOOLS_DIR=/path/to/build_host
make

You should be able to adapt this to a superbuild scenario with two external
projects and it seems like that's exactly what you've done.  Just
confirming that yes that's a sane approach and that's how we do it to.


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


On Mon, Oct 10, 2016 at 9:56 AM, Robert Bielik <robert.bie...@dirac.com>
wrote:

> For reference: I went with Brads suggestion: https://gitlab.kitware.com/
> cmake/cmake/issues/16356
>
>
>
> which seems to be working fine.
>
>
>
> Regards
>
> /R
>
>
>
> *From:* CMake [mailto:cmake-boun...@cmake.org] *On Behalf Of *Robert
> Bielik
> *Sent:* den 10 oktober 2016 14:00
> *To:* Craig Scott <craig.sc...@crascit.com>
>
> *Cc:* Cmake@cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
>
>
> I am using a toolchain file! The CC and CXX environment variables are set
> by CMake (I assume, because I haven’t touched them).
>
>
>
> I’ll disect the link to see what I’ve missed.
>
>
>
> Regards
>
> /R
>
>
>
> *From:* Craig Scott [mailto:craig.sc...@crascit.com
> <craig.sc...@crascit.com>]
> *Sent:* den 10 oktober 2016 13:56
> *To:* Robert Bielik <robert.bie...@dirac.com>
> *Cc:* Cmake@cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
>
>
> Don't use environment variables to set the ARM compilers in your
> situation, use a toolchain file to specify them instead. Your CMake
> experience will generally be smoother if you specify cross-compile details
> via toolchain files. If you are following the method in the stackoverflow
> link I mentioned last time, the host part of the build will then pick up
> the host compilers and the ARM part of the build will use the compilers
> from the toolchain file.
>
>
>
>
>
> On Mon, Oct 10, 2016 at 10:50 PM, Robert Bielik <robert.bie...@dirac.com>
> wrote:
>
> I’m trying to do this, but since I setup a cross compiling env. by setting
> C++ compiler, these settings get used when I run execute_process to setup
> the host build !! Thus I get the ARM version of the build tools anyway! :(
>
>
>
> It seems that when execute_process is executed, the CC and CXX environment
> variables are set, which makes cmake use those when generating the
> makefiles.
>
>
>
> Ideas are most welcome!
>
>
>
> Regards
>
> /R
>
>
>
> *From:* Craig Scott [mailto:craig.sc...@crascit.com]
> *Sent:* den 10 oktober 2016 10:47
> *To:* Robert Bielik <robert.bie...@dirac.com>
> *Cc:* Cmake@cmake.org
> *Subject:* Re: [CMake] Crosscompilation woes
>
>
>
> Here's one possible solution (not perfect, but has been working in
> production for us for a while now for a similar scenario to what you
> describe):
>
>
>
> http://stackoverflow.com/q/36084785/1938798
>
>
>
> An alternative is a superbuild arrangement which would require a top level
> project to drive two sub-builds brought in via ExternalProject
> <https://cmake.org/cmake/help/latest/module/ExternalProject.html>, one
> for the host and the other for arm. This is both better and worse,
> depending on your point of view, so you may need to do some
> research/experimenting to see which is a better fit for your situation.
>
>
>
>
>
> On Mon, Oct 10, 2016 at 7:29 PM, Robert Bielik <robert.bie...@dirac.com>
> wrote:
>
> Hi all,
>
> I am crosscompiling a project for arm (on linux i686), and use
> codegeneration tools within the project (together with add_custom_command).
> Of course, this will fail, since the tools are compiled for arm also and
> thus won't execute on my host system. So the tools need to be compiled for
> i686 whilst the rest for arm. I'm sure this can be handled by CMake
> although haven't done it before so would appreciate pointers :)
>
> Regards
> /Robert
>
> --
>
> 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.or

Re: [CMake] OBJECT libraries and INTERFACE_SOURCES

[Chuck Atkins]

Hi Giovanni,
Does it work if you add lib1 as a private dependency of lib2?  i.e.:
target_link_libraries(lib2 PRIVATE lib1)

Also, it shouldn't matter but what about in your original example if you
use the full path to the source file instead while still keeping the public
link dependency?  i.e.:
add_library(lib1-obj OBJECT $(CMAKE_CURRENT_SOURCE_DIR}/lib1.cpp).

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


On Fri, Dec 9, 2016 at 5:26 AM, Giovanni Funchal <g...@cloudnc.co.uk> wrote:

> Hi,
>
> Apologies, the problem wasn't properly minimised because I had some
> trouble wrapping my head around it. Here's two complete examples which I
> hope can explain the problem better this time.
>
> 1) This works:
>
> [CMakeLists.txt]
> cmake_minimum_required(VERSION 3.6)
> project(Test)
> add_library(lib1-obj OBJECT lib1.cpp)
> add_library(lib1 INTERFACE)
> set_target_properties(lib1 PROPERTIES INTERFACE_SOURCES
> $)
> add_library(lib2 lib2.cpp)
> target_link_libraries(lib2 lib1)
> add_executable(main main.cpp)
> target_link_libraries(main lib2)
>
> 2) But this does not:
>
> [CMakeLists.txt]
> cmake_minimum_required(VERSION 3.6)
> project(Test)
> add_library(lib1-obj OBJECT lib1.cpp)
> add_library(lib1 INTERFACE)
> set_target_properties(lib1 PROPERTIES INTERFACE_SOURCES
> $)
> add_library(lib2 lib2.cpp)
> target_link_libraries(lib2 lib1)
> add_subdirectory(main)
>
> [main/CMakeLists.txt]
> add_executable(main main.cpp)
> target_link_libraries(main lib2)
>
> With the second example, I get an error "cannot find source file
> lib1.cpp.o tried extensions...".
>
> Thanks,
> -- Giovanni
>
>
> On Thu, Dec 8, 2016 at 9:56 PM, Stephen Kelly <steve...@gmail.com> wrote:
>
>> Giovanni Funchal wrote:
>>
>> > Hi,
>> >
>> > The help page [1] mentions that:
>> >
>> >> Although object libraries may not be named directly in calls to the
>> >> target_link_libraries() command, they can be “linked” indirectly by
>> >> using an Interface Library whose INTERFACE_SOURCES target property
>> >> is set to name $.
>> >
>> > However, I was unable to get this to work. Doing this:
>> >
>> > add_library(lib-obj OBJECT test.cpp)
>> > add_library(lib INTERFACE)
>> > add_dependencies(lib lib-obj)
>> > set_target_properties(lib PROPERTIES INTERFACE_SOURCES
>> > $)
>> >
>> > And then trying to specify lib in link_libraries of an executable yields
>> > an error message "Cannot find source file: ... Tried extensions:... ".
>> >
>> > Am I doing something wrong?
>>
>> This works for me:
>>
>> cmake_minimum_required(VERSION 3.3)
>>
>> project(testit CXX)
>>
>> add_library(lib-obj OBJECT foo.cpp)
>> add_library(lib-iface INTERFACE)
>> set_target_properties(lib-iface PROPERTIES
>>   INTERFACE_SOURCES $
>> )
>> add_executable(main foo-user.cpp)
>> target_link_libraries(main lib-iface)
>>
>>
>> Thanks,
>>
>> Steve.
>>
>>
>> --
>>
>> 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
>
>
>
> --
>
> 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
>
-- 

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

Re: [CMake] FindMPI

[Chuck Atkins]

> why does it not interrogate the MPI wrapper if set as FC or CC?
>

CC, CXX, and FC env vars are just used to initialize the
CMAKE_{C,CXX,Fortran}_COMPILER variables wihch CMake will then use as the
"regular" compilers for a given language.  If those regular compilers
already work with MPI then there's no need to retrieve the underlying
settings that it uses.



> Would there be any harm in attempting to pull out the
> {LIBRARIES,INCLUD_DIRS} etc.?
>

They should be empty.  People often think of the variables as "this is
where MPI things are" which is not really what they mean.  What they are
saying is "these are the extra things to add when useing MPI".  So if your
primary compiler is an MPI wrapper then there's no extra includes or
libraries to add.

- 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

Re: [CMake] FindMPI

[Chuck Atkins]

>
> As far as enhancements to FindMPI go, It might be worthwhile to check if
> FC, CC,CXX match any obvious MPI wrappers, and then set MPI__compiler
> and select the MPI version from there: If the user set the compiler
> explicitly to an MPI wrapper, that's likely the MPI they intend to use
> If I find some time maybe I'll work up a pull request for this.
>

It's actualy already there since this is the default and preferred behavior
in Cray systems.  As a fallback if MPI can't be found, then it tests the
regular compilers.  If successful,  it will not interrogate them and
MPI_FOUND wll be true but the MPI__{LIBRARIES,INCLUDE_DIRS} variables
will be empty.  Instead it will explicitly set
MPI__COMPILER_NO_INTERROGATE=/path/to/mpi{cc,c++,f90}.  Look around
line 600 (try_reguilar_compiler and interrogate_mpi_compiler)

I think the logic is a bit backwards on this and if you were to make a
change, I'd suggest it be there and re-order a few things such that if MPI
things haven't been already explicitly set then the *first* thing to do
(rather than last) is test the regular compilers, then if those don't work,
search for and interrogate the MPI wrappers.

- 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

Re: [CMake] Duplicating a shared library and replacing target link libraries

[Chuck Atkins]

>
> The library linking against "originalLibraryForward" has to be
> compiled from the original sources too. Actually performing the

linking step should be sufficient. Is there a way to accomplish that?
>

Object libraries are what you need here.  See
https://cmake.org/cmake/help/v3.7/manual/cmake-buildsystem.7.html#object-libraries
.  Essentially you'll do something like this:

add_library(fooObj OBJECT ${foo_Common_Sources})
add_library(foo $ ${foo_RealOnly_Sources})
add_library(fooMock $ ${foo_MockOnly_Sources})


The function does not work when the library passed to
> AddMockedLibrary() uses target_link_libraries() with IMPORTED targets
> from, e. g. calls to find_package(). In order to make creating the
> _MOCK-Library work I have to duplicate the original call to
> find_package() before calling AddMockedLibrary(). Is there a way to
> automate this as well?
>

You might be able to go down the route of creating an INTERFACE library
with all of the common properties necessary for both the actual and mock
libraries.  You could then add the interface lib as a public dependency
with target_link_libraries(foo PUBLIC fooInterface) and
target_link_libraries(fooMock PUBLIC fooInterface).  It's a bit convoluted
but I think it could work well here for you.

- 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

Re: [CMake] Link to local glibc

[Chuck Atkins]

>
> I'll try and see if I can compile a gcc 4.9.3 chain on the CentOS 5
> machine (I need C++11).
>
I'd suggest using the devtollset repo from
https://people.centos.org/tru/devtools/devtools.repo


> The docker container looks interesting but I haven't used it yet: does it
> need some specific install on the target machine? I don't have any install
> rights on the Cento 5.11 machine
>

I think you misunderstand.  I meant to use a docker container on your
Ubuntu machine running CentOS 5 as a development environment.  That way you
can use your Ubuntu workstation to build in a CentOS 5 environment.

- 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

Re: [CMake] Link to local glibc

[Chuck Atkins]

If you're using a newer Ubuntu environment, I'd suggest using a CentOS 5
docker container.   Either that or the VM.

- Chuck

On Tue, Mar 7, 2017 at 1:53 PM, Marcel Loose  wrote:

> Hi Michele,
>
> This could become a painful exercise. You basically have two options:
> 1) Treat it as a cross-compilation project, or
> 2) Create a virtual machine running CentOS 5.8 and do the build there.
> If I were you, I would go for the second option.
>
> Cheers,
> Marcel.
>
> Op 07-03-17 om 17:56 schreef Michele Portolan:
> > Hello,
> >
> > I build on a Ubuntu machine (kernel 4.4.0-64-generic), but I need my
> > program to be executed on an old Cento 5.8 (kernel 2.6.18). I tried
> > compiling with "-static" to have static linking, but when I try to
> > execute I get "ERROR: Kernel too old!"
> >
> > I therefore locally compiled a glibc with support for kernel 2.6.18 ...
> > but how can I have Cmake use it instead of the system one?
> >
> > Thanks,
> >
> >
> > Michele
> >
>
>
>
> --
>
> 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
>
-- 

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

Re: [CMake] CMAKE_SIZEOF_VOID_P question

[Chuck Atkins]

Hi Thomas,

According to the documentation CMAKE_SIZEOF_VOID_P it is determined by
> running the compiler. However it seems that it is not using pertinent flags
> from the configuration, in particular CMAKE_C_FLAGS and CMAKE_CXX_FLAGS.
>

It is but the results from type size checking get saved in cache variables
so when run a second time, even though specifying extra CMAKE_CXX_FLAGS,
the CMAKE_SIZEOF_VOID_P variable already exists in cache so it's not
checked again.  If you clear your build directory before each invocation of
CMake then you should see it switch between 4 and 8 as expected.

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

Re: [CMake] Failed to build C++ source with CMakeLists.txt

[Chuck Atkins]

Hi Jupiter,


Compiling the C compiler identification source file "CMakeCCompilerId.c"
> failed.
> Compiler: /usr/local/gcc/4.9.1/bin/gcc
> Build flags: /usr/local/cppcms/1.1.0/include
>

It looks like you have an errant "/usr/local/cppcms/1.1.0/include" set in
your CFLAGS environment variable, or otherwise specified as a default
argument to the compiler, which is obviously not a valid flag.

- 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

Re: [CMake] OBJECT libraries and working around lake of target_link_libraries

[Chuck Atkins]

Hi David,


> Supporting OBJECT libraries in
> target_link_libraries calls was mentioned mentioned right back here
> https://cmake.org/pipermail/cmake-developers/2012-March/015422.html but
> sadly seems still to be on the back burner.
>

It's not on the back burner!  There has been progress on desiging the rest
of the implementation to make OBJECT libraries "first class citizens" and
I  can't give you actual dates I do believe you can probably expect it some
time this year.


>
> Not being
> able to use target_link_libraries with thier transitive nature made this
> very painful, many days of work.


I actually just recently went through the exercise of creating a workaround
for this in one of my projects so I can certainly understand the gaping
hole that is currently present.  The workaround I ended up with was to
create three seperate libraries: one for the objects, one for the usage
requirements, and then a third that combines them.

add_library(foo_objects OBJECT foo_src1.cxx foo_src2.cxx ...)

add_library(foo_interface INTERFACE)
target_link_libraries(foo_interface INTERFACE FooDepend1 FooDepend2 ...)
target_include_directories(foo_interface INTERFACE
  $
  $)

add_library(foo INTERFACE)
target_sources(foo INTERFACE $)
target_link_libraries(foo INTERFACE foo_interface)

The interface sources property on "foo" will populate the object files into
whatever uses "foo" in its target_link_libraries and then the usage
requirements in foo_interface will populate transitively.  The only problem
with this approach, and the reason for creating three separate libraries
instead of just adding the objects to the sources on foo_interface, is that
INTERFACE_SOURCES will continue to get propagated transitively potentially
causing duplicate symbols upstream, so it's really only appropriate for
private linking so you want to link publically then add the objects
manually and pass the interface publically.  This essentially means you
need to use it like this:

// Use foo privately, so just put "foo" in TLL and it just works
add_library(bar1 bar1_src1.cxx bar1_src2.cxx)
target_link_libraries(bar1 PRIVATE foo)

// Use foo publicly so we need to separately grab the objects and
// their usage requirements.
add_library(bar2
  bar2_src1.cxx bar2_src2.cxx
  $)
target_link_libraries(bar2 PUBLIC foo_interface)

This is effectively what the current plan is for the upstream
implementation, just all rolled into one; i.e. the objects get added to
whatever is explicitly linking with target_link_libraries, but all
transitive linkage only uses the interface usage requirements.  Plans, of
course, may change but that's what it's looking like right now, we just
need to find the time and funding to implement 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

Re: [CMake] CPack Multicore Usage

[Chuck Atkins]

> > In calls to cpack only one core is used if Makefiles are used. Is there
> any option to enable multicore?
>

It depends on what your trying to achieve.  Typically the bottleneck for
CPack is in the compression step of the resulting tar (or rpm, etc.).  In
that case, CMake is limited by the libarchive, libz, libbz2, liblzma, etc.
implementations it's linked to, which are typically single threaded.  It's
really no different than taking an install tree and running "tar -czf
foo.tgz /path/t/foo-prefix".  So in that sense, even if you can
parallelizes the "temporary" install step where it collects the files to
packages, actually generating and compressing the package, which is the
costly part, will likely remain a single process.
-- 

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

Re: [CMake] CPack Multicore Usage

[Chuck Atkins]

>
> cause cpack does not "rebuild" the software again, it uses the compiled
> software and just starts the "install" into its _CPack_Packages
> subdirectories
>

Just running `cpack` does not.  However, CMake does generate a "package"
make target that is tied into your dependencies, so if instead of running
`make -jN; cpack` you could also run 'make -jN package' which will run the
build, since it's a dependency of the package target.

- 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

Re: [CMake] Unable to build cmoka project using cmake

[Chuck Atkins]

Hi Rajesh, so you're saying it works with 3.8.2 but not with 3.9.x?  Can
you try with the recent release candidate, 3.9.0-RC5?  It would be helpful
to know the output from what you see on the version that works vs the one
that doesn't since it sounds like a possible regression.

Thanks.

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


On Fri, Jun 30, 2017 at 1:17 PM, Rajesh Kumar <thisiz...@gmail.com> wrote:

> Tried with cmake 3.8.2 version. Able to compile CMOCKA.
>
> Regards
> Rajesh
>
> On Wed, Jun 21, 2017, 3:10 PM Rajesh Kumar <thisiz...@gmail.com> wrote:
>
>> Hi Al,
>>
>> I am unable to build cmocka project using Cmake. The below are the errors
>> which I'm facing.
>>
>> "The C compiler identification is unknown"
>> "System is unknown to cmake, create: to use this system, please send your
>> config file to cm...@www.cmake.org so it can be added to cmake"
>>
>> Please suggest.
>>
>> Regards
>> Rajesh
>>
>
> --
>
> 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
>
-- 

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

Re: [CMake] Unable to build cmoka project using cmake

[Chuck Atkins]

Hi Rajesh,
 We would need more information to be useful:

   - What version of CMake are you using?
   - What compiler and version are you using?
   - What OS and version are you using?
   - Do you have separate source and build directories?
   - How are you running cmake?


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


On Wed, Jun 21, 2017 at 5:47 AM, Rajesh Kumar <thisiz...@gmail.com> wrote:

> Hi All,
>
> I am unable to build cmocka project using Cmake. The below are the errors
> which I'm facing.
>
> "The C compiler identification is unknown"
> "System is unknown to cmake, create: to use this system, please send your
> config file to cm...@www.cmake.org so it can be added to cmake"
>
> Please suggest.
>
> Regards
> Rajesh
>
> --
>
> 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
>
-- 

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

Re: [CMake] Emacs cmake-mode indentation flaw

[Chuck Atkins]

Hi Frank,
It's really a matter of personal style.  There's a multitude of different
ways that people format multi-line function calls so no one way is right or
wrong.  For instance:

foo(
  bar1
  bar2)

foo(
  bar1
  bar2
  )

foo(
  bar1
  bar2
)

foo(bar1
bar2)

foo(bar1
bar2
)

foo(bar1
bar2
)

All of which have their justifications.

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


On Fri, Jun 2, 2017 at 1:57 AM, Frank Roland <theldo...@hotmail.com> wrote:

> There is probably a faulty indentation implemented in cmake-mode for emacs
> regarding closing parens.
>
> If you have the following source code:
>
> foo(
>bar
> )
>
>
> I indents the closing parenwould expect it to be indented like this:
>
> foo(
>bar
>)
>
>
> I would expect the single closing paren to be not indendet.
>
>
> Can anybody confirm that this is an issue worth reporting?
>
>
> I could also create a pull request for a fix if there is interest in doing
> so.
>
>
>
> --
>
> 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
>
-- 

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

Re: [CMake] Different flags for compiling and linking with Fortran

[Chuck Atkins]

Hi Xavier,

CMAKE_MINIMUM_REQUIRED(VERSION 2.8.8)
>
...

> -- The C compiler identification is Clang 3.8.0
> -- The CXX compiler identification is Clang 3.8.0
> ...
>
-- The Fortran compiler identification is XL
>

What version of CMake are you using?  Give that the C and C++ compilers are
detected as Clang then I suspect it's rather old.  They should also be
detected as XL like the Fortran compiler.  Do you get the same XL Fortran
errors using a new version of CMake?

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

Re: [CMake] setting rpath-link

[Chuck Atkins]

Hi Petros,
This doesn't really answer your question but it may solve your problem a
different way.  I've fought this very same boost problem many times in the
past.  In my case it was needing to link against Matlab dev libraries,
which in turn pulled their own private copy of boost in.  I tried a similar
approach of rpath-link but it wasn't feasible since it had to work on
Windows as well.  The best way to address it, I found, was to use the bcp
tool that comes with boost to generate a copy of the boost source tree with
a different namespace.  So I created my own private boost in the kwboost::
namespace instead of boost:: with libraries kwboost_filesystem.so, etc.
That way I could guarantee that the version I used was exactly the version
I created and would in turn also not create the same problem for anybody
else when they linked to me.

- Chuck <(518)%20881-1183>

On Fri, Jun 16, 2017 at 10:50 AM, Mamales, Petros via CMake  wrote:

> Hi,
>
> I am in a situation where I have to use 2 versions of the boost library
> (c++), one “explicitly” and one indirectly (through a package that comes as
> a shared lib).
>
> The external package is to be considered as a black box.
>
> Playing around on the web (as I am rather new to it), I came across the
> very nice article:
>
> http://www.kaizou.org/2015/01/linux-libraries/
>
> which in the last section recommends the usage of
> –rpath-link=/path/to/old/boost
>
> How can I specify this in CMake (preferably in 3.5.2 , as this s the
> currently used version in the company I work for)?
>
> TIA,
>
> Petros
>
>
>
> PS: Issues of how this would propagate at installation phase, although
> very important, are not pressing right now, as manual workarounds can be
> employed, or another question later may be made ;-)
>
>
>
> --
>
> 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
>
-- 

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

Re: [CMake] Bootstrap fails to detect C++11 compiler on AIX 7.1/XL C 13.1.3 toolset

[Chuck Atkins]

Hi Nathan,
I am able to reproduce this error on our Dashboard machine; it should be
working and clearly it's not at the moment.

I will investigate...

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

On Tue, Dec 19, 2017 at 11:48 AM, Nathan Strong <gblues+cm...@gmail.com>
wrote:

> I am having difficulty building CMake on AIX 7.1 using IBM XL C 13.1.3,
> which seems to be the newest version as of April 2017.
>
> The bootstrap script fails with the following error:
>
> -
> CMake 3.10.1, Copyright 2000-2017 Kitware, Inc. and Contributors
> Found XL toolchain
> C compiler on this system is: xlc
> -
> Error when bootstrapping CMake:
> Cannot find a C++ compiler supporting C++11 on this system.
> Please specify one using environment variable CXX.
> See cmake_bootstrap.log for compilers attempted.
> -
> Log of errors: src/cmake-3.10.1/Bootstrap.cmk/cmake_bootstrap.log
> -
>
> Given that AIX is explicitly listed as a supported platform, and I am
> using the latest version of the IBM AIX compiler, I find this error dubious.
>
> Below is a the contents of the cmake_bootstrap.log, where we can see that
> it does try to use the appropriate -q flag to enable the compiler's
> supported C++11 features.
>
> Is XL C simply unsupported?
>
> --- paste below ---
> Checking for XL toolchain
> Try: xlc
> Line: xlc  cmake_bootstrap_18350136_test.c -o
> cmake_bootstrap_18350136_test
> --  file   ---
> int main() { return 0; }
> --
> Test succeeded
> Try: xlC
> Line: xlC  cmake_bootstrap_18350136_test.cpp -o
> cmake_bootstrap_18350136_test
> --  file   ---
> int main() { return 0; }
> --
> Test succeeded
> Checking whether 'xlc  ' works.
> Try: xlc
> Line: xlc   cmake_bootstrap_18350136_test.c -o
> cmake_bootstrap_18350136_test
> --  file   ---
>
> #ifdef __cplusplus
> # error "The CMAKE_C_COMPILER is set to a C++ compiler"
> #endif
>
> #if defined(__sun) && __STDC_VERSION__ < 199901L
> #error "On Solaris we need C99."
> #endif
>
> #include 
>
> int main(int argc, char* argv[])
> {
>   printf("%d%c", (argv != 0), (char)0x0a);
>   return argc - 1;
> }
>
> --
> 1
> Test succeeded
> Checking whether 'xlC  ' works.
> Try: xlC
> Line: xlC   cmake_bootstrap_18350136_test.cxx -o
> cmake_bootstrap_18350136_test
> --  file   ---
>
> #include 
> #include 
> #include 
>
> #if __cplusplus < 201103L
> #error "Compiler is not in a mode aware of C++11."
> #endif
>
> #if defined(__SUNPRO_CC) && __SUNPRO_CC < 0x5140
> #error "SunPro <= 5.13 mode not supported due to bug in move semantics."
> #endif
>
> class Class
> {
> public:
>   int Get() const { return this->Member; }
> private:
>   int Member = 1;
> };
> int main()
> {
>   auto const c = std::unique_ptr(new Class);
>   std::cout << c->Get() << std::endl;
>   return 0;
> }
>
> --
> "/opt/IBM/xlC/13.1.3/include/unordered_map", line 71.5: 1540-0859 (S)
> #error directive: To use the unordered map library, macro __IBMCPP_TR1__
> must be defined
> by user to non zero integer value..
> "cmake_bootstrap_18350136_test.cxx", line 7.2: 1540-0859 (S) #error
> directive: "Compiler is not in a mode aware of C++11.".
> Test failed to compile
> Checking whether 'xlC  ' works.
> Try: xlC
> Line: xlC   cmake_bootstrap_18350136_test.cxx -o
> cmake_bootstrap_18350136_test
> --  file   ---
>
> #include 
> #include 
> #include 
>
> #if __cplusplus < 201103L
> #error "Compiler is not in a mode aware of C++11."
> #endif
>
> #if defined(__SUNPRO_CC) && __SUNPRO_CC < 0x5140
> #error "SunPro <= 5.13 mode not supported due to bug in move semantics."
> #endif
>
> class Class
> {
> public:
>   int Get() const { return this->Member; }
> private:
>   int Member = 1;
> };
> int main()
> {
>   auto const c = std::unique_ptr(new Class);
>   std::cout << c->Get() << std::endl;
>   return 0;
> }
>
> --
> "/opt/IBM/xlC/13.1.3/include/unordered_map", line 71.5: 1540-0859 (S)
>

Re: [CMake] Is there a way to obtain the current compiler standard flag?

[Chuck Atkins]

Hi Chris.

Try using the the CMAKE_CXX${std}_STANDARD_COMPILE_OPTION variable.  For
example, the folowing piece of CMake code:
cmake_minimum_required(VERSION 3.9)

project(foo CXX)

foreach(std IN ITEMS 98 11 14 17)
  message("C++${std} std flags: ${CMAKE_CXX${std}_STANDARD_COMPILE_OPTION}")
  message("C++${std} ext flags:
${CMAKE_CXX${std}_EXTENSION_COMPILE_OPTION}")
endforeach()

Wll generate for GCC on Linux:
-- The CXX compiler identification is GNU 8.1.1
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -std=c++98
C++98 ext flags: -std=gnu++98
C++11 std flags: -std=c++11
C++11 ext flags: -std=gnu++11
C++14 std flags: -std=c++14
C++14 ext flags: -std=gnu++14
C++17 std flags: -std=c++1z
C++17 ext flags: -std=gnu++1z
-- Configuring done

PGI on Linux:
-- The CXX compiler identification is PGI 18.4.0
-- Check for working CXX compiler: /opt/pgi/linux86-64/18.4/bin/pgc++
-- Check for working CXX compiler: /opt/pgi/linux86-64/18.4/bin/pgc++ --
works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -A
C++98 ext flags: --gnu_extensions
C++11 std flags: --c++11;-A
C++11 ext flags: --c++11;--gnu_extensions
C++14 std flags: --c++14;-A
C++14 ext flags: --c++14;--gnu_extensions
C++17 std flags: --c++17;-A
C++17 ext flags: --c++17;--gnu_extensions
-- Configuring done


And for IBM XL on AIX:
-- The CXX compiler identification is XL 13.1.3
-- Check for working CXX compiler: /usr/bin/xlC
-- Check for working CXX compiler: /usr/bin/xlC -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
C++98 std flags: -qlanglvl=strict98
C++98 ext flags: -qlanglvl=extended
C++11 std flags: -qlanglvl=extended0x
C++11 ext flags: -qlanglvl=extended0x
C++14 std flags:
C++14 ext flags:
C++17 std flags:
C++17 ext flags:
-- Configuring done
-- Generating done

- 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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] how to detect architecture ?

[Chuck Atkins]

Hi Franck,

I'd suggest going a little more robust by using both
CMAKE_SHARED_LIBRARY_PREFIX and CMAKE_SHARED_LIBRARY_SUFFIX to generate a
function at configure time to resolve the correct filename.

For example, util.h.in:

#ifndef _UTIL_H_
#define _UTIL_H_

#include 

static inline
void get_library_filename(char* filename, const char* libname)
{
  sprintf(filename, "@CMAKE_SHARED_LIBRARY_PREFIX@
%s@CMAKE_SHARED_LIBRARY_SUFFIX@", libname);
}

#endif /* _UTIL_H_ */


Then your CMakeLists.txt:

configure_file(
  ${CMAKE_CURRENT_SOURCE_DIR}/util.h.in
  ${CMAKE_CURRENT_BINARY_DIR}/util.h
  @ONLY
)
add_executable(foo main.c ${CMAKE_CURRENT_BINARY_DIR}/util.h)
target_include_directories(foo PRIVATE ${CMAKE_CURRENT_BINARY_DIR})

And finally main.c:

#include 
#include 

int main(int argc, char **argv)
{
  char filename[256];

  get_library_filename(filename, "foo");

  printf("Library foo uses file %s\n", filename);

  return 0;
}

This will give you "libfoo.so" on Linux, "libfoo.dylib" on Apple, and "
foo.dll" on Windows.


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


On Tue, Jan 9, 2018 at 10:04 AM, Franck Houssen <franck.hous...@inria.fr>
wrote:

> Thanks !
>
> - Mail original -
> > De: "Konstantin Tokarev" <annu...@yandex.ru>
> > À: "Franck Houssen" <franck.hous...@inria.fr>, "CMake Mail List" <
> cmake@cmake.org>
> > Envoyé: Mardi 9 Janvier 2018 16:00:55
> > Objet: Re: [CMake] how to detect architecture ?
> >
> >
> >
> > 09.01.2018, 17:58, "Franck Houssen" <franck.hous...@inria.fr>:
> > > Is there a way to detect architecture ?
> > >
> > > Seems there is nothing simple since these old threads :
> > > https://stackoverflow.com/questions/11944060/how-to-
> detect-target-architecture-using-cmake/12024211#12024211
> > > https://stackoverflow.com/questions/16796629/cmake-
> create-architecture-aware-makefile
> > >
> > > Is there a solution now ?
> > >
> > > My need is quite simple: I have an executable who needs dlopen. To
> test it,
> > > I planned to write a bash script that would have done "./exe
> > > /path/to/lib.so" on linux (debian, ...) OR "./exe /path/to/lib.dylib"
> on
> > > osx. To replace correctly so/dylib in the bash script I need to know
> the
> > > architecture. Any idea how to do this ?
> >
> > ${CMAKE_SHARED_LIBRARY_SUFFIX}
> >
>
> Oh man ! Didn't know this one : exactly what I was looking for
>
> > > Franck
> > > ,--
> > >
> > > 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
> >
> >
> > --
> > Regards,
> > Konstantin
> >
> --
>
> 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
>
-- 

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