Re: [CMake] CMake Digest, Vol 182, Issue 32

[Michael Wild]

On Wed, Jun 19, 2019 at 11:30 AM Innokentiy Alaytsev wrote:
> Hello!
>
> Are the header files of the shared library (DLL) listed as INTERFACE_SOURCES
> for the library target? AFAIK, the only reason for header files to be
> processed by AUTOMOC is to be part of the project. The only way that I know
> of for adding library headers to the consuming project is by declaring them
> as INTERFACE sources of the library target.
>
> Best regards,
> Innokentiy Alaytsev

Hi Innokentiy

Thanks, your answer gave me the hint I needed. And yes, I was being stupid :-)

Problem was that I used `target_sources( PRIVATE mywindow.cpp PUBLIC
mywindow.h )` misinterpreting what `PUBLIC` does. I figured it would
add it to the `PUBLIC_HEADER` property; I would never have imagined
that it causes the `mywindow.h` header to be added as a source to the
targets that link against the library! So, I should do some RTFM on
all the new shiny features in CMake...

Kind regards

Michael
-- 

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

[CMake] Problem with AUTOMOC on WIN32

[Michael Wild]

Dear all

It's a very long time I last posted here, so please be kind :-)

I currently am having a very hard time to get AUTOMOC to work properly
on WIN32 for the case where I have some Qt classes in a DLL that I
link to an executable. In this case, the header gets included by both,
the corresponding *.cpp file in the DLL and the importing *.cpp file
in the executable. The problem is now that the AUTOMOC feature runs
moc twice on the same header, once for the DLL and once for the
executable, resulting in an inconsistent linkage because for the DLL
the moc'ed sources are dllexport but for the executable they are
dllimport.

I put together a minimal example exhibiting the problem:
https://github.com/themiwi/qt_cmake_automoc_test/

Is this a bug in CMake? IMHO moc should be only run on headers for
targets where the corresponding source file is compiled in. Or am I
just being incredibly stupid and completely miss an obvious point?

Of course I could revert to qt5_wrap_cpp() as demonstrated in the
develop branch of above example, but I'd rather not because that adds
considerable complexity and makes configuration much slower in a
real-world project.

Cheers

Michael
-- 

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] [cmake-developers] Obtaining header file dependencies of a source file manually

[Michael Wild]

On Mon, Nov 30, 2015 at 7:01 PM, Dan Liew  wrote:
> Hi Michael,
>
>> Not going into detail as I'm typing on the phone, but this really sounds
>> like a case where a "SuperBuild"
>> (http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
>> can help you to simplify things a lot.
>
> Thanks for the suggestion but this certainly is not a case where a
> "SuperBuild" would help. CMake does not know how to configure a
> compiler that can produce LLVM Bitcode so using a "SuperBuild" is not
> going to help.
>
> Dan.


Hi Dan

I fail to see why that should not work. Producing LLVM bitcode from
C++ with Clang is just adding -emit-llvm flag, right? So, why can't
the SuperBuild configure the child build to use Clang and this flag?
And Bob's your uncle...

Michael
-- 

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-developers] Obtaining header file dependencies of a source file manually

[Michael Wild]

On Mon, Nov 30, 2015 at 7:01 PM, Dan Liew  wrote:
> Hi Michael,
>
>> Not going into detail as I'm typing on the phone, but this really sounds
>> like a case where a "SuperBuild"
>> (http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
>> can help you to simplify things a lot.
>
> Thanks for the suggestion but this certainly is not a case where a
> "SuperBuild" would help. CMake does not know how to configure a
> compiler that can produce LLVM Bitcode so using a "SuperBuild" is not
> going to help.
>
> Dan.


Hi Dan

I fail to see why that should not work. Producing LLVM bitcode from
C++ with Clang is just adding -emit-llvm flag, right? So, why can't
the SuperBuild configure the child build to use Clang and this flag?
And Bob's your uncle...

Michael
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually

[Michael Wild]

On Sun, Nov 29, 2015, 10:47 Dan Liew  wrote:

Hi,

# TL;DR

I need a way of determining the header file dependencies of a source
file and inform CMake about them. CMake doesn't do this automatically
because I'm using custom commands for the compilation step so CMake
doesn't do it's usual magic of automatically inferring source file
header dependencies. This is because this part of the compilation step
requires a separate C++ compiler (completely independent from the one
that CMake detects at configure time).

Is there a way of doing this that will also regenerate the
dependencies if the source file changes?

# Long version

A C++ project that I work on [1] is (amongst other things) a compiler.
In order to compile applications it needs to link in a supporting
runtime that is compiled to LLVM bitcode which is linked into the
applications it compiles.

The supporting runtime is written in C++ and compiled with Clang. The
compilation of the runtime is currently achieved using
``add_custom_command()`` and so I am not using CMake's in built
support for detecting header file dependencies. The reason for doing
it this way is because the LLVM bitcode compiler (i.e. Clang) **is
not** the same compiler as the host C++ compiler for the project. For
example the host code might be built with MSVC but the supporting
runtime is **always** built with Clang.

To see this concretely take a look at [2].

The build works correctly if you build from a clean build directory.
It does not work correctly if you perform a rebuild and change one of
the header files that the supporting runtime depends on. This is
because CMake doesn't know that the runtime source files depend on the
header files and so doesn't rebuild the relevant source files.

I can obviously tell CMake about these manually (adding more entries
under ``DEPENDS`` in the ``add_custom_command()`` invocation) but this
is very cumbersome.

What I really need is a way to

* Automatically infer the dependencies of a source file and tell CMake
about them
* Have the dependencies automatically regenerated if the source file
changes (someone could add or remove a header file include).

In a simple Makefile build system this typically achieved by doing
something like this:

```
all:: $(SRCS:.cpp:.o)

SRCS := foo.cpp bar.cpp

# Include SRC file dependencies generated by the compiler if they exist
-include $(SRCs:.cpp=.d)

%.o : %.cpp
  $(CXX) -c $< -o $@ -MP -MMD -MF $*.d
```

Note the ``-M*`` flags get the compiler when it runs to generate
additional makefile rules that will get included next time a build
happens.

I don't really know how to do the same thing with CMake. One idea is
at configure time invoke Clang with the ``-MP -MMD -MF`` flags on each
runtime source file, extract the dependencies then pass them to
``DEPENDS`` in ``add_custom_command()``. If I wanted the dependencies
regenerated if the runtime source file changes then I would need to
somehow get CMake to reconfigure every time this happens.

I don't like this idea very much due to

* Having to invoke Clang manually to determine the dependencies. CMake
already knows how to determine source file dependencies, but this
functionality (AFAIK) isn't exposed to me.

* Reconfiguring every time one of the runtime source file changes is
annoying (configuring can be slow sometimes).

Does anyone have any other ideas? CMake obviously knows how to do all
this stuff already for source files being compiled for the detected
host C++ compiler, I just don't know how to get at this logic for
source files that need to be built with a second independent C++
compiler.

[1] https://github.com/halide/Halide
[2] https://github.com/halide/Halide/blob/master/src/CMakeLists.txt#L140

Thanks,
Dan.



Hi Dan,

Not going into detail as I'm typing on the phone, but this really sounds
like a case where a "SuperBuild" (
http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
can help you to simplify things a lot.

Michael
-- 

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-developers] Obtaining header file dependencies of a source file manually

[Michael Wild]

On Sun, Nov 29, 2015, 10:47 Dan Liew  wrote:

Hi,

# TL;DR

I need a way of determining the header file dependencies of a source
file and inform CMake about them. CMake doesn't do this automatically
because I'm using custom commands for the compilation step so CMake
doesn't do it's usual magic of automatically inferring source file
header dependencies. This is because this part of the compilation step
requires a separate C++ compiler (completely independent from the one
that CMake detects at configure time).

Is there a way of doing this that will also regenerate the
dependencies if the source file changes?

# Long version

A C++ project that I work on [1] is (amongst other things) a compiler.
In order to compile applications it needs to link in a supporting
runtime that is compiled to LLVM bitcode which is linked into the
applications it compiles.

The supporting runtime is written in C++ and compiled with Clang. The
compilation of the runtime is currently achieved using
``add_custom_command()`` and so I am not using CMake's in built
support for detecting header file dependencies. The reason for doing
it this way is because the LLVM bitcode compiler (i.e. Clang) **is
not** the same compiler as the host C++ compiler for the project. For
example the host code might be built with MSVC but the supporting
runtime is **always** built with Clang.

To see this concretely take a look at [2].

The build works correctly if you build from a clean build directory.
It does not work correctly if you perform a rebuild and change one of
the header files that the supporting runtime depends on. This is
because CMake doesn't know that the runtime source files depend on the
header files and so doesn't rebuild the relevant source files.

I can obviously tell CMake about these manually (adding more entries
under ``DEPENDS`` in the ``add_custom_command()`` invocation) but this
is very cumbersome.

What I really need is a way to

* Automatically infer the dependencies of a source file and tell CMake
about them
* Have the dependencies automatically regenerated if the source file
changes (someone could add or remove a header file include).

In a simple Makefile build system this typically achieved by doing
something like this:

```
all:: $(SRCS:.cpp:.o)

SRCS := foo.cpp bar.cpp

# Include SRC file dependencies generated by the compiler if they exist
-include $(SRCs:.cpp=.d)

%.o : %.cpp
  $(CXX) -c $< -o $@ -MP -MMD -MF $*.d
```

Note the ``-M*`` flags get the compiler when it runs to generate
additional makefile rules that will get included next time a build
happens.

I don't really know how to do the same thing with CMake. One idea is
at configure time invoke Clang with the ``-MP -MMD -MF`` flags on each
runtime source file, extract the dependencies then pass them to
``DEPENDS`` in ``add_custom_command()``. If I wanted the dependencies
regenerated if the runtime source file changes then I would need to
somehow get CMake to reconfigure every time this happens.

I don't like this idea very much due to

* Having to invoke Clang manually to determine the dependencies. CMake
already knows how to determine source file dependencies, but this
functionality (AFAIK) isn't exposed to me.

* Reconfiguring every time one of the runtime source file changes is
annoying (configuring can be slow sometimes).

Does anyone have any other ideas? CMake obviously knows how to do all
this stuff already for source files being compiled for the detected
host C++ compiler, I just don't know how to get at this logic for
source files that need to be built with a second independent C++
compiler.

[1] https://github.com/halide/Halide
[2] https://github.com/halide/Halide/blob/master/src/CMakeLists.txt#L140

Thanks,
Dan.



Hi Dan,

Not going into detail as I'm typing on the phone, but this really sounds
like a case where a "SuperBuild" (
http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
can help you to simplify things a lot.

Michael
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMAKE_LANG_OUTPUT_EXTENSION

[Michael Wild]

It would be useful if these variables were mentioned in the documentation for 
CMAKE_LANG_OUTPUT_EXTENSION. Otherwise this is hardly discoverable.

Michael

On 06.09.2013 21:28, Robert Maynard wrote:
 Both CMAKE_USER_MAKE_RULES_OVERRIDE{,_LANG} are both documented:
 
 http://cmake.org/cmake/help/v2.8.11/cmake.html#variable:CMAKE_USER_MAKE_RULES_OVERRIDE
 http://cmake.org/cmake/help/v2.8.11/cmake.html#variable:CMAKE_USER_MAKE_RULES_OVERRIDE_LANG
 
 If the documentation isn't sufficient, can you please suggest modifications.
 
 On Fri, Sep 6, 2013 at 8:32 AM, Michael Wild them...@gmail.com wrote:



 On Thu, Sep 5, 2013 at 8:22 AM, Michael Wild them...@gmail.com wrote:

 [snip long rant]


 Sorry, Alex. If had scrolled down a bit more in
 CMakeLANGInformation.cmake, I would have seen the hook variables
 CMAKE_USER_MAKE_RULES_OVERRIDE{,_LANG}. However, can I request that this
 be documented?


 Michael

 --

 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_LANG_OUTPUT_EXTENSION

[Michael Wild]

On Thu, Sep 5, 2013 at 8:22 AM, Michael Wild them...@gmail.com wrote:

 [snip long rant]


Sorry, Alex. If had scrolled down a bit more in
CMakeLANGInformation.cmake, I would have seen the hook variables
CMAKE_USER_MAKE_RULES_OVERRIDE{,_LANG}. However, can I request that this
be documented?


Michael
--

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_LANG_OUTPUT_EXTENSION

[Michael Wild]

On 04.09.2013 20:42, Michael Wild wrote:
 Dear all
 
 no matter when I try to set CMAKE_{C,CXX}_OUTPUT_EXTENSION, on my Linux
 box using the GNU Makefiles generator the resulting object files always
 have a .o extension. I tried setting it in the cache, before and after
 the project() call. Nothing helps.
 
 Is this a known issue? I tried trawling the archives, but only found
 references to IDE generators ignoring this setting.
 
 Thanks for any help
 
 Michael
 

Seems like commit 422dc631b by Alex kind of broke the user's ability to specify
CMAKE_LANG_OUTPUT_NAME by unconditionally setting it to .o on UNIX and .obj
otherwise. The only solution I can see is to provide/override platform+compiler
specific files which get loaded by CMakeLANGInformation.cmake like this:

---8

cmake_minimum_required(VERSION 2.8)
project(output_extension NONE)

# create fake system- and compiler specific file
file(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/cmake/Platform)
foreach(id GNU HP Intel MIPSpro PathScale PGI SunPro VisualAge XL)
  foreach(l C CXX)
file(WRITE 
${PROJECT_BINARY_DIR}/cmake/Platform/${CMAKE_SYSTEM_NAME}-${id}-${l}.cmake
  #  SET EXTENSION HERE =
  set(CMAKE_${l}_OUTPUT_EXTENSION .MyFancyExtension)\n
  
include(\${CMAKE_ROOT}/Modules/Platform/\${CMAKE_SYSTEM_NAME}-\${CMAKE_${l}_COMPILER_ID}-${l}.cmake\\n
OPTIONAL RESULT_VARIABLE _INCLUDED_FILE)\n
  if(NOT _INCLUDED_FILE)\n

INCLUDE(\${CMAKE_ROOT}/Modules/Platform/\${CMAKE_SYSTEM_NAME}-\${CMAKE_BASE_NAME}.cmake\\n
  OPTIONAL RESULT_VARIABLE _INCLUDED_FILE)\n
  endif()\n
  if(NOT _INCLUDED_FILE)\n
INCLUDE(\${CMAKE_ROOT}/Modules/Platform/\${CMAKE_SYSTEM_NAME}.cmake\ 
OPTIONAL)\n
  endif()\n
  )
  endforeach()
endforeach()
list(INSERT CMAKE_MODULE_PATH 0 ${PROJECT_BINARY_DIR}/cmake)

cmake_policy(PUSH)
cmake_policy(SET CMP0017 OLD)
enable_language(C)
enable_language(CXX)
cmake_policy(POP)

---8

Michael
--

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-developers] Safe source list GLOBs

[Michael Wild]

On 29.05.2013 22:59, Matthew Woehlke wrote:
 On 2013-05-28 21:23, Wojciech Knapik wrote:
 On Fri, May 24, 2013 at 11:21:57AM -0400, Matthew Woehlke wrote:
[...]
 
 I do understand the distinction between calling cmake and make and I
 understood from the start when variables are evaluated and such, but I
 just assumed that globs are propagated to the generated build system,
 because a) why not ? b) what's the point of globs if they aren't ?

 Imagine my surprise...
 
 Actually, I find your surprise very surprising. You say you understand
 that setting and using variables happens at configure time. Well,
 file(GLOB) populates a variable... so why would you expect those
 variables to be somehow magically special?

Also, very astonishing to me is the fact that after apparently finding
file(GLOB) in the documentation, you clearly didn't read the whole
paragraph. It's right there:

 We do not recommend using  GLOB  to collect  a list of source files
 from your source tree.  If no CMakeLists.txt file changes when a
 source is added or removed then the generated build system cannot
 know when to ask CMake to regenerate.

As you are so fond of clear violations: You failed to RTFM...
(http://en.wikipedia.org/wiki/Rtfm)

Besides, you seem to be very sure that CMake is the *only* tool that
prefers explicit source file listing. Have you ever used any of the
popular IDE's? Visual Studio? Xcode? Eclipse? They all create explicit
list of files in their projects.

What are the (not so serious) pros and cons of GLOB, even if it worked
the way you think it should?

Pro:
* laziness

Con:
* laziness
* extremely error prone:
  - picks up scratch files
  - works for you but breaks for others because you forgot to commit a
file
  - breaks for you because the other dude forgot to commit his file
* makes it unnecessarily difficult to exclude files from the build
  - temporarily: for testing (you'd need to move the file away and then
remember to move it back; error prone again)
  - permanently: dependent on the platform, configuration, enabled
capabilities etc. And using #ifdef's for this is bad because you
still invoke the compiler and waste time to just compile an empty
file.
* when reading the build system code, you have to switch context in
  order to determine the files included in the build.


On the other hand, initially creating and then maintaining an explicit
list of files is easy. Initially I usually create the list of files like
this using vim:

:r !cd $(dirname %); ls **/*.{c,cpp}; ls **/*.{h,hpp}


Michael
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Documentation 'latest' url

[Michael Wild]

On Thu, Apr 4, 2013 at 2:33 PM, Brad King brad.k...@kitware.com wrote:

 On 04/04/2013 12:12 AM, Michael Wild wrote:
  On 09/21/2012 04:36 PM, Stephen Kelly wrote:
  This page has links for various versions of cmake:
 
  http://www.cmake.org/cmake/help/documentation.html
 
  Would it be possible to get a 'latest' url too, such as
 
  http://www.cmake.org/cmake/help/latest/cmake.html
 
  It would make more sense to link to such a url from the Qt
 documentation.
 
  Excavating this oldish, unanswered post:
 
  +1 from me! It certainly would help linking to the up-to-date docs from
  the Wiki...

 The problem with unversioned URLs is that people link to them based
 on their current content.  When the content changes in the next version
 some of the links become nonsense.  I don't know how many times I've
 seen links to a version control web viewer posted to say look at
 line 10 here, and of course line 10 has long since changed because
 they didn't use a URL that specifies the repository version.

 What we need is an unversioned URL that automatically redirects to the
 latest versioned URL.  That way someone following a link that is
 intended to be unversioned will get a versioned URL in their browser.
 Unfortunately server-side redirects cause some browsers to strip the
 #tag part of the URLs, and client-side redirects require Javascript.

 -Brad


Thanks for the details. Not worth the trouble, then.

Michael
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Documentation 'latest' url

[Michael Wild]

On 09/21/2012 04:36 PM, Stephen Kelly wrote:
 
 Hi,
 
 This page has links for various versions of cmake:
 
 http://www.cmake.org/cmake/help/documentation.html
 
 Would it be possible to get a 'latest' url too, such as 
 
 http://www.cmake.org/cmake/help/latest/cmake.html
 
 It would make more sense to link to such a url from the Qt documentation.
 
 Thanks,
 
 Steve.

Excavating this oldish, unanswered post:

+1 from me! It certainly would help linking to the up-to-date docs from
the Wiki...

Michael

--

Powered by www.kitware.com

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

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

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

Re: [CMake] How do I search for personal libraries?

[Michael Wild]

You should find this interesting:
http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file

In short:
* In project A create a AConfig.cmake file and export your targets
* In project B call find_package(A REQUIRED)

HTH

Michael



On Wed, Apr 3, 2013 at 7:44 AM, Saad Khattak saadrus...@gmail.com wrote:

 Hi,

 Suppose I have two personal repositories: A and B. Repository B has a
 dependency on repository A i.e. repository A builds multiple libraries and
 repository B builds multiple libraries and executables. I can build 32-bit
 and 64-bit libraries/executables for both by having a 'build' and
 'buildx64' projects generated by CMake. The libraries and executables are
 put in the default folders (e.g. repoA/build/src/libraryName/Debug and
 repoA/buildx64/src/library/Debug).

 Repo B's executables depend on repo A's libraries and libraries in B.
 Linking with libraries within B is straightforward as CMake is able to
 figure out the necessary paths for the libraries B is building which B's
 executables depend on.

 Repo B also depends on Repo A's libraries and all executables in B have to
 search for them. How do I go about this? Currently I am searching for each
 library by specifying its path:

 # I have a CACHE variable for the path to Repo A's build folder that the
 user must provide
 target_link_libraries(myProject
 repoAPath/build/src/LibName/${CMAKE_CFG_INTDIR})

 which feels like a very wrong way to go about linking with other libraries
 considering CMake is supposed to make the finding libraries part easier. I
 would appreciate clarification of the workflow in this case.

 Thanks,
 Saad



 --

 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] adding program suffix

[Michael Wild]

On Mon, Mar 11, 2013 at 7:56 AM, Chandan Choudhury iitd...@gmail.comwrote:


 Dear cmake users,

 I am very new to cmake. I really find it interesting. I installed gromacs
 (4.6.1) with it. One simple query regarding its usage is, how do I add
 program suffix to the executables created.


 Chandan


Just set the CMAKE_EXECUTABLE_SUFFIX variable in the CMake cache. Be
careful that on Windows this should include the .exe suffix.

HTH

Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] adding program suffix

[Michael Wild]

On Mon, Mar 11, 2013 at 8:42 AM, Chandan Choudhury iitd...@gmail.comwrote:

 Thanks Michael for your quick reply.

 I indeed tried the following command:
 CMAKE_PREFIX_PATH=/soft/sudip/abc/apps/fftw-3.3.3 CC=icc cmake ..
 -DCMAKE_INSTALL_PREFIX=/soft/sudip/abc/apps/gromacs/461
 -DCMAKE_EXECUTABLE_SUFFIX=_461  make -j 12  make install

 But the suffix was not added to the executables. Might be I am missing
 something or doing silly.

 Kindly have a look.

 Chandan


 --
 Chandan kumar Choudhury
 NCL, Pune
 INDIA


 On Mon, Mar 11, 2013 at 12:34 PM, Michael Wild them...@gmail.com wrote:

 On Mon, Mar 11, 2013 at 7:56 AM, Chandan Choudhury iitd...@gmail.comwrote:


 Dear cmake users,

 I am very new to cmake. I really find it interesting. I installed
 gromacs (4.6.1) with it. One simple query regarding its usage is, how do I
 add program suffix to the executables created.


 Chandan


 Just set the CMAKE_EXECUTABLE_SUFFIX variable in the CMake cache. Be
 careful that on Windows this should include the .exe suffix.

 HTH

 Michael



That's a bit difficult to debug remotely. Here a few hints:

* Look into the CMakeCache.txt file and verify that the
CMAKE_EXECUTABLE_SUFFIX is correct.
* Grep the sources for this variable, it might be that one of the
CMakeLists.txt or *.cmake files overrides the cache entry.

Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] adding program suffix

[Michael Wild]

On Mon, Mar 11, 2013 at 9:20 AM, J Decker d3c...@gmail.com wrote:



 On Sun, Mar 10, 2013 at 11:56 PM, Chandan Choudhury iitd...@gmail.comwrote:


 Dear cmake users,

 I am very new to cmake. I really find it interesting. I installed gromacs
 (4.6.1) with it. One simple query regarding its usage is, how do I add
 program suffix to the executables created.


SET_TARGET_PROPERTIES( target PROPERTIES
   SUFFIX .different.suffix )




 Chandan


IMHO this is not they way to go about this problem if you're not the
developer of the software... It might be the last resort if the developers
were not careful enough to allow users to override the program suffix, but
IMHO this should be configurable through the cache.

Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] adding program suffix

[Michael Wild]

That's not what Chandan wants to achieve. He wants to have a suffix
appended to every executable being installed, so he can have different
versions installed and select among them through the suffix. Think gcc-4.4,
gcc-4.6 and gcc-4.7 being present on your system.


On Mon, Mar 11, 2013 at 9:27 AM, J Decker d3c...@gmail.com wrote:



 On Mon, Mar 11, 2013 at 1:24 AM, Michael Wild them...@gmail.com wrote:




 On Mon, Mar 11, 2013 at 9:20 AM, J Decker d3c...@gmail.com wrote:



 On Sun, Mar 10, 2013 at 11:56 PM, Chandan Choudhury 
 iitd...@gmail.comwrote:


 Dear cmake users,

 I am very new to cmake. I really find it interesting. I installed
 gromacs (4.6.1) with it. One simple query regarding its usage is, how do I
 add program suffix to the executables created.


SET_TARGET_PROPERTIES( target PROPERTIES
   SUFFIX .different.suffix )




 Chandan


 IMHO this is not they way to go about this problem if you're not the
 developer of the software... It might be the last resort if the developers
 were not careful enough to allow users to override the program suffix, but
 IMHO this should be configurable through the cache.

 Sure; but should be implemented on a per target basis, and certainly not
 globally.  I've had great success just chaining other CMake based projects
 into my builds, if they don't do rude things like set global library
 suffixes that end up propagating through previuosly working projects.


 Michael



--

Powered by www.kitware.com

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

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

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

Re: [CMake] adding program suffix

[Michael Wild]

Looking at the sources, it seems that you also need to set
GMX_DEFAULT_SUFFIX to FALSE in order for this to work.

Michael


On Mon, Mar 11, 2013 at 10:49 AM, Chandan Choudhury iitd...@gmail.comwrote:

 Dear Micheal, Yngve Decker and Eric

 Thank for remarks.

 Micheal you are right that I want to append a suffix to every executable
 being installed.
 I already have an earlier version of gromacs installed, the suffix would
 help me to distinguish the between the two.

 While looking out for the string SUFFIX in the CMakeCache.txt, I
 encountered a phrase as

 //Suffix for GROMACS binaries (default: _d for double, _mpi for
 // MPI, _mpi_d for MPI and double).
 GMX_BINARY_SUFFIX:STRING=

 What I can understand is if I use the following command it might serve the
 purpose.

 CMAKE_PREFIX_PATH=/soft/sudip/abc/apps/fftw-3.3.3 
 *GMX_BINARY_SUFFIX=_472*CC=icc cmake .. 
 -DCMAKE_INSTALL_PREFIX=/soft/sudip/abc/apps/gromacs/461
 -DCMAKE_EXECUTABLE_SUFFIX=_461  make -j 12  make install

 Chandan



 --
 Chandan kumar Choudhury
 NCL, Pune
 INDIA


 On Mon, Mar 11, 2013 at 2:26 PM, Yngve Inntjore Levinsen 
 yngve.levin...@gmail.com wrote:


 On 11/03/13 09:24, Eric Noulard wrote:
  I think Chandan meant globally for all executables.
 
  That's the purpose of CMAKE_EXECUTABLE_SUFFIX
  as already pointed  out by Michael.
 
  see : cmake --help-variable CMAKE_EXECUTABLE_SUFFIX
 
  Now it doesn't seems to work for Chandan.
 
  I guess the variable is forcibly written by CMakeGenericSystem.cmake
  during early CMake startup.
  So that you cannot overwrite its value on the command line.
  try to add variable_watch(CMAKE_EXECUTABLE_SUFFIX) at the very top
  of main CMakeLists.txt
 
  You may try to do that from within the CMakeLists.txt after the
  project(...) statement (or enable_language)

 Hi,

 Yes I tried to set the same variable on my machine but does not work
 here neither (Linux). Perhaps this only works for platforms where this
 variable is traditionally non-empty?

 As also Michael pointed out, this would not really be a solution for
 non-developers of a software for sure (and I now see Chandan said it was
 a question regarding usage).

 Cheers,
 Yngve
 --

 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

--

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] Passing CMAKE_TOOLCHAIN_FILE on command line causes CMake warning

[Michael Wild]

Hi


On Wed, Feb 6, 2013 at 11:59 AM, Pat Marion pat.mar...@kitware.com wrote:

 Hi,

 I'm emailing about bug 
 13093http://public.kitware.com/Bug/view.php?id=13093in the backlog.  I 
 found comments
 by Brad http://www.cmake.org/pipermail/cmake/2011-February/042556.htmlthat 
 suggest it's a legitimate warning, but I'm not sure how a project
 could avoid the warning.


By not specifying the toolchain file, for instance? If you have the problem
in conjunction with ExternalProject_Add, check whether the CMakeCache.txt
file exists in the build tree of the external project. If not, include the
flag, otherwise drop it.

My 2c

Michael
--

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] When should I use add_subdirectory and when ExternalProject?

[Michael Wild]

I don't know about Windows, but then you might have a team that shares a
common SDL build on a network drive, and then references that using the
ExternalProject feature instead of building this external dependency over
and over again.


On Mon, Feb 4, 2013 at 12:26 PM, Ansis Māliņš ansis.mal...@gmail.comwrote:

 SDL installation? But there is no such thing. At least not on Windows.
 ... Right?


 On Mon, Feb 4, 2013 at 1:10 PM, Michael Wild them...@gmail.com wrote:

 In that case, clearly ExternalProject_Add. It is an external dependency,
 and should be treated as such. If a users have SDL already installed on
 their system, they're going to hate you for shipping it AGAIN in your
 package, possibly even wrecking their original installation of SDL. By
 providing download information in the ExternalProject_Add call, you can
 make things even fully automated for your user.

 Michael


 On Mon, Feb 4, 2013 at 9:23 AM, Ansis Māliņš ansis.mal...@gmail.comwrote:

 If I have a dependency (e.g. SDL2) that seems to work with
 add_subdirectory just fine, should I still use ExternalProject_Add instead?
 Given both ways work, what should I prefer? What are the tradeoffs?

 --

 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] External dependencies and Windows

[Michael Wild]

Hi


On Mon, Feb 4, 2013 at 12:43 PM, Ansis Māliņš ansis.mal...@gmail.comwrote:

 I'm just learning CMake and posting questions in this mailing list, but
 the answers I get only confuse me. It seems I must take a step back and ask
 more general questions.

 In Linux there is a package for everything, so you just find_package
 whatever you need.

 But on Windows most libraries exist only as zip files that you're supposed
 to unpack right in your build environment and ship them together with the
 executable. (Basically, in practice, there is no such thing as shared
 libraries in Windows - nothing for find_package to find.)


What then are DLL's? They are the shared libraries of the Windows world.
True, the semantics are a bit different, but they are dynamically linked.
It's also not true that on Windows everything is a zip files that you're
supposed to unpack right in your build environment. If you don't believe
me, try to take a look at Qt or Python.



 So how am I supposed to write portable CMake scripts in face of this?



 Often the Windows packages are installed into a few well known locations,
or even better, create a registry key containing installation information
which you then can use to find the software in your CMake code. Also, for
SDL I would recommend to use the FindSDL.cmake module (not sure whether
that works with SDL2, though), and only if that fails, to resort to
ExternalProject. It is good practice to offer the user the choice which way
should be used through a cached variable.

HTH

Michael
--

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] External dependencies and Windows

[Michael Wild]

That has nothing to do whether the libraries are shared (i.e. dynamically
linked) or not. It has to do with the way that packaging works (or rather,
doesn't work) on Windows. In the pre-.NET era it was simply impossible to
use library versioning on Windows. If package A installed python.dll
version X.Y into C:\Windows\System32 and later package B installed version
Z.F into the same place, package A stopped working. Further, packagers
where essentially forced to include all dependencies in their packages
because there's no dependency-resolution mechanism. That's why people
started providing a copy of all the dependencies in the installation
directory of their package. Of course, this leads to a lot of duplication,
especially for rather popular things such as Python or Qt. The whole
situation is referred to as DLL hell:
http://en.wikipedia.org/wiki/DLL_Hell

Michael


On Mon, Feb 4, 2013 at 1:43 PM, Ansis Māliņš ansis.mal...@gmail.com wrote:

 If shared libraries on Windows are truly shared, then why so many
 applications carry their own copies of that same Qt and Python? Examples
 from my own Program Files: Anki, Blender, Mixxx, Mumble, TortoiseHg.


 On Mon, Feb 4, 2013 at 2:15 PM, Michael Wild them...@gmail.com wrote:

 Hi


 On Mon, Feb 4, 2013 at 12:43 PM, Ansis Māliņš ansis.mal...@gmail.comwrote:

 I'm just learning CMake and posting questions in this mailing list, but
 the answers I get only confuse me. It seems I must take a step back and ask
 more general questions.

 In Linux there is a package for everything, so you just find_package
 whatever you need.

 But on Windows most libraries exist only as zip files that you're
 supposed to unpack right in your build environment and ship them together
 with the executable. (Basically, in practice, there is no such thing as
 shared libraries in Windows - nothing for find_package to find.)


 What then are DLL's? They are the shared libraries of the Windows world.
 True, the semantics are a bit different, but they are dynamically linked.
 It's also not true that on Windows everything is a zip files that you're
 supposed to unpack right in your build environment. If you don't believe
 me, try to take a look at Qt or Python.



 So how am I supposed to write portable CMake scripts in face of this?



  Often the Windows packages are installed into a few well known
 locations, or even better, create a registry key containing installation
 information which you then can use to find the software in your CMake code.
 Also, for SDL I would recommend to use the FindSDL.cmake module (not sure
 whether that works with SDL2, though), and only if that fails, to resort to
 ExternalProject. It is good practice to offer the user the choice which way
 should be used through a cached variable.

 HTH

 Michael



--

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] External dependencies and Windows

[Michael Wild]

Leave it to your user. Not your problem. Use find_package() (or
find_library() and find_path()) as appropriate, do your best to deal with
common situations (e.g. Python or Qt having keys in the registry telling
you the installation location), and then trust your user to know what he
does. That's all you can do.


On Mon, Feb 4, 2013 at 2:05 PM, Ansis Māliņš ansis.mal...@gmail.com wrote:

 Exactly! So, going back to my original question, how do I use CMake in
 face of DLL Hell?


 On Mon, Feb 4, 2013 at 2:58 PM, Michael Wild them...@gmail.com wrote:

 That has nothing to do whether the libraries are shared (i.e. dynamically
 linked) or not. It has to do with the way that packaging works (or rather,
 doesn't work) on Windows. In the pre-.NET era it was simply impossible to
 use library versioning on Windows. If package A installed python.dll
 version X.Y into C:\Windows\System32 and later package B installed version
 Z.F into the same place, package A stopped working. Further, packagers
 where essentially forced to include all dependencies in their packages
 because there's no dependency-resolution mechanism. That's why people
 started providing a copy of all the dependencies in the installation
 directory of their package. Of course, this leads to a lot of duplication,
 especially for rather popular things such as Python or Qt. The whole
 situation is referred to as DLL hell:
 http://en.wikipedia.org/wiki/DLL_Hell

 Michael


 On Mon, Feb 4, 2013 at 1:43 PM, Ansis Māliņš ansis.mal...@gmail.comwrote:

 If shared libraries on Windows are truly shared, then why so many
 applications carry their own copies of that same Qt and Python? Examples
 from my own Program Files: Anki, Blender, Mixxx, Mumble, TortoiseHg.


 On Mon, Feb 4, 2013 at 2:15 PM, Michael Wild them...@gmail.com wrote:

 Hi


 On Mon, Feb 4, 2013 at 12:43 PM, Ansis Māliņš 
 ansis.mal...@gmail.comwrote:

 I'm just learning CMake and posting questions in this mailing list,
 but the answers I get only confuse me. It seems I must take a step back 
 and
 ask more general questions.

 In Linux there is a package for everything, so you just find_package
 whatever you need.

 But on Windows most libraries exist only as zip files that you're
 supposed to unpack right in your build environment and ship them together
 with the executable. (Basically, in practice, there is no such thing as
 shared libraries in Windows - nothing for find_package to find.)


 What then are DLL's? They are the shared libraries of the Windows
 world. True, the semantics are a bit different, but they are dynamically
 linked. It's also not true that on Windows everything is a zip files that
 you're supposed to unpack right in your build environment. If you don't
 believe me, try to take a look at Qt or Python.



 So how am I supposed to write portable CMake scripts in face of this?



  Often the Windows packages are installed into a few well known
 locations, or even better, create a registry key containing installation
 information which you then can use to find the software in your CMake code.
 Also, for SDL I would recommend to use the FindSDL.cmake module (not sure
 whether that works with SDL2, though), and only if that fails, to resort to
 ExternalProject. It is good practice to offer the user the choice which way
 should be used through a cached variable.

 HTH

 Michael





--

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] When should I use add_subdirectory and when ExternalProject?

[Michael Wild]

If your project is open source and you want to have any chance of it ever
being included in any of the major Linux distros without making somebody
very angry at you, forget about add_subdirectory() for external
dependencies.


On Mon, Feb 4, 2013 at 3:29 PM, Theodore Papadopoulo 
theodore.papadopo...@inria.fr wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 02/04/2013 09:23 AM, Ansis Māliņš wrote:
  If I have a dependency (e.g. SDL2) that seems to work with
  add_subdirectory just fine, should I still use ExternalProject_Add
  instead? Given both ways work, what should I prefer? What are the
  tradeoffs?

 This is just my view on this topic.
 Personnally, I prefer using add_subdirectory even though
 ExternalProject_Add is probably cleaner (no possible interaction
 between variables of different subdirs).

 Why do I prefer the add_subdirectory, well mostly because:

  1) ExternalProject_Add and add_subdirectory do not play very well
 together. External_Project_Add does all its work at make time, so that
 all UseXXX et al are not generated at configure time. So if you use a
 add_subdirectory for a project with a dependency that its build with
 ExternalProject_Add that will not work.

 2) When you use External_Project_add with a download, and get a
 compilation error, you tend to correct some sources that are placed in
 the build directory which can be very easily removed... This probably
 can be corrected with some External_Project_add magic, but I do not
 know if you can strictly separate the build from the source stuffs.

 3) That being said, it is true that External_Project_add is a little
 bit cleaner and should work directly with subprojects that have a
 functionning build system (not necessarily cmake by the way which is
 another advantage). Using add_subdirectory requires to avoid
 conflicting variables and often some changes from
 CMAKE_{SOURCE,BINARY}_DIR to CMAKE_CURRENT_{SOURCE,BINARY}_DIR.
 The same thing can be said for cmake macros (which one do you take), ...

 Still, when add_subdirectory works, it is in my view simpler and better.

 Theo.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.13 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iEYEARECAAYFAlEPxc8ACgkQEr8WrU8nPV2CdACffDVj8hkJKsRnWzZJOiir+ef/
 IIEAn1bzlrfggpkdd9+3eYffwB+rxFlu
 =eb+k
 -END PGP SIGNATURE-
 --

 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] External dependencies and Windows

[Michael Wild]

How did you compile SDL?

Most generally, you would do:

find_path(SDL2_INCLUDE_DIR SDL.h PATH_SUFFIXES SDL2)
# I have no idea against which libraries you have to link, so you might
need more than this
find_library(SDL2_LIBRARY SDL)

if(NOT SDL2_INCLUDE_DIR OR NOT SDL2_LIBRARY)
  message(SEND_ERROR Failed to find SDL2)
endif()
include_directories(${SDL2_INCLUDE_DIR})
set(SDL2_LIBRARIES ${SDL2_LIBRARY}) # and possibly others


add_executable(sdl_test sdl_test.cpp)
target_link_libraries(sdl_test ${SDL_LIBRARIES})


Then, when you invoke CMake, you use the
-DCMAKE_PREFIX_PATH=/path/to/SDL/build flag to inform CMake about where to
search for headers and libraries.


On Mon, Feb 4, 2013 at 3:14 PM, Ansis Māliņš ansis.mal...@gmail.com wrote:

 It looks like I'm still asking the wrong questions.

 As a last resort, here's my specific problem: I want to compile and run a
 hello world SDL2 application on Windows, Linux, and OS X - purely as an
 exercise in CMake. How would YOU do this?

 SDL2 only exists in source form in their repository.

 This is my main.cpp:
 #include SDL.h
 int main(int argc, char** argv)
 {
 if (SDL_Init(SDL_INIT_VIDEO)  0) printf(FAILURE\n);
  else printf(SUCCESS\n);
 SDL_Quit();
  return 0;
 }

 --

 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] When should I use add_subdirectory and when ExternalProject?

[Michael Wild]

In a SuperBuild, all projects, even your own, are built by one large
super-build project that contains a series of ExternalProject_Add calls.
That's all there is to it.


On Mon, Feb 4, 2013 at 4:23 PM, Ansis Māliņš ansis.mal...@gmail.com wrote:

 SuperBuild pattern
 Tell me all about it!

 --

 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] help: Does CMake support Vxworks platform?

[Michael Wild]

AFAIK you will need to cross-compile for VxWorks, and for that you need a
toolchain file that describes the cross-compile toolchain (compiler,
linker, archiver, etc.) to CMake. Googling I found this:
https://github.com/alexbrinister/vxWorks-GCC-NashobaRobotics/blob/master/vxworks-toolchain.cmake.
Perhaps it is of help to you?

Michael


On Tue, Feb 5, 2013 at 3:42 AM, Xuyongli xuyon...@huawei.com wrote:

  Hello,

 ** **

 I will use CMake to our project. Our project runs on Vxworks, Suse Linux,
 and Windows, So I want CMake supports Vxworks. Also I could modify the
 source code, but that is difficult for me. So I hope developers could add
 the Vxworks platform supported.

 ** **

 Xu,YongLi

 --

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

[Michael Wild]

On 10/17/2012 08:05 PM, Totte Karlsson wrote:
 
 On 10/16/2012 12:49 AM, Michael Wild wrote:
 This will always work:

 add_executable(frobnicate frobnicate.c)

 add_custom_command(OUTPUT ${resultFile}
COMMAND frobnicate ${resultFileFolder}
WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}
COMMENT Generating Wiki reports
VERBATIM)

 add_custom_target(generateReports ALL DEPENDS ${resultFile})
 
 This worked perfectly for both CodeGear and VisualStudio.
 
 Thanks!
 Totte
 

You're very welcome, I'm glad it solved your issue.

Michael

--

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

[Michael Wild]

On 10/15/2012 08:20 PM, Totte Karlsson wrote:
 
 set( resultFileFolder ${PROJECT_SOURCE_DIR}/wiki/reports) set(
 resultFile ${resFileFolder}/tests_auto.xml)
 
 First things first: You should *never* pollute your source tree, always
 output to the build tree.
 This is part of a google code project and the output file is a report in
 the wiki. It belongs in the repository. Actually, its not an output from
 the build itself, but output from a test, run just after the build.
 

 You need a top-level target that DEPENDS on the output, that's all. E.g.

 add_custom_target(createWikiReports ALL DEPENDS ${resultFile})
 I ended up doing this instead;
 set( resultFileFolder ${CMAKE_SOURCE_DIR}/wiki/reports)
 
 add_custom_target(test PACKAGE
 COMMAND ${exe_path}/${target}.exe ${resultFileFolder}
 )
 
 This seem to work well with borland, but with visual studio it is
 executed before the target is built, which is a problem, obviously.

You need a DEPENDS ${target}, otherwise the build order of top-level
targets is determined by the build system. The drawback is, that custom
targets are always considedered to be out-of-date, i.e. will be invoked
on every single build. After all, they don't know anything about the
output...

 
 So perhaps the combination of add_custom_command and add_custom_target
 is needed?

If you want to run the command only if any of the dependencies
(executable, input files) changes, yes.

 
 Weird that it behaves differently using borland and visual studio though?

As mentioned, top-level targets without explicit dependencies are built
in which-ever order they please.

 BTW: You don't need to specify the full path to the executable in the
 COMMAND, and also no DEPENDS on it in the custom command. Just use the
 target name, and CMake will handle the rest for you.
 I always seem to have problem with the paths regarding targets, because
 of Visual Studios addition of Debug and Release.
 -totte

It's not clear what you want to say here... Does it work with the target
name, or does it no?

This will always work:

add_executable(frobnicate frobnicate.c)

add_custom_command(OUTPUT ${resultFile}
  COMMAND frobnicate ${resultFileFolder}
  WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}
  COMMENT Generating Wiki reports
  VERBATIM)

add_custom_target(generateReports ALL DEPENDS ${resultFile})

Michael

--

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] Same effect as g++ -bundle ?

[Michael Wild]

On 10/16/2012 02:06 AM, digitalriptide wrote:
 I need to create a Mach-o bundle format file. With g++, for example, I
 can do the following
 
 g++ -o helloWorld.bundle -bundle helloWorld.o
 
 given some object file.
 
 Is there some way to do this from cmake? I've looked at the
 documentation for add_library but I can't seem to find anything.
 
 Any hints or pointers are greatly appreciated. Cheers!

add_library(helloWorld helloWorld.m)
set_taget_properties(helloWorld PROPERTIES BUNDLE TRUE)

HTH

Michael
--

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

[Michael Wild]

Hi

On 10/15/2012 12:54 AM, Totte Karlsson wrote:
 Hi, I have an executable target, that I want to be executed as part
 of its own build.
 
 The target takes one argument, which is output folder of a text
 file. This text file is part of my source dir.
 
 In my CMake file I have, at the end
 
 set( resultFileFolder ${PROJECT_SOURCE_DIR}/wiki/reports) set(
 resultFile ${resFileFolder}/tests_auto.xml)

First things first: You should *never* pollute your source tree, always
output to the build tree.

 
 add_custom_command( DEPENDS ${target} OUTPUT ${resultFile} COMMAND
 ${CMAKE_CURRENT_BINARY_DIR}/bin/${target} ARGS ${resultFileFolder} )
 
 Now, this never seem to execute. No warnings, no nothing.
 
 How to get it going?
 
 -totte
 

You need a top-level target that DEPENDS on the output, that's all. E.g.

add_custom_target(createWikiReports ALL DEPENDS ${resultFile})

BTW: You don't need to specify the full path to the executable in the
COMMAND, and also no DEPENDS on it in the custom command. Just use the
target name, and CMake will handle the rest for you.

HTH

Michael
--

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] Add Find*.cmake files for Pantheios and STLSoft to distro?

[Michael Wild]

On 09/12/2012 12:41 PM, Philipp Berger wrote:

About a few weeks ago I asked for help regarding Find*.cmake files for
Pantheios. With your help, I managed to build a Find file for Pantheios
and its associated library STLSoft. My question now is:

Where can I submit those files to be included in the offical CMake
distro so that everyone can use the files?


Cheers,
Philipp


Hi

Read this: http://www.vtk.org/Wiki/CMake:Module_Maintainers

Michael

--

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] Version in name of shared library

[Michael Wild]

On 09/06/2012 09:43 AM, Anton Sibilev wrote:
 Hi all!
 
 I'm making shared library with add_library(xxx SHARED xxx.c) and as
 result I got 'libxxx.so'.
 I want to create lib with name like 'libxxx.so.1', can you please help,
 how to make this?
 
 Point is not to create link or copy libxxx.so - libxxx.so.1, but to
 create it initially.
 
 Thanks!

You need to set the VERSION and SOVERSION target properties:

http://cmake.org/cmake/help/v2.8.8/cmake.html#command:set_target_properties

Michael

--

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] Version in name of shared library

[Michael Wild]

On 09/06/2012 10:05 AM, Benjamin Eikel wrote:
 Am Donnerstag, 6. September 2012 um 10:01:36 schrieb Michael Wild:
 On 09/06/2012 09:43 AM, Anton Sibilev wrote:
 Hi all!

 I'm making shared library with add_library(xxx SHARED xxx.c) and as
 result I got 'libxxx.so'.
 I want to create lib with name like 'libxxx.so.1', can you please help,
 how to make this?

 Point is not to create link or copy libxxx.so - libxxx.so.1, but to
 create it initially.

 Thanks!

 You need to set the VERSION and SOVERSION target properties:

 http://cmake.org/cmake/help/v2.8.8/cmake.html#command:set_target_properties
 
 Right. One example:
 
 set(MYLIB_VERSION_MAJOR 0)
 set(MYLIB_VERSION_MINOR 1)
 set(MYLIB_VERSION_PATCH 1)
 set(MYLIB_VERSION_STRING 
 ${MYLIB_VERSION_MAJOR}.${MYLIB_VERSION_MINOR}.${MYLIB_VERSION_PATCH})
 
 set_target_properties(MyLib PROPERTIES VERSION ${MYLIB_VERSION_STRING}
   SOVERSION ${MYLIB_VERSION_MAJOR})
 

As an added remark: The SOVERSION is not necessarily the same as the
major version. The rule is that any breakage of the ABI must be
indicated by incrementing the SOVERSION. So, adding e.g. functions is no
problem, modifying argument lists or removing functions would required
the SOVERSION to be incremented. Similar rules hold of course for
non-opaque data-structures. For C++ the whole issue is infinitely more
complicated, as determining whether the ABI was changed in an
incompatible way is AFAIK nearly impossible.

Michael

--

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] Version in name of shared library

[Michael Wild]

On 09/06/2012 10:09 AM, Michael Wild wrote:
 On 09/06/2012 10:05 AM, Benjamin Eikel wrote:
 Am Donnerstag, 6. September 2012 um 10:01:36 schrieb Michael Wild:
 On 09/06/2012 09:43 AM, Anton Sibilev wrote:
 Hi all!

 I'm making shared library with add_library(xxx SHARED xxx.c) and as
 result I got 'libxxx.so'.
 I want to create lib with name like 'libxxx.so.1', can you please help,
 how to make this?

 Point is not to create link or copy libxxx.so - libxxx.so.1, but to
 create it initially.

 Thanks!

 You need to set the VERSION and SOVERSION target properties:

 http://cmake.org/cmake/help/v2.8.8/cmake.html#command:set_target_properties

 Right. One example:

 set(MYLIB_VERSION_MAJOR 0)
 set(MYLIB_VERSION_MINOR 1)
 set(MYLIB_VERSION_PATCH 1)
 set(MYLIB_VERSION_STRING 
 ${MYLIB_VERSION_MAJOR}.${MYLIB_VERSION_MINOR}.${MYLIB_VERSION_PATCH})

 set_target_properties(MyLib PROPERTIES VERSION ${MYLIB_VERSION_STRING}
   SOVERSION ${MYLIB_VERSION_MAJOR})

 
 As an added remark: The SOVERSION is not necessarily the same as the
 major version. The rule is that any breakage of the ABI must be
 indicated by incrementing the SOVERSION. So, adding e.g. functions is no
 problem, modifying argument lists or removing functions would required
 the SOVERSION to be incremented. Similar rules hold of course for
 non-opaque data-structures. For C++ the whole issue is infinitely more
 complicated, as determining whether the ABI was changed in an
 incompatible way is AFAIK nearly impossible.
 
 Michael
 

For the interested, [1] is a very valuable resource for C++ programmers
concerned about ABI compatibility.

[1]
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
--

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] numerical option at compile time

[Michael Wild]

On 09/06/2012 04:15 PM, Jack Stalnaker wrote:
 Using autoconf, I could specify a numerical option using AC_ARG_ENABLE.
 This was useful for specifying a logging level at compile time. I could
 pass --enable-logging=8 to the configure script to enable deep logging.
 Is there a way to do this with cmake? Seems like option only allows
 yes or no answers. 
 
 

-8---
set(LOG_LEVEL 0 CACHE STRING Logging level)
if(NOT LOG_LEVEL MATCHES ^[0-9]$)
  message(FATAL_ERROR LOG_LEVEL must be a number from 0 to 9)
endif()
-8---

HTH

Michael

--

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-developers] what happened to cmake users forum?

[Michael Wild]

On 08/30/2012 03:44 PM, Skippy VonDrake wrote:
 I remember belonging to a mailing list meant for general questions
 from cmake users.
 Where does on go no when the have a problem/question just using cmake?
 This site: http://public.kitware.com/mailman/listinfo/dart
 just lists cmake-developers and cmake-commits.
 Or does this list include user questions?
 From looking at the archives it looks like its meant for developers
 working on enhancing/fixing cmake.
 

Here: http://public.kitware.com/mailman/listinfo/cmake

HTH

Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Failure to create CMakeFiles/libname.dir

[Michael Wild]

On 08/17/2012 05:25 PM, David Cole wrote:
 
 
 On Fri, Aug 17, 2012 at 11:16 AM, Rolf Eike Beer e...@sf-mail.de
 mailto:e...@sf-mail.de wrote:
 
 Am Freitag, 17. August 2012, 14:17:33 schrieb Michael Wild:
  Yes, e.g. i386 works fine:
 
 
 https://buildd.debian.org/status/fetch.php?pkg=freefoamarch=i386ver=0.1.0%
  2Bdfsg-1stamp=1345172639
 
  It seems that only the more exotic (non-Intel) ones have this issue. I
  forgot to mention that mipsel and sparc have the same problem. Except
  for mipsel they are all big-endian...
 
 You are looking at the totally wrong place I guess ;)
 
 i386 command:
 
 cd
 /build/buildd-freefoam_0.1.0+dfsg-1-i386-5n1wds/freefoam-0.1.0+dfsg/obj-
 i486-linux-gnu/src/Pstream/dummy  /usr/bin/g++  
 -DdummyPstream_EXPORTS -DDP
 -DNoRepository -Dlinux -g -O2 -fstack-protector
 --param=ssp-buffer-size=4 -
 Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fpermissive -
 D_FORTIFY_SOURCE=2 -fPIC -I/build/buildd-freefoam_0.1.0+dfsg-1-
 i386-5n1wds/freefoam-0.1.0+dfsg/obj-i486-linux-gnu/include-o
 CMakeFiles/dummyPstream.dir/dummyIPstreamImpl.C.o -c /build/buildd-
 freefoam_0.1.0+dfsg-1-
 i386-5n1wds/freefoam-0.1.0+dfsg/src/Pstream/dummy/dummyIPstreamImpl.C
 
 powerpc build:
 
 cd
 
 /build/buildd-freefoam_0.1.0+dfsg-1-powerpc-810bTJ/freefoam-0.1.0+dfsg/obj-
 powerpc-linux-gnu/src/Pstream/dummy  /usr/bin/g++  
 -DdummyPstream_EXPORTS -
 DDP -DNoRepository -g -O2 -fstack-protector
 --param=ssp-buffer-size=4 -Wformat
 -Werror=format-security -D_FORTIFY_SOURCE=2 -fpermissive
 -D_FORTIFY_SOURCE=2 -
 fPIC -I/build/buildd-freefoam_0.1.0+dfsg-1-
 powerpc-810bTJ/freefoam-0.1.0+dfsg/obj-powerpc-linux-gnu/include  
  -D -o
 CMakeFiles/dummyPstream.dir/dummyIPstreamImpl.C.o -c /build/buildd-
 freefoam_0.1.0+dfsg-1-
 powerpc-810bTJ/freefoam-0.1.0+dfsg/src/Pstream/dummy/dummyIPstreamImpl.C
 
 The important difference is:
 
 the PowerPC build has a stray -D in it, so g++ takes the following
 -o as
 define and the following object file name as input instead of as output.
 
 
 NICE EYE!

How very embarrassing! Thanks for helping me out with this one.

Michael
--

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] Failure to create CMakeFiles/libname.dir

[Michael Wild]

On 08/18/2012 02:20 PM, David Cole wrote:
 
 
 On Sat, Aug 18, 2012 at 6:57 AM, Michael Wild them...@gmail.com
 mailto:them...@gmail.com wrote:
 
 On 08/17/2012 05:25 PM, David Cole wrote:
 
 
  On Fri, Aug 17, 2012 at 11:16 AM, Rolf Eike Beer e...@sf-mail.de
 mailto:e...@sf-mail.de
  mailto:e...@sf-mail.de mailto:e...@sf-mail.de wrote:
 
  Am Freitag, 17. August 2012, 14:17:33 schrieb Michael Wild:
   Yes, e.g. i386 works fine:
  
 
 
 https://buildd.debian.org/status/fetch.php?pkg=freefoamarch=i386ver=0.1.0%
   2Bdfsg-1stamp=1345172639
  
   It seems that only the more exotic (non-Intel) ones have
 this issue. I
   forgot to mention that mipsel and sparc have the same
 problem. Except
   for mipsel they are all big-endian...
 
  You are looking at the totally wrong place I guess ;)
 
  i386 command:
 
  cd
 
 /build/buildd-freefoam_0.1.0+dfsg-1-i386-5n1wds/freefoam-0.1.0+dfsg/obj-
  i486-linux-gnu/src/Pstream/dummy  /usr/bin/g++
  -DdummyPstream_EXPORTS -DDP
  -DNoRepository -Dlinux -g -O2 -fstack-protector
  --param=ssp-buffer-size=4 -
  Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fpermissive -
  D_FORTIFY_SOURCE=2 -fPIC -I/build/buildd-freefoam_0.1.0+dfsg-1-
  i386-5n1wds/freefoam-0.1.0+dfsg/obj-i486-linux-gnu/include-o
  CMakeFiles/dummyPstream.dir/dummyIPstreamImpl.C.o -c
 /build/buildd-
  freefoam_0.1.0+dfsg-1-
 
 i386-5n1wds/freefoam-0.1.0+dfsg/src/Pstream/dummy/dummyIPstreamImpl.C
 
  powerpc build:
 
  cd
 
 
 /build/buildd-freefoam_0.1.0+dfsg-1-powerpc-810bTJ/freefoam-0.1.0+dfsg/obj-
  powerpc-linux-gnu/src/Pstream/dummy  /usr/bin/g++
  -DdummyPstream_EXPORTS -
  DDP -DNoRepository -g -O2 -fstack-protector
  --param=ssp-buffer-size=4 -Wformat
  -Werror=format-security -D_FORTIFY_SOURCE=2 -fpermissive
  -D_FORTIFY_SOURCE=2 -
  fPIC -I/build/buildd-freefoam_0.1.0+dfsg-1-
  powerpc-810bTJ/freefoam-0.1.0+dfsg/obj-powerpc-linux-gnu/include
   -D -o
  CMakeFiles/dummyPstream.dir/dummyIPstreamImpl.C.o -c
 /build/buildd-
  freefoam_0.1.0+dfsg-1-
 
 powerpc-810bTJ/freefoam-0.1.0+dfsg/src/Pstream/dummy/dummyIPstreamImpl.C
 
  The important difference is:
 
  the PowerPC build has a stray -D in it, so g++ takes the
 following
  -o as
  define and the following object file name as input instead of
 as output.
 
 
  NICE EYE!
 
 How very embarrassing! Thanks for helping me out with this one.
 
 
 Just curious: was it a misspelled variable name? Would you have gotten a
 warning if you used --warn-unused-vars on the cmake command line?
 

Not misspelled, it was a unhandled situation. When I originally wrote
that code years ago I consciously decided to only handle i386 and x86_64
and figured I'd deal with other architectures when the situation crops
up. Well, I completely forgot about that, and here it is ;-) And yes,
that flag would have fired, but then I also rely on undefined variables...

Michael
--

Powered by www.kitware.com

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

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

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

[CMake] Failure to create CMakeFiles/libname.dir

[Michael Wild]

Dear all

I have this very strange case that on some hardware architectures
(powerpc, s390, s390x) CMake somehow fails to generate the
target-directories (/path/to/build-tree/CMakeFiles/libname.dir).

Have you ever encountered this problem?

If you're curious, here's the build log of one such failure:

https://buildd.debian.org/status/fetch.php?pkg=freefoamarch=powerpcver=0.1.0%2Bdfsg-1stamp=1345150038

Thanks for any hints

Michael
--

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] Failure to create CMakeFiles/libname.dir

[Michael Wild]

Yes, e.g. i386 works fine:
https://buildd.debian.org/status/fetch.php?pkg=freefoamarch=i386ver=0.1.0%2Bdfsg-1stamp=1345172639

It seems that only the more exotic (non-Intel) ones have this issue. I
forgot to mention that mipsel and sparc have the same problem. Except
for mipsel they are all big-endian...

Michael

On 08/17/2012 02:10 PM, David Cole wrote:
 Guess: Maybe the + in the build tree directory name is messing
 something up?
 
 Are there + characters in the build tree names on architectures that work?
 
 
 On Fri, Aug 17, 2012 at 8:01 AM, Michael Wild them...@gmail.com
 mailto:them...@gmail.com wrote:
 
 Dear all
 
 I have this very strange case that on some hardware architectures
 (powerpc, s390, s390x) CMake somehow fails to generate the
 target-directories (/path/to/build-tree/CMakeFiles/libname.dir).
 
 Have you ever encountered this problem?
 
 If you're curious, here's the build log of one such failure:
 
 
 https://buildd.debian.org/status/fetch.php?pkg=freefoamarch=powerpcver=0.1.0%2Bdfsg-1stamp=1345150038
 
 Thanks for any hints
 
 Michael
 --
 
 Powered by www.kitware.com http://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] cmake output file naming

[Michael Wild]

BTW, I found that using lcov is much easier than trying to figure out
the raw gcov output and it handles the output file naming automatically too.

Michael

On 08/17/2012 04:22 PM, Sumit Adhikari wrote:
 Now I am doing good. Thanks for the info. 
 
 By the way, why not making this a feature (instead of keeping it as an
 internal variable with a chance that it gets dropped in future). A
 suggestion though :)
 
 Regards,
 Sumit
 
 On Fri, Aug 17, 2012 at 3:22 PM, Brad King brad.k...@kitware.com
 mailto:brad.k...@kitware.com wrote:
 
 On 8/17/2012 5:03 AM, Sumit Adhikari wrote:
  I have particular problem with the cmake generated output file naming
  conventions (like myfile.cpp.o, myfile.cpp.gcno, ).
 
 Object file names are computed in a deterministic manner
 based only on the source file name and location.  The
 object name must not conflict with that computed from any
 other source file.  In order to handle
 
  add_executable(foo foo.c foo.cpp)
 
 the object name must include the source extension.
 
 The implementation is here:
 
  
 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalGenerator.cxx;hb=v2.8.9#l2857
 
 If you really want to avoid the extension you can set the
 undocumented internal implementation detail variable:
 
  set(CMAKE_C_OUTPUT_EXTENSION_REPLACE 1)
  set(CMAKE_CXX_OUTPUT_EXTENSION_REPLACE 1)
 
 some time after the project() command call that enables
 the C and CXX languages.  As the variables are internal
 details this will not be guaranteed to work in the future.
 
  These naming conventions creating trouble for me to run gcov *.cpp
  properly with my -o /objdir option
 
 How does *.cpp match .cpp.o?
 
 -Brad
 
 
 
 
 -- 
 Sumit Adhikari,
 Institute of Computer Technology,
 Faculty of Electrical Engineering,
 Vienna University of Technology,
 Gußhausstraße 27-29,1040 Vienna
 
 
 --
 
 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 build only when file contents are actually changed?

[Michael Wild]

On 08/14/2012 01:18 PM, Peng Yu wrote:
 CMake really leaves the decision when to recompile something to the
 backend, i.e. GNU Make, Xcode, Visual Studio, ninja etc. It merely
 defines dependencies and then lets the actual build tool handle the
 rest, and most of them choose to use simple time-stamps instead of
 
 Although GNU Make natively does not support build on content change,
 it can be hijacked using the trick in the link that I mentioned. I
 think that it is not impossible to do so in cmake at the language
 level. But it is better if cmake can support this natively.

Again, using ccache solves this much more elegantly. And calling md5sum
twice is also not very nice...

 
 Yes this is a feature request not a bug report. (To J Decker)

Well, if you have the time, I'm pretty sure that the CMake developers
would happily review your patch implementing this feature.

 
 This feature is available to scons. And I think it is reasonable to
 expect cmake also have it. I seems that people here did think about it
 seriously before, which is a surprise to me.

Yes, but scons is monolithic. It doesn't have the backend build-system
from the front end and hence doesn't have to ensure that GNU Make
behaves consistently with what Xcode, Visual Studio, ninja etc. do.

Michael
--

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 build only when file contents are actually changed?

[Michael Wild]

On 08/14/2012 02:41 PM, Peng Yu wrote:
 Again, using ccache solves this much more elegantly. And calling md5sum
 twice is also not very nice...
 
 I'm not sure ccache replaces hash. My understanding is that ccache
 speed up individual compilation, but all the targets that depends on
 it are still compiled. With hash, a file is checked first whether it
 should be recompiled, if not, it will not be recompiled, and all the
 targets that depend on it will not be compiled either. I'm not with a
 machine that I can check ccache as this moment. Please correct me if
 I'm wrong.
 
 The following compares a few features. But since it is from waf, it
 might be biased in favor of waf. Nevertheless, there are some features
 that available in other tools missing in cmake.
 
 http://code.google.com/p/waf/wiki/WafAndOtherBuildSystems
 

You miss the point. If CMake wanted to offer hash-based checking, it
would need to do so for *all* backends, not just GNU Make. Good look
implementing that hack in Visual Studio or Xcode...

Michael
--

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 build only when file contents are actually changed?

[Michael Wild]

On 08/14/2012 04:32 PM, Peng Yu wrote:
 You miss the point. If CMake wanted to offer hash-based checking, it
 would need to do so for *all* backends, not just GNU Make. Good look
 implementing that hack in Visual Studio or Xcode...
 
 I get your point that there is not an easy to do content based
 dependency (hash as an approximation) for all backends. For the reason
 mentioned below, I'd think that content based dependency is important.
 The support for this feature should be considered first for GNU make,
 which does seem to be too difficult (as it just requires some
 additional rules). The support for *all* backends can be added later
 on one by one.

I'm not sure how the CMake-devs feel about that, but again, you are most
welcome to submit a patch implementing this.

 
 o Makepp will not recompile if only comments or whitespace in
   C/C++ sources have changed.  This is especially important for header
   files which are automatically generated by other programs and are
   included in many modules.  Even if the date has changed because the
   file was remade, makepp won't recompile if the file hasn't changed.
 

That's plenty dangerous! Only a full C/C++ compiler can decide whether
something is a comment or not (as this requires full parsing
capabilities) and further it might interfere with compiler bugs; I
remember having the problem that with -O3 and old version of the Apple
GCC produced code that segfaulted depending on whether a certain comment
line was present or not!

Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] cmake manpage in pdf with section (subsection, etc) bookmarks and hyperlinks?

[Michael Wild]

On 08/13/2012 04:18 PM, Peng Yu wrote:
 Hi,
 
 I use the following command to generate the pdf file from cmake
 manpage. But the pdf file does not have bookmarks. Does anybody know a
 way to generated the manual in pdf with bookmarks and possibly
 hyperlinks?
 
 man -t $f | ps2pdf -  $f.pdf
 
 

Install dblatex and then run

cmake --help-full cmake-doc.docbook

to generate DocBook XML output which you then can process with your
favourite tool-chain (e.g. dblatex or the xmlto convenience wrapper).

However, it seems that the XML output does not validate (at least with
CMake 2.8.6 that is...). xmllint really chokes badly on it.

Michael
--

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 build only when file contents are actually changed?

[Michael Wild]

CMake really leaves the decision when to recompile something to the
backend, i.e. GNU Make, Xcode, Visual Studio, ninja etc. It merely
defines dependencies and then lets the actual build tool handle the
rest, and most of them choose to use simple time-stamps instead of
hashes. Also note that computing the hash might also incur considerable
overhead, in particular for very large projects with thousands of files.

You can alleviate the situation a bit by using e.g. ccache to speed up
unnecessary recompilations. E.g. on a system that has ccache installed
in /usr/lib/ccache (Ubuntu, Debian,...)

mkdir build
cd build
rm -rf *
PATH=/usr/lib/cchace:$PATH cmake ..

will build using ccache instead the normal compilers.

HTH

Michael

On 08/14/2012 05:22 AM, Peng Yu wrote:
 Hi,
 
 The following command output shows that when I touch a source without
 changing the content, the source are compiled and linked, which is a
 waste.
 
 This post shows how to use the checksum to decide whether a file is
 changed or not, if changed then update target. This feature seems to
 be missing in cmake. In case that I miss something in the document,
 could anybody let me know if this is the case?
 
 http://blog.jgc.org/2006/04/rebuilding-when-hash-has-changed-not.html
 
 ~/linux/test/cmake/lang/command/target_link_libraries/src$ cat.sh  *
 == CMakeLists.txt ==
 cmake_minimum_required(VERSION 2.8)
 add_library(print print.cpp)
 #include_directories(${HELLO_SOURCE_DIR})
 add_executable(main main.cpp)
 target_link_libraries(main print)
 
 == main.cpp ==
 #include print.hpp
 int main() {
   print();
 }
 
 == print.cpp ==
 #include print.hpp
 #include iostream
 using namespace std;
 void print() {
   cout  Hello, World!  endl;
 }
 
 == print.hpp ==
 #ifndef _hello_h
 #define _hello_h
 void print();
 #endif
 
 ~/linux/test/cmake/lang/command/target_link_libraries/build$ cmake ../src/
 -- The C compiler identification is GNU 4.2.1
 -- The CXX compiler identification is GNU 4.2.1
 -- Checking whether C compiler has -isysroot
 -- Checking whether C compiler has -isysroot - yes
 -- Checking whether C compiler supports OSX deployment target flag
 -- Checking whether C compiler supports OSX deployment target flag - yes
 -- 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
 -- Checking whether CXX compiler has -isysroot
 -- Checking whether CXX compiler has -isysroot - yes
 -- Checking whether CXX compiler supports OSX deployment target flag
 -- Checking whether CXX compiler supports OSX deployment target flag - yes
 -- 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:
 /Users/pengy/linux/test/cmake/lang/command/target_link_libraries/build
 ~/linux/test/cmake/lang/command/target_link_libraries/build$ make
 Scanning dependencies of target print
 [ 50%] Building CXX object CMakeFiles/print.dir/print.cpp.o
 Linking CXX static library libprint.a
 [ 50%] Built target print
 Scanning dependencies of target main
 [100%] Building CXX object CMakeFiles/main.dir/main.cpp.o
 Linking CXX executable main
 [100%] Built target main
 ~/linux/test/cmake/lang/command/target_link_libraries/build$ touch
 ../src/print.hpp
 ~/linux/test/cmake/lang/command/target_link_libraries/build$ make
 Scanning dependencies of target print
 [ 50%] Building CXX object CMakeFiles/print.dir/print.cpp.o
 Linking CXX static library libprint.a
 [ 50%] Built target print
 Scanning dependencies of target main
 [100%] Building CXX object CMakeFiles/main.dir/main.cpp.o
 Linking CXX executable main
 [100%] Built target main
 
 
 
 

--

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] Howto create a ProjectConfig.cmake tutorial

[Michael Wild]

Oops, my bad. Apologies. Fixed now.

Michael

On 08/08/2012 01:04 PM, Eric Noulard wrote:
 2012/8/8 Nico Schlömer nico.schloe...@gmail.com:
 Hi,

 I just looked at
 http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
 to learn about exporting build information to the installation, and
 started off by copying-and-pasting the contents of the tutorial to my
 own project. It doesn't quite run through since there's this one
 undefined variable ${INSTALL_DATA_DIR}. I have no idea what this is
 actually supposed to be.
 
 Usually this is the install prefix location of the data of your project.
 Like some dictionaries, or template files for something, may be CMake script
 files as well or 
 
 You can have a look  at GNUInstallDirs.cmake module to chekcout various
 standard directories.
 
 cmake --help-module GNUInstallDirs
 
 
 Anyone?
 
 The example is buggy, if you take the FooBar.zip as-is it can be configured
 but trying to install gives you:
 
 -- Install configuration: 
 CMake Error at cmake_install.cmake:56 (FILE):
   file cannot create directory: /FooBar/CMake.  Maybe need administrative
   privileges.
 
 telling you that INSTALL_DATA_DIR has not been defined in the project.
 I guess you get similar error?
 
 Concerning ProjectConfig file you should have a look at the helper module:
 CMakePackageConfigHelpers.cmake
 
 see:
 cmake --help-module CMakePackageConfigHelpers
 
 it provides macros which helps to produce package config files.
 

--

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] stderr and stdout in cmake

[Michael Wild]

On 07/30/2012 04:12 PM, luxInteg wrote:
 Greetings
 
 I have   a  bash script (from an auto-tools Makefile )   to translate
 to cmake
 
 
 My 'translation might  go something like thios
 
 execute_process(COMMAND ${some_command}  '21' INPUT_FILE
 ${someFile2} OUTPUT_FILE/dev/null WORKING_DIRECTORY
 ${some_dir} )
 
 I am unconfortable with the '21'  and I tried  reading up on
 
 file(WRITE ) and file(APPEND )
 
 but I am unsure how to proceed; for example how to use cmake -P  or
 cmake -- build  or using /dev/std* device files
 
 test [ ~ ]$ ls /dev/std* /dev/stderr  /dev/stdin  /dev/stdout test [
 ~ ]$
 
 
 Advice would be  appreciated
 
 Yours sincerely luxInteg

You should read up on execute_process() instead:

 If OUTPUT_QUIET or ERROR_QUIET is given then the standard  output or
 standard error results will be quietly ignored.

Michael

--

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] installing python scripts

[Michael Wild]

On 07/30/2012 02:15 AM, Kyle Husmann wrote:
 Hi all,
 
 In my project I have a python program (call it program.py) that
 references a python module also in my project (call it pymodule).
 program.py gets installed to ${CMAKE_INSTALL_PREFIX}/bin/program and
 pymodule gets installed to ${PYTHON_INSTALL_DIR}.
 
 To make sure the program.py program always finds pymodule, I treat it
 like a config script in cmake and then add the following to the top of
 program.py.in http://program.py.in:
 
 import sys
 sys.path.append(@PYTHON_INSTALL_DIR@)
 import pymodule
 
 This works great, but it means that I can only run program.py after
 running a make install, and running it from the installed location.
 
 My question is, is there are clever way of doing this so that I can run
 program.py from the build directory, without having to install it? (But
 have it still run properly when installed)
 
 Thanks,
 Kyle

Call CONFIGURE_FILE() twice, once for the installation and once for the
build-tree:

set(CONFIG_PY_DIR ${PROJECT_SOURCE_DIR})
configure_file(program.py.in ${PROJECT_BINARY_DIR}/program.py @ONLY)
set(CONFIG_PY_DIR ${PYTHON_INSTALL_DIR})
configure_file(program.py.in
  ${PROJECT_BINARY_DIR}/installFiles/program.py @ONLY)
install(PROGRAMS ${PROJECT_BINARY_DIR}/installFiles/program.py
  DESTINATION bin)


You'll need to replace PYTHON_INSTALL_DIR with CONFIG_PY_DIR in your
program.py.in file, of course. Also, I would replace the
sys.path.append(@CONFIG_PY_DIR@) call with sys.path.insert(0,
@CONFIG_PY_DIR@). There are pros and cons for each...

HTH

Michael
--

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] Writing a custom Find*.cmake file for Pantheios

[Michael Wild]

A few comments:

* transform all CMake commands to lower case names: s/IF/if/g,
s/ELSE/else/g, s/ENDIF/endif/g, s/SET/set/g etc.

* spelling: s/Settung/Setting/g

* docs list a component NFrontEnd, but that string doesn't show up in
the actual code. Typo?

* just set the default front- and backends before parsing the
Pantheios_FIND_COMPONENTS. Then you can also just drop the
PANTHEIOS_HAVE_{FRONT,BACK}END variables. Much simpler that way.

* set the default for PANTHEIOS_WIDESTRING before the
if(Pantheios_FIND_COMPONENTS), then you can remove the else() block.

* when defaulting PANTHEIOS_ROOT, use the
get_filename_component(PANTHEIOS_ROOT ${PANTHEIOS_INCLUDE_DIR} PATH)
idiom. Also, don't compare PANTHEIOS_INCLUDE_DIR against the empty
string. In a previous run, if not found, it can be set to
PANTHEIOS_INCLUDE_DIR_NOT-FOUND, which is not the empty string! Just use
if(PANTHEIOS_INCLUDE_DIR) instead. Marking the PANTHEIOS_ROOT variable
as advanced when not being in the cache is useless too.

* using $ENV{PANTHEIOS_ROOT}/include in the HINTS is dangerous since if
the environment variable is not set, it will evaluate to /include which
exists on *NIX systems. Better to use

find_path(PANTHEIOS_INCLUDE_DIR pantheios/pantheios.h
  PATH_SUFFIXES include
  HINTS ${PANTHEIOS_ROOT}
  ENV PANTHEIOS_ROOT)

* Don't set PANTHEIOS_INCLUDE_DIRS to the variable *name*
PANTHEIOS_INCLUDE_DIR. You have to dereference the variable:

set(PANTHEIOS_INCLUDE_DIRS ${PANTHEIOS_INCLUDE_DIR})

* Again, comparing ${PANTHEIOS_INCLUDE_DIR} against the empty string
is wrong! CMake will set its value to ..._NOT-FOUND in case of failure.
Just use

if(PANTHEIOS_INCLUDE_DIR)

and skip the whole message() stuff.

* Using file(GLOB ...) is almost certainly wrong. You'll need to find
out how the Pantheios library naming scheme works. From your example,
i'd think you could use the following when using Visual Studio:

# No idea what the UNIXEm stuff is, so I don't handle it here...
set(_P_COMP_TAG)
set(_P_OS_TAG)
set(_P_ARCH_TAG)
if(MSVC)
  if(MSVC60)
set(_P_COMP_TAG vc6)
  elseif(MSVC70)
set(_P_COMP_TAG vc7)
  elseif(MSVC71)
set(_P_COMP_TAG vc71)
  elseif(MSVC80)
set(_P_COMP_TAG vc8)
if(CMAKE_SIZEOF_VOID_P EQUAL 8)
  set(_P_ARCH_TAG .x64)
endif()
  elseif(MSVC90)
set(_P_COMP_TAG vc9)
if(CMAKE_SIZEOF_VOID_P EQUAL 8)
  set(_P_ARCH_TAG .x64)
endif()
  elseif(MSVC10)
set(_P_COMP_TAG vc10)
if(CMAKE_SIZEOF_VOID_P EQUAL 8)
  set(_P_ARCH_TAG .x64)
endif()
  endif()
elseif(...)
  ...
endif()

set(_P_LIB_TAG ${_P_COMP_TAG}${_P_OS_TAG}${_P_ARCH_TAG})


Once you have that, you can continue finding the libraries (you missed
all the local and remote backends, and also you missed the actual
globbing in the backend and frontend libraries...)


if(PANTHEIOS_INCLUDE_DIR)
  get_filename_component(PANTHEIOS_ROOT_HINT
${PANTHEIOS_INCLUDE_DIR} PATH)
endif()

set(_P_REQUIRED_LIBVARS)

# core and util libraries
foreach(l core util)
  find_library(PANTHEIOS_${l}_${PANTHEIOS_LIB_LINKTYPE}_DEBUG_LIBRARY
pantheios.1.core.${_P_LIB_TAG}.${PANTHEIOS_LIB_LINKTYPE}.debug
PATH_SUFFIXES lib
HINTS ${PANTHEIOS_ROOT_HINT} ${PANTHEIOS_ROOT}
ENV PANTHEIOS_ROOT)

  find_library(PANTHEIOS_${l}_${PANTHEIOS_LIB_LINKTYPE}_LIBRARY
pantheios.1.core.${_P_LIB_TAG}.${PANTHEIOS_LIB_LINKTYPE}
PATH_SUFFIXES lib
HINTS ${PANTHEIOS_ROOT_HINT} ${PANTHEIOS_ROOT}
ENV PANTHEIOS_ROOT)

  list(APPEND _P_REQUIRED_LIBVARS
PANTHEIOS_${l}_${PANTHEIOS_LIB_LINKTYPE}_DEBUG_LIBRARY
PANTHEIOS_${l}_${PANTHEIOS_LIB_LINKTYPE}_LIBRARY)
endforeach()

# backend libraries (split, sole, local, remote and common)
set(_P_LT ${PANTHEIOS_LIB_LINKTYPE})
set(_P_BE ${PANTHEIOS_BACKEND})
find_library(PANTHEIOS_be_lrsplit_${_P_LT}_DEBUG_LIBRARY
  pantheios.1.be.lrsplit.${_P_LIB_TAG}.${_P_LT}.debug
  PATH_SUFFIXES lib
  HINTS ${PANTHEIOS_ROOT_HINT} ${PANTHEIOS_ROOT}
  ENV PANTHEIOS_ROOT)

find_library(PANTHEIOS_be_lrsplit_LIBRARY
  pantheios.1.be.lrsplit.${_P_LIB_TAG}.${_P_LT}
  PATH_SUFFIXES lib
  HINTS ${PANTHEIOS_ROOT_HINT} ${PANTHEIOS_ROOT}
  ENV PANTHEIOS_ROOT)

list(APPEND _P_REQUIRED_LIBVARS
  PANTHEIOS_be_lrsplit_${_P_LT}_DEBUG_LIBRARY
  PANTHEIOS_be_lrsplit_${_P_LT}_LIBRARY)

foreach(t be bel ber bec)
  find_library(PANTHEIOS_${t}_${_P_BE}_${_P_LT}_DEBUG_LIBRARY
pantheios.1.${t}.${_P_BE}.${_P_LIB_TAG}.${_P_LT}.debug
PATH_SUFFIXES lib
HINTS ${PANTHEIOS_ROOT_HINT} ${PANTHEIOS_ROOT}
ENV PANTHEIOS_ROOT)

  find_library(PANTHEIOS_${t}_${_P_BE}_${_P_LT}_LIBRARY
pantheios.1.${t}.${_P_BE}.${_P_LIB_TAG}.${_P_LT}
PATH_SUFFIXES lib
HINTS ${PANTHEIOS_ROOT_HINT} ${PANTHEIOS_ROOT}
ENV PANTHEIOS_ROOT)

  list(APPEND _P_REQUIRED_LIBVARS
PANTHEIOS_${t}_${_P_BE}_${_P_LT}_DEBUG_LIBRARY
PANTHEIOS_${t}_${_P_BE}_${_P_LT}_LIBRARY)
endforeach()

# frontent libraries
set(PANTHEIOS_fe_DEBUG_LIBRARY)
set(PANTHEIOS_fe_LIBRARY)
if(NOT PANTHEIOS_FRONTENT STREQUAL null)
  set(_P_FE ${PANTHEIOS_FRONTEND})
  

Re: [CMake] Can multiple make commands be set in BUILD_COMMAND for ExternalProject_Add?

[Michael Wild]

On 07/04/2012 08:37 AM, hce wrote:
 Hi,
 
 In ExternalProject_Add, BUILD_COMMAND make works fine, but I need to add
 multiple make commands. In Linux command line I can type make  make
 extra, but how can I set following BUILD_COMMAND for multiple make
 commands, it just not working?
 
 BUILD_COMMAND make  make extra
 INSTALL_COMMAND make install  make extra-install
 
 Thank you.
 
 Kind regards,
 
 Jupiter
 

What's wrong with?

BUILD_COMMAND make all extra
INSTALL_COMMAND make install extra-install


HTH

Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Adding *.obj geometry files...

[Michael Wild]

On 06/13/2012 12:13 PM, Daniel Dekkers wrote:
 Somewhat related...
 
 We now have the resources excluded from the build but visible in the IDE. So
 far so good.
 But we also want to copy them (all) to the build directory.
 We have a post build command that does that. 
 But if you only change the contents of one of the resource files, a rebuild
 is not invoked (exclude from build) and so the files are not copied.
 For another project we made specific targets (ADD_CUSTOM_TARGET) just to
 handle the copying but that gives a lot of extra subprojects in the IDE.
 Is there another way to achieve this?
 
 Thanks,
 Daniel

You can use configure_file with COPYONLY in the CMakeLists.txt files,
but then, you'll have to reconfigure every time one of them changes.

Michael

--

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] Custom install target to install only files

[Michael Wild]

On 05/24/2012 03:43 PM, vivek goel wrote:
 I have a project with 10 binary files.
 and I am installing custom 15 bash files using
 
 install(PROGRAMS
   file-list
  DESTINATION /bin
   )
 
 Is there a way to have custom install target like
 make install script which will install only required script files with
 building source code for binary files?
 
 regards
 Vivek Goel

Add the COMPONENT scripts option to the install() command and then
install the scripts like this:

cmake -DCOMPONENT=scripts -P cmake_install.cmake

Note that the -D option must be *before* the -P option, otherwise it is
ignored.

HTH

Michael
--

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-developers] FinQt4/UseQt4 / module QtWebKit isn't found with Qt 4.8.1 even if installed

[Michael Wild]

On 05/16/2012 06:51 AM, Adrien Guinet wrote:
 Hello everyone,
 
 It seems that, in Qt 4.8.1 (at least in the Debian packages), the QtWebKit
 module isn't shipped in a separated .so (libQtWebKit.so).
 Thus, this makes FindQt4.cmake fails to find the QtWebkit modules, beucase
 a module is considered found when both its libraries files and directories
 are found. As a consequence, include directories are not set if the
 QT_USE_QTWEBKIT variable is set to TRUE (for instance), and code fails to
 compile.
 
 I don't know if this is an issue with the Debian packages of Qt (last
 packages in sid as of today), or if Qt decided to build QtWebkit within
 QtGui.
 
 Attached to this mail is a temporary patch (well, an ugly *hack* actually)
 that I am using (against FindQt4.cmake) :
 
 Thanks for any help or comments about this !
 
 Regards,
 

Do you have the libqtwebkit-dev package installed?

Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Reason of Fortran include directories /config?

[Michael Wild]

My guess is that it has something to do with module files.

Michael

On 05/16/2012 08:31 AM, Petr Kmoch wrote:
 Anyone? Surely there must be a reason for adding those directories.
 
 Petr
 
 On Thu, May 10, 2012 at 9:25 AM, Petr Kmoch petr.km...@gmail.com wrote:
 Hi all,

 we're using cmake to generate Intel Fortran .vfproj files and some of
 my developers were asking why include directories in the project
 always include X and X/config_name for every directory X specified
 via include_directories(). Looking at cmake source code, the lines
 responsible seem to be 829-837 of cmLocalVisualStudio7Generator.cxx
 (in the 2.8.8 released archive):

 // if this is fortran then output the include with
 // a ConfigurationName on the end of it.
 if(this-FortranProject)
  {
  ipath = i-c_str();
  ipath += /$(ConfigurationName);
  ipath = this-ConvertToXMLOutputPath(ipath.c_str());
  fout  ipath  ;;
  }
 }

 I would be really interested in the reason for this behaviour. Could
 anyone shed some light onto this for me?

 Thanks in advance.

 Petr

--

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] Package installation conundrum

[Michael Wild]

On 05/08/2012 11:13 PM, Dave Abrahams wrote:
 
 on Tue May 08 2012, Alexander Neundorf 
 a.neundorf-work-hi6Y0CQ0nG0-AT-public.gmane.org wrote:
 
 On Tuesday 08 May 2012, Dave Abrahams wrote:

 Here's another one!

 Scenario:

 * I am running CMake under 0install to build and install libraries

 * Each library builds a package SomePackage for the library binaries
 and another package SomePackage-dev for the library headers (and
 import libraries on Windows)

 * The FindSomePackage.cmake file is part of the -dev package

 * After building, 0install moves each package's build products into a
 mostly-unpredictable subdirectory of its otherwise-read-only cache
 (~/.cache/0install.net/). The subdirectory's name is determined by a
 hash of the files.

 * To get this working, I followed the scheme discussed here:

 http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40pluto.l
 uannocracy.com%3e

 Summary:

 1. Create a 0install SomePackage-preinstall package. Building this
 package involves CMake building and installing both SomePackage and
 SomePackage-dev into separate subdirectories (main/ and dev/) of
 some prefix. 0install thereafter moves the whole directory tree
 into its cache in a directory called sha1=someuglyhash

 2. SomePackage's 0installation procedure is to copy
 sha1=someuglyhash/main/ into its distribution directory (which then ends
 up in
 ~/.cache/0install.net/sha1=otheruglyhash)

 3. SomePackage-dev's 0installation procedure is to copy
 sha1=someuglyhash/dev/ into its distribution directory

 Problem: FindSomePackageConfig.cmake now has the wrong path to the
 library binaries.

 Any help most appreciated.

 Can you please summarize what you actually want to achieve ?
 
 Well, I tried to, above.
 
 In short, I want to create separate main and -dev packages without
 building twice, under the constraints imposed by 0install.
 
 Do you say that libFoo installs a FindFoo.cmake as part of libFoo-devel ?

 If that's the case, then this is wrong.
 
 I'm sorry, that *is* wrong.  It installs a FooConfig.cmake as part of 
 libFoo.devel
 
 FindFoo.cmake must be part of the using software, not of the software to be
 searched.

 Why do you have to find the installed library in this cache directory
 ?
 
 Because, in a 0install world, that's where things go when you install
 them.
 


Ok, how you do it along these lines:

CMakeLists.txt:
#-- BOF

cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
project(Foo)

set(FOO_VERSION 1.2.3)

# initialize (absolute) installation directory variables
set(INSTALL_BIN_DIR bin CACHE PATH Install path for binaries)
set(INSTALL_LIB_DIR lib CACHE PATH Install path for libraries)
set(INSTALL_INCLUDE_DIR include CACHE PATH Install path for headers)
# this is for UNIX systems, see docs of find_package() for the search
# paths on APPLE and WIN32
set(INSTALL_CMAKE_DIR lib/foo-${FOO_VERSION}/cmake CACHE PATH
  Install path for CMake files)
foreach(t BIN LIB INCLUDE CMAKE)
  if(NOT IS_ABSOLUTE ${INSTALL_${t}_DIR})
set(INSTALL_${t}_DIR ${CMAKE_INSTALL_PREFIX}/${INSTALL_${t}_DIR})
  endif()
  mark_as_advanced(INSTALL_${t}_DIR)
endforeach()

# configure FooConfig.cmake and friends. FooConfig.cmake must be able
# to locate FooExports.cmake and FOO_INCLUDE_DIR relative to its own
# directory without using absolute paths.
configure_file(cmake/FooConfig.cmake.in
  ${PROJECT_BINARY_DIR}/FooConfig.cmake @ONLY)
configure_file(cmake/FooConfigVersion.cmake.in
  ${PROJECT_BINARY_DIR}/FooConfigVersion.cmake @ONLY)

# configure the headers into the build tree so the package can be used
# without installing it and not hard-coding the source/build directory
# information into FooConfig.cmake
configure_file(include/foo.h
  ${PROJECT_BINARY_DIR}/include/foo.h COPYONLY)

# build targets
add_library(foo src/foo.cpp include/foo.h)
set_target_properties(foo PROPERTIES
  PUBLIC_HEADER include/foo.h
  VERSION ${FOO_VERSION}
  SOVERSION 1.0)
add_executable(bar bar.cpp)
target_link_libraries(bar foo)

# install targets and files
install(TARGETS foo bar
  EXPORT FooExports
  RUNTIME DESTINATION ${INSTALL_BIN_DIR} COMPONENT bin
  LIBRARY DESTINATION ${INSTALL_LIB_DIR} COMPONENT bin
  ARCHIVE DESTINATION ${INSTALL_LIB_DIR} COMPONENT dev
  PUBLIC_HEADER DESTINATION ${INSTALL_INCLUDE_DIR} COMPONENT dev)

install(FILES
  ${PROJECT_BINARY_DIR}/FooConfig.cmake
  ${PROJECT_BINARY_DIR}/FooConfigVersion.cmake
  DESTINATION ${INSTALL_CMAKE_DIR} COMPONENT dev)

# export targets to build and install tree
export(TARGETS foo bar NAMESPACE Foo_
  FILE ${PROJECT_BINARY_DIR}/FooExports.cmake)
export(PACKAGE Foo)

install(EXPORT FooExports
  DESTINATION ${INSTALL_CMAKE_DIR}
  NAMESPACE Foo_
  COMPONENT dev)

#-- EOF


With such a setup, you do something like the following for the
installation into the cache directories:

mkdir /path/to/build-tree
cd /path/to/build-tree
cmake /path/to/source-tree
make
DESTDIR=/path/to/bin-cache cmake -DCOMPONENT=bin -P cmake_install.cmake

Re: [CMake] Package installation conundrum

[Michael Wild]

On 09.05.2012, at 21:03, Alexander Neundorf a.neundorf-w...@gmx.net wrote:

 On Wednesday 09 May 2012, Michael Wild wrote:
  On 05/08/2012 11:13 PM, Dave Abrahams wrote:
   on Tue May 08 2012, Alexander Neundorf 
   a.neundorf-work-hi6Y0CQ0nG0-AT-public.gmane.org wrote:
   On Tuesday 08 May 2012, Dave Abrahams wrote:
   Here's another one!
  
   Scenario:
  
   * I am running CMake under 0install to build and install libraries
  
   * Each library builds a package SomePackage for the library binaries
   and another package SomePackage-dev for the library headers (and
   import libraries on Windows)
  
   * The FindSomePackage.cmake file is part of the -dev package
  
   * After building, 0install moves each package's build products into a
   mostly-unpredictable subdirectory of its otherwise-read-only cache
   (~/.cache/0install.net/). The subdirectory's name is determined by a
   hash of the files.
  
   * To get this working, I followed the scheme discussed here:
  
   http://news.gmane.org/find-root.php?message_id=%3cm2lil6s8jq.fsf%40plut
   o.l uannocracy.com%3e
  
   Summary:
  
   1. Create a 0install SomePackage-preinstall package. Building this
   package involves CMake building and installing both SomePackage and
   SomePackage-dev into separate subdirectories (main/ and dev/) of
   some prefix. 0install thereafter moves the whole directory tree
   into its cache in a directory called sha1=someuglyhash
  
   2. SomePackage's 0installation procedure is to copy
   sha1=someuglyhash/main/ into its distribution directory (which then
   ends up in
   ~/.cache/0install.net/sha1=otheruglyhash)
  
   3. SomePackage-dev's 0installation procedure is to copy
   sha1=someuglyhash/dev/ into its distribution directory
  
   Problem: FindSomePackageConfig.cmake now has the wrong path to the
   library binaries.
  
   Any help most appreciated.
  
   Can you please summarize what you actually want to achieve ?
  
   Well, I tried to, above.
  
   In short, I want to create separate main and -dev packages without
   building twice, under the constraints imposed by 0install.
  
   Do you say that libFoo installs a FindFoo.cmake as part of libFoo-devel
   ?
  
   If that's the case, then this is wrong.
  
   I'm sorry, that *is* wrong. It installs a FooConfig.cmake as part of
   libFoo.devel
  
   FindFoo.cmake must be part of the using software, not of the software to
   be searched.
  
   Why do you have to find the installed library in this cache directory
   ?
  
   Because, in a 0install world, that's where things go when you install
   them.
 
  Ok, how you do it along these lines:
 
  CMakeLists.txt:
  #-- BOF
 
  cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
  project(Foo)
 
  set(FOO_VERSION 1.2.3)
 
  # initialize (absolute) installation directory variables
  set(INSTALL_BIN_DIR bin CACHE PATH Install path for binaries)
  set(INSTALL_LIB_DIR lib CACHE PATH Install path for libraries)
  set(INSTALL_INCLUDE_DIR include CACHE PATH Install path for headers)
  # this is for UNIX systems, see docs of find_package() for the search
  # paths on APPLE and WIN32
  set(INSTALL_CMAKE_DIR lib/foo-${FOO_VERSION}/cmake CACHE PATH
  Install path for CMake files)
  foreach(t BIN LIB INCLUDE CMAKE)
  if(NOT IS_ABSOLUTE ${INSTALL_${t}_DIR})
  set(INSTALL_${t}_DIR ${CMAKE_INSTALL_PREFIX}/${INSTALL_${t}_DIR})
  endif()
  mark_as_advanced(INSTALL_${t}_DIR)
  endforeach()
 
  # configure FooConfig.cmake and friends. FooConfig.cmake must be able
  # to locate FooExports.cmake and FOO_INCLUDE_DIR relative to its own
  # directory without using absolute paths.
  configure_file(cmake/FooConfig.cmake.in
  ${PROJECT_BINARY_DIR}/FooConfig.cmake @ONLY)
 Please have a lokok at the new macro configure_package_config_file() which is 
 in cmake 2.8.8.
 This helps a lot with writing config files which are relocatable.
 The Config.cmake.in file has to contains a few special variables/macros:
 @PACKAGE_INIT@
 set(FOO_INCLUDE_DIR @PACKAGE_INSTALL_INCLUDE_DIR@ )
 set(FOO_BIN_DIR @PACKAGE_INSTALL_BIN_DIR@ )
 i.e. for every FOO_XYZ variable use a @PACKAGE_FOO_XYZ@ variable, and the 
 configure_package_config_file() will replace this with the help of the 
 @PACKAGE_INIT@ macro with a relocatable version.
 http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:CMakePackageConfigHelpers
  configure_file(cmake/FooConfigVersion.cmake.in
  ${PROJECT_BINARY_DIR}/FooConfigVersion.cmake @ONLY)
 
  # configure the headers into the build tree so the package can be used
  # without installing it and not hard-coding the source/build directory
  # information into FooConfig.cmake
  configure_file(include/foo.h
  ${PROJECT_BINARY_DIR}/include/foo.h COPYONLY)
 The input file should have a suffix which indicates it is a file which is 
 intended to be configured, usually foo.h.in.
 Alex

I don't agree, since it's COPYONLY. Besides, with a little more work in 
FooConfig.cmake you can skip that step...

Michael 
--

Powered by www.kitware.com

Visit

Re: [CMake] relocatable build directory: howto?

[Michael Wild]

On 05/05/2012 07:25 AM, Dave Abrahams wrote:
 
 I need to preserve the built-but-not-yet-installed state of some
 projects, and the tool I'm driving CMake with moves the result of every
 build step from a read-write build directory into a readonly cache.  The
 result is that the generated cmake_install.cmake files no longer work,
 because they are full of absolute paths.  I wrote a simple program to
 adjust the paths in the cmake_install.cmake files as a postprocessing
 step, replacing $CWD, where it is found, with a cmake variable.  The
 only problem: on my Mac, /tmp is a symlink to /private/tmp, and in some
 scenarios the absolute path in cmake_install.cmake is the short one
 wheras while $CWD is the long one.  No match :(
 
 I started to write some code to address this problem, but it's getting
 complex to the point where it seems like there must be a better way.
 So I ask: is there?
 
 Thanks in advance,
 

I'm afraid that the answer is no. There is the variable
CMAKE_USE_RELATIVE_PATHS, but that is broken and does not work in
general. Just out of curiosity: Why do you need to cache the build tree
in the first place? Would it be enough to make install
DESTDIR=/path/to/cache?

Michael
--

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] automatable way to specify parallel --builds

[Michael Wild]

On 05/05/2012 08:25 AM, Dave Abrahams wrote:
 
 I am driving invocations of cmake with another tool, and I would like to
 pass the equivalent of -jN for the cmake --build step, but I don't
 seem to be about to find out what generator will be used, which makes it
 hard to even write code to generate the right command line options.  Can
 anyone help?
 
 Thanks!
 

When you run CMake to configure the project, you can select the
generator with -G. Does that help?

Michael
--

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] Setting COMPILE_FLAGS property on a target in only debug?

[Michael Wild]

On 05/04/2012 10:16 PM, Robert Dailey wrote:
 I'm doing the following:
 
 set_property( TARGET ${target_name} APPEND_STRING PROPERTY
 COMPILE_FLAGS /ZI /Gy 
 )
 
 However this applies to all configurations. I want to only set this
 compiler flag for debug builds, not release. How can I do this?
 

Can you misuse the COMPILE_DEFINITIONS_DEBUG property? Should work, IMHO.

Michael
--

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] relocatable build directory: howto?

[Michael Wild]

On 05/05/2012 09:59 PM, Dave Abrahams wrote:
[...]
 
 ...but I hadn't thought of installing everything as part of creating
 the pre-installed state and then having the installed state draw from
 those results.  That's a very interesting idea.  I'll try it, thanks.
 The other advantage is that we won't keep a bunch of .o files around in
 the cache (though we will still have two copies of the libraries until
 we can figure out how to flush the preinstalled state).

;-) That's what I actually meant with the DESTDIR idea. Sorry I didn't
expand further on that.

[...]
 
 P.S. The people on this list are terrific.  I'm very grateful for the
 responsive help I've gotten over the past few days.
 

Yep, it's a cozy place :-D

Michael
--

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] Add IDE-specific projects

[Michael Wild]

On 04/30/2012 04:42 AM, Klaim - Joël Lamotte wrote:
 Hi,
 
 I'm having a hard time finding documentation about this: I have a
 library that provide IDE-specific project files, for example Visual
 Studio project files. Instead of writing CMake file for it, I just
 want to write in my CMakeFiles.txt that if the target compiler is
 MSVC, I want to include the library project files in the solution.
 
 Is there a way to do this in CMake? I assume there is but I can't
 find a specific answer to this.
 
 Thanks for reading.
 
 Joël Lamotte
 
 
 --
 
 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

You are looking for the MSVC [1] variable and the
include_external_msproject [2] command


HTH

Michael

[1] http://cmake.org/cmake/help/cmake-2-8-docs.html#variable:MSVC
[2]
http://cmake.org/cmake/help/cmake-2-8-docs.html#command:include_external_msproject
--

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] FortranCInterface generating header correctly?

[Michael Wild]

On 03/21/2012 02:32 PM, Giovanni Azua wrote:
 Hello,
 
 I have a project for which the main language is C (soon CPP) that calls
 some functions from Intel MKL. I have the need to use four third-party
 high performance fortran routines and I need to:
 
 1) be able to call these Fortran routines from my C code
 2) Automatically generate C headers I can include in my C code (use
 the FortranCInterface.cmake)
 3) be able to compile the Fortran routines and have them linking
 with/calling MKL's LAPACK and BLAS implementations and not any other
 possible GNU variants.
 
 I followed the example here
 http://public.kitware.com/cgi-bin/viewcvs.cgi/Tests/Fortran/?root=CMake and
 I think I am not too far from the target. However, there are a few
 unclear points e.g. I didn't exactly understand what this line is doing:
 
 list(APPENDFORTRAN_FUNCTIONSmy_sub mysub)
 
 my attempt to achieve the same thing is:
 
 add_library(qr_updatesSTATIC
 src/addcols.f
 src/addcolsq.f
 src/delcols.f
 src/delcolsq.f
 )
 
 list(APPEND FORTRAN_FUNCTIONS ADDCOLS addcols)
 list(APPEND FORTRAN_FUNCTIONS ADDCOLSQ addcolsq)
 list(APPEND FORTRAN_FUNCTIONS DELCOLS delcols)
 list(APPEND FORTRAN_FUNCTIONS DELCOLSQ delcolsq)
 FortranCInterface_HEADER(qr_updates.h
 MACRO_NAMESPACE FC_
 SYMBOL_NAMESPACE F_
 SYMBOLS ${FORTRAN_FUNCTIONS}
 )
 include_directories(${myproject_BINARY_DIR})
 
 then I get the following qr_updates.h as output:
 
 *#ifndef* FC_HEADER_INCLUDED
 *#define* FC_HEADER_INCLUDED
 
 /* Mangling for Fortran global symbols without underscores. */
 *#define* FC_GLOBAL(name,NAME) name*##*_
 
 /* Mangling for Fortran global symbols with underscores. */
 *#define* FC_GLOBAL_(name,NAME) name*##*_
 
 /* Mangling for Fortran module symbols without underscores. */
 *#define* FC_MODULE(mod_name,name, mod_NAME,NAME)
 __*##*mod_name*##*_MOD_*##*name
 
 /* Mangling for Fortran module symbols with underscores. */
 *#define* FC_MODULE_(mod_name,name, mod_NAME,NAME)
 __*##*mod_name*##*_MOD_*##*name
 
 /*--*/
 /* Mangle some symbols automatically.  
 */
 *#define* F_ADDCOLS FC_GLOBAL(addcols, ADDCOLS)
 *#define* F_addcols FC_GLOBAL(addcols, ADDCOLS)
 *#define* F_ADDCOLSQ FC_GLOBAL(addcolsq, ADDCOLSQ)
 *#define* F_addcolsq FC_GLOBAL(addcolsq, ADDCOLSQ)
 *#define* F_DELCOLS FC_GLOBAL(delcols, DELCOLS)
 *#define* F_delcols FC_GLOBAL(delcols, DELCOLS)
 *#define* F_DELCOLSQ FC_GLOBAL(delcolsq, DELCOLSQ)
 *#define* F_delcolsq FC_GLOBAL(delcolsq, DELCOLSQ)
 
 *#endif*
 *
 *
 but the signatures in this generated header look fishy, am I missing
 anything? For example the function signature for the ADDCOLSQ Fortran
 routine looks like this:
 
   *SUBROUTINE*ADDCOLSQ( M, N, A, LDA, Q, LDQ, K, P, TAU, WORK, INFO)
 *
 * Craig Lucas, University of Manchester
 * March, 2004
 *
 * .. Scalar Arguments ..
   *INTEGER*INFO, K, LDA, LDQ, M, N, P
 * ..
 * .. Array Arguments ..
   *DOUBLE* *PRECISION*   A( LDA, * ), Q( LDQ, * ), TAU( * ), WORK( * )
 
 I expected the generated header to contain a matching signature or?
 
 TIA,
 Best regards,
 Giovanni

Hi Giovanni

I think you misunderstand what FortranCInterface.cmake does. It doesn
*not* generate signatures, it only generates macros to handle the
*name-mangling* for you. You still have to provide the signatures
yourself, using the defined macros. E.g. (I hope I get this one right,
it's been quite some time I last did this...):

void F_ADDCOLSQ(int M, int N, double* A, int LDA, double* Q, int LDQ,
int K, int P, double* TAU, double* WORK, int* info);


I hope this gets you started.

Michael
--

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] Triggers for isysroot

[Michael Wild]

On 03/11/2012 07:46 AM, P. Martin wrote:
 In CMake 2.8.7 on Lion, is there anything that would trigger -isysroot
 to appear in flags.make for a cxx program when there is no code by the
 devs to specifically add a -isysroot?  Thanks.


Yes, the CMAKE_OSX_SYSROOT in the cache does that.

Michael
--

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] Triggers for isysroot

[Michael Wild]

On 03/11/2012 09:07 PM, P. Martin wrote:
 
 On Mar 11, 2012, Michael Wild them...@gmail.com wrote: 
 On 03/11/2012 07:46 AM, P. Martin wrote:
 In CMake 2.8.7 on Lion, is there anything that would trigger -isysroot
 to appear in flags.make for a cxx program when there is no code by the
 devs to specifically add a -isysroot?  Thanks.


 Yes, the CMAKE_OSX_SYSROOT in the cache does that.

 Michael
 
 
 I made a hello world program in c++, building in a CMake project.
 That variable gets defined during cmake.  It does not trigger the
 inclusion of -isysroot /some/path/to/an/sdk in flags.make.
 Thank you for your reply.

I think it depends on what you set it to. If it's the default SDK, it
doesn't get included. It could also be that the
CMAKE_OSX_DEPLOYMENT_TARGET variable plays into this.

Sadly, my Mac died quiet some time ago, so I can't check right now...

Michael

--

Powered by www.kitware.com

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

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

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

Re: [CMake] CMake Linking Error

[Michael Wild]

On 03/08/2012 05:40 PM, buzz clay wrote:
 Hi,
 
 I have not been able to find the answer to my current problem so I
 thought I'd try a new post. Before diving into the details, please be
 aware that the code I am writing compiles/runs perfectly with a personal
 Makefile I wrote.
 
 My code is written in C++ and has many different class definitions. To
 run different simulations some classes may or may not have actual
 objects created. However, there are other portions of the code that
 specifically reference functions from nearly all classes (although this
 code might not actually be used because the object was never created).
 The linking errors that I am facing arise when I do not make an object
 of a given class. Other parts of the code need to be aware that the
 class exists, even if an object was never made. Although this seems like
 it would be a result of not including the appropriate header files, I
 assure you they are correct! For some reason, if I do not make an object
 of a given class cmake ignores the class and when it comes time to
 link everything together I get the following error:
 
 Linking CXX executable collision
 Output/libOutput.a(Output.cpp.o): In function
 `Output::Output(std::vectorBall*, std::allocatorBall* *,
 std::vectorCollisionObject*, std::allocatorCollisionObject* *)':
 Output.cpp:(.text+0x379): undefined reference to `SWall::getY2()'
 Output.cpp:(.text+0x391): undefined reference to `SWall::getX2()'
 Output.cpp:(.text+0x3a9): undefined reference to `SWall::getY1()'
 Output.cpp:(.text+0x3c1): undefined reference to `SWall::getX1()'
 collect2: ld returned 1 exit status
 make[2]: *** [collision] Error 1
 make[1]: *** [CMakeFiles/collision.dir/all] Error 2
 make: *** [all] Error 2
 
 PLEASE NOTE: If in my main.cpp file I simply create an SWall object and
 never use it, the errors go away and everything works perfectly. I
 simply do not understand why cmake would care whether or not I actually
 make an object of a given class!
 
 The following is my CMakeLists.txt file in the highest level directory:
 
 cmake_minimum_required(VERSION 2.8)
 
 project(collision CXX)
 
 add_subdirectory(Extraneous)
 add_subdirectory(Output)
 add_subdirectory(Simulation)
 add_subdirectory(CollisionObject)
 
 add_definitions(-ansi -Wall -O2)
 
 add_executable(collision test.cpp)
 
 target_link_libraries(collision Simulation)
 target_link_libraries(collision PriorityQueue)
 target_link_libraries(collision Event)
 target_link_libraries(collision Ball)
 target_link_libraries(collision SWall)
 target_link_libraries(collision Circle)
 target_link_libraries(collision Output)
 target_link_libraries(collision SimpleMath)
 
 INSTALL(PROGRAMS ${CMAKE_BINARY_DIR}/collision DESTINATION
 ${CMAKE_SOURCE_DIR})
 
 All of the lower level directories simply had add_library(libname
 libname.cpp) in the CMakeLists.txt file. Any help is greatly appreciated!
 
 Thanks,
 Matthew

What happens if you set BUILD_SHARED_LIBS to TRUE? Or, alternatively,
add the SHARED option to all of the add_library() calls?

BTW: you can link against all those libraries in a single call:

target_link_libraries(collision
  Simulation
  PriorityQueue
  Event
  Ball
  ...
  )

Michael

--

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] Forcibly run 'moc' on Qt files that are NOT part of the build

[Michael Wild]

On 03/07/2012 04:10 PM, Michael Jackson wrote:
 In an effort to speed up the build of a project that uses Qt (and moc) I 
 tried an alternate approach with the moc files. Normally I use the basic idea 
 of gathering the headers that need to be moc'ed and feed those to moc with 
 this type of CMake Code:
 
 QT4_WRAP_CPP( FilterWidgets_Generated_MOC_SRCS ${QFilterWidget_HDRS} 
 ${FilterWidget_GEN_HDRS}) 
 
 The in the Add_Executable(...) call include the 
 ${FilterWidgets_Generated_MOC_SRCS} variable to the list of sources. In my 
 project I have at least 30 auto-generated files which all get moc'ed. That 
 gives me an additional 60 compiled files. So I tried the idea of #include 
 moc_[some_file.cxx] in each of the auto-generated .cpp files for each 
 Widget. This would cut the number of files compiled in half. The issue is 
 that since they are being #include'ed in the .cpp files then they do NOT need 
 to be compiled themselves so I took the ${FilterWidgets_Generated_MOC_SRCS} 
 out of the list of sources in the add_executable() call. What happened is 
 that CMake did NOT run moc on those headers because there were now NOT 
 included in the build.
 
  So for that version of the cmake code I have something like this:
 
 QT4_WRAP_CPP( FilterWidgets_Generated_MOC_SRCS ${FilterWidget_GEN_HDRS}) 
 QT4_WRAP_CPP( FilterWidgets_MOC_SRCS ${QFilterWidget_HDRS} )
 
 Is there a way to forcibly run the moc step even if the resulting source 
 files are NOT directly included in the add_executable? Custom_Command? 
 Add_Depends?
 
 Thanks

You could still add them to the add_executable() call, but set their
HEADER_FILE_ONLY source file property to TRUE to prevent them from being
compiled. This way they would still show up in the proper place in
IDE's, and no need for fiddling around with add_custom_target() and
add_dependencies(). Of course, you might still want to introduce the
custom target for convenience so you can trigger moc'ing manually (e.g.
make moc)...

Michael

--

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] recognizing shell in use

[Michael Wild]

That's the wrong way to go about things. Rather than putting the COMMAND
in the custom target, put it in a add_custom_command() call and make the
custom target DEPENDS on it. Then you let the build system handle the
dependencies. E.g. like this:

find_program(JAVAC_COMPILER javac PATH_SUFFIXES bin ENV JAVA_HOME)

add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/test.class
  COMMAND ${JAVAC_COMPILER} -d ${PROJECT_BINARY_DIR}
${PROJECT_BINARY_DIR}/test.java
  DEPENDS ${PROJECT_BINARY_DIR}/test.java
  COMMENT Compiling test.java
  VERBATIM)

add_custom_target(compile-test-java
  DEPENDS ${PROJECT_BINARY_DIR}/test.class)


It looks like test.java is a generated file, so depending on how you
generate it, you also need to set the GENERATED source file property to
TRUE in order for this to work.

HTH

Michael

On 03/06/2012 04:27 PM, Ajay Panyala wrote:
 That is because I have a custom target like
 
 ADD_CUSTOM_TARGET(testc ALL
   COMMAND java ${PROJECT_BINARY_DIR}/test.java 
   DEPENDS ${PROJECT_BINARY_DIR}/test.java 
 )
 
 I want to build test.java only if it has been changed.
 
 Since custom targets are always out-of-date, I wanted to have the
 command inside the custom target like
 
 COMMAND if( test.java has not been modified ) then java build/test.java; fi
 
 The syntax of *if* differs between different shells. So I wanted to
 check for 
 the shell first and use the appropriate IF syntax.
 
 
 Thanks
 Ajay
 
 
 On Mon, Mar 5, 2012 at 11:03 PM, Eric Noulard eric.noul...@gmail.com
 mailto:eric.noul...@gmail.com wrote:
 
 2012/3/6 Ajay Panyala a...@csc.lsu.edu mailto:a...@csc.lsu.edu:
  Hello,
 
  Is there anyway that cmake could figure out the shell (bash,csh,..)
  that is being use when cmake is invoked on the command line ?
 
 May be you can check $ENV{SHELL} ?
 Why would you like to do that?
 
 Usually when using CMake one tries to avoid shell/command interpreter
 dependency??
 --
 Erk
 Le gouvernement représentatif n'est pas la démocratie --
 http://www.le-message.org
 
 
 
 
 
 
 
 --
 
 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 include the generated header file?

[Michael Wild]

On 03/01/2012 07:21 AM, Tan, Tom (Shanghai) wrote:
 According to the doc,  generate_export_header(somelib) generates a file
 in the ${CMAKE_CURRENT_BUILD_DIR} called somelib_export.h.
 What's the recommended way to include this   somelib_export.h.
 #include somelib_export.h does not work. And
 ${CMAKE_CURRENT_BUILD_DIR} is empty too.  I am using v2.8.7. The header
 file does get generated, only the doc is not very helpful on how to
 include it.

include_directories(${CMAKE_CURRENT_BINARY_DIR})

That's a bug in the documentation, the variable CMAKE_CURRENT_BUILD_DIR
does not exist (notice the difference is between BUILD and BINARY)...

Michael
--

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] figuring out exact name of boost-regex lib to use

[Michael Wild]

On 02/28/2012 10:00 AM, Bart Vandewoestyne wrote:
 Hello list,
 
 I'm quite new to CMake, still learning my way around...  I currently
 have the following in a CMakeList.txt file:
 
   set(BOOST_LIBNAME boost_regex)
   #set(BOOST_LIBNAME boost_regex-mt)
   target_link_libraries(airspace ${BOOST_LIBNAME})
 
 On some platforms, it only works if I set the Boost RegEx library name
 to boost_regex, on others it only works with boost_regex-mt.
 
 Up until now, I always uncomment the correct form, depending on what
 platform I am (Linux, Cygwin,...) but this is quite annoying.  How can I
 figure out automatically the name of the Boost RegEx library to use?
 
 Thanks!
 Bart

Don't do it this way. Use this:

find_package(Boost REQUIRED COMPONENTS regex)
include_directories(${Boost_INCLUDE_DIRS})

# add_executable etc...

target_link_libraries(airspace ${Boost_LIBRARIES})


Michael
--

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] figuring out exact name of boost-regex lib to use

[Michael Wild]

Hi Bart

Please keep answers on the list, so others can also profit from the
discussion.

On 02/28/2012 01:59 PM, Bart Vandewoestyne wrote:
 On 02/28/2012 10:28 AM, Michael Wild wrote:
 Don't do it this way. Use this:

 find_package(Boost REQUIRED COMPONENTS regex)
 include_directories(${Boost_INCLUDE_DIRS})

 # add_executable etc...

 target_link_libraries(airspace ${Boost_LIBRARIES})
 
 Michael,
 
 Thanks for pointing me to the find_package command!  One more
 detail-question however: in the docs online at
 http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package
 is the syntax written as:
 
   find_package(package [version] [EXACT] [QUIET]
[[REQUIRED|COMPONENTS] [components...]]
[NO_POLICY_SCOPE])
 
 Notice the [REQUIRED|COMPONENTS] from which i deduce that the
 find_package command should probably be written as
 
   find_package(Boost REQUIRED regex)
 
 I tried it, and it seems to work...
 
 Kind regards,
 Bart

You are absolutely right, I wrote my reply from memory, and got it
obviously wrong ;-)

Michael
--

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-developers] How to handle package Config.cmake files with dependencies ?

[Michael Wild]

On 02/27/2012 09:15 PM, Alexander Neundorf wrote:
 Hi,
 
 I think find_package in Config mode might still need some more work.
 
 When the FooConfig.cmake has been found, Foo_FOUND is set to TRUE:
 
  // Set a variable marking whether the package was found.
   std::string foundVar = this-Name;
   foundVar += _FOUND;
 
 
 This means it is true in all cases that the Config.cmake file has been found 
 (and the version was compatible).
 
 Now I have to questions:
 
 
 * how to handle COMPONENTS ?
 
 
 If a package is requested with COMPONENTS, these should be considered for 
 setting Foo_FOUND:
 find_package(Foo REQUIRED COMPONENTS A B C)
 should only succeed if A, B and C are found.
 
 This is how I would expect COMPONENTS to be handled in a FindFoo.cmake:
 (a) all components are searched by the Find-module, and each per-component 
 X_Y_FOUND is set accordingly
 
 (b) there is a package-specific default subset of these components which have 
 to be found to make the package found, i.e. FOO_FOUND=TRUE
 
 (c) by adding COMPONENTS to the find_package() call, these components are 
 added to the set of components which have to be found to make FOO_FOUND=TRUE
 
 (d) if REQUIRED is used and FOO_FOUND is false, it errors out
 

I like that proposal. I'm also quite unhappy with how components are
handled in config-mode.

 
 
 * how to handle dependencies ?
 
 
 Let's say the exported targets of Foo link against other imported/exported 
 targets. So that the imported targets work properly, the targets for the 
 libraries it depends on must have been found and imported before.
 Where should this 
 find_package(Bar)
 be done ?
 In FooConfig.cmake ?
 This would be possible only if Bar can be found in Config mode, because 
 otherwise Foo cannot rely on FindBar.cmake being available.
 
 For Find-modules, it is clear that a Find-module should also find all its 
 dependencies.
 For a Config file I'm not sure about it. Shouldn't this be only a source of 
 information, purely declarative, and not initiate searching other packages ?


I think current best practice is to call find_package(Bar) inside the
FooConfig.cmake. If the FindBar.cmake is contained in CMake,
everything's fine (possibly, you need a cmake_minimum_required()),
otherwise Foo should install FindBar.cmake alongside FooConfig.cmake.

Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] apply for maintainer of FindOpenCL.cmake

[Michael Wild]

On 02/24/2012 10:52 AM, yao wang wrote:
 Hi,
 We've written a module finding AMD's APP SDK's include abd library
 paths. And set  OPENCL_INCLUDE_DIR and OPENCL_LIBRARY, which are
 useful for compiling OpenCL programs. Is it possible for me to
 contribute to the share modules and make it included in next release?
 
 Thanks!


You'll want to read this:
http://www.vtk.org/Wiki/CMake:Module_Maintainers

Michael
--

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] upper/lower case

[Michael Wild]

On 02/23/2012 04:08 PM, Andrea Crotti wrote:
 I really physically suffer using case-insensitive languages,

Seriously? You must be an annoyingly happy person if that's your biggest
problem in life! ;-)

 but is
 there any convention to decide
 at least when to use upper and when to use a lower case?

Variables *are* case-sensitive. Only commands, macros and functions are
case-insensitive.

 
 For example user defined variables should be upper or lower case?

If the variables is cached, the convention is to use all-caps. A lot of
people use all-caps for all other variables too. I tend to mix them,
e.g. loop variables are quite often 1-3 lower-case letters because they
are used only very locally and their meaning is pretty clear. Anything
that is not used in a very local context is all-caps in my code.

But all of this is pure convention and personal preference...

 
 Or what happens if I hide by mistake a CMake-defined variable? (are they
 all upper case?)

The only occasion where you can hide a CMake-defined variable is inside
a function(). Otherwise you *overwrite* it's value. And you often want
to actually do that (e.g. to set the output directories for executables,
libraries, archives etc.).

HTH

Michael
--

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 script distribution strategy

[Michael Wild]

On 02/20/2012 04:32 PM, Barth wrote:
 Hello, 
 
 Let be a project A developed and distributed by organization AA. 
 Let be another project B depending on A, developed by organization BB. B
 calls find_package(A) in its CMakeLists.txt as to get the dependencies
 libraries and includes. 
 
 How should FindA.cmake be distributed ? 
 Option 1: package A (eg. A.rpm) installs it in /usr/share/cmake/ (on Linux)
 so that it is found by B or any other project that needs it.
 Option 2: package A installs it in a more specific location such as
 /opt/A/cmake. However, how would B find it ? 
 Option 3: package A doesn't install it anywhere and we let the developers of
 B download it manually. 
 
 I would go for option 1 but I am not really sure what is the standard way. 
 
 Thank you in advance
 Barth

If A is built with CMake, AA should make it install AConfig.cmake in one
of the directories documented for the find_package command. See
http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
for a simplistic tutorial.

Otherwise BB can include FindA.cmake in its own package. If it is a
transitive dependency (i.e. people wanting to compile against B also
need to find A) it should be installed next to the BConfig.cmake which
uses it directly.

HTH

Michael

--

Powered by www.kitware.com

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

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

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

Re: [CMake] CMAKE_INSTALL_LIBDIR - full path or relative?

[Michael Wild]

On 02/20/2012 09:59 PM, Orion Poplawski wrote:
 For quite a while, Fedora packages will call cmake with
 -DCMAKE_INSTALL_LIBDIR set to /usr/lib or /usr/lib64 as appropriate. 
 Some projects that use this convention include plplot, lasi
 
 The relatively new cmake module GNUInstallDirs sets CMAKE_INSTALL_LIBDIR
 to lib or lib64.  Other projects like tkimg appear to use this convention.
 
 A bug has been filed in Fedora due to this:
 
 https://bugzilla.redhat.com/show_bug.cgi?id=795542
 
 Is this indeed the preferred convention for CMAKE_INSTALL_LIBDIR?  Shall
 I file bugs against plplot, lasi and others to change the usage?
 

Hi Orion

Whenever an installation directory is not an absolute path, CMake
prefixes it with the value of CMAKE_INSTALL_PREFIX. This is for
convenience and make it easier to be consistent. AFAIK this behaviour is
similar to what autoconf does.

So, as long as your CMAKE_INSTALL_PREFIX and CMAKE_INSTALL_LIBDIR are
consistent, you should be fine. Normally I consider setting projects
which set any of the CMAKE_INSTALL_*DIR (or whatever they are called) to
an absolute path to be a nuisance for the user because it is not enough
to set one variable (CMAKE_INSTALL_PREFIX) in order to change the
installation prefix. But that is IMHO a matter of taste and you can
argue both ways.

My 2c...

Michael
--

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] $TARGET_FILE:tgt in the add_custom_command()

[Michael Wild]

On 02/14/2012 04:36 PM, aaron.mead...@thomsonreuters.com wrote:
 *Looks like ‘+’ is not a valid character for the target name. *
 
 *  *
 
 *Specifically, cmGeneratorExpression.cxx does not have it as part of the
 regular expression to match target names: (line 23 on) *
 
 *  *
 
 *  *
 
   this-TargetInfo.compile(^\\$TARGET
 
(|_SONAME|_LINKER)  // File with what purpose?
 
_FILE(|_NAME|_DIR): // Filename component.
 
([A-Za-z0-9_.-]+)   // Target name.
 
$);
 
 *  *
 
 *(In case you’re unfamiliar with regular expressions, that + is just to
 denote 1 or more of the things between the [ and ] . ) *
 
 *  *
 
 *I tried adding + to that list, but I’m not sure how (if it’s possible)
 to escape it (and it resulted in a regular expression compile error
 (runtime)).  I’d suggest using something else instead of a + in your
 target name. *
 
 *  *
 
 *Aaron Meadows*
 
 *  *
 
 *From:*cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] *On
 Behalf Of *Kozlovskiy, Alexey
 *Sent:* Tuesday, February 14, 2012 5:38 AM
 *To:* cmake@cmake.org
 *Subject:* [CMake] $TARGET_FILE:tgt in the add_custom_command()
 
  
 
 Hi,
 
  
 
 If the project name has a symbols “-” or “+” the $TARGET_FILE:tgt in
 the add_custom_command() return Error: “Error evaluating generator
 expression”
 
  
 
 For example:
 
 SET ( PROJECT_NAME 00010-Liquid+Gas_as_capture  )
 
 set ( SRCS_MAIN_CPT main.c  )
 
 add_executable ( ${ PROJECT_NAME } ${SRCS_MAIN_CPT} )
 
  
 
 add_custom_command ( TARGET ${ PROJECT_NAME } POST_BUILD
 
 COMMAND $TARGET_FILE:${
 PROJECT_NAME }
 
 ARGS $TARGET_FILE_DIR:${
 PROJECT_NAME }/110.cnf
 
 COMMENT Running cpt.exe...
 
  
 
 )
 
  
 
 When I run the CMake I received the following error:
 
  
 
 “CMake Error at problems.rt.Cmake:114 (add_custom_command):
 
   Error evaluating generator expression:
 
 $TARGET_FILE:00010-Liquid+Gas_as_capture
 
 Expression syntax not recognized.”
 
  
 
 Is this a bug or some syntax limitation?
 
  
 
 Regards,
 
 Alexey

As a work-around use a different target name which is clean and then
use the OUTPUT_NAME target property to get the desired file name.

Michael



--

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] Install selected|group of targets

[Michael Wild]

On 02/02/2012 08:44 AM, Joakim Hove wrote:
 
 
 First you should use the COMPONENT parameter of the INSTALL command.
 See:
 cmake --help-command install
 and
 http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack
 
 then you may install all the target/files/... belonging to a
 particular component by doing:
 
 cd buildir
 cmake -DCOMPONENT=componentname -P cmake_install.cmake
 
 http://www.april.org 
 
 
 OK;
 
 thank you. That was maybe slightly more involved than I had thougth -
 but certainly doable.
 
 Joakim
 
 

I implemented the make install-foo feature some time ago, but didn't
find the time to write the required tests, so it never got merged into
CMake:

http://cmake.org/Bug/view.php?id=10531

Michael
--

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] Issues with FindBoost / ${Boost_LIBRARIES}

[Michael Wild]

On 02/01/2012 09:33 AM, Arnaud Gelas wrote:
 Hi all,
 
 I have been trying to compile a very simple example with cmake (2.8.5)
 and boost, and I can't get what I am doing wrong...
 
 CMakeLists.txt
 --
 
 cmake_minimum_required(VERSION 2.6)
 
 project(ReadGraph)
 
 find_package(Boost 1.46 COMPONENTS graph regex )
 
 link_directories(${Boost_LIBRARY_DIRS})
 include_directories(BEFORE ${Boost_INCLUDE_DIRS})
 
 add_executable(ReadGraph ReadGraph.cpp)
 target_link_libraries(ReadGraph ${Boost_LIBRARIES} )
 # target_link_libraries(ReadGraph boost_graph boost_regex )
 
 
 ReadGraph.cpp
 --
 // http://www.boost.org/doc/libs/1_37_0/libs/graph/doc/read_graphviz.html
 #include iostream
 #include string
 #include fstream
 
 #include boost/graph/adjacency_list.hpp
 #include boost/graph/graphviz.hpp
 
 int main(int , char* [])
 {
   return 0;
 }
 
 Here is what the error I get when trying to compile:
 
 $ make
 /usr/bin/cmake -H/home/ajg23/GITROOT/BGLCMakeQuestion
 -B/home/ajg23/GITROOT/BGLCMakeQuestion/build --check-build-system
 CMakeFiles/Makefile.cmake 0
 /usr/bin/cmake -E cmake_progress_start
 /home/ajg23/GITROOT/BGLCMakeQuestion/build/CMakeFiles
 /home/ajg23/GITROOT/BGLCMakeQuestion/build/CMakeFiles/progress.marks
 make -f CMakeFiles/Makefile2 all
 make[1]: Entering directory `/home/ajg23/GITROOT/BGLCMakeQuestion/build'
 make -f CMakeFiles/ReadGraph.dir/build.make CMakeFiles/ReadGraph.dir/depend
 make[2]: Entering directory `/home/ajg23/GITROOT/BGLCMakeQuestion/build'
 cd /home/ajg23/GITROOT/BGLCMakeQuestion/build  /usr/bin/cmake -E
 cmake_depends Unix Makefiles /home/ajg23/GITROOT/BGLCMakeQuestion
 /home/ajg23/GITROOT/BGLCMakeQuestion
 /home/ajg23/GITROOT/BGLCMakeQuestion/build
 /home/ajg23/GITROOT/BGLCMakeQuestion/build
 /home/ajg23/GITROOT/BGLCMakeQuestion/build/CMakeFiles/ReadGraph.dir/DependInfo.cmake
 --color=
 make[2]: Leaving directory `/home/ajg23/GITROOT/BGLCMakeQuestion/build'
 make -f CMakeFiles/ReadGraph.dir/build.make CMakeFiles/ReadGraph.dir/build
 make[2]: Entering directory `/home/ajg23/GITROOT/BGLCMakeQuestion/build'
 /usr/bin/cmake -E cmake_progress_report
 /home/ajg23/GITROOT/BGLCMakeQuestion/build/CMakeFiles 1
 [100%] Building CXX object CMakeFiles/ReadGraph.dir/ReadGraph.cpp.o
 /usr/bin/c++ -o CMakeFiles/ReadGraph.dir/ReadGraph.cpp.o -c
 /home/ajg23/GITROOT/BGLCMakeQuestion/ReadGraph.cpp
 make[2]: *** No rule to make target `/usr/lib/libboost_graph-mt.so',
 needed by `ReadGraph'.  Stop.
 make[2]: Leaving directory `/home/ajg23/GITROOT/BGLCMakeQuestion/build'
 make[1]: *** [CMakeFiles/ReadGraph.dir/all] Error 2
 make[1]: Leaving directory `/home/ajg23/GITROOT/BGLCMakeQuestion/build'
 make: *** [all] Error 2
 
 
 If I don't use ${Boost_LIBRARIES} but explicitly the corresponding
 libraries (i.e. boost_graph and boost_regex) it compiles without any
 problem...
 
 Can anyone give me a hand on this one? Is this a bug?
 
 Note that I have also been trying with the master and the next version
 of cmake, same thing...
 
 Thanks,
 Arnaud
 

Looks to me like the symlink /usr/lib/libboost_graph-mt.so doesn't
exist. Did you check that?

Michael
--

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-developers] Documented property IMPORTED_LOCATION does not exist

[Michael Wild]

On 01/25/2012 12:25 AM, Alan W. Irwin wrote:
 On 2012-01-24 06:28+0100 Michael Wild wrote:
 
 On 01/24/2012 05:50 AM, Alan W. Irwin wrote:
 The documentation you get from

 cmake --help-full

 refers to the IMPORTED_LOCATION property as one of the more important
 ones set for imported targets.  I have to agree that location is the
 most important property for imported targets, but the name appears to
 be wrong for the documentation of this property!

 After screwing around for a while trying to use the above
 property for my imported targets, I discovered (by guessing) that the
 name of a property that actually does give the location information is
 IMPORT_LOCATION, not IMPORTED_LOCATION.  For what it is worth,
 IMPORT_LOCATION works for an imported library, and I haven't tried
 this on imported executables. (By the way, LOCATION works as well, but
 that appears from the documentation to be a left-over from CMake 2.4
 which is why I tried to get IMPORTED_LOCATION to work and when that
 failed, switched to the currently undocumentated IMPORT_LOCATION.)

 I find IMPORTED_LOCATION is mentioned in the following
 places in the cmake-2.8.6 source tree:

 software@raven find cmake-2.8.6 -print0 -type f \
 |xargs -0 grep -l IMPORTED_LOCATION
 cmake-2.8.6/ChangeLog.txt
 cmake-2.8.6/Modules/FindQt4.cmake
 cmake-2.8.6/Tests/ExportImport/Import/A/CMakeLists.txt
 cmake-2.8.6/Tests/SimpleInstall/CMakeLists.txt
 cmake-2.8.6/Tests/SimpleInstallS2/CMakeLists.txt
 cmake-2.8.6/Source/cmTarget.cxx
 cmake-2.8.6/Source/cmAddExecutableCommand.h
 cmake-2.8.6/Source/cmAddLibraryCommand.h
 cmake-2.8.6/Source/cmExportBuildFileGenerator.cxx
 cmake-2.8.6/Source/cmExportInstallFileGenerator.cxx

 A similar search for IMPORT_LOCATION found nothing at all!

 However, I spot-checked cmake-2.8.6/Source/cmTarget.cxx, and all those
 mentions of IMPORTED_LOCATION appear to be documentation strings
 rather than executable code, and I was unable to find why
 IMPORTED_LOCATION does not work for me while IMPORT_LOCATION does. So
 this needs someone who is familiar with the CMake code to figure out
 what the actual problem is here, and to decide whether a fix to the
 documentation strings is all that is required or whether some deeper
 change needs to be made.

 Alan

 IMPORTED_LOCATION works just fine for me. Also IMPORT_LOCATION, as you
 call it, is not referenced once in the whole CMake source, while
 IMPORTED_LOCATION is, and not only as a documentation string as you
 claim.
 
 Hi Michael:
 
 Thanks for your response.
 
 Since you cannot verify the issue, then the most likely reason is
 there is some difference between your and my CMake version, minimum
 CMake version (which affects policy decisions), and hardware/software
 platform. Could you be more specific about those constraints in your
 case?
 
 Just to be sure I was reporting a clean result, I started with a
 fresh bootstrap build and install of CMake-2.8.7 that I did on my Debian
 Squeeze platform. I then built and installed PLplot (which
 specifies cmake_minimum_required(VERSION 2.8.2 FATAL_ERROR) from
 scratch using that version of cmake.
 
 I have attached the resulting export module files that are installed
 as a result of that PLplot install.
 
 I then checked imported target properties with the following CMake test
 script
 (which is also attached for convenience).
 
 project(test_export NONE)
 cmake_minimum_required(VERSION 2.8.2 FATAL_ERROR)
 set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR} )
 include(export_plplot OPTIONAL RESULT_VARIABLE IF_PLOT)
 if(IF_PLOT)
   get_target_property(test_loc1 _plplotcmodule IMPORT_LOCATION)
   message(STATUS IMPORT_LOCATION = ${test_loc1})
   get_target_property(test_loc2 _plplotcmodule IMPORTED_LOCATION)
   message(STATUS IMPORTED_LOCATION = ${test_loc2})
 else(IF_PLOT)
   message(WARNING IF_PLOT = ${IF_PLOT})
 endif(IF_PLOT)
 
 And here was the result when cmake was invoked from a sub-directory
 of the one containing the above CMakeLists.txt and the export files.
 
 software@raven cmake ..
 -- IMPORT_LOCATION =
 /home/software/plplot_svn/installcmake/lib/python2.6/site-packages/_plplotcmodule.so
 
 -- IMPORTED_LOCATION = test_loc2-NOTFOUND
 -- Configuring done
 -- Generating done
 -- Build files have been written to: /tmp/cmake_test/build_dir
 
 Note, _plplotcmodule is one of the shared objects generated by PLplot
 for our python bindings, but if you look at the export files, there
 doesn't seem to be anything done differently for _plplotcmodule compared
 to other PLplot library targets, and also I assure you
 the result for IMPORT_LOCATION is correct.
 
 So the above simple script cleanly shows the issue for 2.8.7.
 IMPORT_LOCATION is an imported target property with the correct value
 while IMPORTED_LOCATION is not found.
 
 If you try the same test script with the same exported files, do you
 get a different result? If you still have trouble verifying the above
 result, then please also try CMake-2.8.7 to see whether that version
 is the source

Re: [CMake] About CMAKE_INSTALL_PREFIX

[Michael Wild]

On 01/24/2012 09:35 AM, pellegrini wrote:
 Hello everbody,
 
 I would like to understand a bit more one feature related to
 CMAKE_INSTALL_PREFIX initialization.
 
 When reading the documentation, it is specified that this variable
 contains the directory that will be pre-pended to all install
 directories and that it should be defaulted to C:/Program Files on
 Windows. However, in my current build the variable is not defaulted to
 C:/Program Files but to C:/Program Files/libcrysfml where crysfml  is
 the name of my base project.
 
 This unexpected feature (at least to my understanding !) leads me to my
 second question.
 
 I would like to get rid of the crysfml  subdirectory in the value of
 CMAKE_INSTALL_PREFIX. I could obvioulsy
 use:
get_filename_component(MY_CMAKE_INSTALL_PREFIX
 ${CMAKE_INSTALL_PREFIX} PATH)
 but this would fail if CMAKE_INSTALL_PREFIX is set on the cmake command
 line by the user because, in such case, the installation will not be
 done in the directory that he provided but in its parent directory.
 Rather counter-intuitive.
 
 What I would need is a mechanism to detect whether the
 CMAKE_INSTALL_PREFIX has been set or not by the user on the
 command-line. If so, I take directly the values he provided, and if not
 so, I take the parent directory of the default value.
 
 Is that possible ?
 
 thanks a lot
 
 Eric
 
 
 

You can use the variable CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT to
determine whether the cache contains the default value or has been
modified by the user. E.g.

project(Foo)
if(WIN32 AND CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
  set(CMAKE_INSTALL_PREFIX ${CMAKE_GENERIC_PROGRAM_FILES} CACHE PATH
Install path prefix, prepended onto install directories. FORCE)
endif()

should do what you want.

HTH

Michael
--

Powered by www.kitware.com

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

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

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

[cmake-developers] License of the dashboard:cmake_common.cmake script

[Michael Wild]

Hi all

I based my dashboard driver script on the one used by CMake
(http://cmake.org/gitweb?p=cmake.git;a=blob;f=cmake_common.cmake;hb=refs/heads/dashboard)
and wonder what it's license is. Is it the usual 3-clause BSD-style license?

Michael
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] License of the dashboard:cmake_common.cmake script

[Michael Wild]

On 01/18/2012 03:16 PM, Brad King wrote:
 On Wed, Jan 18, 2012 at 8:41 AM, Michael Wild them...@gmail.com wrote:
 I based my dashboard driver script on the one used by CMake
 (http://cmake.org/gitweb?p=cmake.git;a=blob;f=cmake_common.cmake;hb=refs/heads/dashboard)
 and wonder what it's license is. Is it the usual 3-clause BSD-style license?
 
 Yes, the notice was simply missing.  I added it:
 
   http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe760baa
 
 Thanks!
 -Brad

Great, thanks for the fast response!

Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Copy files to build folder

[Michael Wild]

AFAICS these files are considered to be source files, right? So they
should be explicitly listed in the CMakeLists.txt file. If your
CMakeLists.txt file gets too big, you can put the relevant code into
another file and then include() it from the CMakeLists.txt.

Doing this also helps you detecting errors early on. E.g. it is much
less likely that a developer forgets to add the new file to the version
control when you do it this way, because it's not enough to just drop
the file into the source tree.

Also, once you have the files in your CMakeLists.txt, you might as well
just use configure_file(... COPYONLY).

Michael

On 01/17/2012 02:07 PM, Tim Hutton wrote:
 Thanks Andreas, but that leaves us with having to edit the
 CMakeLists.txt every time we add a pattern file. There must be a
 better way?
 
 On 17 January 2012 13:02, Andreas Pakulat ap...@gmx.de wrote:
 On 17.01.12 12:54:28, Tim Hutton wrote:
 We've got this section in our CMakeLists.txt:

 #--copy pattern files to build
 folder-

 file( GLOB_RECURSE pattern_files RELATIVE
 ${CMAKE_CURRENT_SOURCE_DIR}/ patterns/*.vti )
 foreach( pattern_file ${pattern_files} )
   add_custom_command(
 OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${pattern_file}
 COMMAND cmake -E copy
 ${CMAKE_CURRENT_SOURCE_DIR}/${pattern_file}
 ${CMAKE_CURRENT_BINARY_DIR}/${pattern_file}
 DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${pattern_file}
   )
   list( APPEND pattern_files_dest ${pattern_file} )
 endforeach( pattern_file )

 add_custom_target( CopyPatterns ALL DEPENDS ${pattern_files_dest} )

 #---

 The idea is to copy all the *.vti files in the patterns folder (and
 subfolders) into the build folder, so our program can load them. This
 works fine when running CMake for the first time. However, if we add a
 new pattern file it doesn't get picked up, even after make clean. (It
 works if we edit the CMakeLists.txt, or delete everything in the build
 folder.) Is there a way to make this work every time?

 Don't use GLOB, but list all files individually in a variable and
 iterate over that. CMake is not executed when doing a make call and no
 cmake-related file has changed and hence the above code is not re-run on
 each make call.

 Andreas



--

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] Copy files to build folder

[Michael Wild]

On 01/17/2012 03:25 PM, Tim Hutton wrote:
 On 17 January 2012 13:21, David Cole david.c...@kitware.com wrote:
 If you want to use file GLOB at CMake time, then you have to re-run
 CMake manually when you add or remove a file. There's no way around
 that, because we are not going to monitor your hard drive for
 arbitrary file changes on a continuous basis...
 
 On 17 January 2012 13:22, Rolf Eike Beer e...@sf-mail.de wrote:
 Thanks Andreas, but that leaves us with having to edit the
 CMakeLists.txt every time we add a pattern file. There must be a
 better way?

 How should CMake find out that it needs to update it's file list then?
 
 It could re-run the FILE(GLOB) on every build? Instead of making a
 dependency on a list of files, I would like to make a dependency on
 the contents of a folder.
 
 Thanks for all the replies. I understand that the recommended method
 is to have an explicit list of files. And I can see the benefits for
 avoiding slip-ups like adding a file without checking it in.
 
 What confuses me now is that for packaging we can use the INSTALL command:
 
 # copy the patterns from the source folder
 install( DIRECTORY patterns DESTINATION . FILES_MATCHING PATTERN *.vti)
 
 This does exactly what I want: it finds all the *.vti files from the
 patterns folder and subfolders. And yet there's no matching command
 to achieve this in the normal build? Is using the INSTALL command like
 this not recommended?
 

What you can do is something like this:


copy_patterns.cmake:
#
foreach(v SRCDIR DSTDIR)
  if(NOT DEFINED ${v})
message(FATAL_ERROR ${v} not defined on command line)
  endif()
endforeach()

file( GLOB_RECURSE pattern_files RELATIVE
  ${SRCDIR}/ ${SRCDIR}/patterns/*.vti )
foreach(p IN LISTS pattern_files)
  configure_file(${SRCDIR}/${p}
${DSTDIR}/${p} COPYONLY)
endforeach()
#

CMakeLists.txt:
#--
#
add_custom_target(copy_patterns ALL
  COMMAND ${CMAKE_COMMAND} -DSRCDIR=${CMAKE_CURRENT_SOURCE_DIR}
-DDSTDIR=${CMAKE_CURRENT_BINARY_DIR}
-P ${CMAKE_CURRENT_SOURCE_DIR}/copy_patterns.cmake
  COMMENT Copying pattern files to build tree)
#
#

Now since custom targets are always out of date, this rule will always run.

HTH

Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Problems finding the SSL library

[Michael Wild]

On 01/16/2012 04:59 PM, Maciej (Matchek) Bliziński wrote:
 2011/12/22 Maciej (Matchek) Bliziński mac...@opencsw.org:
 CMake Error at cmake/ssl.cmake:83 (MESSAGE):
  Cannot find appropriate system libraries for SSL.  Use WITH_SSL=bundled to
  enable SSL support
 Call Stack (most recent call first):
  CMakeLists.txt:255 (MYSQL_CHECK_SSL)
 
 I found the MySQL-5.5 source code repository. Is CMakeLists.txt file
 the main one? If so, here's the link:
 
 http://bazaar.launchpad.net/~mysql/mysql-server/5.5/view/head:/CMakeLists.txt
 
 Another one that seems relevant, is this:
 
 http://bazaar.launchpad.net/~mysql/mysql-server/5.5/view/head:/cmake/ssl.cmake
 
 Could anyone look and make suggestions how to proceed with debugging?
 
 Maciej


Definitely a bug in MySQL. They should be setting
CMAKE_REQUIRED_INCLUDES to ${OPENSSL_INCLUDE_DIR} before invoking the
CHECK_SYMBOL_EXISTS() function/macro in line 72 of cmake/ssl.cmake.
Otherwise CMake will not use the include directory found by
FindOpenSSL.cmake.

HTH

Michael
--

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] directshow change dll name to .ax

[Michael Wild]

On 01/12/2012 04:26 PM, gilles B wrote:
 Hi,
 
 I want to create a directshow filter (windows) and so change output name
 of my dll from myfilter.dll to myfilter.ax
 How to do this ?
 
 Thank you very much for your help
 
 regards
 Gilles.
 

set_target_properties(myfilter PROPERTIES
  SUFFIX .ax)


HTH

Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Cmake coloring gcc output on errror

[Michael Wild]

On 01/11/2012 01:44 PM, Michael Hertling wrote:
 On 01/10/2012 07:17 PM, vivek goel wrote:
 Is there a way to color warning/error of gcc with cmake ?
 
 AFAIK, no, but you might remember the power of *nix, feed the output
 of make VERBOSE=1 21 into sed/awk/perl/your-favorite-here and
 use ANSI Control Sequence Initiators:
 
 CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
 PROJECT(P C)
 FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){Return 0;}\n)
 SET_SOURCE_FILES_PROPERTIES(main.c PROPERTIES COMPILE_FLAGS -Wall)
 ADD_EXECUTABLE(main main.c)
 
 % cmake srcdir
 ...
 % make VERBOSE=1 21 | sed \
 -e 's%^.*: error: .*$%\x1b[37;41m\x1b[m%' \
 -e 's%^.*: warning: .*$%\x1b[30;43m\x1b[m%'
 
 Regards,
 
 Michael

Does colorgcc work with CMake? That would be a *lot* easier...

--

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] CPack output name using VS IDE

[Michael Wild]

On 01/10/2012 10:50 AM, Totte Karlsson wrote:

 But when executing the PACKAGE target, from within VS IDE, the
 ${CMAKE_BUILD_TYPE} does not seem to be set.

 VS IDE or XCode do not set this because they are able to handle
 several config at once.
 
 yes.
 
 You may try to use CMAKE_CFG_INTDIR instead.
 See:
cmake --help-variable CMAKE_CFG_INTDIR
 
 When executing the PACKAGE target from the IDE, that variable is
 evaluated to
 $(Configuration)

Not quite. CMake evaluates it to $(Configuration) (or what ever the
particular IDE uses), which then gets expanded by the IDE to the current
configuration, i.e. Debug, Release, etc.


Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Adding user defined search path for find_package

[Michael Wild]

On 01/10/2012 11:14 AM, Martin Uhrin wrote:
 Dear CMake community,
 
 firstly, thank you for the extremely useful build tool, it's saved me a
 lot of time and effort!
 
 I'm trying to solve the following problem:
 
 I'd like the user (i.e. non-developer compiling my code) to have the
 option to specify a location for an external library and *iff* this
 option is set it should be used as the 'top-priority' search location
 for that library, falling back to all the others if it is not found or
 not set.  Ideally this option would be set as a variable so that it is
 visible in e.g. ccmake.
 
 The reason for doing this is that if the user just sets a variable to
 indicate the library path I would then have to manually check that the
 library does indeed exist at that path.
 
 Is there a way to do this?
 
 Many thanks,
 -Martin

There are quite a few such variables:

CMAKE_PREFIX_PATH
CMAKE_LIBRARY_PATH
CMAKE_INCLUDE_PATH
CMAKE_PROGRAM_PATH
CMAKE_FRAMEWORK_PATH
CMAKE_APPBUNDLE_PATH
CMAKE_IGNORE_PATH


Michael

--

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-developers] Should a module attempt to find its own dependencies?

[Michael Wild]

On 01/09/2012 03:07 AM, David Cole wrote:
 
 
 On Sunday, January 8, 2012, Alexander Neundorf neund...@kde.org
 mailto:neund...@kde.org wrote:
 On Sunday 08 January 2012, Stephen Kelly wrote:
 Alexander Neundorf wrote:
  On Sunday 08 January 2012, Stephen Kelly wrote:
  Hi,
 
  I don't think I've ever seen a direct answer to this question.
 
  AFAIK, yes, they should.
  FindKDE4Internal.cmake finds Qt, FindPNG.cmake finds zlib.
 
  Is it something to be decided on a case by case basis? If so, then why
  is there no general case?
 
  I can see a possible reason that it is not solvable in the general
 case
  because sometimes the behaviour of find_package can be changed by
  setting variables (eg, one might use QT_USE_QTXMLPATTERNS before
  finding Qt4).
 
  Specifically this comes up for me because I need to know whether Qt5
  modules should find their own dependencies. That is, should
 
  find_package(Qt5Gui)
 
  cause
 
  find_package(Qt5Core REQUIRED)
 
  to be called or not?
 
  I'd say yes.
  Otherwise the imported targets in Qt5Gui will depend on not yet defined
  targets from Qt5Core.
 
  The same way cmake takes care of adding the required additional
 libraries
  to the link line (like adding zlib when linking libpng), it should also
  take care of this, IMO.
 
  You should just have to state
  find_package(Foo)
  and this will get you Foo.

 That implies that

 * Qt5Gui_INCLUDE_DIRS should also contain Qt5Core_INCLUDE_DIRS

 * Qt5Gui_DEFINITIONS should contain Qt5Core_DEFINITIONS

 * Qt5Gui_COMPILE_DEFINITIONS should contain Qt5Core_COMPILE_DEFINITIONS

 Right?


 Yes, I'd say so.
 But let's wait also for some opinions from others.

 Alex
 --

 Powered by www.kitware.com http://www.kitware.com

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

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

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

 
 I'd say so too. Waiting for a dissenting opinion... ;-)

Not from me... I fully agree with Alex.

Michael

--

Powered by www.kitware.com

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

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

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

Re: [CMake] Add Custom COmmand and CMAKE_CFG_INTDIR

[Michael Wild]

On 01/04/2012 09:28 PM, Michael Jackson wrote:
 I am having trouble getting add_custom_Command and CMAKE_CFG_INTDIR to work 
 correctly together. This is what I have so far.
 
 # -- Setup output Directories -
 SET (CMAKE_LIBRARY_OUTPUT_DIRECTORY
   ${PROJECT_BINARY_DIR}/Bin
   CACHE PATH
   Single Directory for all Libraries
   )
 
 # Create our custom executable that will generate most of our QFilterWidget
 # classes from information stored in the Filters themselves.   
 configure_file( ${FilterWidgets_SOURCE_DIR}/CodeGen.cpp.in
 ${FilterWidgets_BINARY_DIR}/FilterWidgetCodeGen.cpp)
 add_executable(FilterWidgetCodeGen 
 ${FilterWidgets_BINARY_DIR}/FilterWidgetCodeGen.cpp)
 target_link_libraries(FilterWidgetCodeGen MXA EbsdLib DREAM3DLib)
 set(EXE_EXTENSION )
 if (WIN32)
   set (EXE_EXTENSION .exe)
 endif()
 # Now run the code to generate the header files which will over write the 
 place
 # holder files that were generated from above  
 add_custom_command(TARGET FilterWidgetCodeGen POST_BUILD 
 COMMAND FilterWidgetCodeGen${EXE_EXTENSION} 
 WORKING_DIRECTORY ${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
 
 
 I know this is going to fail on visual studio, which it did. The issue is, 
 what combination of CMAKE_CFG_INTDIR and anything else do I use to get this 
 to work?
 
 Thanks

Hi

AFAICS the only real problem is the EXE_EXTENSION. If you use a target
name in add_custom_command, CMake will figure out the location and name
of the actual executable on its own. By appending EXE_EXTENSION CMake
won't be able to recognize the target name any more, and just run the
command as you specified it. In this case you would need to fiddle
around with CMAKE_CFG_INTDIR, that's true. But since CMake is able to do
it automagically, I think you shouldn't try to outsmart it.

Another thing: I think you should use CMAKE_RUNTIME_OUTPUT_DIRECTORY
instead of CMAKE_LIBRARY_OUTPUT_DIRECTORY.

My 2c...

Michael

--

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] __FILE__ relative path

[Michael Wild]

set(SRCS a/a.cpp b/b.cpp c/c.cpp d/d.cpp)

foreach(f IN LISTS SRCS)
  get_filename_component(b ${f} NAME)
  set_source_files_properties(${f} PROPERTIES
COMPILE_DEFINITIONS MYSRCNAME=${b})
endforeach()

add_executable(foo ${SRCS})


HTH

Michael

On 12/28/2011 08:17 AM, vivek goel wrote:
 Is there any way to define custom
 macro as given in following answer
 http://stackoverflow.com/questions/237542/learning-the-source-codes-filename-at-compile-time
 with cmake
 
 
 regards
 Vivek Goel
 
 
 
 On Tue, Dec 27, 2011 at 11:02 PM, Rolf Eike Beer e...@sf-mail.de
 mailto:e...@sf-mail.de wrote:
 
 Am Dienstag, 27. Dezember 2011, 09:18:15 schrieb J Decker:
  On Tue, Dec 27, 2011 at 1:42 AM, Rolf Eike Beer e...@sf-mail.de
 mailto:e...@sf-mail.de wrote:
   Am Dienstag, 27. Dezember 2011, 14:58:32 schrieb vivek goel:
   How can I make cmake to compile source with relative path ?
  
   So that __FILE__ belongs to relative path of the file
  
   or there is another way I can replace __FILE__ with some other
 variable ?
 
  relative path to what?  What is it you need the path to be?
 
   __FILE__ is implemented by the compiler, it has nothing to do
 with CMake.
   What
  Well, it does have a little to do with CMake; the variable is the
  filename passed to the compiler, which comes from cmake.
 
 Yes, but the compiler is free to convert it to an absolute path or
 do whatever
 it wants with it.
 
 Eike


--

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] __FILE__ relative path

[Michael Wild]

If you don't want to have the full path embedded in the binary, you do.

As an addendum to my previous answer, the string after the equal sign might 
need escaped quoting.

Michael.



On 28.12.2011, at 18:41, J Decker d3c...@gmail.com wrote:

 ya - before using the file parameter, find the last / or '\' and print
 from there forward... you dono't need an absolute or relative path for
 that
 
 On Tue, Dec 27, 2011 at 11:17 PM, vivek goel goelvivek2...@gmail.com wrote:
 Is there any way to define custom
 macro as given in following answer
 http://stackoverflow.com/questions/237542/learning-the-source-codes-filename-at-compile-time
 with cmake
 
 
 regards
 Vivek Goel
 
 
 
 On Tue, Dec 27, 2011 at 11:02 PM, Rolf Eike Beer e...@sf-mail.de wrote:
 
 Am Dienstag, 27. Dezember 2011, 09:18:15 schrieb J Decker:
 On Tue, Dec 27, 2011 at 1:42 AM, Rolf Eike Beer e...@sf-mail.de wrote:
 Am Dienstag, 27. Dezember 2011, 14:58:32 schrieb vivek goel:
 How can I make cmake to compile source with relative path ?
 
 So that __FILE__ belongs to relative path of the file
 
 or there is another way I can replace __FILE__ with some other
 variable ?
 
 relative path to what?  What is it you need the path to be?
 
 __FILE__ is implemented by the compiler, it has nothing to do with
 CMake.
 What
 Well, it does have a little to do with CMake; the variable is the
 filename passed to the compiler, which comes from cmake.
 
 Yes, but the compiler is free to convert it to an absolute path or do
 whatever
 it wants with it.
 
 Eike
 --
 
 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
 --
 
 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] building on linux, extra libraries referenced

[Michael Wild]

On 12/26/2011 08:46 AM, J Decker wrote:
 I have this huge project that I've been building with cmake; and even
 under gcc (mingw) I don't have this problem... but what is happening
 is I have a generic list of libraries that I provide for applications
 to link against.  This includes the c version and the c++ version of
 two libraries.  On Windows, only those libraries that are actually
 used are referenced in the final output.  On Linux, with very recent
 gcc compilers, the programs end up with references to both libraries,
 and both(all 4) libraries are loaded.  I understand that this is
 probably a feature of some sort; but now do I specify for ld to only
 use the libraries that have referenced symbols in them?

Actually, it should be just the reverse. Recent versions of Linux
(Ubuntu and Debian I know of) should have --as-needed and
--no-copy-dt-needed-entries in effect by default, causing the behaviour
you want.

Michael

--

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] regex first subfolder

[Michael Wild]

On 12/26/2011 11:52 AM, Anton Sibilev wrote:
 Hello! Can you, please, help me with regex?
 
 I have the string, for example, aaa111/bbb222/ccc333.
 As the result of regex I want to get aaa111, but I can't set proper
 expression..
 
 string (REGEX REPLACE ^(.*/)?  folder ${folder}) ?
 

string(REGEX REPLACE ^(/?[^/]+).* \\1 folder ${folder})

Michael

--

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] Printing the detailed link command call

[Michael Wild]

Try

make VERBOSE=1


Michael



On 26.12.2011, at 15:18, Ceylow cey...@gmail.com wrote:

 Hello,
 
 I'm having some troubles with a linking step and I would like to see exactly 
 which parameters are given to my compiler when running the Makefile generated 
 by CMake.
 
 Currently it only shows:
 Linking CXX shared library xxx
 
 which isn't enough for me to find out why I have undefined symbols. I 
 couldn't find any information about this on the web (maybe searching with the 
 wrong words but...).
 
 Thanks,
 Ceylo 
 --
 
 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] Determine 32 vs 64 bit cpu

[Michael Wild]

On 12/22/2011 12:23 PM, pellegrini wrote:
 Hi all,
 
 I have a program that uses an external library whose path name depends
 on its version (32 or 64 bit).
 
 Is there a direct way in cmake to test whether my cpu is 32 or 64 bit ?

You don't actually care about the CPU, but the operating system (you can
install a 32-bit OS on a 64-bit machine)

 
 The one I found up to now is the following:
 
 if(CMAKE_SIZEOF_VOID_P EQUAL 8)
set(arch_64 TRUE)
 else()
 set(arch_64 FALSE)
 endif()

Yes, that's the way to go. However, remember that on Mac OS X this is
almost always the wrong thing to do when you're building universal
binaries. So, if your software is supposed to work on Mac, you will need
to take special precautions.

 
 thanks a lot and merry Christmas !

Same to you too!

 
 Eric
 
 

Michael
--

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] Compile project as C++ if MSVC

[Michael Wild]

On 12/23/2011 07:23 AM, Eric Noulard wrote:
 2011/12/23 Pau Garcia i Quiles pgqui...@elpauer.org:
 Hi,

 Visual C++ 2010 does not support C99 yet and it seems it will be a
 long time before MSVC supports it. For now, the usual work-around is
 to build the project as C++.

 I'd like to build as C if using mingw, and as C++ if using MSVC. How
 can I do that? project() seems not to be valid here (I can't do
 if(MSVC) before project()) and I cannot find a target property to say
 compile as language CXX
 
 There is a LANGUAGE property but it is for source files not target
 (which is logical because a target may contain mixed language sources)
 
 so
 
 set_source_files_properties(SRC PROPERTIES LANGUAGE C)
 
 see
 cmake --help-property LANGUAGE
 cmake --help-command set_source_files_properties
 
 you may be interested by the SOURCE target property as well
 which makes its possible to retrieve all SOURCE file belonging to a
 target.
 
 

You could also fiddle around with the CMAKE_LANG_SOURCE_FILE_EXTENSION
variables. E.g:

if(MSVC)
  list(APPEND CMAKE_CXX_SOURCE_FILE_EXTENSION
${CMAKE_C_SOURCE_FILE_EXTENSION})
  set(CMAKE_C_SOURCE_FILE_EXTENSION)
endif()

Michael
--

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