[CMake] Portability of preprocessor defines
Hello. It seems that everyone defines their preprocessor symbols like this: -DFOO I actually prefer this: -D FOO (With a space.) Is this just as portable as the version without the space though? Would CMake remove the space if needed, and if not, would that ever cause issues? -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How to deal with generated source files (w/ dependency tracking) for globs
On 4/4/16, Nicholas Braden wrote: > I haven't tested this myself, but instead of using a glob, you could > have a build step that generates a CMake script file with the list of > generated files in it (e.g. via execute_process to run another CMake > script whose only job is to generate the CMake script inception-style) > and just include the generated file - CMake will see that the CMake > file has been modified during every build but will still handle source > file changes correctly. Worth a shot. > Thanks for the reply. So if I understand this correctly, this is what the workflow is going to feel like. - User adds their Nim file to the CMakeLists.txt - CMake detects a change and a bootstrap generate/update takes place, and my stuff re-runs the Nim compiler. - Also during this phase, I need to generate another CMake script which contains the list of files the Nim compiler output. - Since this other script is also under CMake change tracking, this will trigger another CMake change detection and bootstrap/generate/update. - Now the generated build system has the updated list of generated .c files to compile and will finally compile it. Does this sound right? My major concern is that the two bootstrap phases kind of break the flow. What I mean by that is that in Xcode for example, when a bootstrap/generate/update happens, it actually causes your Build/Run (run button) action to abort midway through. You sit there expecting it to build, but CMake's regeneration was the only thing that happened. You must hit the Run button again to actually build/run. Kind of annoying and also really confusing for people who don't understand this because it isn't obvious why this happened. But in the above example, there are now two bootstrap phases. So assuming this works, I think the user will have to hit the Run button at least 3 times before something actually builds/runs. I think this is going to feel real broken and feel like dumb luck something actually built. So I was hoping to find a one-step bootstrap solution instead of two-step. Thanks, Eric -- 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] Performance issues on very large project
It turns out the problem was due to scoping. The module in question was only being included by subdirectories, but not the top-level listfile (I'm sure you can see where this is going). Switching the include guard to make use of a property rather than a variable took care of the problem nicely - we're back to 55s. Thanks for the responses! Steve On Wed, Apr 6, 2016 at 8:38 AM, Miller Henry wrote: > I found the same thing a few years ago, and my solution was the same: only > include those modules once. I find that my sub cmake modules are much > cleaner now as a bonus. > > I tend to blame the time not on file IO, but on time to parse those files. > I've never done actual profiling though. > > -Original Message- > From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Steven Stallion > Sent: Tuesday, April 05, 2016 11:19 PM > To: cmake@cmake.org > Subject: [CMake] Performance issues on very large project > > All, > > I am currently working on a very large project that contains over 500 (yes, > really) listfiles. A co-worker was looking into some performance issues we > were seeing during configuration and found something very interesting. > Currently configuration is taking 1m57s across several configurations using > Mac OS X as a host and the latest .dmg from cmake.org (3.5.1). > > We have a core module that provides a number of helper functions and macros > (completely stateless) that is included by most of this listfiles (nearly 400 > of them). We found that an include guard was missing, after adding that > configuration now clocks in at 1m30s. > > Taking things a step further, we removed includes of the module, and simply > included it once in the top-level listfile. Configuration then dropped to > about 55s. > > The results above seem to indicate a possible file I/O bottleneck. > This is very surprising to me - these builds are being run on recent > core-i7's with SSDs. Is anyone else on the list dealing with large projects > or similar configuration issues? > > TIA, > > Steve > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How to deal with generated source files (w/ dependency tracking) for globs
Okay, so I tried my own suggesting and found that it doesn't work at all (it's more complicated than I thought). However I want to ask you about your logic here - you say that when the configure step runs, it cancels XCode's build and so the user has to run the build a second time. If we use a script to generate a file or just touch one of the cmake files for every build, that means that every build will be cancelled and XCode will never move on to actually compile anything. The only way to actually let a build not be cancelled is either to run `cmake --build .` from the command line instead of using the IDE, or to not modify any CMake file, which requires some pretty elaborate scripting to accomplish. Even just touching the modified date of a CMake file will cause the configure step to run. At this point I think you should just tell your users to manually run the configure step whenever they add or remove a nim source file, because either way it will be a two-click process. There is no way I see to have the magic single-click build you want given XCode's limitations. But if you ever do find a way I'd be interested to hear. (Though, I don't know how XCode treats External Projects - maybe you could get it to work that way, but it'd be ugly) On Wed, Apr 6, 2016 at 6:28 AM, Eric Wing wrote: > On 4/4/16, Nicholas Braden wrote: >> I haven't tested this myself, but instead of using a glob, you could >> have a build step that generates a CMake script file with the list of >> generated files in it (e.g. via execute_process to run another CMake >> script whose only job is to generate the CMake script inception-style) >> and just include the generated file - CMake will see that the CMake >> file has been modified during every build but will still handle source >> file changes correctly. Worth a shot. >> > > Thanks for the reply. So if I understand this correctly, this is what > the workflow is going to feel like. > > - User adds their Nim file to the CMakeLists.txt > - CMake detects a change and a bootstrap generate/update takes place, > and my stuff re-runs the Nim compiler. > - Also during this phase, I need to generate another CMake script > which contains the list of files the Nim compiler output. > - Since this other script is also under CMake change tracking, this > will trigger another CMake change detection and > bootstrap/generate/update. > - Now the generated build system has the updated list of generated .c > files to compile and will finally compile it. > > Does this sound right? > > My major concern is that the two bootstrap phases kind of break the > flow. What I mean by that is that in Xcode for example, when a > bootstrap/generate/update happens, it actually causes your Build/Run > (run button) action to abort midway through. You sit there expecting > it to build, but CMake's regeneration was the only thing that > happened. You must hit the Run button again to actually build/run. > Kind of annoying and also really confusing for people who don't > understand this because it isn't obvious why this happened. > > But in the above example, there are now two bootstrap phases. So > assuming this works, I think the user will have to hit the Run button > at least 3 times before something actually builds/runs. I think this > is going to feel real broken and feel like dumb luck something > actually built. > > So I was hoping to find a one-step bootstrap solution instead of two-step. > > Thanks, > Eric -- 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] Performance issues on very large project
I found the same thing a few years ago, and my solution was the same: only include those modules once. I find that my sub cmake modules are much cleaner now as a bonus. I tend to blame the time not on file IO, but on time to parse those files. I've never done actual profiling though. -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Steven Stallion Sent: Tuesday, April 05, 2016 11:19 PM To: cmake@cmake.org Subject: [CMake] Performance issues on very large project All, I am currently working on a very large project that contains over 500 (yes, really) listfiles. A co-worker was looking into some performance issues we were seeing during configuration and found something very interesting. Currently configuration is taking 1m57s across several configurations using Mac OS X as a host and the latest .dmg from cmake.org (3.5.1). We have a core module that provides a number of helper functions and macros (completely stateless) that is included by most of this listfiles (nearly 400 of them). We found that an include guard was missing, after adding that configuration now clocks in at 1m30s. Taking things a step further, we removed includes of the module, and simply included it once in the top-level listfile. Configuration then dropped to about 55s. The results above seem to indicate a possible file I/O bottleneck. This is very surprising to me - these builds are being run on recent core-i7's with SSDs. Is anyone else on the list dealing with large projects or similar configuration issues? TIA, Steve -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] OBJECT Libraries with Xcode Generator
I think I ran into a bug but I am wondering if anyone has seen it an worked
around.
I have a source structure like the following (this is a contrived small example
to illustrate the problem):
- CMakeLists.txt
- main.c
- lib
- CMakeLists.txt
- x.c
- x.h
- alt1
- x.c
- x.h
- alt2
- x.c
- x.h
CMakeLists.txt:
cmake_minimum_required(VERSION 3.5)
project(example)
add_subdirectory(lib)
include_directories(lib)
add_executable(main main.c $)
main.c:
#include "x.h"
int main()
{
return example_func();
}
lib/CMakeLists.txt:
option(ALT1 "ALT1" ON)
option(ALT2 "ALT2" ON)
set(SOURCES x.c)
if ( ALT1 )
add_definitions(-DALT1)
list(APPEND SOURCES alt1/x.c)
elseif ( ALT2 )
add_definitions(-DALT2)
list(APPEND SOURCES alt2/x.c)
else ()
message(FATAL_ERROR "No alt defined")
endif()
add_library(example OBJECT ${SOURCES})
lib/x.h:
#ifndef X_H
#define X_H
int example_func();
#endif
lib/x.c:
#include "x.h"
#ifdef ALT2
#include "alt2/x.h"
#else
#include "alt1/x.h"
#endif
int example_func()
{
return call_example_func();
}
lib/alt1/x.h:
#ifndef ALT1_X_H
#define ALT1_X_H
int alt1_example_func();
#define call_example_func() alt1_example_func()
#endif
lib/alt1/x.c:
int alt1_example_func()
{
return 1;
}
lib/alt2/x.h:
#ifndef ALT2_X_H
#define ALT2_X_H
int alt2_example_func();
#define call_example_func() alt2_example_func()
#endif
lib/alt2/x.c:
int alt2_example_func()
{
return 2;
}
Now if I run cmake using the makefile generator and then run make, all is well
and everything is built and runs as expected. If I use the Xcode generator I
get the following errors:
clang: error: no such file or directory: ‘/lib/example.build/Debug/example.build/Objects-normal/x86_64/x.o’
Within the directory /lib/example.build/Debug/example.build/Objects-normal/x86_64 there is
in fact no x.o. Instead there are two files, x-8171277E06B93FB2.o and
x-FA155118579B6D7E.o. So it looks like for the XCode generators sources
intermediate object files for a single CMakeLists.txt are stored within a
single directory. And in this case the sources have the same name so the
x-.o names are used instead. However the $ generator
expression seems to be referencing an incorrect name. Is there any workaround
so that for the Xcode generator it will not store all the build artifacts in a
single directory and not use the object file name with the unique id in it and
secondly where is the proper place to file a bug for this.
--
Matthew Keeler
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] OBJECT Libraries with Xcode Generator
On 06/04/16 20:32, Matthew Keeler wrote:
>
> I think I ran into a bug but I am wondering if anyone has seen it an worked
> around.
>
> I have a source structure like the following (this is a contrived small
> example to illustrate the problem):
>
> - CMakeLists.txt
> - main.c
> - lib
>- CMakeLists.txt
>- x.c
>- x.h
>- alt1
> - x.c
> - x.h
>- alt2
> - x.c
> - x.h
>
> CMakeLists.txt:
>
>cmake_minimum_required(VERSION 3.5)
>project(example)
>add_subdirectory(lib)
>include_directories(lib)
>add_executable(main main.c $)
>
>
> main.c:
>
>#include "x.h"
>
>int main()
>{
> return example_func();
>}
>
> lib/CMakeLists.txt:
>
>option(ALT1 "ALT1" ON)
>option(ALT2 "ALT2" ON)
>set(SOURCES x.c)
>if ( ALT1 )
> add_definitions(-DALT1)
> list(APPEND SOURCES alt1/x.c)
>elseif ( ALT2 )
> add_definitions(-DALT2)
> list(APPEND SOURCES alt2/x.c)
>else ()
>message(FATAL_ERROR "No alt defined")
>endif()
>add_library(example OBJECT ${SOURCES})
>
> lib/x.h:
>
>#ifndef X_H
>#define X_H
>int example_func();
>#endif
>
> lib/x.c:
>
> #include "x.h"
> #ifdef ALT2
> #include "alt2/x.h"
> #else
> #include "alt1/x.h"
> #endif
> int example_func()
> {
> return call_example_func();
> }
>
>
> lib/alt1/x.h:
>
>#ifndef ALT1_X_H
>#define ALT1_X_H
>int alt1_example_func();
>#define call_example_func() alt1_example_func()
>#endif
>
>
> lib/alt1/x.c:
>
>int alt1_example_func()
>{
> return 1;
>}
>
> lib/alt2/x.h:
>
>#ifndef ALT2_X_H
>#define ALT2_X_H
>int alt2_example_func();
>#define call_example_func() alt2_example_func()
>#endif
>
>
> lib/alt2/x.c:
>
>int alt2_example_func()
>{
> return 2;
>}
>
>
>
> Now if I run cmake using the makefile generator and then run make, all is
> well and everything is built and runs as expected. If I use the Xcode
> generator I get the following errors:
>
> clang: error: no such file or directory: ‘ directory>/lib/example.build/Debug/example.build/Objects-normal/x86_64/x.o’
>
> Within the directory directory>/lib/example.build/Debug/example.build/Objects-normal/x86_64 there
> is in fact no x.o. Instead there are two files, x-8171277E06B93FB2.o and
> x-FA155118579B6D7E.o. So it looks like for the XCode generators sources
> intermediate object files for a single CMakeLists.txt are stored within a
> single directory. And in this case the sources have the same name so the
> x-.o names are used instead. However the $ generator
> expression seems to be referencing an incorrect name. Is there any workaround
> so that for the Xcode generator it will not store all the build artifacts in
> a single directory and not use the object file name with the unique id in it
> and secondly where is the proper place to file a bug for this.
Thank you for the minimal example. Please file a bug in the bug tracker.
Thanks,
Gregor
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] OBJECT Libraries with Xcode Generator
On 04/06/2016 03:47 PM, Gregor Jasny wrote: > On 06/04/16 20:32, Matthew Keeler wrote: >> clang: error: no such file or directory: >> '.../lib/example.build/Debug/example.build/Objects-normal/x86_64/x.o' >> >> Within the directory >> .../lib/example.build/Debug/example.build/Objects-normal/x86_64 >> there is in fact no x.o. Instead there are two files, x-8171277E06B93FB2.o >> and >> x-FA155118579B6D7E.o. So it looks like for the XCode generators sources >> intermediate >> object files for a single CMakeLists.txt are stored within a single >> directory. >> And in this case the sources have the same name so the x-.o names are >> used instead. >> However the $ generator expression seems to be referencing >> an >> incorrect name. Is there any workaround so that for the Xcode generator it >> will >> not store all the build artifacts in a single directory and not use the >> object >> file name with the unique id in it It is unlikely CMake will be able to predict the object file names Xcode will choose for repeated sources, so yes it would be nice to be able to tell Xcode to put the objects in separate directories. I don't know whether this is possible though. As a workaround you could either rename one source or add/generate another source with a different name that uses #include to get the original. >> and secondly where is the proper place to file a bug for this. > Thank you for the minimal example. Please file a bug in the bug tracker. https://cmake.org/Bug Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] OBJECT Libraries with Xcode Generator
Ah, I thought cmake was controlling the output filenames of the compiler and not Xcode. Then its not really a cmake problem. Changing source names is easy enough. I was just curious. Also in the real case I could just as easily use a STATIC library instead but normally go for OBJECT libraries first. Oh well. Thanks for the info. -- Matthew Keeler On April 6, 2016 at 16:06:11, Brad King (brad.k...@kitware.com) wrote: On 04/06/2016 03:47 PM, Gregor Jasny wrote: > On 06/04/16 20:32, Matthew Keeler wrote: >> clang: error: no such file or directory: >> '.../lib/example.build/Debug/example.build/Objects-normal/x86_64/x.o' >> >> Within the directory >> .../lib/example.build/Debug/example.build/Objects-normal/x86_64 >> there is in fact no x.o. Instead there are two files, x-8171277E06B93FB2.o >> and >> x-FA155118579B6D7E.o. So it looks like for the XCode generators sources >> intermediate >> object files for a single CMakeLists.txt are stored within a single >> directory. >> And in this case the sources have the same name so the x-.o names are >> used instead. >> However the $ generator expression seems to be referencing >> an >> incorrect name. Is there any workaround so that for the Xcode generator it >> will >> not store all the build artifacts in a single directory and not use the >> object >> file name with the unique id in it It is unlikely CMake will be able to predict the object file names Xcode will choose for repeated sources, so yes it would be nice to be able to tell Xcode to put the objects in separate directories. I don't know whether this is possible though. As a workaround you could either rename one source or add/generate another source with a different name that uses #include to get the original. >> and secondly where is the proper place to file a bug for this. > Thank you for the minimal example. Please file a bug in the bug tracker. https://cmake.org/Bug Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] CPack does not generate a RPM
Hi,
I have an error and I do not know, how to solve this error.
I have an archive, where are some files. I want to generate a rpm
package with the files, which are in that archive. So first, I extract
that archive with a bash script. After that, the script calls "cpack
-G RPM -V ." for this CMakeLists.txt:
cmake_minimum_required(VERSION 3.5)
project(project1)
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/usr/bin/calculator DESTINATION bin)
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/usr/lib64/* DESTINATION lib)
set(CPACK_GENERATOR "RPM")
set(CPACK_PACKAGE_VERSION_MAJOR 1)
set(CPACK_PACKAGE_VERSION_MINOR 2)
set(CPACK_PACKAGE_NAME "project1")
set(CPACK_RPM_PACKAGE_NAME "project1")
set(CPACK_RPM_PACKAGE_SUMMARY "Some random calculator")
set(CPACK_RPM_PACKAGE_ARCHITECTURE x86_64)
set(CPACK_PACKAGE_VENDOR "Vendor Coorp.")
set(CPACK_RPM_PACKAGE_MAINTAINER "Vendor Coorp.")
INCLUDE(CPack)
But calling the cpack command, I always getting the error "CPack
project name not specified". Why is that? What I am missing?
--
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
[CMake] Fwd: CPack does not generate a RPM
Ok, one part of the problem, I could solve. I could solve the problem
with running the following commands:
cmake . && make package
After that, I get a rpm package. But now, I have another problem and I
do not know, if I am doing something wrong or if this is a bug.
Let's assume, I have a library, e.g. liblibrary.so.5.6.7 and I have
two symbolic links, so the result of "ls -l" would look like this
liblibrary.so -> liblibrary.so.0
liblibrary.so.0 -> liblibrary.so.5.6.7
liblibrary.so.5.6.7
And let's assume, I have these lines in my CMakeLists.txt:
***
set(LIBRARIES
${LIB}/liblibrary.so
${LIB}/liblibrary.so.0
${LIB}/liblibrary.so.5.6.7)
#...
install(FILES ${LIBRARIES} DESTINATION lib)
***
Now, I call the commands "cmake . && make package" and I get a package
"project1.1-Linux.rpm". After that, I try to install that package with
"yum install project1.1-Linux.rpm", I get some strange dependency
resolution errors, which would look like this
--> Finished Dependency Resolution
Error: Package: project1.1-1.x86_64 (/project1.1-Linux)
Requires: liblibrary.so.0()(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
But when I have only these lines in CMakeLists.txt
**
set(LIBRARIES
${LIB}/liblibrary.so.0
${LIB}/liblibrary.so.5.6.7)
#...
install(FILES ${LIBRARIES} DESTINATION lib)
**
then installation of my very simple project works and I am not getting
any dependency resolution errors.
-- Forwarded message --
From: Kristian
Date: 2016-04-07 0:50 GMT+02:00
Subject: CPack does not generate a RPM
To: cmake@cmake.org
Hi,
I have an error and I do not know, how to solve this error.
I have an archive, where are some files. I want to generate a rpm
package with the files, which are in that archive. So first, I extract
that archive with a bash script. After that, the script calls "cpack
-G RPM -V ." for this CMakeLists.txt:
cmake_minimum_required(VERSION 3.5)
project(project1)
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/usr/bin/calculator DESTINATION bin)
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/usr/lib64/* DESTINATION lib)
set(CPACK_GENERATOR "RPM")
set(CPACK_PACKAGE_VERSION_MAJOR 1)
set(CPACK_PACKAGE_VERSION_MINOR 2)
set(CPACK_PACKAGE_NAME "project1")
set(CPACK_RPM_PACKAGE_NAME "project1")
set(CPACK_RPM_PACKAGE_SUMMARY "Some random calculator")
set(CPACK_RPM_PACKAGE_ARCHITECTURE x86_64)
set(CPACK_PACKAGE_VENDOR "Vendor Coorp.")
set(CPACK_RPM_PACKAGE_MAINTAINER "Vendor Coorp.")
INCLUDE(CPack)
But calling the cpack command, I always getting the error "CPack
project name not specified". Why is that? What I am missing?
--
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
[CMake] Documenting CMakeLists.txt and custom or local .cmake files
Two days ago I posted this question on StackOverflow, http://stackoverflow.com/q/36415261/3154588. I have not gotten an answer there, so I thought I would ask on this list. What are good ways to document my project ``CMakeLists.txt`` files and local project ``.cmake`` files? There is a two year old question/answer http://stackoverflow.com/q/21628833/3154588 that I am essentially asking here again. The answer contains the statement > Currently, CMake 3.0 is under development which will get a new documentation > system based on Sphinx and reStructuredText. I guess that this will bring new > ways to document your modules. I have looked at the [cmake developer documentation](https://cmake.org/cmake/help/v3.5/manual/cmake-developer.7.html?highlight=sphinx#id2), but this *new documentation system* seems geared towards the documentation of cmake itself. I do not see how I can use this to document my user-defined project ``CMakeLists.txt`` files or local ``.cmake`` files. I am hoping that since the cmake project internally has various sphinx directives and roles that there is was some way as a user I could take advantage of this internal usage of sphinx. I would like to be able to have some *markup* in my ``CMakeLists.txt`` files and local ``.cmake`` files without having to reinvent the wheel. There are related efforts in other projects. For example the ROS catkin project seems to offer the most complete approach that I have seen, but that is fairly heavyweight not easy to use for non-ROS projects. (As an example, look at their [extracted cmake api page](http://docs.ros.org/api/catkin/html/dev_guide/generated_cmake_api.html).) The simplest, is the [sphinx-contrib](https://bitbucket.org/birkenfeld/sphinx-contrib/) cmakedomain, but that relies on a separate rst source doc rather than an *autodoc* approach with markup comments. I appreciate any help. Sincerely, Phil -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How to deal with generated source files (w/ dependency tracking) for globs
I think it depends on when you want the output files from Nim
generated and which files are the most frequently developed.
If it is usually a one-time generation per clean development session,
the simplest case, where the *.NIM source files are not the files
most likely to be changed, I would think execute_process should
work okay?
cmake_minimum_required( VERSION 2.8.11 )
project( GenerateSomeFilesAndBuildThem C )
execute_process( COMMAND touch a.c a.h b.c b.h c.c c.h
COMMAND echo "Generating some C files using NIM..."
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} )
file( GLOB SRC ${CMAKE_CURRENT_BINARY_DIR}/*.c
${CMAKE_CURRENT_BINARY_DIR}/*.h )
add_executable( generated main.c ${SRC} )
target_include_directories( generated PRIVATE ${CMAKE_CURRENT_BINARY_DIR} )
...
The C compiler identification is GNU 5.2.1
Check for working C compiler: /usr/bin/cc
Check for working C compiler: /usr/bin/cc -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Detecting C compile features
Detecting C compile features - done
Generating some C files using NIM...
Configuring done
Generating done
...
make
Scanning dependencies of target generated
[ 25%] Building C object CMakeFiles/generated.dir/main.c.o
[ 50%] Building C object CMakeFiles/generated.dir/c.c.o
[ 75%] Building C object CMakeFiles/generated.dir/a.c.o
[100%] Building C object CMakeFiles/generated.dir/b.c.o
Linking C executable generated
[100%] Built target generated
On Wed, Apr 6, 2016 at 8:55 AM, Nicholas Braden
wrote:
> Okay, so I tried my own suggesting and found that it doesn't work at
> all (it's more complicated than I thought). However I want to ask you
> about your logic here - you say that when the configure step runs, it
> cancels XCode's build and so the user has to run the build a second
> time. If we use a script to generate a file or just touch one of the
> cmake files for every build, that means that every build will be
> cancelled and XCode will never move on to actually compile anything.
> The only way to actually let a build not be cancelled is either to run
> `cmake --build .` from the command line instead of using the IDE, or
> to not modify any CMake file, which requires some pretty elaborate
> scripting to accomplish. Even just touching the modified date of a
> CMake file will cause the configure step to run. At this point I think
> you should just tell your users to manually run the configure step
> whenever they add or remove a nim source file, because either way it
> will be a two-click process. There is no way I see to have the magic
> single-click build you want given XCode's limitations. But if you ever
> do find a way I'd be interested to hear.
>
> (Though, I don't know how XCode treats External Projects - maybe you
> could get it to work that way, but it'd be ugly)
>
> On Wed, Apr 6, 2016 at 6:28 AM, Eric Wing wrote:
>> On 4/4/16, Nicholas Braden wrote:
>>> I haven't tested this myself, but instead of using a glob, you could
>>> have a build step that generates a CMake script file with the list of
>>> generated files in it (e.g. via execute_process to run another CMake
>>> script whose only job is to generate the CMake script inception-style)
>>> and just include the generated file - CMake will see that the CMake
>>> file has been modified during every build but will still handle source
>>> file changes correctly. Worth a shot.
>>>
>>
>> Thanks for the reply. So if I understand this correctly, this is what
>> the workflow is going to feel like.
>>
>> - User adds their Nim file to the CMakeLists.txt
>> - CMake detects a change and a bootstrap generate/update takes place,
>> and my stuff re-runs the Nim compiler.
>> - Also during this phase, I need to generate another CMake script
>> which contains the list of files the Nim compiler output.
>> - Since this other script is also under CMake change tracking, this
>> will trigger another CMake change detection and
>> bootstrap/generate/update.
>> - Now the generated build system has the updated list of generated .c
>> files to compile and will finally compile it.
>>
>> Does this sound right?
>>
>> My major concern is that the two bootstrap phases kind of break the
>> flow. What I mean by that is that in Xcode for example, when a
>> bootstrap/generate/update happens, it actually causes your Build/Run
>> (run button) action to abort midway through. You sit there expecting
>> it to build, but CMake's regeneration was the only thing that
>> happened. You must hit the Run button again to actually build/run.
>> Kind of annoying and also really confusing for people who don't
>> understand this because it isn't obvious why this happened.
>>
>> But in the above example, there are now two bootstrap phases. So
>> assuming this works, I think the user will have to hit the Run button
>> at least 3 times before something actually builds/runs. I think this
>> is going to feel real broken and feel like dumb luck something
>> actually built.
>>
>> So I was hoping
Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_* generator expressions on iOS
Hello,
sorry for the delayed reply. The root of the problem is actually not the XCtest
feature, but generator expressions. The minimal repro case is just the
following CMakeLists.txt file:
cmake_minimum_required(VERSION 3.5)
project(IosTarget C)
file(GENERATE
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/location.c
CONTENT "#define LOCATION \"$\""
CONDITION $)
add_library(lib STATIC ${CMAKE_CURRENT_BINARY_DIR}/location.c)
Create build directory and invoke CMake like this:
cmake ..
-DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk
-DCMAKE_OSX_ARCHITECTURES=armv7 -DCMAKE_C_COMPILER_WORKS=ON -G Xcode
(I had to put the CMAKE_C_COMPILER_WORKS there because of
https://cmake.org/Bug/view.php?id=15329 -- passing the CMAKE_MACOSX_BUNDLE and
CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED on command-line somehow didn't work
and I didn't want to inflate the repro case with a toolchain file. By the way,
why CMake can't set those properties implicitly for the compiler tests?)
Then, in the build directory a `location.c` file appears with contents similar
to this:
#define LOCATION
"/path/to/the/project/build/Debug${EFFECTIVE_PLATFORM_NAME}/liblib.a"
The expected value is however this:
#define LOCATION "/path/to/the/project/build/Debug-iphoneos/liblib.a"
Which corresponds to the location of the generated library if you run `cmake
--build .`
Hope the repro case is clear enough.
Regards
mosra
__
> Od: Gregor Jasny
> Komu: "Vladimír Vondruš" ,
> Datum: 30.03.2016 14:15
> Předmět: Re: [CMake] EFFECTIVE_PLATFORM_NAME not expanded in TARGET_*
> generator expressions on iOS
>
>Hello,
>
>I fear you're one of the first users of the XCtest feature :)
>
>On 21/03/16 13:42, Vladimír Vondruš wrote:
>> Hello,
>>
>> I came across this problem when trying to use XCTest macros (
>> https://cmake.org/cmake/help/latest/module/FindXCTest.html ) on iOS. When
>> compiling for OSX, ctest properly executes all test cases, but when
>> targeting iOS or iOS simulator, all the test cases fail similarly to the
>> following:
>>
>> 25: Test command:
>> /Applications/Xcode.app/Contents/Developer/usr/bin/xctest
>> "/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTestRunner.xctest/../.."
>> 25: Environment variables:
>> 25:
>> DYLD_FRAMEWORK_PATH=/Users/mosra/Code/corrade/build-ioss/src/Corrade/Utility/Test/Debug${EFFECTIVE_PLATFORM_NAME}/UtilityTypeTraitsTest.framework/..
>> 25: Test timeout computed to be: 9.99988e+06
>> 25: 2016-03-21 12:41:38.799 xctest[31113:31078264] The bundle “Test”
>> couldn’t be loaded because its executable couldn’t be located. Try
>> reinstalling the bundle.
>> 25/28 Test #25: UtilityTypeTraitsTest ...***Failed0.04
>> sec
>>
>> As you can see, the `${EFFECTIVE_PLATFORM_NAME}` is not being expanded to
>> `-iphonesimulator` and thus the file is not found. The problem is that the
>> `$` generator expression does not expand the
>> variable. On the other hand, installation works without an issue, because
>> the `cmake_install.cmake` scripts do additional round of variable expansion
>> that (accidentally?) fixes this. The relevant part of the CMake source is
>> here:
>> https://github.com/Kitware/CMake/blob/cd569b962dbeaa7ea718021c16582cddd158df3a/Source/cmGeneratorTarget.cxx#L5063
>>
>> From the source it looks like the generator is just putting the
>> "${EFFECTIVE_PLATFORM_NAME}" output and hopes that someone later expands it.
>> That's the case with install scripts (so they work), but not with generator
>> expressions. The `TARGET_LINKER_FILE_DIR` is not the only affected, the
>> problem is the same for all `TARGET_*` generator expressions.
>>
>> Currently I'm working around this by partially hardcoding the path, but
>> that's far from ideal and I would like to avoid that:
>>
>> if(CMAKE_OSX_SYSROOT MATCHES "iPhoneOS")
>> set(platform_name "-iphoneos")
>> elseif(CMAKE_OSX_SYSROOT MATCHES "iPhoneSimulator")
>> set(platform_name "-iphonesimulator")
>> endif()
>> set(target_linker_file_dir
>> ${CMAKE_CURRENT_BINARY_DIR}/$${platform_name}/${target}.xctest)
>>
>> Is there any way to fix this directly in CMake? Also the above workaround
>> works only when targeting single SDK and not when having single generated
>> project for both the device and the simulator.
>
>Could you please send me a minimal example and a command line how you
>invoke CMake?
>
>Thanks,
>Gregor
>
--
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
