From dan at su-root.co.uk Tue Dec 1 14:41:44 2015 From: dan at su-root.co.uk (Dan Liew) Date: Tue, 1 Dec 2015 19:41:44 +0000 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: <565C9EA1.8020704@kitware.com> References: <565C96E1.1000205@kitware.com> <565C9EA1.8020704@kitware.com> Message-ID: >> There is an alternative which I suggested in the post. Have CMake >> determine the dependencies of the files passed to ``IMPLICIT_DEPENDS`` >> at configure time and spit that into the build files of the generator >> (that would work for any generator). Then have any changes made to the >> files passed to ``IMPLICIT_DEPENDS`` trigger a reconfigure so that the >> dependencies can be recomputed. > > Perhaps, but after regenerating the project the build tool will not > re-load the build files and start building again. That will take > an additional invocation. The number of iterations required is > bounded only by the depth of dependency chains. I don't understand what you mean. What do you mean by "build tool" here? I also don't see why you would need to reconfigure multiple times. From dan at su-root.co.uk Tue Dec 1 14:53:25 2015 From: dan at su-root.co.uk (Dan Liew) Date: Tue, 1 Dec 2015 19:53:25 +0000 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: Message-ID: > 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... Hmm, to be honest I hadn't tried. It works better than expected but... The problem for this particular project is that it doesn't file a very standard compilation process. It compiles to LLVM IR, then to LLVM bitcode and then it invokes and external program to generate source files with the LLVM bitcode embedded in specially named arrays these generated source files then are compiled along with other sources into the projects main library. If I made the external project create OBJECT libraries rather than regular libraries then that might work but when I add the ``-emit-llvm`` flag to CMAKE_C_FLAGS things start breaking..., e.g. ``` include(CheckCCompilerFlag) CHECK_C_COMPILER_FLAG("-g" SUPPORTS_DEBUG) ``` Checking this compiler flag fails if CMAKE_C_FLAGS contains ``-emit-llvm`` due to linking errors. I also need a way of communicating to the outside world where the object files are as they are the final output. Using ``add_library(foo OBJECT ...)`` is just a hack to avoid invoking the linker. Maybe I should use a tool-chain file? I've never used this feature of CMake before but perhaps that would solve these problems. That way I could have CMake use, llvm-link rather than the system linker. Then things wouldn't break when trying to link. Dan. From brad.king at kitware.com Tue Dec 1 14:56:52 2015 From: brad.king at kitware.com (Brad King) Date: Tue, 1 Dec 2015 14:56:52 -0500 Subject: [CMake] [cmake-developers] Obtaining header file dependencies of a source file manually In-Reply-To: References: <565C96E1.1000205@kitware.com> <565C9EA1.8020704@kitware.com> Message-ID: <565DFB84.1040809@kitware.com> On 12/01/2015 02:41 PM, Dan Liew wrote: >> Perhaps, but after regenerating the project the build tool will not >> re-load the build files and start building again. That will take >> an additional invocation. The number of iterations required is >> bounded only by the depth of dependency chains. > > I don't understand what you mean. What do you mean by "build tool" here? > I also don't see why you would need to reconfigure multiple times. If a .vcxproj file is re-generated while "msbuild" is running then the new one may not be loaded and used until the next "msbuild". Perhaps that is okay for this use-case, but dynamic dependency injection is not possible if the dependencies are needed the first time around (which was the case last time I thought about this). Perhaps IMPLICIT_DEPENDS could be implemented by outputting the dependency information as a side effect of running the custom command. Then as part of deciding whether CMake needs to re-run on the next build it can look to see if that dependency information was updated. -Brad From a.neundorf-work at gmx.net Tue Dec 1 17:13:04 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Tue, 01 Dec 2015 23:13:04 +0100 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <565CE71F.9070707@yahoo.com> References: <20151130021049.GH99499@hades.panopticon> <1469290.AThC99h1Gj@tuxedo.neundorf.net> <565CE71F.9070707@yahoo.com> Message-ID: <483008399.bPTQzqbrGB@tuxedo.neundorf.net> On Tuesday, December 01, 2015 07:17:35 Ruslan Baratov wrote: > On 01-Dec-15 03:51, Alexander Neundorf wrote: > > On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake wrote: > > > On 30-Nov-15 09:10, Dmitry Marakasov wrote: > > > > Hi! > > > > ... > > > > > > The best solution would be for cmake to fix path in executable file > > > > > > > > right after installation, something similar to what cmake does with > > > > > > > > rpaths. > > > > > > I doubt there is a general way to patch data section with string in > > > > > > executable. At least with different size and in safe manner. For example > > > > > > Clang is smart enough to figure out 'strlen' of literal string at > > > > > > compile time, so changing string affects logic and hence is dangerous. > > > > > > And rpaths unlike data is designed to be modifiable > > > > Not really. CMake has extra code to make sure the build rpath is as > > long as the install rpath will be, so it can be patched in later. > > Well, that's exactly what I said - RPATH can be patched. well, the RPATH entry was not designed to be patched, any other string in an executable could be patched too: const char* my_builddir_flag = "$$$$_I_M_NOT_INSTALLED_$$$$"; ... if (*my_builddir_flag) { ... code when not installed } else { ... code for the installed version } Just search for that string in the executable and replace the first byte with a '\0'. Not sure there is a simple tool to do that, but writing one shouldn't be hard. Maybe it would even be accepted as an option into cmake. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Wed Dec 2 00:27:42 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 2 Dec 2015 12:27:42 +0700 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <483008399.bPTQzqbrGB@tuxedo.neundorf.net> References: <20151130021049.GH99499@hades.panopticon> <1469290.AThC99h1Gj@tuxedo.neundorf.net> <565CE71F.9070707@yahoo.com> <483008399.bPTQzqbrGB@tuxedo.neundorf.net> Message-ID: <565E814E.9050402@yahoo.com> On 02-Dec-15 05:13, Alexander Neundorf wrote: > > On Tuesday, December 01, 2015 07:17:35 Ruslan Baratov wrote: > > > On 01-Dec-15 03:51, Alexander Neundorf wrote: > > > > On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake wrote: > > > > > On 30-Nov-15 09:10, Dmitry Marakasov wrote: > > > > > > Hi! > > > > > > > > ... > > > > > > > > > > The best solution would be for cmake to fix path in executable > file > > > > > > > > > > > > right after installation, something similar to what cmake does > with > > > > > > > > > > > > rpaths. > > > > > > > > > > I doubt there is a general way to patch data section with string in > > > > > > > > > > executable. At least with different size and in safe manner. For > example > > > > > > > > > > Clang is smart enough to figure out 'strlen' of literal string at > > > > > > > > > > compile time, so changing string affects logic and hence is > dangerous. > > > > > > > > > > And rpaths unlike data is designed to be modifiable > > > > > > > > Not really. CMake has extra code to make sure the build rpath is as > > > > long as the install rpath will be, so it can be patched in later. > > > > > > Well, that's exactly what I said - RPATH can be patched. > > well, the RPATH entry was not designed to be patched, > RPATH designed to be patched. And since it's a third time I'm making this statement please provide any arguments if you don't agree. Here is mine (comes from wikipedia, https://en.wikipedia.org/wiki/Rpath): The rpath of an executable or shared library is an optional entry in the .dynamic section of the ELF executable or shared libraries, with the type DT_RPATH, called the DT_RPATH attribute. It can be stored there at link time by the linker. Tools such as chrpath and patchelf can create or MODIFY the entry later. Man chrpath (http://linux.die.net/man/1/chrpath): -r | --replace Replace current rpath or runpath setting with the path given > any other string in an executable could be patched too: > RPATH and C++ string literals have not the same nature. E.g. on my Linux machine RPATH string goes to ".dynstr" section and C++ literal to ".rodata" section. The difference is quite huge. By parsing ELF headers you can figure out RPATH offset and be 100% sure that patching is totally correct and doesn't affect other binary or general executable logic. RPATH is just a hint for linker. Changing bytes in .rodata is much trickier. E.g. how do you distinguish two strings: void print_some_info() { const char* path = "/usr/local"; // must not be changed std::cout << "General note: user specific packages usually installed to " << path << std::endl; } void parse_resources() { const char* resources_path = "/usr/local"; // want to change it in future std::string myresource = resources_path + "/foo/some.file"; } What if compiler merge them? (Just a general note, not related to how you want to implement resources trick) > const char* my_builddir_flag = "$$$$_I_M_NOT_INSTALLED_$$$$"; > > ... > > if (*my_builddir_flag) > > { > > ... code when not installed > > } > > else > > { > > ... code for the installed version > > } > > Just search for that string in the executable and replace the first > byte with a '\0'. > Still can violates logic. What if I want to print string to resources in next format: 1. "-" x size of path to resources (compiler can figure out it at compile time!) 2. path to resources 3. "-" x size of path to resources If you pass "/usr/local" output will be (nice): -------------- /usr/local -------------- If you pass "/home/username", output will be (nice): ------------------------ /home/username ------------------------ If you pass "$$$$_I_M_NOT_INSTALLED_$$$$" then change string to "/usr/local" after install (ugly, not what I expect!): --------------------------- /usr/local --------------------------- > Not sure there is a simple tool to do that, but writing one shouldn't > be hard. > sed? :) > Maybe it would even be accepted as an option into cmake. > Note that even if you solve all the issues above and make peace with violation logic you still will not able to create relocatable package. And just to be clear by relocation I mean packing application to *.tar.gz archive so user can install it just by doing "tar xf" to any place, like CMake do: https://cmake.org/download/ Out of curiosity can somebody show me cross-platform application (Windows, Linux, OSX) that expect resources in hard-coded location? Cheers, Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Wed Dec 2 00:34:11 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 2 Dec 2015 12:34:11 +0700 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <565E814E.9050402@yahoo.com> References: <20151130021049.GH99499@hades.panopticon> <1469290.AThC99h1Gj@tuxedo.neundorf.net> <565CE71F.9070707@yahoo.com> <483008399.bPTQzqbrGB@tuxedo.neundorf.net> <565E814E.9050402@yahoo.com> Message-ID: <565E82D3.1040807@yahoo.com> On 02-Dec-15 12:27, Ruslan Baratov via CMake wrote: > > If you pass "/usr/local" output will be (nice): > > -------------- > /usr/local > -------------- > > If you pass "/home/username", output will be (nice): > > ------------------------ > /home/username > ------------------------ > > If you pass "$$$$_I_M_NOT_INSTALLED_$$$$" then change string to > "/usr/local" after install (ugly, not what I expect!): > > --------------------------- > /usr/local > --------------------------- > Sorry, for bad formatting. Use this link to see what I mean: * https://gist.githubusercontent.com/ruslo/f6b143ff53cd3e8a2f91/raw/724dba7cf90cd425a5129e3dca0340e9066d6922/gistfile1.txt Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloydkl.tech at gmail.com Wed Dec 2 08:07:13 2015 From: lloydkl.tech at gmail.com (Lloyd) Date: Wed, 2 Dec 2015 18:37:13 +0530 Subject: [CMake] CPack-NSIS Start menu item not created Message-ID: Hi, Hi I am using CMake for building and packing on Windows. I have a root cmake file and the subfolders contains executable and other modules. I am writing the packing code in the root cmake file and executable contained in a subfolder. My executable name is myexec, and I want to create start menu item and desktop icon for this exe. For this I have used set(CPACK_PACKAGE_EXECUTABLES myexec;"My Exec" ${CPACK_PACKAGE_EXECUTABLES}) set(CPACK_CREATE_DESKTOP_LINKS "My Exec" ${CPACK_CREATE_DESKTOP_LINKS}) But it is not creating start menu item or the desktop shortcut. What could be the reason? I am using NSIS. I have a custom NSIS template. Is this the reason for it not to work? Thanks, Lloyd -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Wed Dec 2 14:18:26 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 2 Dec 2015 13:18:26 -0600 Subject: [CMake] How to generate for Ninja + MSVC? Message-ID: Is there a way to generate for Ninja using MSVC toolchain? If so, how do I do that? Do I need a toolchain file? From nilsgladitz at gmail.com Wed Dec 2 14:29:56 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 2 Dec 2015 20:29:56 +0100 Subject: [CMake] How to generate for Ninja + MSVC? In-Reply-To: References: Message-ID: <565F46B4.4060105@gmail.com> On 02.12.2015 20:18, Robert Dailey wrote: > Is there a way to generate for Ninja using MSVC toolchain? If so, how > do I do that? Do I need a toolchain file? You can select the Ninja generator (e.g. cmake -G Ninja) while running cmake from the desired Visual Studio command line environment. Nils From rcdailey.lists at gmail.com Wed Dec 2 14:37:26 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 2 Dec 2015 13:37:26 -0600 Subject: [CMake] How to generate for Ninja + MSVC? In-Reply-To: <565F46B4.4060105@gmail.com> References: <565F46B4.4060105@gmail.com> Message-ID: On Wed, Dec 2, 2015 at 1:29 PM, Nils Gladitz wrote: > On 02.12.2015 20:18, Robert Dailey wrote: >> >> Is there a way to generate for Ninja using MSVC toolchain? If so, how >> do I do that? Do I need a toolchain file? > > > You can select the Ninja generator (e.g. cmake -G Ninja) while running cmake > from the desired Visual Studio command line environment. This doesn't work unfortunately; it still finds GNU 4.8.3 compiler somehow. From rcdailey.lists at gmail.com Wed Dec 2 14:39:48 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 2 Dec 2015 13:39:48 -0600 Subject: [CMake] How to generate for Ninja + MSVC? In-Reply-To: References: <565F46B4.4060105@gmail.com> Message-ID: On Wed, Dec 2, 2015 at 1:37 PM, Robert Dailey wrote: > On Wed, Dec 2, 2015 at 1:29 PM, Nils Gladitz wrote: >> On 02.12.2015 20:18, Robert Dailey wrote: >>> >>> Is there a way to generate for Ninja using MSVC toolchain? If so, how >>> do I do that? Do I need a toolchain file? >> >> >> You can select the Ninja generator (e.g. cmake -G Ninja) while running cmake >> from the desired Visual Studio command line environment. > > This doesn't work unfortunately; it still finds GNU 4.8.3 compiler somehow. For some reason Strawberry Perl installed gcc/g++ to my PATH. I removed this and it's finding MSVC 19 now. Thanks. From robert.maynard at kitware.com Wed Dec 2 14:54:43 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 2 Dec 2015 14:54:43 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.4.1 available for download Message-ID: We are pleased to announce that CMake 3.4.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.4.1 since 3.4.0: Bill Hoffman (1): Fix auto export symbols for Dlls containing /bigobj for 64bit builds. Brad King (23): Cray: Implement Fortran compiler version detection (#15845) MSVC: Fix linking with /MANIFEST:NO option Make C and C++ default dialect detection robust to advanced optimizations FindGTest: Refactor test type checks to avoid cases triggering CMP0064 Android: Restore generation of non-versioned soname (#15851) Project: Guess default standard dialect if compiler was forced (#15852) Revert "Disable shared library support when compiler links statically" (#15855) Tests: Add case for add_subdirectory inside a function Tests: Add case for unmatched cmake_policy({PUSH,POP}) Tests: Add case for package version file unmatched policy scope cmState: Skip variable scope snapshots to avoid call stack duplicates cmMakefile: Clarify purpose of method that pops a scope snapshot cmMakefile: Remove unused PolicyPushPop interfaces cmLocalGenerator: Use ScopePushPop RAII class to manage local variable scopes cmState: Enforce policy scope balancing around variable scopes cmLinkedTree: Rename 'Extend' method to 'Push' cmLinkedTree: Add Pop method cmListFileCache: Implement cmListFileBacktrace ctor/dtor out-of-line cmState: Avoid accumulating policy stack storage for short-lived scopes cmState: Avoid accumulating snapshot storage for short-lived scopes cmOrderDirectories: Factor out directory comparison cmOrderDirectories: Reduce repeat realpath() calls CMake 3.4.1 Kylie McClain (1): Include `sys/types.h` header to get `mode_t` Marek Vasut (1): Add NIOS2 CPU support Ty Smith (1): cmELF: Avoid divide by zero if there are no dynamic section entries From bill.hoffman at kitware.com Wed Dec 2 15:52:56 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 2 Dec 2015 15:52:56 -0500 Subject: [CMake] How to generate for Ninja + MSVC? In-Reply-To: References: <565F46B4.4060105@gmail.com> Message-ID: <565F5A28.3050808@kitware.com> On 12/2/2015 2:39 PM, Robert Dailey wrote: > For some reason Strawberry Perl installed gcc/g++ to my PATH. I > removed this and it's finding MSVC 19 now. Thanks. Could also set CC and CXX to cl before running CMake. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman at kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 From a.neundorf-work at gmx.net Wed Dec 2 16:34:25 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Wed, 02 Dec 2015 22:34:25 +0100 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <565E814E.9050402@yahoo.com> References: <20151130021049.GH99499@hades.panopticon> <483008399.bPTQzqbrGB@tuxedo.neundorf.net> <565E814E.9050402@yahoo.com> Message-ID: <5664739.y74KCdRPZX@tuxedo.neundorf.net> On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote: > On 02-Dec-15 05:13, Alexander Neundorf wrote: ... > > well, the RPATH entry was not designed to be patched, > > RPATH designed to be patched. And since it's a third time I'm making > this statement please provide any arguments if you don't agree. > > Here is mine (comes from wikipedia, https://en.wikipedia.org/wiki/Rpath): > > The rpath of an executable or shared library is an optional entry > in the > .dynamic section of the ELF executable or shared libraries, with > the type > DT_RPATH, called the DT_RPATH attribute. It can be stored there at > link time by > the linker. Tools such as chrpath and patchelf can create or MODIFY > the entry > later. > > Man chrpath (http://linux.die.net/man/1/chrpath): > > -r | --replace > Replace current rpath or runpath setting with the path given It doesn't matter and it is nitpicking: the RPATH entry has some size, and its content cannot simply be changed. I.e. it could be replaced with a string of the same length or a shorter one, but not a longer one. CMake works around this by extending the build RPATH artificially with ":" at the end I think, patchelf works around this by making the whole executable one page bigger if the new entry is longer. If RPATH was _designed_ to be patchable, tools could just do it, instead of having to implement workarounds for longer strings. E.g. the linker would support a command line argument how much space it should reserve for the RPATH entry, or something like that. > > any other string in an executable could be patched too: > RPATH and C++ string literals have not the same nature. E.g. on my Linux > machine RPATH string goes to ".dynstr" section and C++ literal to > ".rodata" section. > The difference is quite huge. By parsing ELF headers you can figure out > RPATH offset and be 100% sure that patching is totally correct and > doesn't affect other binary or general executable logic. RPATH is just a > hint for linker. > Changing bytes in .rodata is much trickier. E.g. how do you distinguish > two strings: > > void print_some_info() { > const char* path = "/usr/local"; // must not be changed > std::cout << "General note: user specific packages usually installed > to " << path << std::endl; > } > > void parse_resources() { > const char* resources_path = "/usr/local"; // want to change it in future > std::string myresource = resources_path + "/foo/some.file"; > } > > What if compiler merge them? By using a very special string which is very unlikely to be used by something else, like e.g. "$$$_CMAKE_I_AM_NOT_INSTALLED_$$$". Maybe it could even be put into a custom ELF section, and then tools could just look at that section (... but then it's ELF-only). I would actually (despite it being hacky) trust the uniqueness of a string like the one above. Probably the string could be made even more unique by embedding the target name or something using cmake functionality. > (Just a general note, not related to how you want to implement resources > trick) > > > const char* my_builddir_flag = "$$$$_I_M_NOT_INSTALLED_$$$$"; > > > > ... > > > > if (*my_builddir_flag) > > > > { > > > > ... code when not installed > > > > } > > > > else > > > > { > > > > ... code for the installed version > > > > } > > > > Just search for that string in the executable and replace the first > > byte with a '\0'. > > Still can violates logic. What if I want to print string to resources in > next format: > 1. "-" x size of path to resources (compiler can figure out it at > compile time!) > 2. path to resources > 3. "-" x size of path to resources > > If you pass "/usr/local" output will be (nice): > > -------------- > /usr/local > -------------- > > If you pass "/home/username", output will be (nice): > > ------------------------ > /home/username > ------------------------ > > If you pass "$$$$_I_M_NOT_INSTALLED_$$$$" then change string to > "/usr/local" after install (ugly, not what I expect!): > > --------------------------- > /usr/local > --------------------------- Sorry, I don't understand. The idea above was only for solving the question "am I installed ?" yes/no, not "where am I installed ?". > > Not sure there is a simple tool to do that, but writing one shouldn't > > be hard. > > sed? :) I have never used sed on binary files. Does that work ? Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Wed Dec 2 16:59:19 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Wed, 2 Dec 2015 21:59:19 +0000 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <20151130021049.GH99499@hades.panopticon> References: <20151130021049.GH99499@hades.panopticon> Message-ID: <565F69B7.1020606@codelibre.net> On 30/11/2015 02:10, Dmitry Marakasov wrote: > Hi! > > This question bugs me for a long time so I though maybe someone has > a solution. I have a project which includes an application and some > data for it. An application needs to know path to its data files, so > I pass it via compiler definition: ADD_DEFINITIONS(-DDATADIR="...") > > The problem is that this path is different based on whether I want to > run the application from build directory: > > ADD_DEFINITIONS(-DDATADIR="${PROJECT_SOURCE_DIR}/data") > > or want to install it systemwide: > > ADD_DEFINITIONS(-DDATADIR="${CMAKE_INSTALL_PREFIX}/share/myapp") > > I want my project to both run from build directory and to be > installable systemwide, without the need to rebuild or specify extra > options. > > Any ideas? I don't claim this is a universal solution, but it works for me. It's also likely to be further improved--this is the first functional implementation. https://github.com/openmicroscopy/bioformats/blob/dev_5_1/cpp/lib/ome/common/module.cpp While you can configure and use hardcoded install paths, it will also optionally introspect itself at runtime and compute the install paths dynamically. This means you can have a relocatable installation and it will discover this on the fly. Lastly, you can overrride each path component with an environment variable. This is used to run inside the install tree where the path layout doesn't match the installed layout. It's also useful for testing or overriding things after installation, if needed, or overriding the autodetection on platforms where autodetection doesn't work. This approach requires this source file to be in a shared library (Linux/FreeBSD/MacOS X - using dlopen(3)/dladdr(3)) or in a DLL (Windows - uses GetModuleHandleExW()/GetModuleFileNameW()). It would also work in an executable compiled with -rdynamic with suitable adjustment for the install path computation. Other platforms could be added, but this covers all my needs at the present. Basically we get the path to the .so/.dylib/.dll, then remove the library runtime path to get the installation root, then add on any relative path we need, e.g. the datadir or anything else. This works for system installations or relocatable installs anywhere. This uses the CMake GNUInstallDirs module variables via a generated header to store all the paths. Regards, Roger From iosif.neitzke+cmake at gmail.com Wed Dec 2 20:22:11 2015 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Wed, 2 Dec 2015 19:22:11 -0600 Subject: [CMake] How to generate for Ninja + MSVC? In-Reply-To: <565F5A28.3050808@kitware.com> References: <565F46B4.4060105@gmail.com> <565F5A28.3050808@kitware.com> Message-ID: Isn't this what Generator Toolset selection is for? ex. cmake -G Ninja -T v140 http://cmake.blogspot.com/2013/05/cmake-2811-available-for-download.html From ruslan_baratov at yahoo.com Wed Dec 2 21:27:29 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 3 Dec 2015 09:27:29 +0700 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <5664739.y74KCdRPZX@tuxedo.neundorf.net> References: <20151130021049.GH99499@hades.panopticon> <483008399.bPTQzqbrGB@tuxedo.neundorf.net> <565E814E.9050402@yahoo.com> <5664739.y74KCdRPZX@tuxedo.neundorf.net> Message-ID: <565FA891.9030808@yahoo.com> On 03-Dec-15 04:34, Alexander Neundorf wrote: > > On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote: > > > On 02-Dec-15 05:13, Alexander Neundorf wrote: > > ... > > > > well, the RPATH entry was not designed to be patched, > > > > > > RPATH designed to be patched. And since it's a third time I'm making > > > this statement please provide any arguments if you don't agree. > > > > > > Here is mine (comes from wikipedia, > https://en.wikipedia.org/wiki/Rpath): > > > > > > The rpath of an executable or shared library is an optional entry > > > in the > > > .dynamic section of the ELF executable or shared libraries, with > > > the type > > > DT_RPATH, called the DT_RPATH attribute. It can be stored there at > > > link time by > > > the linker. Tools such as chrpath and patchelf can create or MODIFY > > > the entry > > > later. > > > > > > Man chrpath (http://linux.die.net/man/1/chrpath): > > > > > > -r | --replace > > > Replace current rpath or runpath setting with the path given > > It doesn't matter and it is nitpicking: the RPATH entry has some size, > and its content cannot simply be changed. > Still see no arguments, it's just your personal opinion. > I.e. it could be replaced with a string of the same length or a > shorter one, but not a longer one. > > CMake works around this by extending the build RPATH artificially with > ":" at the end I think, patchelf works around this by making the whole > executable one page bigger if the new entry is longer. > Just an implementation notes, doesn't change the fact that it can be done and it's designed to be modifiable. > If RPATH was _designed_ to be patchable, tools could just do it, > instead of having to implement workarounds for longer strings. E.g. > the linker would support a command line argument how much space it > should reserve for the RPATH entry, or something like that. > I think it's not possible. As far as I know there is no limitation for path size on Linux for example. Hence it's not possible to predict what size for path to library user want to use by setting RPATH. > > > any other string in an executable could be patched too: > > > RPATH and C++ string literals have not the same nature. E.g. on my Linux > > > machine RPATH string goes to ".dynstr" section and C++ literal to > > > ".rodata" section. > > > The difference is quite huge. By parsing ELF headers you can figure out > > > RPATH offset and be 100% sure that patching is totally correct and > > > doesn't affect other binary or general executable logic. RPATH is just a > > > hint for linker. > > > Changing bytes in .rodata is much trickier. E.g. how do you distinguish > > > two strings: > > > > > > void print_some_info() { > > > const char* path = "/usr/local"; // must not be changed > > > std::cout << "General note: user specific packages usually installed > > > to " << path << std::endl; > > > } > > > > > > void parse_resources() { > > > const char* resources_path = "/usr/local"; // want to change it in > future > > > std::string myresource = resources_path + "/foo/some.file"; > > > } > > > > > > What if compiler merge them? > > By using a very special string which is very unlikely to be used by > something else, like e.g. "$$$_CMAKE_I_AM_NOT_INSTALLED_$$$". > Just like I said it was a general note to show that C++ literal strings is not the same as RPATH entry and can't be changed correctly/easily after code already compiled. > Maybe it could even be put into a custom ELF section, and then tools > could just look at that section (... but then it's ELF-only). > > I would actually (despite it being hacky) trust the uniqueness of a > string like the one above. > > Probably the string could be made even more unique by embedding the > target name or something using cmake functionality. > > > (Just a general note, not related to how you want to implement resources > > > trick) > ... > > > > > > const char* my_builddir_flag = "$$$$_I_M_NOT_INSTALLED_$$$$"; > > > > > > > > ... > > > > > > > > if (*my_builddir_flag) > > > > > > > > { > > > > > > > > ... code when not installed > > > > > > > > } > > > > > > > > else > > > > > > > > { > > > > > > > > ... code for the installed version > > > > > > > > } > > > > > > > > Just search for that string in the executable and replace the first > > > > byte with a '\0'. > > > > > > Still can violates logic. What if I want to print string to resources in > > > next format: > > > 1. "-" x size of path to resources (compiler can figure out it at > > > compile time!) > > > 2. path to resources > > > 3. "-" x size of path to resources > > > > > > If you pass "/usr/local" output will be (nice): > > > > > > -------------- > > > /usr/local > > > -------------- > > > > > > If you pass "/home/username", output will be (nice): > > > > > > ------------------------ > > > /home/username > > > ------------------------ > > > > > > If you pass "$$$$_I_M_NOT_INSTALLED_$$$$" then change string to > > > "/usr/local" after install (ugly, not what I expect!): > > > > > > --------------------------- > > > /usr/local > > > --------------------------- > > Sorry, I don't understand. > > The idea above was only for solving the question "am I installed ?" > yes/no, not "where am I installed ?". > Then I don't understand how it's planned to be used. I thought that in build directory you changing "$$$$_I_M_NOT_INSTALLED_$$$$" to "/path/to/build/directory" so resources can be found there, and on install you change it to "/path/to/install/directory". So my guess is not correct? > > > Not sure there is a simple tool to do that, but writing one shouldn't > > > > be hard. > > > > > > sed? :) > > I have never used sed on binary files. Does that work ? > Yes, why not. > cat bar.cpp #include int main() { std::cout << "Bar say: " << "11111abc22222" << std::endl; } > g++ -O3 bar.cpp -o bar > ./bar Bar say: 11111abc22222 > sed -i 's,11111abc22222,11111XYZ22222,' ./bar > ./bar Bar say: 11111XYZ22222 Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Wed Dec 2 22:09:30 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 2 Dec 2015 22:09:30 -0500 Subject: [CMake] How to generate for Ninja + MSVC? In-Reply-To: References: <565F46B4.4060105@gmail.com> <565F5A28.3050808@kitware.com> Message-ID: <565FB26A.90107@kitware.com> On 12/2/2015 8:22 PM, iosif neitzke wrote: > Isn't this what Generator Toolset selection is for? > > ex. cmake -G Ninja -T v140 > > http://cmake.blogspot.com/2013/05/cmake-2811-available-for-download.html No, that is for telling the VS IDE which tool set to use. It has no effect on the Ninja generator. Like makefiles the ninja generator assumes it is running in an environment that is setup to run a compiler from the command line. If there is more than one compiler it picks one. If you have more than one compiler you can force it to pick one over the other with CC and CXX variables. The IDE has its own environment for the compiler and some IDEs support more than one tool chain and the -T is how you tell it to use something other than its default. -Bill From iosif.neitzke+cmake at gmail.com Wed Dec 2 22:39:05 2015 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Wed, 2 Dec 2015 21:39:05 -0600 Subject: [CMake] How to generate for Ninja + MSVC? In-Reply-To: <565FB26A.90107@kitware.com> References: <565F46B4.4060105@gmail.com> <565F5A28.3050808@kitware.com> <565FB26A.90107@kitware.com> Message-ID: Ah, okay, thanks. From cmake-gui the solution equivalent would be selecting the Ninja generator but specifying native compilers (cl.exe for this example) instead of using the default native compilers? From lloydkl.tech at gmail.com Thu Dec 3 01:32:03 2015 From: lloydkl.tech at gmail.com (Lloyd) Date: Thu, 3 Dec 2015 12:02:03 +0530 Subject: [CMake] generator expression for set_target_properties Message-ID: Hi, We have a cmake file for Qt project. We want to hide the console from release build. For that we are using ADD_EXECUTABLE(myexec ${MYEXEC_SRC} ) SET_TARGET_PROPERTIES(myexec PROPERTIES WIN32_EXECUTABLE true) Is it possible for me to set this property only for the release build? I am using cmake 2.8, Windows 7, VS 2013 Thanks, Lloyd -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Thu Dec 3 02:45:02 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Thu, 3 Dec 2015 08:45:02 +0100 Subject: [CMake] generator expression for set_target_properties In-Reply-To: References: Message-ID: Hi Lloyd, You mean like: if( ${CMAKE_BUILD_TYPE} STREQUAL "Release" ) set_target_properties( myexec PROPERTIES WIN32_EXECUTABLE TRUE ) endif() ? Or would you like the build configuration to change in this respect when you change the build type in the IDE? This latter may not be possible to do. But others may very well correct me. Cheers, Attila > On 03 Dec 2015, at 07:32, Lloyd wrote: > > Hi, > > We have a cmake file for Qt project. We want to hide the console from release build. For that we are using > > ADD_EXECUTABLE(myexec ${MYEXEC_SRC} ) > SET_TARGET_PROPERTIES(myexec PROPERTIES WIN32_EXECUTABLE true) > > Is it possible for me to set this property only for the release build? > > I am using cmake 2.8, Windows 7, VS 2013 > > Thanks, > Lloyd > -- > > 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 From marc.chevrier at sap.com Thu Dec 3 02:53:39 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 3 Dec 2015 07:53:39 +0000 Subject: [CMake] How to generate for Ninja + MSVC? In-Reply-To: References: <565F46B4.4060105@gmail.com> Message-ID: <654FC381-19D2-4A2A-9ACF-AF85A32E7CA2@sap.com> Alternate solution is to define following environment variables: * CC=cl.exe * CXX=cl.exe In this case, CMake will search these compilers rather than the standard choices (starting with c++ and g++ for C++ language). And you don?t have any longer constraints about your environment. Marc On 02/12/15 20:39, "CMake on behalf of Robert Dailey" wrote: >On Wed, Dec 2, 2015 at 1:37 PM, Robert Dailey wrote: >> On Wed, Dec 2, 2015 at 1:29 PM, Nils Gladitz wrote: >>> On 02.12.2015 20:18, Robert Dailey wrote: >>>> >>>> Is there a way to generate for Ninja using MSVC toolchain? If so, how >>>> do I do that? Do I need a toolchain file? >>> >>> >>> You can select the Ninja generator (e.g. cmake -G Ninja) while running cmake >>> from the desired Visual Studio command line environment. >> >> This doesn't work unfortunately; it still finds GNU 4.8.3 compiler somehow. > >For some reason Strawberry Perl installed gcc/g++ to my PATH. I >removed this and it's finding MSVC 19 now. Thanks. >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/cmake From lloydkl.tech at gmail.com Thu Dec 3 03:51:40 2015 From: lloydkl.tech at gmail.com (Lloyd) Date: Thu, 3 Dec 2015 14:21:40 +0530 Subject: [CMake] generator expression for set_target_properties In-Reply-To: References: Message-ID: I mean the latter, changing the build type in ide On Thu, Dec 3, 2015 at 1:15 PM, Attila Krasznahorkay < attila.krasznahorkay at gmail.com> wrote: > Hi Lloyd, > > You mean like: > > if( ${CMAKE_BUILD_TYPE} STREQUAL "Release" ) > set_target_properties( myexec PROPERTIES WIN32_EXECUTABLE TRUE ) > endif() > > ? > > Or would you like the build configuration to change in this respect when > you change the build type in the IDE? This latter may not be possible to > do. But others may very well correct me. > > Cheers, > Attila > > > On 03 Dec 2015, at 07:32, Lloyd wrote: > > > > Hi, > > > > We have a cmake file for Qt project. We want to hide the console from > release build. For that we are using > > > > ADD_EXECUTABLE(myexec ${MYEXEC_SRC} ) > > SET_TARGET_PROPERTIES(myexec PROPERTIES WIN32_EXECUTABLE true) > > > > Is it possible for me to set this property only for the release build? > > > > I am using cmake 2.8, Windows 7, VS 2013 > > > > Thanks, > > Lloyd > > -- > > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.zarl-zierl at jku.at Thu Dec 3 04:59:26 2015 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Thu, 03 Dec 2015 10:59:26 +0100 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <565FA891.9030808@yahoo.com> References: <20151130021049.GH99499@hades.panopticon> <5664739.y74KCdRPZX@tuxedo.neundorf.net> <565FA891.9030808@yahoo.com> Message-ID: <1500374.P6YEo21Ouc@ersa> > > I.e. it could be replaced with a string of the same length or a > > shorter one, but not a longer one. > > > > CMake works around this by extending the build RPATH artificially with > > ":" at the end I think, patchelf works around this by making the whole > > executable one page bigger if the new entry is longer. > > Just an implementation notes, doesn't change the fact that it can be > done and it's designed to be modifiable. This is only nitpicking about a side-topic, but: Just because it can be done does not mean that it was designed for that purpose. You argument is like saying that a wrench was designed to be used as a hammer (after all, you can hit a nail with it). If one were to follow that argument, it would be very hard *not* to design something for a given purpose. > > If RPATH was _designed_ to be patchable, tools could just do it, > > instead of having to implement workarounds for longer strings. E.g. > > the linker would support a command line argument how much space it > > should reserve for the RPATH entry, or something like that. > > I think it's not possible. As far as I know there is no limitation for > path size on Linux for example. Hence it's not possible to predict what > size for path to library user want to use by setting RPATH. If RPATH were *designed* to be modifiable, it would need provisions to account for arbitrary path lengths. One possible solution (not necessarily the best, or even a good one) would be to make RPATH a fixed-length field, part of which is a pointer to the next entry, if any. Regards, Johannes From ruslan_baratov at yahoo.com Thu Dec 3 05:50:12 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 3 Dec 2015 17:50:12 +0700 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <1500374.P6YEo21Ouc@ersa> References: <20151130021049.GH99499@hades.panopticon> <5664739.y74KCdRPZX@tuxedo.neundorf.net> <565FA891.9030808@yahoo.com> <1500374.P6YEo21Ouc@ersa> Message-ID: <56601E64.8080604@yahoo.com> On 03-Dec-15 16:59, Johannes Zarl-Zierl wrote: >>> I.e. it could be replaced with a string of the same length or a >>> shorter one, but not a longer one. >>> >>> CMake works around this by extending the build RPATH artificially with >>> ":" at the end I think, patchelf works around this by making the whole >>> executable one page bigger if the new entry is longer. >> Just an implementation notes, doesn't change the fact that it can be >> done and it's designed to be modifiable. > This is only nitpicking about a side-topic, but: Just because it can be done > does not mean that it was designed for that purpose. If it succeed it doesn't break the things. And for every C++ string changing trick can be created counter-example (yes, synthetic, but anyway) that violates logic or even crash an application. At least in the form how I see it will be implemented. > You argument is like saying that a wrench was designed to be used as a hammer > (after all, you can hit a nail with it). I've never seen manual to the wrench but if one exists I doubt there is a section "how to hit a nail with wrench". But I see chrpath tool on Linux and install_name_tool on OSX. Will you be okay if I change "designed" to "can be done correctly"? Ruslo From attila.krasznahorkay at gmail.com Thu Dec 3 09:47:38 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Thu, 3 Dec 2015 15:47:38 +0100 Subject: [CMake] Adding required source files to a custom target Message-ID: <8299C749-D70C-4A2C-9E71-7201126DCF30@gmail.com> Dear All, Is it possible to add additional source files to an already existing custom target? My project needs to generate a number of "different things", which it does by setting up many custom commands. In order to trigger the generation of everything, I currently need to set up an inconvenient number of custom targets as well. Would it be possible to attach multiple custom commands to an already existing custom target? Unfortunately it's not really an option to only set up the custom target once all the custom commands are already configured, and all their outputs are already known. I guess my question is, what property of a custom target I need to append file names to? What internal property gets set with the values passed to the SOURCES argument of add_custom_target? (That I could then append additional file names to.) Cheers, Attila From nilsgladitz at gmail.com Thu Dec 3 10:00:24 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 3 Dec 2015 16:00:24 +0100 Subject: [CMake] Adding required source files to a custom target In-Reply-To: <8299C749-D70C-4A2C-9E71-7201126DCF30@gmail.com> References: <8299C749-D70C-4A2C-9E71-7201126DCF30@gmail.com> Message-ID: <56605908.5060903@gmail.com> On 12/03/2015 03:47 PM, Attila Krasznahorkay wrote: > Dear All, > > Is it possible to add additional source files to an already existing custom target? > > My project needs to generate a number of "different things", which it does by setting up many custom commands. In order to trigger the generation of everything, I currently need to set up an inconvenient number of custom targets as well. Would it be possible to attach multiple custom commands to an already existing custom target? e.g. this nonsense example seems to work: cmake_minimum_required(VERSION 3.4) add_custom_target(foo ALL COMMAND ${CMAKE_COMMAND} -E echo $ DEPENDS "$" VERBATIM ) function(add_custom_input input) set(_output "${CMAKE_CURRENT_BINARY_DIR}/${input}.out") set(_input "${CMAKE_CURRENT_SOURCE_DIR}/${input}") add_custom_command(OUTPUT ${_output} COMMAND ${CMAKE_COMMAND} -E copy ${_input} ${_output} DEPENDS ${_input} VERBATIM ) set_property(TARGET foo APPEND PROPERTY MY_INPUTS ${_output}) endfunction() file(WRITE input1) add_custom_input(input1) file(WRITE input2) add_custom_input(input2) Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Thu Dec 3 10:13:32 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Thu, 3 Dec 2015 16:13:32 +0100 Subject: [CMake] Adding required source files to a custom target In-Reply-To: <56605908.5060903@gmail.com> References: <8299C749-D70C-4A2C-9E71-7201126DCF30@gmail.com> <56605908.5060903@gmail.com> Message-ID: <3C212498-9580-4AA6-807F-11438F068AF0@gmail.com> Hi Nils, Clever. I didn't even consider specifying the SOURCES argument of the custom target with a generator expression. But it seems to work perfectly. Thanks! Attila > On 03 Dec 2015, at 16:00, Nils Gladitz wrote: > > On 12/03/2015 03:47 PM, Attila Krasznahorkay wrote: >> Dear All, >> >> Is it possible to add additional source files to an already existing custom target? >> >> My project needs to generate a number of "different things", which it does by setting up many custom commands. In order to trigger the generation of everything, I currently need to set up an inconvenient number of custom targets as well. Would it be possible to attach multiple custom commands to an already existing custom target? >> > > e.g. this nonsense example seems to work: > > cmake_minimum_required(VERSION 3.4) > > add_custom_target(foo ALL > COMMAND ${CMAKE_COMMAND} -E echo $ > DEPENDS "$" > VERBATIM > ) > > function(add_custom_input input) > set(_output "${CMAKE_CURRENT_BINARY_DIR}/${input}.out") > set(_input "${CMAKE_CURRENT_SOURCE_DIR}/${input}") > > add_custom_command(OUTPUT ${_output} > COMMAND ${CMAKE_COMMAND} -E copy ${_input} ${_output} > DEPENDS ${_input} > VERBATIM > ) > > set_property(TARGET foo APPEND PROPERTY MY_INPUTS ${_output}) > endfunction() > > file(WRITE input1) > add_custom_input(input1) > > file(WRITE input2) > add_custom_input(input2) > Nils From rcdailey.lists at gmail.com Thu Dec 3 10:28:12 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 3 Dec 2015 09:28:12 -0600 Subject: [CMake] List of debug configurations for multi-generators? Message-ID: For any arbitrary configuration in a multi-generator, I need to determine if it's configuration is optimized or not (release or debug). At the moment I thought I could do this by comparing against the list of DEBUG_CONFIGURATIONS, however this property is empty if I have not set it. I was expecting CMake to fill this in at least with "Debug" for the pre-provided configurations. Is there no way to get this information? The only other way to do this is to compare if the current configuration is "Debug", and if not, treat it as release. But this will not work if I add my own custom configurations. I need to do this because for third party libraries, I only build "Debug" and "Release" versions. "RelMinSize" and "RelWithDebInfo" both use "release" libraries. I use this logic to help build relative paths to point to the proper libs. From bill.hoffman at kitware.com Thu Dec 3 10:46:16 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 3 Dec 2015 10:46:16 -0500 Subject: [CMake] How to generate for Ninja + MSVC? In-Reply-To: References: <565F46B4.4060105@gmail.com> <565F5A28.3050808@kitware.com> <565FB26A.90107@kitware.com> Message-ID: <566063C8.6040400@kitware.com> On 12/2/2015 10:39 PM, iosif neitzke wrote: > Ah, okay, thanks. From cmake-gui the solution equivalent would be > selecting the Ninja generator but specifying native compilers (cl.exe > for this example) instead of using the default native compilers? > . Yes, that would work as well. As long as cmake-gui was run in an environment that had the compiler setup to work from the command line. -Bill From vasily at gatech.edu Thu Dec 3 11:04:10 2015 From: vasily at gatech.edu (Vasily Vladimirovich Vylkov) Date: Thu, 3 Dec 2015 08:04:10 -0800 Subject: [CMake] 3.4.1 installer overwrites Windows PATH system var Message-ID: Installing CMake on Windows (7, 64-bit) with the "add cmake to system PATH for all users" option overwrote the contents of my PATH variable, instead of appending to it. This is horrible! I don't know of any way to recover my previous PATH value. It also looks like this has been an issue in several previous versions: * https://cmake.org/Bug/view.php?id=10257 * https://cmake.org/Bug/view.php?id=12875 Shouldn't there be a regression / sanity test case for this prior to publishing a new version of the installer? From brad.king at kitware.com Thu Dec 3 11:36:11 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 3 Dec 2015 11:36:11 -0500 Subject: [CMake] 3.4.1 installer overwrites Windows PATH system var In-Reply-To: References: Message-ID: <56606F7B.4090609@kitware.com> On 12/03/2015 11:04 AM, Vasily Vladimirovich Vylkov wrote: > Installing CMake on Windows (7, 64-bit) with the "add cmake to system > PATH for all users" option overwrote the contents of my PATH variable, > instead of appending to it. This is horrible! I don't know of any > way to recover my previous PATH value. > > It also looks like this has been an issue in several previous versions: > * https://cmake.org/Bug/view.php?id=10257 > * https://cmake.org/Bug/view.php?id=12875 > > Shouldn't there be a regression / sanity test case for this prior to > publishing a new version of the installer? For every new release binary we run the installer by hand to verify that the interaction works. This doesn't happen to us. The installer is produced with NSIS. I wonder if this is a case of: http://stackoverflow.com/questions/21897103/nsis-envvarupdate-overwrites-system-path-when-path-is-too-long-is-there-a-wor How long was your PATH before? -Brad From tamas.kenez at gmail.com Thu Dec 3 13:02:48 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 3 Dec 2015 19:02:48 +0100 Subject: [CMake] 3.4.1 installer overwrites Windows PATH system var In-Reply-To: <56606F7B.4090609@kitware.com> References: <56606F7B.4090609@kitware.com> Message-ID: about recovering the path see http://superuser.com/questions/523688/deleted-path-environment-variable-how-to-restore On Thursday, December 3, 2015, Brad King wrote: > On 12/03/2015 11:04 AM, Vasily Vladimirovich Vylkov wrote: > > Installing CMake on Windows (7, 64-bit) with the "add cmake to system > > PATH for all users" option overwrote the contents of my PATH variable, > > instead of appending to it. This is horrible! I don't know of any > > way to recover my previous PATH value. > > > > It also looks like this has been an issue in several previous versions: > > * https://cmake.org/Bug/view.php?id=10257 > > * https://cmake.org/Bug/view.php?id=12875 > > > > Shouldn't there be a regression / sanity test case for this prior to > > publishing a new version of the installer? > > For every new release binary we run the installer by hand to verify > that the interaction works. This doesn't happen to us. > > The installer is produced with NSIS. I wonder if this is a case of: > > > http://stackoverflow.com/questions/21897103/nsis-envvarupdate-overwrites-system-path-when-path-is-too-long-is-there-a-wor > > How long was your PATH before? > > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Thu Dec 3 15:47:35 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Thu, 03 Dec 2015 21:47:35 +0100 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <565FA891.9030808@yahoo.com> References: <20151130021049.GH99499@hades.panopticon> <5664739.y74KCdRPZX@tuxedo.neundorf.net> <565FA891.9030808@yahoo.com> Message-ID: <14211828.dtnMx6GTBJ@tuxedo.neundorf.net> On Thursday, December 03, 2015 09:27:29 Ruslan Baratov via CMake wrote: > On 03-Dec-15 04:34, Alexander Neundorf wrote: > > On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote: > > If RPATH was _designed_ to be patchable, tools could just do it, > > instead of having to implement workarounds for longer strings. E.g. > > the linker would support a command line argument how much space it > > should reserve for the RPATH entry, or something like that. > > I think it's not possible. As far as I know there is no limitation for > path size on Linux for example. Hence it's not possible to predict what > size for path to library user want to use by setting RPATH. More nitpicking about the meaning of "designed" ;-) : CMake knows the length of the build RPATH and the length of the install RPATH. Let's say the build RPATH has a length of 100, and the install RPATH has a length of 150, it could, during linking, give the build RPATH to the linker, and also something like --rpath-size=150, and the linker would make the field for the RPATH 150 bytes big, so it could be patched easly later on. This is what I would consider the minimum support if it was "designed" to be patched. Instead cmake has to add 50 ":" at the end of the build RPATH. :-/ ... > > The idea above was only for solving the question "am I installed ?" > > yes/no, not "where am I installed ?". > > Then I don't understand how it's planned to be used. I thought that in > build directory you changing "$$$$_I_M_NOT_INSTALLED_$$$$" to > "/path/to/build/directory" so resources can be found there, and on > install you change it to "/path/to/install/directory". So my guess is > not correct? Nothing is planned, just some ideas. The idea was, during install, to set the first byte of that special string to '\0', and in the code you test whether the string is empty ( -> it has been patched, so it is installed) or not (still the original "$$$$_I_M_NOT_INSTALLED_$$$$"). With that information, the developer can then do whatever he wants. e.g. when not installed, search just in $CMAKE_BINARY_DIR (which could be configured into some other string), and if installed, search in some other way. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Thu Dec 3 18:23:09 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Fri, 4 Dec 2015 06:23:09 +0700 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <14211828.dtnMx6GTBJ@tuxedo.neundorf.net> References: <20151130021049.GH99499@hades.panopticon> <5664739.y74KCdRPZX@tuxedo.neundorf.net> <565FA891.9030808@yahoo.com> <14211828.dtnMx6GTBJ@tuxedo.neundorf.net> Message-ID: <5660CEDD.9050908@yahoo.com> On 04-Dec-15 03:47, Alexander Neundorf wrote: > > On Thursday, December 03, 2015 09:27:29 Ruslan Baratov via CMake wrote: > > > On 03-Dec-15 04:34, Alexander Neundorf wrote: > > > > On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote: > > > > If RPATH was _designed_ to be patchable, tools could just do it, > > > > instead of having to implement workarounds for longer strings. E.g. > > > > the linker would support a command line argument how much space it > > > > should reserve for the RPATH entry, or something like that. > > > > > > I think it's not possible. As far as I know there is no limitation for > > > path size on Linux for example. Hence it's not possible to predict what > > > size for path to library user want to use by setting RPATH. > > More nitpicking about the meaning of "designed" ;-) : > > CMake knows the length of the build RPATH and the length of the > install RPATH. Let's say the build RPATH has a length of 100, and the > install RPATH has a length of 150, it could, during linking, give the > build RPATH to the linker, and also something like --rpath-size=150, > and the linker would make the field for the RPATH 150 bytes big, so it > could be patched easly later on. > > This is what I would consider the minimum support if it was "designed" > to be patched. > > Instead cmake has to add 50 ":" at the end of the build RPATH. :-/ > > ... > > > > The idea above was only for solving the question "am I installed ?" > > > > yes/no, not "where am I installed ?". > > > > > > Then I don't understand how it's planned to be used. I thought that in > > > build directory you changing "$$$$_I_M_NOT_INSTALLED_$$$$" to > > > "/path/to/build/directory" so resources can be found there, and on > > > install you change it to "/path/to/install/directory". So my guess is > > > not correct? > > Nothing is planned, just some ideas. > > The idea was, during install, to set the first byte of that special > string to '\0', and in the code you test whether the string is empty ( > -> it has been patched, so it is installed) or not (still the original > "$$$$_I_M_NOT_INSTALLED_$$$$"). > > With that information, the developer can then do whatever he wants. > e.g. when not installed, search just in $CMAKE_BINARY_DIR (which could > be configured into some other string), and if installed, search in > some other way. > Will not work, just like I said compiler is smart enough to figure out if the first char in string literal is '\0' or not. Just make some testing: https://gist.github.com/ruslo/04d8993800ee78513d1c The only one possibility to implement what you want I see in creating new dynamic library (probably by CMake) with one literal: // 3rd party library API const char* path_to_install(); void parse_resources() { const char* x = path_to_install(); assert(x != 0); if (x[0] == '\0') { // OK, can't be optimized since it's an external library } else { // load resources } } So CMake should create such library in build directory and then re-create and install it with new string in install directory. Of course if you move such library it will not work :) So still doesn't make sense to me... Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasily at gatech.edu Fri Dec 4 02:12:51 2015 From: vasily at gatech.edu (Vasily Vladimirovich Vylkov) Date: Thu, 3 Dec 2015 23:12:51 -0800 Subject: [CMake] 3.4.1 installer overwrites Windows PATH system var In-Reply-To: References: <56606F7B.4090609@kitware.com> Message-ID: Thanks all -- that worked. The key: regedit.exe --> HKLM\SYSTEM\ControlSet001\Control\Environment\Path had a backup of the path var before the CMake install nuked it. > How long was your PATH before? Just my luck, it was 1028 chars long (just 4 over the threshold). > The installer is produced with NSIS. Is there a bug filed with NSIS to address this? Also, there should be a very prominent warning about this on the CMake download/install page next to the Windows installer. Extremely unpleasant from a user perspective. On Thu, Dec 3, 2015 at 10:02 AM, Tam?s Ken?z wrote: > about recovering the path see > http://superuser.com/questions/523688/deleted-path-environment-variable-how-to-restore > > On Thursday, December 3, 2015, Brad King wrote: >> >> On 12/03/2015 11:04 AM, Vasily Vladimirovich Vylkov wrote: >> > Installing CMake on Windows (7, 64-bit) with the "add cmake to system >> > PATH for all users" option overwrote the contents of my PATH variable, >> > instead of appending to it. This is horrible! I don't know of any >> > way to recover my previous PATH value. >> > >> > It also looks like this has been an issue in several previous versions: >> > * https://cmake.org/Bug/view.php?id=10257 >> > * https://cmake.org/Bug/view.php?id=12875 >> > >> > Shouldn't there be a regression / sanity test case for this prior to >> > publishing a new version of the installer? >> >> For every new release binary we run the installer by hand to verify >> that the interaction works. This doesn't happen to us. >> >> The installer is produced with NSIS. I wonder if this is a case of: >> >> >> http://stackoverflow.com/questions/21897103/nsis-envvarupdate-overwrites-system-path-when-path-is-too-long-is-there-a-wor >> >> How long was your PATH before? >> >> -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 From vasily at gatech.edu Fri Dec 4 02:13:59 2015 From: vasily at gatech.edu (Vasily Vladimirovich Vylkov) Date: Thu, 3 Dec 2015 23:13:59 -0800 Subject: [CMake] 3.4.1 installer overwrites Windows PATH system var In-Reply-To: References: <56606F7B.4090609@kitware.com> Message-ID: > For every new release binary we run the installer by hand > to verify that the interaction works. This doesn't happen to us. Do you run it on a machine with PATH set to a string >1024 chars long? From amdmi3 at amdmi3.ru Fri Dec 4 06:05:19 2015 From: amdmi3 at amdmi3.ru (Dmitry Marakasov) Date: Fri, 4 Dec 2015 14:05:19 +0300 Subject: [CMake] Best way to handle application data path for local run vs. installation In-Reply-To: <20151130115350.GI99499@hades.panopticon> References: <20151130021049.GH99499@hades.panopticon> <565C131F.6070104@yahoo.com> <20151130115350.GI99499@hades.panopticon> Message-ID: <20151204110519.GL99499@hades.panopticon> * Dmitry Marakasov (amdmi3 at hades.panopticon) wrote: > Anyway for now, I did some research and solved the problem of inplace > vs. systemwide compilation in a way that I find acceptable. > > I check for CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT to basically > know whether a user has explicitly specified CMAKE_INSTALL_PREFIX. > If user specified install prefix, I prepare for systemwide install, > otherwise I prepare for inplace run. > > https://github.com/AMDmi3/hoverboard-sdl/blob/0.4.0/CMakeLists.txt > > This doesn't support inplace and systemwide /at the same time/, but > still supports either of them cleanly, doesn't require extra actions > from user and behaves sensibly by default. Wanted to add that this doesn't really work well. When cmake is run second time, it always switches to systemwide installation because of cache. I think I'll go with adding explicit SYSTEMWIDE and STANDALONE options, former builds for systemwide installation with global paths, and latter for installation into self-contained directory with local paths (e.g. for windows/macos), and if neither is specified the project runs from the build directory. I don't see any better solution right now. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3 at amdmi3.ru ..: jabber: amdmi3 at jabber.ru http://amdmi3.ru From bruce.r.stephens at gmail.com Fri Dec 4 09:05:31 2015 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Fri, 4 Dec 2015 14:05:31 +0000 Subject: [CMake] Shared library from sources in several subdirectories Message-ID: Any suggestions on how to organise that? Presumably there are lots of examples in (for example) KDE, but I'm not familiar enough with that codebase to be able to find them easily. Currently our GNU Make build builds static libraries in the subdirectories, then those are put into a big static library and that's linked into a shared library. (The last step uses a shell script which knows how to do that for various platforms.) My first attempt uses add_library(... OBJECT ...) in the subdirectories, then add_library(... SHARED $ $) to combine them. That works, though it means repeating the same information (more or less) twice since for each add_subdirectory() there'll be a $. Also the dependent libraries need to be added in the top-level but they're triggered by the subdirectory (by the looks of it I can't use target_link_libraries() on an OBJECT library). It works, though, and didn't take me very long to do, and the result looks clean and relatively easy to follow. Any better ways to do this? (In the particular case I'm looking at, splitting the libraries and just having one per subdirectory might make sense, but not in all cases.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Dec 4 14:22:15 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 4 Dec 2015 14:22:15 -0500 Subject: [CMake] CMAKE_CXX_STANDARD does not get used in PERFORM_CMAKE_TEST In-Reply-To: <25FDF00B-885A-4BD8-BF93-32C646158B36@uiowa.edu> References: <25FDF00B-885A-4BD8-BF93-32C646158B36@uiowa.edu> Message-ID: <5661E7E7.5020400@kitware.com> On 12/04/2015 02:14 PM, Johnson, Hans J wrote: > PERFORM_CMAKE_TEST(vxl_platform_tests.cxx VCL_STATIC_CONST_INIT_FLOAT) > NOTE: THIS FAILS WHEN IT SHOULD PASS! [snip] > Should I simply add -DCMAKE_CXX_STANDARD:STRING=${CMAKE_CXX_STANDARD} > to the TRY_COMPILE? The seems too simplistic. I think that is all that is needed but have not thought this through in detail. Here is a related issue: https://cmake.org/Bug/view.php?id=15361#c37760 Eventually a similar fix will be needed for all CMake's builtin check modules. Perhaps even try_compile itself will need new options to specify the language dialect, defaulting to the CMAKE__STANDARD variable if set. -Brad From antoniodeangelis1 at gmail.com Fri Dec 4 17:44:50 2015 From: antoniodeangelis1 at gmail.com (Antonio de Angelis) Date: Fri, 4 Dec 2015 22:44:50 +0000 Subject: [CMake] Fwd: Installing on MSYS2 and Windows 10 In-Reply-To: References: Message-ID: Hello, I'm trying to build the source package for cmocka 1.0.1 ( https://cmocka.org/files/1.0/cmocka-1.0.0.tar.xz) on MSYS2 and Windows 10, but when running cmake I get: C:\cmocka\cmocka-1.0.1\build>cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release System is unknown to cmake, create: Platform/posix to use this system, please send your config file to cmake at www.cmake.org so it can be added to cmake Your CMakeCache.txt file was copied to CopyOfCMakeCache.txt. Please send that file to cmake at www.cmake.org. I've built successfully this package under MSYS2 and Windows 7 following exactly the same procedure, can you please advise how to get rid of this error? Thanks, Antonio -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbeekman at gmail.com Fri Dec 4 17:51:50 2015 From: zbeekman at gmail.com (Zaak Beekman) Date: Fri, 04 Dec 2015 22:51:50 +0000 Subject: [CMake] MPI wrappers vs FindMPI Message-ID: >From working on a Homebrew formula < https://github.com/Homebrew/homebrew/pull/46547> for OpenCoarrays < https://github.com/sourceryinstitute/opencoarrays> I'm under the impression that common practice is to use FindMPI over passing mpicc and mpif90 to cmake directly. Is this correct, and the way most people expect to build MPI packages with CMake? (i.e., using their normal compilers rather and MPI wrappers for the CC, CXX and FC variables?) What are the pros and cons of using FindMPI over passing FC=mpif90 and CC=mpicc? TIA, Zaak -------------- next part -------------- An HTML attachment was scrubbed... URL: From brlcad at mac.com Fri Dec 4 23:17:29 2015 From: brlcad at mac.com (Christopher Sean Morrison) Date: Fri, 04 Dec 2015 23:17:29 -0500 Subject: [CMake] print a message during a specific build target In-Reply-To: References: <13FCFD29-DBC8-4E1C-A5D8-0778E0ACA3C3@mac.com> Message-ID: Thanks, that worked for printing a message during our ?check? target. Makes sense for ?if (TARGET?)? to truthfully enter if that target name exists. What threw me off, I think, was having "TARGET test? not actually pass and misunderstanding the docs that this would embed logic in the generator output. I ended up adding COMMAND ${CMAKE_COMMAND} -E echo ??? lines to the add_custom_target() and that did the trick for my ?check? target. Getting similar behavior for the ?test" target seems to be impossible, though. I even tried to trick ctest by creating a test that printed a message but failed. I could create a custom target that only printed a message and ran ?false? to give an error; and I could create another cmake target that ran ctest with ?output-on-failure to see the message ? and that worked just fine for running that target via cmake. However, every which way I tried to invoke that target via add_test seemed to only produce an infinite loop during ?make test? or ctest. What I ended up doing was punting on displaying the fancy message and just added a test whose test name was a very shortened form of the message intended (via add_test(NAME ?NOTE\\ important\\ message\\ here??). Made the test still run the ?false? message target too (via COMMAND cmake ?), so it ends up in the testing log during make test and conveniently pauses for 3-4 seconds on just that one test (apparently the overhead on our build system to simply invoke cmake). In all, it?s working, but hopefully this info might be useful to any archive searcher hitting a similar problem? at least until http://public.kitware.com/Bug/view.php?id=8438 is addressed... Cheers! Sean On Nov 24, 2015, at 7:44 AM, Parag Chandra wrote: > The if() statements are executed when CMake runs, because you?re basically adding logic to the ?meta-build? process that generates your build system; not the build system itself. Maybe you can use ?add_custom_target? to create targets which do nothing but print the desired message, and then use ?add_dependencies? to tie these targets back to your original ones? So something like: > > add_custom_target(?test_print? ?) > add_dependencies(test test_print) > > > > > Parag Chandra > Senior Software Engineer, Mobile Team > Mobile: +1.919.824.1410 > > > > Ionic Security Inc. > 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 > > > > > > > > > > > > > > On 11/24/15, 12:04 AM, "CMake on behalf of Christopher Sean Morrison" wrote: > >> >> Hi, >> >> I?m trying to print a message for a particular build target and am a bit stuck. I found that the IF statement has a TARGET keyword that should truthfully match for a particular build target, but it doesn?t seem to be working at least the way I?m trying to use it and would expect it to work. Snippet in question in a top-level CMakeLists.txt file looks like this: >> >> if (TARGET check) >> message(?special note about CHECK target??) >> elseif (TARGET test) >> message(?different note about TEST target??) >> endif (TARGET check) >> >> Now what happens is that the CHECK message is printed ? during cmake(!). What I?m trying to achieve is only have those messages printed during? ?make check? and ?make test?, etc. Ideally, I want to be able to inject a message before any target actions are taken and possibly after. >> >> I see in the docs that I can set COMMENT during add_custom_target(check ?) and that should print my message before any target actions, but how can I get a similar message printed during ?test? or ?all? or some other implicit target? Is there a better or more general way? Thanks for your assistance. >> >> Cheers! >> Sean >> >> -- >> >> 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 From nilsgladitz at gmail.com Mon Dec 7 04:08:40 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 7 Dec 2015 10:08:40 +0100 Subject: [CMake] Shared library from sources in several subdirectories In-Reply-To: References: Message-ID: <56654C98.1070708@gmail.com> On 12/04/2015 03:05 PM, Bruce Stephens wrote: > Any suggestions on how to organise that? Presumably there are > lots of examples in (for example) KDE, but I'm not familiar enough > with that codebase to be able to find them easily. > > Currently our GNU Make build builds static libraries in the > subdirectories, > then those are put into a big static library and that's linked into a > shared > library. (The last step uses a shell script which knows how to do that for > various platforms.) > > My first attempt uses add_library(... OBJECT ...) in the subdirectories, > then add_library(... SHARED $ $) > to combine them. > > That works, though it means repeating the same information (more or > less) twice > since for each add_subdirectory() there'll be a $. Also > the dependent libraries need to be added in the top-level but they're > triggered > by the subdirectory (by the looks of it I can't use > target_link_libraries() on an OBJECT > library). It works, though, and didn't take me very long to do, and > the result looks > clean and relatively easy to follow. > > Any better ways to do this? (In the particular case I'm looking at, > splitting the > libraries and just having one per subdirectory might make sense, but > not in all > cases.) I would avoid creating these single use, per directory libraries entirely. A single target can build sources located in any number of directories. If you want to subdivide the source file listing of that one target for organizational purposes you can do so with e.g. include(), target_sources() and/or list variables. Nils From attila.krasznahorkay at gmail.com Mon Dec 7 04:57:15 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Mon, 7 Dec 2015 10:57:15 +0100 Subject: [CMake] Control the build target's external dependencies Message-ID: Dear All, I'm struggling since a few days with the following issue. Our development setup is such that we build large software projects in a nightly build system, which puts these projects onto a network drive. The developers then set up these nightly projects, and build their own code against them. (They can even rebuild parts that are in the nightly itself, that also required some clever tricks in CMake...) This kind of works by now. But the system is incredibly slow. When I try to build some source code against installed releases on the network file system, >90% of the time is seemingly just spent in dependency calculation/evaluation. To demonstrate the extent of the issue, here is an example of the files generated by CMake for one of our "packages". (Sorry, they are pretty large. But that's the point...) Mind you, this is a very simple package that just picks up Boost from the network disk. For high level packages the depend.make file can be up to 2 MB in size. :-( -------------- next part -------------- A non-text attachment was scrubbed... Name: depend.make Type: application/octet-stream Size: 127800 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: flags.make Type: application/octet-stream Size: 1314 bytes Desc: not available URL: -------------- next part -------------- As you can see, I tried to convince CMake to treat the include directories coming from the network file system (AFS) as system include directories. But still, the dependencies put into depend.make list every single header file that the build targets have any relationship with. As it turns out, AFS is pretty slow for such operations. Checking the change times of thousands of files. At least this is what I contribute the ridiculously slow build times to. (Not for this example. This package still builds reasonably. It's the higher level packages that break down completely. I just couldn't attach example files from those due to the size limitations of this mailing list.) So... How could one convince CMake to exclude some directories from the dependency setup? The files that are part of the nightly builds should definitely not need to be checked for changes every time I run a build. As you can see, depend.make even list all the Boost headers at the moment. :-( What I tried so far was to specify the include directories using SYSTEM in target_include_directories. But it didn't make any difference whether I used SYSTEM or not. Is there some other mechanism that I could use here? Cheers, Attila From mohammedrashadkm at gmail.com Mon Dec 7 05:15:59 2015 From: mohammedrashadkm at gmail.com (Rashad Kanavath) Date: Mon, 7 Dec 2015 11:15:59 +0100 Subject: [CMake] [CDash] CTEST_CUSTOM_WARNING_EXECPTION In-Reply-To: References: Message-ID: Hello David, It didn't worked. I end up passing -wno-cpp to the cmake flags to finally get over this issue. I don't get how CTEST_CUSTOM_WARNING_EXCEPTION works. How does this compare the regex when it gets a warning? How do I disable all warnings from a directory? eg: /path/to/build/Superbuild/TIFF/build On Fri, Nov 6, 2015 at 1:09 PM, Rashad M wrote: > > So using *.#warning.*deprecated.* should work? > > I will test this and let you know. > > On Thu, Nov 5, 2015 at 4:49 PM, David Cole wrote: > >> Looks to me like it might be (I'm hopeful) working at ignoring the >> line which matches the expression ".*vcl_deprecated_header.h.*" ... >> >> But then, the following line is: >> >> # warning "deprecated" >> >> Since that line does not match any of your expressions, maybe that's >> the one triggering this warning slipping through as unignored? >> >> >> HTH, >> D >> >> >> >> >> On Thu, Nov 5, 2015 at 10:01 AM, Rashad M >> wrote: >> > yes. >> > >> > On Thu, Nov 5, 2015 at 1:46 PM, David Cole wrote: >> >> >> >> Does your ctest -S script call ctest_read_custom_files >> >> https://cmake.org/cmake/help/v3.4/command/ctest_read_custom_files.html >> after >> >> ctest_configure? >> >> >> >> >> >> On Thursday, November 5, 2015, Rashad M >> >> wrote: >> >>> >> >>> Hello all, >> >>> >> >>> I have CTestCustom.cmake.in file in source tree with the following >> >>> contents >> >>> >> >>> >> >>> >> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in >> >>> >> >>> during ctest build CTestCustom.cmake file is getting generated inside >> the >> >>> build tree. >> >>> >> >>> But however the warnings are not filtered out on the dashboard. For >> >>> instance, see the dashboard submission >> >>> >> http://dash.orfeo-toolbox.org/viewBuildError.php?type=1&buildid=206112 >> >>> >> >>> and see the exception for vcl_deprecated_header >> >>> >> >>> >> >>> >> https://git.orfeo-toolbox.org/otb.git/blob/refs/heads/develop:/CMake/CTestCustom.cmake.in#l69 >> >>> >> >>> The warning appears on dashobard anyway. Can someone point me in the >> >>> right direction. ? >> >>> >> >>> Thanks in advance. >> >>> >> >>> >> >>> CMake Version: >> >>> 2.8.12.2 >> >>> >> >>> CDash Version: >> >>> 2.2.3 >> >>> >> >>> uname -a >> >>> Linux ubuntu >> >>> >> >>> 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64 >> >>> x86_64 x86_64 GNU/Linux >> >>> -- >> >>> Regards, >> >>> Rashad >> > >> > >> > >> > >> > -- >> > Regards, >> > Rashad >> > > > > -- > Regards, > Rashad > -- Regards, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Mon Dec 7 05:55:42 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Mon, 7 Dec 2015 11:55:42 +0100 Subject: [CMake] Control the build target's external dependencies In-Reply-To: References: Message-ID: <4736E3F0-35A1-4374-A95A-D704711D0BFE@gmail.com> Dear All, Maybe I should've google-d better. So now I started experimenting with include_regular_expression(...). https://cmake.org/cmake/help/v3.0/command/include_regular_expression.html But now I'm having a problem with expressing my intent with a regular expression. In principle I'd like to only take headers from the source directory into account in the dependency calculation. So I first tried this: include_regular_expression( "^${CMAKE_SOURCE_DIR}.*$" ) But this was way too restrictive. As headers from the source directory normally show up with relative paths in the depend.make files. So okay, I tried this next: include_regular_expression( "^(${CMAKE_SOURCE_DIR}.*)|([^/]+.*)$" ) (To try to make it only accept paths that are either in CMAKE_SOURCE_DIR, or are not starting with "/".) But this didn't work either. I'm back to having all the boost files in my dependency list. Any suggestion for how I could express my intent in a regular expression that CMake would understand? Cheers, Attila > On 07 Dec 2015, at 10:57, Attila Krasznahorkay wrote: > > Dear All, > > I'm struggling since a few days with the following issue. > > Our development setup is such that we build large software projects in a nightly build system, which puts these projects onto a network drive. The developers then set up these nightly projects, and build their own code against them. (They can even rebuild parts that are in the nightly itself, that also required some clever tricks in CMake...) > > This kind of works by now. But the system is incredibly slow. When I try to build some source code against installed releases on the network file system, >90% of the time is seemingly just spent in dependency calculation/evaluation. To demonstrate the extent of the issue, here is an example of the files generated by CMake for one of our "packages". (Sorry, they are pretty large. But that's the point...) Mind you, this is a very simple package that just picks up Boost from the network disk. For high level packages the depend.make file can be up to 2 MB in size. :-( > > > > As you can see, I tried to convince CMake to treat the include directories coming from the network file system (AFS) as system include directories. But still, the dependencies put into depend.make list every single header file that the build targets have any relationship with. > > As it turns out, AFS is pretty slow for such operations. Checking the change times of thousands of files. At least this is what I contribute the ridiculously slow build times to. (Not for this example. This package still builds reasonably. It's the higher level packages that break down completely. I just couldn't attach example files from those due to the size limitations of this mailing list.) > > So... How could one convince CMake to exclude some directories from the dependency setup? The files that are part of the nightly builds should definitely not need to be checked for changes every time I run a build. As you can see, depend.make even list all the Boost headers at the moment. :-( > > What I tried so far was to specify the include directories using SYSTEM in target_include_directories. But it didn't make any difference whether I used SYSTEM or not. > > Is there some other mechanism that I could use here? > > Cheers, > Attila From brad.king at kitware.com Mon Dec 7 08:56:14 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 7 Dec 2015 08:56:14 -0500 Subject: [CMake] MPI wrappers vs FindMPI In-Reply-To: References: Message-ID: <56658FFE.6050606@kitware.com> On 12/04/2015 05:51 PM, Zaak Beekman wrote: > What are the pros and cons of using FindMPI over passing FC=mpif90 and CC=mpicc? It shouldn't matter much if all the code in the project is meant to be build for MPI. Using plain FindMPI with the CC/CXX/FC set to the system compilers is cleaner for building only a subset of targets for MPI. FindMPI will look for the MPI compilers separately in order to ask them for the proper flags to tell the system compiler how to use MPI, and then project CMake code can take responsibility for applying that information to the desired subset of its targets. Using CC=mpicc, FindMPI will recognize that the C compiler is already a MPI compiler and not bother to look for a separate one to query the settings (and similarly for C++ and Fortran). -Brad From brad.king at kitware.com Mon Dec 7 09:06:31 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 7 Dec 2015 09:06:31 -0500 Subject: [CMake] 3.4.1 installer overwrites Windows PATH system var In-Reply-To: References: <56606F7B.4090609@kitware.com> Message-ID: <56659267.3030208@kitware.com> On 12/04/2015 02:12 AM, Vasily Vladimirovich Vylkov wrote: > Thanks all -- that worked. The key: > regedit.exe --> HKLM\SYSTEM\ControlSet001\Control\Environment\Path > > had a backup of the path var before the CMake install nuked it. > >> How long was your PATH before? > > Just my luck, it was 1028 chars long (just 4 over the threshold). Thanks. That is consistent with my hypothesis. I'm glad you got it restored (thanks Tam?s!). > Extremely unpleasant from a user perspective. Yes. We will look at addressing this for the 3.5 release now that we understand the cause. On 12/04/2015 02:13 AM, Vasily Vladimirovich Vylkov wrote: > > Do you run it on a machine with PATH set to a string >1024 chars long? No, so that is why we haven't noticed it. Thanks, -Brad From attila.krasznahorkay at gmail.com Mon Dec 7 09:39:40 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Mon, 7 Dec 2015 15:39:40 +0100 Subject: [CMake] Making CMake *not* use -isystem at all Message-ID: Dear All, I'm still debugging the performance problems of our build. But now I bumped into another surprising thing. Our "highest level" packages can depend on a *lot* of low level packages. The one I'm testing now depends on more than 180 of them. This generates >180 -isystem flags for the compilation lines. But I found a very surprising thing. If I replace all of these -isystem flags with -I ones by simply modifying the flags.cmake files that CMake generated for me, the build time of my code is cut to less than half of what it is when using -isystem. So... How do I tell CMake to forget about using -isystem all together, and take all my include directories with -I? Not using SYSTEM in target_include_directories and include_directories doesn't seem to make a difference. I still get all my out-of-source directories with -isystem. I even tried setting CMAKE_INCLUDE_SYSTEM_FLAG_CXX and CMAKE_INCLUDE_SYSTEM_FLAG_C to "-I " forcefully. But this didn't help either. Neither did explicitly unsetting these variables. How could it be done then? How could I force CMake to always use -I for the directories that I give to either include_directories or target_include_directories? Cheers, Attila From zbeekman at gmail.com Mon Dec 7 09:40:59 2015 From: zbeekman at gmail.com (Zaak Beekman) Date: Mon, 07 Dec 2015 14:40:59 +0000 Subject: [CMake] MPI wrappers vs FindMPI In-Reply-To: <56658FFE.6050606@kitware.com> References: <56658FFE.6050606@kitware.com> Message-ID: Thanks for the insight Brad. Another advantage may be that the FindMPI module knows about what `mpirun` or `mpiexec` is called, as well as some common flags, like number of ranks to execute. Since OpenCoarrays writes an MPI compiler wrapper script and a script to run the executable, `caf` and `cafrun`, using FindMPI could also help reduce the overhead of knowing about different MPI implementations and their peculiarities; this task would effectively be delighted to FindMPI... Damian, I'll poke around in the CMake code and we can discuss this on Friday. Thanks again, -Zaak On Mon, Dec 7, 2015 at 8:56 AM Brad King wrote: > On 12/04/2015 05:51 PM, Zaak Beekman wrote: > > What are the pros and cons of using FindMPI over passing FC=mpif90 and > CC=mpicc? > > It shouldn't matter much if all the code in the project is meant > to be build for MPI. Using plain FindMPI with the CC/CXX/FC set > to the system compilers is cleaner for building only a subset of > targets for MPI. FindMPI will look for the MPI compilers separately > in order to ask them for the proper flags to tell the system compiler > how to use MPI, and then project CMake code can take responsibility > for applying that information to the desired subset of its targets. > Using CC=mpicc, FindMPI will recognize that the C compiler is already > a MPI compiler and not bother to look for a separate one to query > the settings (and similarly for C++ and Fortran). > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Mon Dec 7 09:50:53 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Mon, 7 Dec 2015 15:50:53 +0100 Subject: [CMake] Control the build target's external dependencies In-Reply-To: <4736E3F0-35A1-4374-A95A-D704711D0BFE@gmail.com> References: <4736E3F0-35A1-4374-A95A-D704711D0BFE@gmail.com> Message-ID: <86B9DA15-E382-4E39-8468-A18A0DB48FE4@gmail.com> Just to answer myself: After looking at the source code, I now understand that the regular expression set by include_regular_expression(...) is not compared against the full path name of the included file, but just what's in the source file after #include. So this machinery is non too useful for me at the moment. For now I patched CMake locally with the following to ignore all out of source files in the dependency generation for me. With: diff -u -r orig/cmake-3.4.1/Source/cmDepends.cxx cmake-3.4.1/Source/cmDepends.cxx --- orig/cmake-3.4.1/Source/cmDepends.cxx 2015-12-02 16:43:21.000000000 +0100 +++ cmake-3.4.1/Source/cmDepends.cxx 2015-12-07 13:59:07.039749715 +0100 @@ -18,6 +18,7 @@ #include "cmFileTimeComparison.h" #include #include +#include //---------------------------------------------------------------------------- cmDepends::cmDepends(cmLocalGenerator* lg, const char* targetDir): @@ -291,6 +292,13 @@ return okay; } +// Helper predicate for removing absolute paths from the include directory +// list. +bool IsAbsolutePath( const std::string& path ) +{ + return cmSystemTools::FileIsFullPath( path ); +} + //---------------------------------------------------------------------------- void cmDepends::SetIncludePathFromLanguage(const std::string& lang) { @@ -317,4 +325,8 @@ cmSystemTools::ExpandListArgument(includePath, this->IncludePath); } } + // Remove all absolute paths from the dependency evaluation: + auto itr = std::remove_if( this->IncludePath.begin(), this->IncludePath.end(), + IsAbsolutePath ); + this->IncludePath.erase( itr, this->IncludePath.end() ); } (Could be implemented with slightly fewer lines as well.) Which sped up the generation of these depend.make files immensely. So I wonder if turning on this behaviour could be a new thing in the future. As I imagine that it could be useful to a lot of people if it could be set via some property that only files from the source directory should be considered in the dependency calculation. Should one open a bug report with this? (Does the CMake bug tracking system have the ability to track "feature requests"?) Cheers, Attila > On 07 Dec 2015, at 11:55, Attila Krasznahorkay wrote: > > Dear All, > > Maybe I should've google-d better. So now I started experimenting with include_regular_expression(...). > > https://cmake.org/cmake/help/v3.0/command/include_regular_expression.html > > But now I'm having a problem with expressing my intent with a regular expression. In principle I'd like to only take headers from the source directory into account in the dependency calculation. So I first tried this: > > include_regular_expression( "^${CMAKE_SOURCE_DIR}.*$" ) > > But this was way too restrictive. As headers from the source directory normally show up with relative paths in the depend.make files. > > So okay, I tried this next: > > include_regular_expression( "^(${CMAKE_SOURCE_DIR}.*)|([^/]+.*)$" ) > > (To try to make it only accept paths that are either in CMAKE_SOURCE_DIR, or are not starting with "/".) > > But this didn't work either. I'm back to having all the boost files in my dependency list. > > Any suggestion for how I could express my intent in a regular expression that CMake would understand? > > Cheers, > Attila > >> On 07 Dec 2015, at 10:57, Attila Krasznahorkay wrote: >> >> Dear All, >> >> I'm struggling since a few days with the following issue. >> >> Our development setup is such that we build large software projects in a nightly build system, which puts these projects onto a network drive. The developers then set up these nightly projects, and build their own code against them. (They can even rebuild parts that are in the nightly itself, that also required some clever tricks in CMake...) >> >> This kind of works by now. But the system is incredibly slow. When I try to build some source code against installed releases on the network file system, >90% of the time is seemingly just spent in dependency calculation/evaluation. To demonstrate the extent of the issue, here is an example of the files generated by CMake for one of our "packages". (Sorry, they are pretty large. But that's the point...) Mind you, this is a very simple package that just picks up Boost from the network disk. For high level packages the depend.make file can be up to 2 MB in size. :-( >> >> >> >> As you can see, I tried to convince CMake to treat the include directories coming from the network file system (AFS) as system include directories. But still, the dependencies put into depend.make list every single header file that the build targets have any relationship with. >> >> As it turns out, AFS is pretty slow for such operations. Checking the change times of thousands of files. At least this is what I contribute the ridiculously slow build times to. (Not for this example. This package still builds reasonably. It's the higher level packages that break down completely. I just couldn't attach example files from those due to the size limitations of this mailing list.) >> >> So... How could one convince CMake to exclude some directories from the dependency setup? The files that are part of the nightly builds should definitely not need to be checked for changes every time I run a build. As you can see, depend.make even list all the Boost headers at the moment. :-( >> >> What I tried so far was to specify the include directories using SYSTEM in target_include_directories. But it didn't make any difference whether I used SYSTEM or not. >> >> Is there some other mechanism that I could use here? >> >> Cheers, >> Attila > From zbergquist99 at gmail.com Mon Dec 7 13:44:07 2015 From: zbergquist99 at gmail.com (Zac Bergquist) Date: Mon, 7 Dec 2015 13:44:07 -0500 Subject: [CMake] CMake not finding boost headers Message-ID: I'm stuck on what seems like a rather simple problem. I've got this in my CMakeLists.txt set(BOOST_INCLUDEDIR ${CMAKE_CURRENT_LIST_DIR}/boost_1_59_0) set(Boost_DEBUG 1) find_package(Boost 1.59.0 EXACT REQUIRED) The boost_1_59_0 I'm pointing it to contains the Boost source straight from the 1.59.0 release. I've tried both CMake 3.3.1 and 3.4.1. When I run CMake, I get the "Unable to find the Boost header files" error. Here's some of the debug output: -- [ FindBoost.cmake:551 ] _boost_TEST_VERSIONS = 1.59.0;1.59 -- [ FindBoost.cmake:553 ] Boost_USE_MULTITHREADED = TRUE -- [ FindBoost.cmake:555 ] Boost_USE_STATIC_LIBS = -- [ FindBoost.cmake:557 ] Boost_USE_STATIC_RUNTIME = -- [ FindBoost.cmake:559 ] Boost_ADDITIONAL_VERSIONS = -- [ FindBoost.cmake:561 ] Boost_NO_SYSTEM_PATHS = -- [ FindBoost.cmake:613 ] Declared as CMake or Environmental Variables: -- [ FindBoost.cmake:615 ] BOOST_ROOT = -- [ FindBoost.cmake:617 ] BOOST_INCLUDEDIR = /home/user/thirdparty/boost_1_59_0 -- [ FindBoost.cmake:619 ] BOOST_LIBRARYDIR = -- [ FindBoost.cmake:621 ] _boost_TEST_VERSIONS = 1.59.0;1.59 -- [ FindBoost.cmake:690 ] Include debugging info: -- [ FindBoost.cmake:692 ] _boost_INCLUDE_SEARCH_DIRS = /home/user/thirdparty/boost_1_59_0;PATHS;C:/boost/include;C:/boost;/sw/local/include -- [ FindBoost.cmake:694 ] _boost_PATH_SUFFIXES = boost-1_59_0;boost_1_59_0;boost/boost-1_59_0;boost/boost_1_59_0;boost-1_59;boost_1_59;boost/boost-1_59;boost/boost_1_59 So I see that the FindBoost module picked up my BOOST_INCLUDEDIR hint. I looked at the source for the FindBoost module, and it comes down to: find_path(NAMES boost/config.hpp ...). The file exists exactly where CMake says it's looking. $ ls -l /home/user/thirdparty/boost_1_59_0/boost/config.hpp -r--r--r-- 1 user user 2188 Nov 30 16:20 /home/user/thirdparty/boost_1_59_0/boost/config.hpp Yet CMake is still setting Boost_INCLUDE_DIR-NOTFOUND. I have tried removing boost_1_59_0 from my BOOST_INCLUDEDIR hint (since I saw that portion of the path in the suffixes, but it doesn't help). The only way I am able to get CMake to locate the boost headers is to install them into a global location like /usr/local/include (which I'd like to avoid). -------------- next part -------------- An HTML attachment was scrubbed... URL: From zbergquist99 at gmail.com Mon Dec 7 13:56:20 2015 From: zbergquist99 at gmail.com (Zac Bergquist) Date: Mon, 7 Dec 2015 13:56:20 -0500 Subject: [CMake] CMake not finding boost headers In-Reply-To: References: Message-ID: It turns out I missed some important information. I am cross compiling, and my toolchain file sets CMAKE_FIND_ROOT_PATH_MODE_INCLUDE to ONLY. If I change ONLY to BOTH, CMake succesfully locates the Boost headers. I'm not sure if this is the correct solution though. Why would setting this to ONLY prevent CMake from searching outside CMAKE_FIND_ROOT_PATH? On Mon, Dec 7, 2015 at 1:44 PM, Zac Bergquist wrote: > I'm stuck on what seems like a rather simple problem. > > I've got this in my CMakeLists.txt > > set(BOOST_INCLUDEDIR ${CMAKE_CURRENT_LIST_DIR}/boost_1_59_0) > set(Boost_DEBUG 1) > find_package(Boost 1.59.0 EXACT REQUIRED) > > The boost_1_59_0 I'm pointing it to contains the Boost source straight > from the 1.59.0 release. > > I've tried both CMake 3.3.1 and 3.4.1. When I run CMake, I get the > "Unable to find the Boost header files" error. Here's some of the debug > output: > > -- [ FindBoost.cmake:551 ] _boost_TEST_VERSIONS = 1.59.0;1.59 > -- [ FindBoost.cmake:553 ] Boost_USE_MULTITHREADED = TRUE > -- [ FindBoost.cmake:555 ] Boost_USE_STATIC_LIBS = > -- [ FindBoost.cmake:557 ] Boost_USE_STATIC_RUNTIME = > -- [ FindBoost.cmake:559 ] Boost_ADDITIONAL_VERSIONS = > -- [ FindBoost.cmake:561 ] Boost_NO_SYSTEM_PATHS = > -- [ FindBoost.cmake:613 ] Declared as CMake or Environmental Variables: > -- [ FindBoost.cmake:615 ] BOOST_ROOT = > -- [ FindBoost.cmake:617 ] BOOST_INCLUDEDIR = > /home/user/thirdparty/boost_1_59_0 > -- [ FindBoost.cmake:619 ] BOOST_LIBRARYDIR = > -- [ FindBoost.cmake:621 ] _boost_TEST_VERSIONS = 1.59.0;1.59 > -- [ FindBoost.cmake:690 ] Include debugging info: > -- [ FindBoost.cmake:692 ] _boost_INCLUDE_SEARCH_DIRS = > /home/user/thirdparty/boost_1_59_0;PATHS;C:/boost/include;C:/boost;/sw/local/include > -- [ FindBoost.cmake:694 ] _boost_PATH_SUFFIXES = > boost-1_59_0;boost_1_59_0;boost/boost-1_59_0;boost/boost_1_59_0;boost-1_59;boost_1_59;boost/boost-1_59;boost/boost_1_59 > > So I see that the FindBoost module picked up my BOOST_INCLUDEDIR hint. I > looked at the source for the FindBoost module, and it comes down to: > > find_path(NAMES boost/config.hpp ...). > > The file exists exactly where CMake says it's looking. > > $ ls -l /home/user/thirdparty/boost_1_59_0/boost/config.hpp > -r--r--r-- 1 user user 2188 Nov 30 16:20 > /home/user/thirdparty/boost_1_59_0/boost/config.hpp > > Yet CMake is still setting Boost_INCLUDE_DIR-NOTFOUND. > > I have tried removing boost_1_59_0 from my BOOST_INCLUDEDIR hint (since I > saw that portion of the path in the suffixes, but it doesn't help). The > only way I am able to get CMake to locate the boost headers is to install > them into a global location like /usr/local/include (which I'd like to > avoid). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From parag at ionicsecurity.com Mon Dec 7 14:04:13 2015 From: parag at ionicsecurity.com (Parag Chandra) Date: Mon, 7 Dec 2015 19:04:13 +0000 Subject: [CMake] CMake not finding boost headers In-Reply-To: References: Message-ID: <7D0BF133-2CBA-4E88-8963-F8C5943F3394@ionicsecurity.com> The reason is that ONLY really does mean: ?only look in the CMAKE_FIND_ROOT_PATH, and don?t look anywhere else?. This can be useful when cross-compiling, as it ensures that you can strictly control the location(s) where system headers are found, and not accidentally find them on the host system. It would be bad if, e.g., you were trying to target an embedded device and CMake and/or the compiler used the system headers from your host Linux machine. Having said that, I disabled the ONLY option when I cross-compile for iOS and Android, as I found it too limiting. I have cross-compiled dependencies (including Boost) in locations outside of the CMAKE_FIND_ROOT_PATH, and I didn?t want to relocate them all inside CMAKE_FIND_ROOT_PATH to satisfy the ONLY option. Parag Chandra Senior Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 400, Atlanta, GA 30309 From: CMake > on behalf of Zac Bergquist > Date: Monday, December 7, 2015 at 1:56 PM To: Cmake Mailing List > Subject: Re: [CMake] CMake not finding boost headers It turns out I missed some important information. I am cross compiling, and my toolchain file sets CMAKE_FIND_ROOT_PATH_MODE_INCLUDE to ONLY. If I change ONLY to BOTH, CMake succesfully locates the Boost headers. I'm not sure if this is the correct solution though. Why would setting this to ONLY prevent CMake from searching outside CMAKE_FIND_ROOT_PATH? On Mon, Dec 7, 2015 at 1:44 PM, Zac Bergquist > wrote: I'm stuck on what seems like a rather simple problem. I've got this in my CMakeLists.txt set(BOOST_INCLUDEDIR ${CMAKE_CURRENT_LIST_DIR}/boost_1_59_0) set(Boost_DEBUG 1) find_package(Boost 1.59.0 EXACT REQUIRED) The boost_1_59_0 I'm pointing it to contains the Boost source straight from the 1.59.0 release. I've tried both CMake 3.3.1 and 3.4.1. When I run CMake, I get the "Unable to find the Boost header files" error. Here's some of the debug output: -- [ FindBoost.cmake:551 ] _boost_TEST_VERSIONS = 1.59.0;1.59 -- [ FindBoost.cmake:553 ] Boost_USE_MULTITHREADED = TRUE -- [ FindBoost.cmake:555 ] Boost_USE_STATIC_LIBS = -- [ FindBoost.cmake:557 ] Boost_USE_STATIC_RUNTIME = -- [ FindBoost.cmake:559 ] Boost_ADDITIONAL_VERSIONS = -- [ FindBoost.cmake:561 ] Boost_NO_SYSTEM_PATHS = -- [ FindBoost.cmake:613 ] Declared as CMake or Environmental Variables: -- [ FindBoost.cmake:615 ] BOOST_ROOT = -- [ FindBoost.cmake:617 ] BOOST_INCLUDEDIR = /home/user/thirdparty/boost_1_59_0 -- [ FindBoost.cmake:619 ] BOOST_LIBRARYDIR = -- [ FindBoost.cmake:621 ] _boost_TEST_VERSIONS = 1.59.0;1.59 -- [ FindBoost.cmake:690 ] Include debugging info: -- [ FindBoost.cmake:692 ] _boost_INCLUDE_SEARCH_DIRS = /home/user/thirdparty/boost_1_59_0;PATHS;C:/boost/include;C:/boost;/sw/local/include -- [ FindBoost.cmake:694 ] _boost_PATH_SUFFIXES = boost-1_59_0;boost_1_59_0;boost/boost-1_59_0;boost/boost_1_59_0;boost-1_59;boost_1_59;boost/boost-1_59;boost/boost_1_59 So I see that the FindBoost module picked up my BOOST_INCLUDEDIR hint. I looked at the source for the FindBoost module, and it comes down to: find_path(NAMES boost/config.hpp ...). The file exists exactly where CMake says it's looking. $ ls -l /home/user/thirdparty/boost_1_59_0/boost/config.hpp -r--r--r-- 1 user user 2188 Nov 30 16:20 /home/user/thirdparty/boost_1_59_0/boost/config.hpp Yet CMake is still setting Boost_INCLUDE_DIR-NOTFOUND. I have tried removing boost_1_59_0 from my BOOST_INCLUDEDIR hint (since I saw that portion of the path in the suffixes, but it doesn't help). The only way I am able to get CMake to locate the boost headers is to install them into a global location like /usr/local/include (which I'd like to avoid). -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris+cmake at qwirx.com Mon Dec 7 14:43:27 2015 From: chris+cmake at qwirx.com (Chris Wilson) Date: Mon, 7 Dec 2015 19:43:27 +0000 Subject: [CMake] Problems with transitive dependencies Message-ID: Dear CMake users, I'm trying to use CMake to replace the complex hand-built Visual Studio configuration of our open source project, Box Backup. And I'm having trouble making it generate the correct transitive dependencies between modules, particularly for include directories. We have a lot of modules whose header files need to be part of the public interface to link to these modules. I thought from the manual that "The usage requirements of a target can transitively propagate to dependents" but I can't make it work (for anything except link libraries). Here is a toy example taken from the manual: add_library(archive archive.cpp) target_compile_definitions(archive PUBLIC USING_ARCHIVE_LIB) add_library(serialization serialization.cpp) target_compile_definitions(serialization INTERFACE USING_SERIALIZATION_LIB) add_library(archiveExtras extras.cpp) target_link_libraries(archiveExtras PUBLIC archive) target_link_libraries(archiveExtras PRIVATE serialization) # archiveExtras is compiled with -DUSING_ARCHIVE_LIB # and -DUSING_SERIALIZATION_LIB add_executable(consumer consumer.cpp) # consumer is compiled with -DUSING_ARCHIVE_LIB target_link_libraries(consumer archiveExtras) My understanding is that the target_compile_definitions are part of the public interface of the archive module, and should be added to anything that links to it, which archiveExtras does. But if I add some debugging messages after the above code: foreach (lib archive serialization archiveExtras consumer) get_property(ill TARGET ${lib} PROPERTY INTERFACE_LINK_LIBRARIES) get_property(ll TARGET ${lib} PROPERTY LINK_LIBRARIES) get_property(icd TARGET ${lib} PROPERTY INTERFACE_COMPILE_DEFINITIONS) get_property(cd TARGET ${lib} PROPERTY COMPILE_DEFINITIONS) message(STATUS "${lib}: INTERFACE_LINK_LIBRARIES = \"${ill}\" " "LINK_LIBRARIES = \"${ll}\"") message(STATUS "${lib}: INTERFACE_COMPILE_DEFINITIONS = \"${icd}\" " "COMPILE_DEFINITIONS = \"${cd}\"") endforeach() I can see that archiveExtras inherits the link libraries of archive, *but not its compile_definitions* (nor the include directories if I try to inherit them instead): -- archive: INTERFACE_LINK_LIBRARIES = "" LINK_LIBRARIES = "" -- archive: INTERFACE_COMPILE_DEFINITIONS = "USING_ARCHIVE_LIB" COMPILE_DEFINITIONS = "USING_ARCHIVE_LIB" -- serialization: INTERFACE_LINK_LIBRARIES = "" LINK_LIBRARIES = "" -- serialization: INTERFACE_COMPILE_DEFINITIONS = "USING_SERIALIZATION_LIB" COMPILE_DEFINITIONS = "" -- archiveExtras: INTERFACE_LINK_LIBRARIES = "archive;$" LINK_LIBRARIES = "archive;serialization" -- archiveExtras: INTERFACE_COMPILE_DEFINITIONS = "" COMPILE_DEFINITIONS = "" -- consumer: INTERFACE_LINK_LIBRARIES = "archiveExtras" LINK_LIBRARIES = "archiveExtras" -- consumer: INTERFACE_COMPILE_DEFINITIONS = "" COMPILE_DEFINITIONS = "" The COMPILE_DEFINITIONS of archiveExtras is empty; it has not inherited anything. The manual says: Because archive is a PUBLIC dependency of archiveExtras, the usage > requirements of it are propagated to consumer too. Because serialization is > a PRIVATE dependency of archive, the usage requirements of it are not > propagated to consumer... > "Usage requirements are propagated by reading the INTERFACE_ variants of > target properties from dependencies and appending the values to the > non-INTERFACE_ variants of the operand. For example, the > INTERFACE_INCLUDE_DIRECTORIES of dependencies is read and appended to the > INCLUDE_DIRECTORIES of the operand." I would assume that the same happens for COMPILE_DEFINITIONS: it should be copied from the INTERFACE_COMPILE_DEFINITIONS of the dependencies. But this doesn't appear to be happening, as far as I can tell. Nor is the "consumer compiled with -DUSING_ARCHIVE_LIB", contrary to the comment (at least it's not in the COMPILE_DEFINITIONS). Can anyone tell me what I'm doing wrong? Specifiying "dependencies" the wrong way? I would really appreciate some help :) Do I have to hard-code or script all the transitive dependencies myself, or is there something I'm missing? Thanks in advance, Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dresserd at alum.mit.edu Mon Dec 7 15:13:35 2015 From: dresserd at alum.mit.edu (Derek Dresser) Date: Mon, 7 Dec 2015 15:13:35 -0500 Subject: [CMake] Set tests to "not-run" in CDash Message-ID: Hello, We sometimes have tests that are failing and want to disable them temporarily, but still be reminded of them in the CDash dashboard. To accomplish this, we sometimes map the test name to a non existing executable. CTest then can't find the executable and marks the test as "not run" in CDash. That way we see that there is a test in the "not run" column and it reminds us that we have a test that needs some work before it can be re-enabled. Is there a better way to intentionally mark a test as "not run?" We still want to see it in the "not run" column. Thanks, Derek -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neundorf-work at gmx.net Mon Dec 7 16:05:25 2015 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Mon, 07 Dec 2015 22:05:25 +0100 Subject: [CMake] Making CMake *not* use -isystem at all In-Reply-To: References: Message-ID: <1846056.1IKV3CX08a@tuxedo.neundorf.net> On Monday, December 07, 2015 15:39:40 Attila Krasznahorkay wrote: > Dear All, > > I'm still debugging the performance problems of our build. But now I bumped > into another surprising thing. > > Our "highest level" packages can depend on a *lot* of low level packages. > The one I'm testing now depends on more than 180 of them. > > This generates >180 -isystem flags for the compilation lines. But I found a > very surprising thing. If I replace all of these -isystem flags with -I > ones by simply modifying the flags.cmake files that CMake generated for me, > the build time of my code is cut to less than half of what it is when using > -isystem. > > So... How do I tell CMake to forget about using -isystem all together, and > take all my include directories with -I? > > Not using SYSTEM in target_include_directories and include_directories > doesn't seem to make a difference. I still get all my out-of-source > directories with -isystem. I even tried setting > CMAKE_INCLUDE_SYSTEM_FLAG_CXX and CMAKE_INCLUDE_SYSTEM_FLAG_C to "-I " > forcefully. But this didn't help either. Neither did explicitly unsetting > these variables. I would have expected this to work. Maybe set them to -I on the initial cmake run ? Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Mon Dec 7 16:24:11 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Mon, 7 Dec 2015 22:24:11 +0100 Subject: [CMake] Making CMake *not* use -isystem at all In-Reply-To: <1846056.1IKV3CX08a@tuxedo.neundorf.net> References: <1846056.1IKV3CX08a@tuxedo.neundorf.net> Message-ID: Hi Alex, From what I could see, if the base CMake code decides that internally CMAKE_INCLUDE_SYSTEM_FLAG_CXX needs to be set to ?-isystem ?, then I can?t influence this decision from the outside. But the reason that the decision between using -I and -isystem seemed so inexplainable to me was that my project uses imported targets quite heavily. And as I had to learn, CMake treats the include directories set on imported libraries as system includes by default. Regardless whether those were set as system includes originally or not. After some google-ing I found out about it here: https://cmake.org/cmake/help/v3.0/prop_tgt/NO_SYSTEM_FROM_IMPORTED.html After setting CMAKE_NO_SYSTEM_FROM_IMPORTED to TRUE, my project now uses -I and -isystem includes as I originally expected it to. And it could still be interesting to people that apparently using -isystem for directories on network disks is not a good idea. I?m really not sure what GCC does in the background exactly, but it clearly has some noticeable overhead over using -I for the same directories. So for now I just stopped using system include directories myself completely. Cheers, Attila > On Dec 7, 2015, at 10:05 PM, Alexander Neundorf wrote: > > On Monday, December 07, 2015 15:39:40 Attila Krasznahorkay wrote: > > Dear All, > > > > I'm still debugging the performance problems of our build. But now I bumped > > into another surprising thing. > > > > Our "highest level" packages can depend on a *lot* of low level packages. > > The one I'm testing now depends on more than 180 of them. > > > > This generates >180 -isystem flags for the compilation lines. But I found a > > very surprising thing. If I replace all of these -isystem flags with -I > > ones by simply modifying the flags.cmake files that CMake generated for me, > > the build time of my code is cut to less than half of what it is when using > > -isystem. > > > > So... How do I tell CMake to forget about using -isystem all together, and > > take all my include directories with -I? > > > > Not using SYSTEM in target_include_directories and include_directories > > doesn't seem to make a difference. I still get all my out-of-source > > directories with -isystem. I even tried setting > > CMAKE_INCLUDE_SYSTEM_FLAG_CXX and CMAKE_INCLUDE_SYSTEM_FLAG_C to "-I " > > forcefully. But this didn't help either. Neither did explicitly unsetting > > these variables. > > I would have expected this to work. > Maybe set them to -I on the initial cmake run ? > > Alex > From kristianonline28 at gmail.com Mon Dec 7 16:52:39 2015 From: kristianonline28 at gmail.com (Kristian) Date: Mon, 7 Dec 2015 22:52:39 +0100 Subject: [CMake] CMake and a simple java example Message-ID: Dear All, I am learning CMake, and one of my personal lessons is combine Java and CMake. I made a small example (HelloWorld.java): ========== public class HelloWorld { public static void main(String[] args) { System.out.println("Hey :)"); } } ========== And a CMakeLists.txt file: ========== cmake_minimum_required(VERSION 2.8) project(HelloWorld) find_package(Java REQUIRED) include(UseJava) set(JAR_NAME HelloWorld) set(JAVA_SOURCE_DIRECTORY ) set(JAVA_SOURCE_FILES ${JAVA_SOURCE_DIRECTORY}/HelloWorld.java) add_jar(${JAR_NAME} ${JAVA_SOURCE_FILES}) ========== Then I go into that directory where the CMakeLists.txt is and start the command ========== cmake --target=HelloWorld --build . ========== Output is: ========== -- The C compiler identification is GNU 4.8.4 -- The CXX compiler identification is GNU 4.8.4 -- 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 -- 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 -- Found Java: /usr/bin/java (found version "1.8.0.66") -- Jar file /home/some/Downloads/HelloWorld/HelloWorld.jar -- Class compiled to /home/some/Downloads/HelloWorld/CMakeFiles/HelloWorld.dir -- Configuring done -- Generating done -- Build files have been written to: /home/some/Downloads/HelloWorld ========== But when I start the command "make", then I get the following output: ========== Scanning dependencies of target HelloWorld make[2]: *** No rule to make target `/HelloWorld.java', needed by `CMakeFiles/HelloWorld.dir/java_compiled_HelloWorld'. Stop. make[1]: *** [CMakeFiles/HelloWorld.dir/all] Error 2 make: *** [all] Error 2 ========== Can you tell me, what I am doing wrong? From rcdailey.lists at gmail.com Mon Dec 7 16:53:02 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 7 Dec 2015 15:53:02 -0600 Subject: [CMake] Copying directories as post build events without losing parent directory Message-ID: I have a custom target which runs a command similar to this: $ cmake -E copy_directory foo bar The problem is that the contents of "foo" are copied inside of "bar", instead of it creating a directory "bar/foo" and putting the contents in there. Is there a way to make copy_directory behave like this? If not, I guess my only option is to create a little CMake script that runs file(INSTALL) to copy the directories like I want. From DLRdave at aol.com Mon Dec 7 16:59:43 2015 From: DLRdave at aol.com (David Cole) Date: Mon, 7 Dec 2015 16:59:43 -0500 Subject: [CMake] Copying directories as post build events without losing parent directory In-Reply-To: References: Message-ID: $ cmake -E copy_directory foo bar/foo ? On Mon, Dec 7, 2015 at 4:53 PM, Robert Dailey wrote: > I have a custom target which runs a command similar to this: > > $ cmake -E copy_directory foo bar > > The problem is that the contents of "foo" are copied inside of "bar", > instead of it creating a directory "bar/foo" and putting the contents > in there. > > Is there a way to make copy_directory behave like this? If not, I > guess my only option is to create a little CMake script that runs > file(INSTALL) to copy the directories like I want. > -- > > 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 From rcdailey.lists at gmail.com Mon Dec 7 17:15:50 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 7 Dec 2015 16:15:50 -0600 Subject: [CMake] Copying directories as post build events without losing parent directory In-Reply-To: References: Message-ID: On Mon, Dec 7, 2015 at 3:59 PM, David Cole wrote: > $ cmake -E copy_directory foo bar/foo > > ? > > > On Mon, Dec 7, 2015 at 4:53 PM, Robert Dailey wrote: >> I have a custom target which runs a command similar to this: >> >> $ cmake -E copy_directory foo bar >> >> The problem is that the contents of "foo" are copied inside of "bar", >> instead of it creating a directory "bar/foo" and putting the contents >> in there. >> >> Is there a way to make copy_directory behave like this? If not, I >> guess my only option is to create a little CMake script that runs >> file(INSTALL) to copy the directories like I want. >> -- >> >> 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 That's the obvious answer but due to complexity reasons I don't want to repeat the destination directory name. I want the copy to be inclusive of the source directory name. I'd have to use get_filename_component() to find the leaf directory name in the list of directories I provide to my function for copying, simply to repeat that name in the destination path I build. I want to avoid this. Another weirdness is that I like to pass in a list with a mixture of directories and files. Think of this is a way for me to pass in a list of game data resources that need to be copied to the EXE directory so the game can find them and run. I also have to add weird if(IS_DIRECTORY) checks so I can tell my custom command to use "copy" or "copy_directory". A simple little install.cmake script that I run is able to do this, but as far as complexity goes, it doesn't save me a whole lot: function( copy_data ) if( NOT TARGET copy_data ) add_custom_target( copy_data COMMENT "Copying data directories and files..." ) endif() set( data_directories ${ARGN} ) foreach( data ${data_directories} ) get_filename_component( data ${data} ABSOLUTE ) set( output_dir "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$" ) set( install_script "${BUILD_CMAKE_DIR}/scripts/install.cmake" ) add_custom_command( TARGET copy_data POST_BUILD COMMAND ${CMAKE_COMMAND} ARGS "-DSOURCE=${data}" "-DOUTPUT_DIR=${output_dir}" -P "${install_script}" ) endforeach() endfunction() From rcdailey.lists at gmail.com Mon Dec 7 17:16:58 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 7 Dec 2015 16:16:58 -0600 Subject: [CMake] Copying directories as post build events without losing parent directory In-Reply-To: References: Message-ID: On Mon, Dec 7, 2015 at 4:15 PM, Robert Dailey wrote: > On Mon, Dec 7, 2015 at 3:59 PM, David Cole wrote: >> $ cmake -E copy_directory foo bar/foo >> >> ? >> >> >> On Mon, Dec 7, 2015 at 4:53 PM, Robert Dailey wrote: >>> I have a custom target which runs a command similar to this: >>> >>> $ cmake -E copy_directory foo bar >>> >>> The problem is that the contents of "foo" are copied inside of "bar", >>> instead of it creating a directory "bar/foo" and putting the contents >>> in there. >>> >>> Is there a way to make copy_directory behave like this? If not, I >>> guess my only option is to create a little CMake script that runs >>> file(INSTALL) to copy the directories like I want. >>> -- >>> >>> 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 > > That's the obvious answer but due to complexity reasons I don't want > to repeat the destination directory name. I want the copy to be > inclusive of the source directory name. I'd have to use > get_filename_component() to find the leaf directory name in the list > of directories I provide to my function for copying, simply to repeat > that name in the destination path I build. I want to avoid this. > Another weirdness is that I like to pass in a list with a mixture of > directories and files. Think of this is a way for me to pass in a list > of game data resources that need to be copied to the EXE directory so > the game can find them and run. I also have to add weird > if(IS_DIRECTORY) checks so I can tell my custom command to use "copy" > or "copy_directory". > > A simple little install.cmake script that I run is able to do this, > but as far as complexity goes, it doesn't save me a whole lot: > > function( copy_data ) > if( NOT TARGET copy_data ) > add_custom_target( copy_data COMMENT "Copying data directories > and files..." ) > endif() > > set( data_directories ${ARGN} ) > > foreach( data ${data_directories} ) > get_filename_component( data ${data} ABSOLUTE ) > set( output_dir "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$" ) > set( install_script "${BUILD_CMAKE_DIR}/scripts/install.cmake" ) > > add_custom_command( TARGET copy_data POST_BUILD > COMMAND ${CMAKE_COMMAND} > ARGS "-DSOURCE=${data}" "-DOUTPUT_DIR=${output_dir}" -P > "${install_script}" > ) > endforeach() > endfunction() Oh and the contents of install.cmake: file( INSTALL ${SOURCE} DESTINATION ${OUTPUT_DIR} ) From bruce.r.stephens at gmail.com Mon Dec 7 17:51:06 2015 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Mon, 7 Dec 2015 22:51:06 +0000 Subject: [CMake] Shared library from sources in several subdirectories In-Reply-To: <56654C98.1070708@gmail.com> References: <56654C98.1070708@gmail.com> Message-ID: On Mon, Dec 7, 2015 at 9:08 AM, Nils Gladitz wrote: > I would avoid creating these single use, per directory libraries entirely. > > Well, creating the static libraries is obviously just an artifact of our current build scheme, so it makes sense to ditch it. Creating these CMake object libraries doesn't seem bad; is there some reason to avoid doing that? A reason for doing it is it gives targets for target_include_directories, so just the crypto objects can be built with the OpenSSL include directory. Also for some reason setting the POSITION_INDEPENDENT_CODE property for the top-level shared library (the default anyway) doesn't seem to propagate down (and maybe it can't), and the named thing makes it easy to apply the property to the sources. Though now I look, I could use set_property on the sources (or the directory), and I could use set_property similarly to add include directories (and compile definitions). > A single target can build sources located in any number of directories. > > If you want to subdivide the source file listing of that one target for > organizational purposes you can do so with e.g. include(), target_sources() > and/or list variables. > Thanks for suggesting that. For some reason it hadn't occurred to me. I'm not sure whether that would work out better for this particular case or not, or for the larger library I'd like to do (with ~500 sources in a tree of ~40 directories). (I suspect there's not that much in it ultimately and worrying about the choice is as much bike shedding as anything.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Tue Dec 8 02:40:48 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Tue, 8 Dec 2015 07:40:48 +0000 Subject: [CMake] CMake and a simple java example In-Reply-To: References: Message-ID: Hi, You didn?t specify nothing in variable JAVA_SOURCE_DIRECTORY, so java source path is effectively /HelloWorld.java. By the way, you can specify relative paths to the CMakeLists.txt directory for java sources, so: set(JAVA_SOURCE_FILES HelloWorld.java) add_jar(${JAR_NAME} ${JAVA_SOURCE_FILES}) Should do the work. Or alternately: set(JAVA_SOURCE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}) set(JAVA_SOURCE_FILES ${JAVA_SOURCE_DIRECTORY}/HelloWorld.java) add_jar(${JAR_NAME} ${JAVA_SOURCE_FILES}) is also OK. On 07/12/15 22:52, "CMake on behalf of Kristian" wrote: >Dear All, > >I am learning CMake, and one of my personal lessons is combine Java >and CMake. I made a small example (HelloWorld.java): > >========== > >public class HelloWorld >{ > public static void main(String[] args) > { > System.out.println("Hey :)"); > } >} > >========== > >And a CMakeLists.txt file: > >========== > >cmake_minimum_required(VERSION 2.8) >project(HelloWorld) > >find_package(Java REQUIRED) >include(UseJava) > >set(JAR_NAME HelloWorld) >set(JAVA_SOURCE_DIRECTORY ) >set(JAVA_SOURCE_FILES ${JAVA_SOURCE_DIRECTORY}/HelloWorld.java) >add_jar(${JAR_NAME} ${JAVA_SOURCE_FILES}) > >========== > >Then I go into that directory where the CMakeLists.txt is and start the command > >========== >cmake --target=HelloWorld --build . >========== > >Output is: > >========== > >-- The C compiler identification is GNU 4.8.4 >-- The CXX compiler identification is GNU 4.8.4 >-- 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 >-- 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 >-- Found Java: /usr/bin/java (found version "1.8.0.66") >-- Jar file /home/some/Downloads/HelloWorld/HelloWorld.jar >-- Class compiled to /home/some/Downloads/HelloWorld/CMakeFiles/HelloWorld.dir >-- Configuring done >-- Generating done >-- Build files have been written to: /home/some/Downloads/HelloWorld > >========== > >But when I start the command "make", then I get the following output: > >========== > >Scanning dependencies of target HelloWorld >make[2]: *** No rule to make target `/HelloWorld.java', needed by >`CMakeFiles/HelloWorld.dir/java_compiled_HelloWorld'. Stop. >make[1]: *** [CMakeFiles/HelloWorld.dir/all] Error 2 >make: *** [all] Error 2 > >========== > >Can you tell me, what I am doing wrong? >-- > >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 From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Tue Dec 8 02:34:21 2015 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Tue, 8 Dec 2015 07:34:21 +0000 Subject: [CMake] Problems with transitive dependencies In-Reply-To: References: Message-ID: <8D981219EEA621479C112DA9BDC39A8E46F799D0@EXMBS1.ad.igd.fraunhofer.de> You are evaluating those properties at the wrong time. Transitive properties are not passed on at configure time (they can?t be), but at generation time. Therefore to debug those values you will have to use generator expressions (except they don?t work for link_libraries). Or just look at the generated project? -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Chris Wilson Sent: Monday, December 07, 2015 20:43 To: cmake at cmake.org Subject: [CMake] Problems with transitive dependencies Dear CMake users, I'm trying to use CMake to replace the complex hand-built Visual Studio configuration of our open source project, Box Backup. And I'm having trouble making it generate the correct transitive dependencies between modules, particularly for include directories. We have a lot of modules whose header files need to be part of the public interface to link to these modules. I thought from the manual that "The usage requirements of a target can transitively propagate to dependents" but I can't make it work (for anything except link libraries). Here is a toy example taken from the manual: add_library(archive archive.cpp) target_compile_definitions(archive PUBLIC USING_ARCHIVE_LIB) add_library(serialization serialization.cpp) target_compile_definitions(serialization INTERFACE USING_SERIALIZATION_LIB) add_library(archiveExtras extras.cpp) target_link_libraries(archiveExtras PUBLIC archive) target_link_libraries(archiveExtras PRIVATE serialization) # archiveExtras is compiled with -DUSING_ARCHIVE_LIB # and -DUSING_SERIALIZATION_LIB add_executable(consumer consumer.cpp) # consumer is compiled with -DUSING_ARCHIVE_LIB target_link_libraries(consumer archiveExtras) My understanding is that the target_compile_definitions are part of the public interface of the archive module, and should be added to anything that links to it, which archiveExtras does. But if I add some debugging messages after the above code: foreach (lib archive serialization archiveExtras consumer) get_property(ill TARGET ${lib} PROPERTY INTERFACE_LINK_LIBRARIES) get_property(ll TARGET ${lib} PROPERTY LINK_LIBRARIES) get_property(icd TARGET ${lib} PROPERTY INTERFACE_COMPILE_DEFINITIONS) get_property(cd TARGET ${lib} PROPERTY COMPILE_DEFINITIONS) message(STATUS "${lib}: INTERFACE_LINK_LIBRARIES = \"${ill}\" " "LINK_LIBRARIES = \"${ll}\"") message(STATUS "${lib}: INTERFACE_COMPILE_DEFINITIONS = \"${icd}\" " "COMPILE_DEFINITIONS = \"${cd}\"") endforeach() I can see that archiveExtras inherits the link libraries of archive, but not its compile_definitions (nor the include directories if I try to inherit them instead): -- archive: INTERFACE_LINK_LIBRARIES = "" LINK_LIBRARIES = "" -- archive: INTERFACE_COMPILE_DEFINITIONS = "USING_ARCHIVE_LIB" COMPILE_DEFINITIONS = "USING_ARCHIVE_LIB" -- serialization: INTERFACE_LINK_LIBRARIES = "" LINK_LIBRARIES = "" -- serialization: INTERFACE_COMPILE_DEFINITIONS = "USING_SERIALIZATION_LIB" COMPILE_DEFINITIONS = "" -- archiveExtras: INTERFACE_LINK_LIBRARIES = "archive;$" LINK_LIBRARIES = "archive;serialization" -- archiveExtras: INTERFACE_COMPILE_DEFINITIONS = "" COMPILE_DEFINITIONS = "" -- consumer: INTERFACE_LINK_LIBRARIES = "archiveExtras" LINK_LIBRARIES = "archiveExtras" -- consumer: INTERFACE_COMPILE_DEFINITIONS = "" COMPILE_DEFINITIONS = "" The COMPILE_DEFINITIONS of archiveExtras is empty; it has not inherited anything. The manual says: Because archive is a PUBLIC dependency of archiveExtras, the usage requirements of it are propagated to consumer too. Because serialization is a PRIVATE dependency of archive, the usage requirements of it are not propagated to consumer... "Usage requirements are propagated by reading the INTERFACE_ variants of target properties from dependencies and appending the values to the non-INTERFACE_ variants of the operand. For example, the INTERFACE_INCLUDE_DIRECTORIES of dependencies is read and appended to the INCLUDE_DIRECTORIES of the operand." I would assume that the same happens for COMPILE_DEFINITIONS: it should be copied from the INTERFACE_COMPILE_DEFINITIONS of the dependencies. But this doesn't appear to be happening, as far as I can tell. Nor is the "consumer compiled with -DUSING_ARCHIVE_LIB", contrary to the comment (at least it's not in the COMPILE_DEFINITIONS). Can anyone tell me what I'm doing wrong? Specifiying "dependencies" the wrong way? I would really appreciate some help :) Do I have to hard-code or script all the transitive dependencies myself, or is there something I'm missing? Thanks in advance, Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Dec 8 03:13:40 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 8 Dec 2015 09:13:40 +0100 Subject: [CMake] Shared library from sources in several subdirectories In-Reply-To: References: <56654C98.1070708@gmail.com> Message-ID: <56669134.9090702@gmail.com> On 12/07/2015 11:51 PM, Bruce Stephens wrote: > > On Mon, Dec 7, 2015 at 9:08 AM, Nils Gladitz > wrote: > > I would avoid creating these single use, per directory libraries > entirely. > > > Well, creating the static libraries is obviously just an artifact of > our current > build scheme, so it makes sense to ditch it. > > Creating these CMake object libraries doesn't seem bad; is there some > reason to avoid doing that? A reason for doing it is it gives targets for > target_include_directories, so just the crypto objects can be built with > the OpenSSL include directory. While the additional object libraries will more easily allow you to have more granular property settings they also might make it more difficult to maintain property settings that you do want to be the same for the entire library (especially when inheriting properties from linked targets). > > Also for some reason setting the POSITION_INDEPENDENT_CODE > property for the top-level shared library (the default anyway) doesn't > seem to propagate down (and maybe it can't), and the named thing > makes it easy to apply the property to the sources. Though now I look, > I could use set_property on the sources (or the directory), and I could > use set_property similarly to add include directories (and compile > definitions). I am not entirely sure what you mean here but it might be relevant to point out that directory properties refer to the location (CMakeLists.txt) where a target is defined not the location where source files are. Given that if you have a single target then there is only one directory in which it is defined and from which it gets directory properties irregardless of over how many directories the sources files may be spread over. > A single target can build sources located in any number of > directories. > > If you want to subdivide the source file listing of that one > target for organizational purposes you can do so with e.g. > include(), target_sources() and/or list variables. > > > Thanks for suggesting that. For some reason it hadn't occurred to me. > I'm not sure whether that would work out better for this particular case > or not, or for the larger library I'd like to do (with ~500 sources in > a tree > of ~40 directories). The number of source files is the same irregardless of how many targets you split them up over and the number of objects in the final link step will stay the same as well. But I would think that you would see improvements over the split approach given that there are fewer superfluous intermediate steps. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From lloydkl.tech at gmail.com Tue Dec 8 04:29:52 2015 From: lloydkl.tech at gmail.com (Lloyd) Date: Tue, 8 Dec 2015 14:59:52 +0530 Subject: [CMake] CPack Uninstalling locked files Message-ID: Hi, In CPack NSIS template I came across a variable CPACK_NSIS_DELETE_FILES. When the NSIS script is generated, this variable is expanded to "nsis delete commands" for all the cmake install commands. The proble with this is, if the file is locked it will not be deleted. To overcome this NSIS has a "REBOOTOK" flag in the delete command. When the system is reboot these locked files will be deleted. eg. Delete /REBOOTOK "$INSTDIR\uninst.exe" Does CMake/CPack provide any mechanism for deleting locked files ? Thanks, Lloyd -------------- next part -------------- An HTML attachment was scrubbed... URL: From soeren.textor at ditec-gmbh.de Tue Dec 8 05:25:16 2015 From: soeren.textor at ditec-gmbh.de (=?UTF-8?Q?Dr._S=c3=b6ren_Textor?=) Date: Tue, 8 Dec 2015 11:25:16 +0100 Subject: [CMake] Fixed ProjectGUID Message-ID: <5666B00C.8050606@ditec-gmbh.de> Hello I just installed 3.4.1 and the usage of a hardcoded guid does not seem to work anymore: set_property(CACHE ${target_name}_GUID_CMAKE PROPERTY VALUE ${MY_GUID} ) Is thre another way to set the project GUID? best regards SirAnn -------- Original-Nachricht -------- >/Datum: Fri, 7 Jan 2011 22:26:31 +0100 />/Von: Pau Garcia i Quiles > />/An: David Cole > />/CC: "S?ren Freudiger" >, cmake at cmake.org />/Betreff: Re: [CMake] Fixed ProjectGUID / >/Hello, />//>/In Visual Studio 2010, ProjectGUID is a global. This bug provides a />/patch to add global definitions to CMake, but only up to Visual Studio />/2008. It shouldn't be difficult to update the patch to add support for />/Visual C++ 2010. Setting the ProjectGUID would then be as easy as: />//>/set_target_properties( thetarget PROPERTIES VS_GLOBAL_ProjectGUID />/"{384A545C-A6F2-4833-9260-F05C46557610}" ) />//>/I opened the bug and provided the code almost two years ago, so it's />/not like I expect CMake developers to suddenly implement it... />//>/2011/1/7 David Cole >: />/ > The guids should remain constant in a given build tree for the life of />/the />/ > CMakeCache.txt file. />/ > />/ > But after you delete that and start in a fresh build tree, you'll get />/fresh />/ > guids. />/ > />/ > If you want constant guids in your vcproj files, they should be built by />/ > hand, not with CMake. />/ > />/ > />/ > HTH, />/ > David />/ > />/ > />/ > 2011/1/7 "S?ren Freudiger" > />/ >> />/ >> Hello />/ >> Is it possible to set the ProjectGUID by CMake? Every time I generate a />/ >> vcproj file with CMake the ProjectGUID changes. But we need to have a />/fixed />/ >> one (because other projects are including the vcproj). />/ >> />/ >> Best regards />/ >> SirAnn />/ >> -- />/ >> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit />/ >> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl />/ >> _______________________________________________ />/ >> 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 />/ > />//>//>//>/-- />/Pau Garcia i Quiles />/http://www.elpauer.org />/(Due to my workload, I may need 10 days to answer) / -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren:http://www.gmx.net/de/go/freephone -------------- next part -------------- An HTML attachment was scrubbed... URL: From soeren.textor at ditec-gmbh.de Tue Dec 8 06:06:20 2015 From: soeren.textor at ditec-gmbh.de (=?UTF-8?Q?Dr._S=c3=b6ren_Textor?=) Date: Tue, 8 Dec 2015 12:06:20 +0100 Subject: [CMake] Fixed ProjectGUID In-Reply-To: <5666B00C.8050606@ditec-gmbh.de> References: <5666B00C.8050606@ditec-gmbh.de> Message-ID: <5666B9AC.6020403@ditec-gmbh.de> Taking a look at the CMakeCache.txt offers the missing ${target_name}_GUID_CMAKE variable. Thus set_property(CACHE ${target_name}_GUID_CMAKE PROPERTY VALUE ${MY_GUID} ) seems to work. But how do I get the actual GUID set by CMake? This one was stored in CMakeCache.txt before. But right know I cannot find the GUID from a generated project file in any ccmake chache file. How do I gain the GUID created by CMake. In my project I just store the new GUIDs created by CMake in a file. Next time I build the project file I'm looking if a GUID was already generated for that project an will use that one. Best regards, SirAnn Am 08.12.2015 um 11:25 schrieb Dr. S?ren Textor: > Hello > I just installed 3.4.1 and the usage of a hardcoded guid does not seem to work anymore: > > set_property(CACHE ${target_name}_GUID_CMAKE PROPERTY VALUE ${MY_GUID} ) > > Is thre another way to set the project GUID? > > best regards > SirAnn > > -------- Original-Nachricht -------- > >/Datum: Fri, 7 Jan 2011 22:26:31 +0100 />/Von: Pau Garcia i Quiles > />/An: David Cole > />/CC: "S?ren Freudiger" >, cmake at cmake.org > />/Betreff: Re: [CMake] Fixed ProjectGUID / > >/Hello, />//>/In Visual Studio 2010, ProjectGUID is a global. This bug provides a />/patch to add global definitions to CMake, but only up to Visual Studio />/2008. It shouldn't be difficult to update the patch to add support for />/Visual C++ 2010. Setting the ProjectGUID would then be as easy as: />//>/set_target_properties( thetarget PROPERTIES VS_GLOBAL_ProjectGUID />/"{384A545C-A6F2-4833-9260-F05C46557610}" ) />//>/I opened the bug and provided the code almost two years ago, so it's />/not like I expect CMake developers to suddenly implement it... />//>/2011/1/7 David Cole >: />/> The guids should remain constant in a given build tree for the life of />/the />/> CMakeCache.txt file. />/> />/> But after you delete that and start in a fresh build tree, you'll get />/fresh />/> guids. />/> />/> If you want constant guids in your vcproj files, they should be > built by />/> hand, not with CMake. />/> />/> />/> HTH, />/> David />/> />/> />/> 2011/1/7 "S?ren Freudiger" > />/>> />/>> Hello />/>> Is it possible to set the ProjectGUID by CMake? Every time I > generate a />/>> vcproj file with CMake the ProjectGUID changes. But we need to have a />/fixed />/>> one (because other projects are including the vcproj). />/>> />/>> Best regards />/>> SirAnn />/>> -- />/>> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit />/>> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl />/>> _______________________________________________ />/>> 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 />/> />//>//>//>/-- />/Pau Garcia i Quiles />/http://www.elpauer.org />/(Due to my workload, I may need 10 days to answer) / > -- > NEU: FreePhone - kostenlos mobil telefonieren und surfen! > Jetzt informieren:http://www.gmx.net/de/go/freephone > > > -- Dr.-Ing. S?ren Textor Softwareentwicklung phone | +49 6221 31698 225 fax | +49 6221 31698 399 email | s.textor at ditec-gmbh.de web | http://www.ditec-gmbh.de DiTEC Dr. Siegfried Kahlich & Dierk Langer GmbH Im Breitspiel 19 | 69126 Heidelberg | Germany Handelsregister | Mannheim | HRB 341229 Dieses Dokument ist vertraulich zu behandeln. Die Weitergabe, sowie Vervielf?ltigung, Verwertung und Mitteilung seines Inhalts ist nur mit unserer ausdr?cklichen Genehmigung gestattet. Alle Rechte vorbehalten, insbesondere f?r den Fall der Schutzrechtsanmeldung. This document has to be treated confidentially. Its contents are not to be passed on, duplicated, exploited or disclosed without our express permission. All rights reserved, especially the right to apply for protective rights. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Dec 8 06:28:21 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 8 Dec 2015 12:28:21 +0100 Subject: [CMake] Fixed ProjectGUID In-Reply-To: <5666B9AC.6020403@ditec-gmbh.de> References: <5666B00C.8050606@ditec-gmbh.de> <5666B9AC.6020403@ditec-gmbh.de> Message-ID: <5666BED5.90401@gmail.com> On 12/08/2015 12:06 PM, Dr. S?ren Textor wrote: > Taking a look at the CMakeCache.txt offers the missing > ${target_name}_GUID_CMAKE > variable. > Thus > set_property(CACHE ${target_name}_GUID_CMAKE PROPERTY VALUE ${MY_GUID} ) > seems to work. > > But how do I get the actual GUID set by CMake? This one was stored in CMakeCache.txt before. But right know I cannot find the GUID from a generated project file in any ccmake chache file. > How do I gain the GUID created by CMake. In my project I just store the new GUIDs created by CMake in a file. Next time I build the project file I'm looking if a GUID was already generated for that project an will use that one. > See https://cmake.org/gitweb?p=cmake.git;a=commit;h=c85367f4 I don't think cmake exposes the GUID that it uses anymore but you should still be able to provide your own. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From soeren.textor at ditec-gmbh.de Tue Dec 8 06:39:19 2015 From: soeren.textor at ditec-gmbh.de (=?UTF-8?Q?Dr._S=c3=b6ren_Textor?=) Date: Tue, 8 Dec 2015 12:39:19 +0100 Subject: [CMake] Fixed ProjectGUID In-Reply-To: <5666BED5.90401@gmail.com> References: <5666B00C.8050606@ditec-gmbh.de> <5666B9AC.6020403@ditec-gmbh.de> <5666BED5.90401@gmail.com> Message-ID: <5666C167.5040209@ditec-gmbh.de> Yes, it seems that cmake does not store that ID as befere. Thus I just create my own UUID ;-) String( UUID ...) Am 08.12.2015 um 12:28 schrieb Nils Gladitz: > On 12/08/2015 12:06 PM, Dr. S?ren Textor wrote: >> Taking a look at the CMakeCache.txt offers the missing >> ${target_name}_GUID_CMAKE >> variable. >> Thus >> set_property(CACHE ${target_name}_GUID_CMAKE PROPERTY VALUE ${MY_GUID} ) >> seems to work. >> >> But how do I get the actual GUID set by CMake? This one was stored in CMakeCache.txt before. But right know I cannot find the GUID from a generated project file in any ccmake chache file. >> How do I gain the GUID created by CMake. In my project I just store the new GUIDs created by CMake in a file. Next time I build the project file I'm looking if a GUID was already generated for that project an will use that one. >> > > See https://cmake.org/gitweb?p=cmake.git;a=commit;h=c85367f4 > I don't think cmake exposes the GUID that it uses anymore but you > should still be able to provide your own. > > Nils -- Dr.-Ing. S?ren Textor Softwareentwicklung phone | +49 6221 31698 225 fax | +49 6221 31698 399 email | s.textor at ditec-gmbh.de web | http://www.ditec-gmbh.de DiTEC Dr. Siegfried Kahlich & Dierk Langer GmbH Im Breitspiel 19 | 69126 Heidelberg | Germany Handelsregister | Mannheim | HRB 341229 Dieses Dokument ist vertraulich zu behandeln. Die Weitergabe, sowie Vervielf?ltigung, Verwertung und Mitteilung seines Inhalts ist nur mit unserer ausdr?cklichen Genehmigung gestattet. Alle Rechte vorbehalten, insbesondere f?r den Fall der Schutzrechtsanmeldung. This document has to be treated confidentially. Its contents are not to be passed on, duplicated, exploited or disclosed without our express permission. All rights reserved, especially the right to apply for protective rights. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kainjow at kainjow.com Tue Dec 8 13:04:35 2015 From: kainjow at kainjow.com (Kevin Wojniak) Date: Tue, 08 Dec 2015 10:04:35 -0800 Subject: [CMake] Idea: generic task-driven make-like targets with CMake Message-ID: The one thing I?ve found I still have to replace with CMake is the ability to specify generic ?make? targets that do various tasks, such as a release build using the same build directory, run tests, grab dependencies. For example, with Make I can do: release: mkdir -p build_dir cd build_dir && cmake -DCMAKE_BUILD_TYPE=Release .. And all I need to run is: make release But this obviously doesn?t work with native MSVC builds. So, then you?re stuck duplicating this logic with Batch or PowerShell scripts, or using a scripting language such as Python or Ruby. Now, Ruby with Rake is a very nice replacement, so this can become: task :release do FileUtils.mkdir_p ?build_dir? Dir.chdir ?build_dir? do sh ?cmake?, ?-DCMAKE_BUILD_TYPE=Release?, ?..? end end And I can run on all platforms where Ruby/Rake are available: rake release However, Rake/Ruby is a heavy requirement to run these tasks which are very simple for most projects. Plus, you cannot use CMake logic such as compiler/platform detection if you need it outside of CMake. Is there any way to do this cleanly with CMake tools? If not, what if a simple ?ctask? tool was added that offered this basic functionality. For example, within my CMakeLists.txt file I could have tasks defined like: add_task(release COMMAND ${CMAKE_COMMAND} -E make_directory ?build_dir? COMMAND ${CMAKE_COMMAND} -E chdir ?build_dir? ${CMAKE_COMMAND} ?-DCMAKE_BUILD_TYPE=Release?, ?..? ) Then, this could be executed as: ctask release Tasks could depend on other tasks with a DEPENDS argument, just like normal CMake targets. Thoughts? Kevin From nilsgladitz at gmail.com Tue Dec 8 13:22:23 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 8 Dec 2015 19:22:23 +0100 Subject: [CMake] Idea: generic task-driven make-like targets with CMake In-Reply-To: References: Message-ID: <56671FDF.6010902@gmail.com> On 08.12.2015 19:04, Kevin Wojniak wrote: > > add_task(release > COMMAND ${CMAKE_COMMAND} -E make_directory ?build_dir? > COMMAND ${CMAKE_COMMAND} -E chdir ?build_dir? ${CMAKE_COMMAND} > ?-DCMAKE_BUILD_TYPE=Release?, ?..? > ) > There is add_custom_target(). You can e.g. add_custom_target(release ${CMAKE_COMMAND} -E echo foobar) and with the Makefiles generator run "make release" and with visual studio trigger the build of the "release" project. For scripting you can use cmake in script mode with -P. e.g. given a script file release.cmake: message("Hello World") add_custom_target(release ${CMAKE_COMMAND} -P ${CMAKE_CURRENT_SOURCE_DIR}/release.cmake) Nils From kainjow at kainjow.com Tue Dec 8 13:44:22 2015 From: kainjow at kainjow.com (Kevin Wojniak) Date: Tue, 08 Dec 2015 10:44:22 -0800 Subject: [CMake] Idea: generic task-driven make-like targets with CMake In-Reply-To: <56671FDF.6010902@gmail.com> References: <56671FDF.6010902@gmail.com> Message-ID: <81F99498-6B0D-43AC-832B-4A666996A4A5@kainjow.com> Functionality like add_custom_target combined with script mode is close, but not quite there. add_custom_target already requires a build directory and a generator, so it?s too late. Script mode requires setting variables on the command line, so it?s too verbose. For example: if(?${ACTION}? STREQUAL ?release?) execute_process(?) endif() cmake -P myscript.cmake -DACTION=release I suppose you could have multiple *.cmake files for each task, and those could then call the master file with necessary variables set, but then you?d need one file per task and that could become excessive. Kevin On 8 Dec 2015, at 10:22, Nils Gladitz wrote: > On 08.12.2015 19:04, Kevin Wojniak wrote: >> >> add_task(release >> COMMAND ${CMAKE_COMMAND} -E make_directory ?build_dir? >> COMMAND ${CMAKE_COMMAND} -E chdir ?build_dir? ${CMAKE_COMMAND} >> ?-DCMAKE_BUILD_TYPE=Release?, ?..? >> ) >> > > There is add_custom_target(). > > You can e.g. add_custom_target(release ${CMAKE_COMMAND} -E echo > foobar) > and with the Makefiles generator run "make release" and with visual > studio trigger the build of the "release" project. > > For scripting you can use cmake in script mode with -P. > > e.g. given a script file release.cmake: > message("Hello World") > > add_custom_target(release ${CMAKE_COMMAND} -P > ${CMAKE_CURRENT_SOURCE_DIR}/release.cmake) > > Nils From digitalriptide at gmail.com Tue Dec 8 14:21:11 2015 From: digitalriptide at gmail.com (digitalriptide) Date: Tue, 8 Dec 2015 11:21:11 -0800 Subject: [CMake] target_include_directories SYSTEM adds -isystem to Clang, but not GCC In-Reply-To: <564F4A1E.60105@googlemail.com> References: <55D5EE6B.80405@googlemail.com> <564F4A1E.60105@googlemail.com> Message-ID: Thank you Gregor! I have tried the Makefile generator, but on OS X -isystem still seems to be missing with GCC. The -isystem flag appears with Clang, however. I have installed CMake 3.4.1 and GCC 5.3.0, both through MacPorts. I can provide a sample project, if that would help. On Fri, Nov 20, 2015 at 8:28 AM, Gregor Jasny wrote: > On 15/11/15 21:13, digitalriptide wrote: > >> Did this fix make it into 3.4? After upgrading to 3.4, GCC still seems >> to lack -isystem flags on OS X. Is there anything extra I need to do? >> > > It should be fixed for the Makefile and Ninja generators but not Xcode. > My proposed fix broke older Xcode versions so that I had to revert it > back. I did not find time to pick this up again. > > Thanks, > Gregor > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Tue Dec 8 19:59:41 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Wed, 9 Dec 2015 01:59:41 +0100 Subject: [CMake] Idea: generic task-driven make-like targets with CMake In-Reply-To: <81F99498-6B0D-43AC-832B-4A666996A4A5@kainjow.com> References: <56671FDF.6010902@gmail.com> <81F99498-6B0D-43AC-832B-4A666996A4A5@kainjow.com> Message-ID: Kevin, I have a shell script for such tasks, see https://gist.github.com/tamaskenez/d4509f240f4224eb9853. Feel free to use it if that's what you need. It extends the `cmake` command by executing multiple, related `cmake` calls with one command. See docs in gist. Your 'make release' example looks like this: cmakex cr -Hsourcedir -Bbuilddir # Configure Release with additional options you can do many tasks with one command cmakex cbitdr -Hsourcedir -Bbuilddir -GXcode # Configure, Build, Install, Test Debug & Release using Xcode Tamas On Tue, Dec 8, 2015 at 7:44 PM, Kevin Wojniak wrote: > Functionality like add_custom_target combined with script mode is close, > but not quite there. add_custom_target already requires a build directory > and a generator, so it?s too late. Script mode requires setting variables > on the command line, so it?s too verbose. For example: > > if(?${ACTION}? STREQUAL ?release?) > execute_process(?) > endif() > > cmake -P myscript.cmake -DACTION=release > > I suppose you could have multiple *.cmake files for each task, and those > could then call the master file with necessary variables set, but then > you?d need one file per task and that could become excessive. > > Kevin > > > > On 8 Dec 2015, at 10:22, Nils Gladitz wrote: > > On 08.12.2015 19:04, Kevin Wojniak wrote: >> >>> >>> add_task(release >>> COMMAND ${CMAKE_COMMAND} -E make_directory ?build_dir? >>> COMMAND ${CMAKE_COMMAND} -E chdir ?build_dir? ${CMAKE_COMMAND} >>> ?-DCMAKE_BUILD_TYPE=Release?, ?..? >>> ) >>> >>> >> There is add_custom_target(). >> >> You can e.g. add_custom_target(release ${CMAKE_COMMAND} -E echo foobar) >> and with the Makefiles generator run "make release" and with visual >> studio trigger the build of the "release" project. >> >> For scripting you can use cmake in script mode with -P. >> >> e.g. given a script file release.cmake: >> message("Hello World") >> >> add_custom_target(release ${CMAKE_COMMAND} -P >> ${CMAKE_CURRENT_SOURCE_DIR}/release.cmake) >> >> Nils >> > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Wed Dec 9 01:33:59 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Tue, 8 Dec 2015 22:33:59 -0800 (PST) Subject: [CMake] How to set _default_ timeout for the ctest command? Message-ID: For the lapack CMake-based build and test system, some of the ctests can exceed 1500 seconds (the default limit) for special conditions (e.g, a quadruple-precision build of lapack that can be very slow). To reduce such issues without forcing users to use the ctest --timeout option, the lapack developers would like to increase the default limit substantially above 1500 seconds. Does anyone here know how to do that? I guessed that setting CTEST_TEST_TIMEOUT might do that, but when I experimentally set that to a small number (actually 1) (just before the first add_test command of another project I am completely familiar with (PLplot, natch)) the ctests that ran beyond that one second limit did not error out (i.e., I presume they were still using the 1500 second default). Note, the ctests I am referring to are simply run using the ctest command from the command line and are not submitted to a dashboard server. I presume another way to do it would be to set the TIMEOUT test property for every ctest, but that constitutes a maintanence issue, i.e., it is a pretty clumsy way to do it. So any ideas for setting the default timeout (either higher or lower than 1500) for ctests would be welcome. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From loose at astron.nl Wed Dec 9 03:23:34 2015 From: loose at astron.nl (Marcel Loose) Date: Wed, 9 Dec 2015 09:23:34 +0100 Subject: [CMake] How to set _default_ timeout for the ctest command? In-Reply-To: References: Message-ID: <5667E506.9080801@astron.nl> Hi Alan, Just by experimenting, I discovered that you also need to set DART_TESTING_TIMEOUT. I'm not sure what the relationship (if any) is between CTEST_TEST_TIMEOUT and DART_TESTING_TIMEOUT. I set them both in the file CTestConfig.cmake. I get the feeling that DART_TESTING_TIMEOUT is there for less than historic reasons. Maybe someone from Kitware can shed a light on this. Regards, Marcel Loose. On 09/12/15 07:33, Alan W. Irwin wrote: > For the lapack CMake-based build and test system, some of the ctests > can exceed 1500 seconds (the default limit) for special conditions > (e.g, a quadruple-precision build of lapack that can be very slow). To > reduce such issues without forcing users to use the ctest --timeout > option, the lapack developers would like to > increase the default limit substantially above 1500 seconds. Does > anyone here know how to do that? > > I guessed that setting CTEST_TEST_TIMEOUT might do that, but when I > experimentally set that to a small number (actually 1) (just before > the first add_test command of another project I am completely familiar > with (PLplot, natch)) the ctests that ran beyond that one second limit > did not error out (i.e., I presume they were still using the 1500 > second default). Note, the ctests I am referring to are simply run > using the ctest command from the command line and are not submitted to > a dashboard server. > > I presume another way to do it would be to set the TIMEOUT test property > for every ctest, but that constitutes a maintanence issue, i.e., it > is a pretty clumsy way to do it. > > So any ideas for setting the default timeout (either higher or lower > than 1500) for ctests would be welcome. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and > Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: loose.vcf Type: text/x-vcard Size: 292 bytes Desc: not available URL: From demelier.david at gmail.com Wed Dec 9 09:50:13 2015 From: demelier.david at gmail.com (David Demelier) Date: Wed, 9 Dec 2015 15:50:13 +0100 Subject: [CMake] How to select components by default using CPack ? Message-ID: <56683FA5.1000908@gmail.com> Hello, I'm trying to create a tree of components like this: - plugins | - a | - b Where the user can select plugins to select all children or manually select a, b. I can get the selection of that component tree but unable to mark them selected by default using CPackIFW. This is my current CMakeLists.txt: cmake_minimum_required(VERSION 3.2) project(test) set(CPACK_PACKAGE_NAME Hello) set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "Hello world using IFW") set(CPACK_PACKAGE_VERSION "1.0.0") set(CPACK_GENERATOR "IFW") set(PLUGINS one two) foreach (plugin ${PLUGINS}) install( FILES ${plugin}.js COMPONENT plugin_${plugin} DESTINATION plugins ) list(APPEND CPACK_COMPONENTS_ALL plugin_${plugin}) endforeach () include(CPack) include(CPackIFW) cpack_add_component_group(plugins) foreach (plugin ${PLUGINS}) cpack_add_component_group( plugin_group_${plugin} PARENT_GROUP plugins DISPLAY_NAME "${plugin}" DESCRIPTION "Install ${plugin}.js" ) cpack_add_component(plugin_${plugin} GROUP plugin_group_${plugin}) endforeach () The CMakeLists.txt just expect to have one.js and two.js in the top-level directory. Can you please tell me what I'm doing wrong? Regards, -- David Demelier From sluge at mail.ru Wed Dec 9 08:32:19 2015 From: sluge at mail.ru (=?UTF-8?B?SWdvciBTb2Jpbm92?=) Date: Wed, 09 Dec 2015 16:32:19 +0300 Subject: [CMake] =?utf-8?q?Parallel_jobs_failed_for_cmake?= Message-ID: <1449667939.717612735@f323.i.mail.ru> Hello, I compiled cmake based project with -jN option, but failed: I got the following error: make[4]: warning: jobserver unavailable: using -j1. ?Add `+' to parent make rule. How to make cmake to compile with multiple targets? Bye, Igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From hobbes1069 at gmail.com Wed Dec 9 09:57:33 2015 From: hobbes1069 at gmail.com (Richard Shaw) Date: Wed, 9 Dec 2015 08:57:33 -0600 Subject: [CMake] Parallel jobs failed for cmake In-Reply-To: <1449667939.717612735@f323.i.mail.ru> References: <1449667939.717612735@f323.i.mail.ru> Message-ID: On Wed, Dec 9, 2015 at 7:32 AM, Igor Sobinov wrote: > Hello, > > I compiled cmake based project with -jN option, but failed: I got the > following error: > > make[4]: warning: jobserver unavailable: using -j1. Add `+' to parent > make rule. > > How to make cmake to compile with multiple targets? > Are you using the ExternalProject module? A little more detail would be helpful. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Wed Dec 9 10:15:48 2015 From: d3ck0r at gmail.com (J Decker) Date: Wed, 9 Dec 2015 07:15:48 -0800 Subject: [CMake] Parallel jobs failed for cmake In-Reply-To: <1449667939.717612735@f323.i.mail.ru> References: <1449667939.717612735@f323.i.mail.ru> Message-ID: On Wed, Dec 9, 2015 at 5:32 AM, Igor Sobinov wrote: > Hello, > > I compiled cmake based project with -jN option, but failed: I got the > following error: > > make[4]: warning: jobserver unavailable: using -j1. Add `+' to parent make > rule. > That is actually only a warning.... ?warning: jobserver unavailable: using -j1. Add `+' to parent make rule.? In order for make processes to communicate, the parent will pass information to the child. Since this could result in problems if the child process isn?t actually a make, the parent will only do this if it thinks the child is a make. The parent uses the normal algorithms to determine this (see How the MAKE Variable Works). If the makefile is constructed such that the parent doesn?t know the child is a make process, then the child will receive only part of the information necessary. In this case, the child will generate this warning message and proceed with its build in a sequential manner. Probably you're building on windows; which doesn't do 'fork' so it's not possible to parallel make, and you'll have to suffer with single-target makes. It's slower but doesn't cause 'issues'. Maybe grab Visual Studio community edition target that instead which is able to parallel make... I think Ninja handles parallel makes also(?). > How to make cmake to compile with multiple targets? > > Bye, Igor > > -- > > 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 From robert.bielik at dirac.se Wed Dec 9 10:56:40 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Wed, 9 Dec 2015 16:56:40 +0100 Subject: [CMake] CPack and PackageMaker Message-ID: <56684F38.1090201@dirac.se> Mac OSX: Since PackageMaker has been deprecated by Apple, the new tools to use are pkgbuild [1] and productbuild [2]. Simple question: Is there any work being done by the CMake community on a new OS X CPack backend to support the above tools ? Regards /Robert [1] https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html [2] https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html From rcdailey.lists at gmail.com Wed Dec 9 11:23:59 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 9 Dec 2015 10:23:59 -0600 Subject: [CMake] Toolset target property? Message-ID: Doesn't look like there is a Toolset target property anywhere. You can set it from the command line, but I think setting a toolset per target makes sense. Considering the direction that Visual Studio 2015 is headed. For example Microsoft has a Clang compiler with MS CodeGen. They recommend using this toolset with the platform agnostic targets, and using normal MSVC with windows-specific targets (for example, CLR projects). This requires setting a toolset per target. Does this feature make sense from the CMake perspective? From kainjow at kainjow.com Wed Dec 9 12:43:26 2015 From: kainjow at kainjow.com (Kevin Wojniak) Date: Wed, 09 Dec 2015 09:43:26 -0800 Subject: [CMake] Idea: generic task-driven make-like targets with CMake In-Reply-To: References: <56671FDF.6010902@gmail.com> <81F99498-6B0D-43AC-832B-4A666996A4A5@kainjow.com> Message-ID: <69258096-CD1D-43B4-B897-7BB8AD9A5696@kainjow.com> Looks interesting Tamas! Too bad shell scripts don?t work natively on Windows :) Kevin On 8 Dec 2015, at 16:59, Tam?s Ken?z wrote: > Kevin, I have a shell script for such tasks, see > https://gist.github.com/tamaskenez/d4509f240f4224eb9853. Feel free to > use > it if that's what you need. > It extends the `cmake` command by executing multiple, related `cmake` > calls > with one command. See docs in gist. > > Your 'make release' example looks like this: > > cmakex cr -Hsourcedir -Bbuilddir # Configure Release > > with additional options you can do many tasks with one command > > cmakex cbitdr -Hsourcedir -Bbuilddir -GXcode # Configure, Build, > Install, Test Debug & Release using Xcode > > Tamas > > On Tue, Dec 8, 2015 at 7:44 PM, Kevin Wojniak > wrote: > >> Functionality like add_custom_target combined with script mode is >> close, >> but not quite there. add_custom_target already requires a build >> directory >> and a generator, so it?s too late. Script mode requires setting >> variables >> on the command line, so it?s too verbose. For example: >> >> if(?${ACTION}? STREQUAL ?release?) >> execute_process(?) >> endif() >> >> cmake -P myscript.cmake -DACTION=release >> >> I suppose you could have multiple *.cmake files for each task, and >> those >> could then call the master file with necessary variables set, but >> then >> you?d need one file per task and that could become excessive. >> >> Kevin >> >> >> >> On 8 Dec 2015, at 10:22, Nils Gladitz wrote: >> >> On 08.12.2015 19:04, Kevin Wojniak wrote: >>> >>>> >>>> add_task(release >>>> COMMAND ${CMAKE_COMMAND} -E make_directory ?build_dir? >>>> COMMAND ${CMAKE_COMMAND} -E chdir ?build_dir? ${CMAKE_COMMAND} >>>> ?-DCMAKE_BUILD_TYPE=Release?, ?..? >>>> ) >>>> >>>> >>> There is add_custom_target(). >>> >>> You can e.g. add_custom_target(release ${CMAKE_COMMAND} -E echo >>> foobar) >>> and with the Makefiles generator run "make release" and with visual >>> studio trigger the build of the "release" project. >>> >>> For scripting you can use cmake in script mode with -P. >>> >>> e.g. given a script file release.cmake: >>> message("Hello World") >>> >>> add_custom_target(release ${CMAKE_COMMAND} -P >>> ${CMAKE_CURRENT_SOURCE_DIR}/release.cmake) >>> >>> Nils >>> >> -- >> >> 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 >> From normand.robert at sri.utoronto.ca Wed Dec 9 12:22:51 2015 From: normand.robert at sri.utoronto.ca (Normand Robert) Date: Wed, 9 Dec 2015 12:22:51 -0500 Subject: [CMake] CMake target_link_libraries items should be quoted or not? Linux/Ubuntu 14.04 cmake 3.4.1 Message-ID: <5668636B.7030104@sri.utoronto.ca> robert at kalymnos:~/Code/Debug/normandBuild$ cmake --version cmake version 3.4.1 Reading docs trying to understand why my build works when I write target_link_libraries(Debug ${VTK_LIBRARIES} -lsri-spatialfft -lsri-spatial -lsri-memory) but not when everything is protected in quotes: target_link_libraries(Debug "${VTK_LIBRARIES} -lsri-spatialfft -lsri-spatial -lsri-memory") which causes an extra library which does not exist to be passed to the linker. Is this expected behaviour? -- Normand Robert PhD Sunnybrook Health Sciences Centre Room S632, 2075 Bayview Avenue, Toronto, ON M4N 3M5 From normand.robert at sri.utoronto.ca Wed Dec 9 12:25:41 2015 From: normand.robert at sri.utoronto.ca (Normand Robert) Date: Wed, 9 Dec 2015 12:25:41 -0500 Subject: [CMake] CMake target_link_libraries() items should be quoted or not? Linux/Ubuntu 14.04 cmake 3.4.1 Message-ID: <56686415.4020900@sri.utoronto.ca> Reading docs trying to understand why my build works when I write target_link_libraries(Debug ${VTK_LIBRARIES} -lsri-spatialfft -lsri-spatial -lsri-memory) but does not work when everything is protected in quotes: target_link_libraries(Debug "${VTK_LIBRARIES} -lsri-spatialfft -lsri-spatial -lsri-memory") which causes an extra library which does not exist to be passed to the linker. Is this expected behaviour? robert at kalymnos:~/Code/Debug/normandBuild$ cmake --version cmake version 3.4.1 -- Normand Robert PhD Sunnybrook Health Sciences Centre Room S632, 2075 Bayview Avenue, Toronto, ON M4N 3M5 From tamas.kenez at gmail.com Wed Dec 9 13:20:05 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Wed, 9 Dec 2015 19:20:05 +0100 Subject: [CMake] Idea: generic task-driven make-like targets with CMake In-Reply-To: <69258096-CD1D-43B4-B897-7BB8AD9A5696@kainjow.com> References: <56671FDF.6010902@gmail.com> <81F99498-6B0D-43AC-832B-4A666996A4A5@kainjow.com> <69258096-CD1D-43B4-B897-7BB8AD9A5696@kainjow.com> Message-ID: [getting offtopic] Well, not because of this script but for any serious development on Windows I think it's a good idea to use the *nix shell provided by the Windows Git installation, it feels quite native. Together with cbucher's ConsoleZ you get a very convenient environment for cmake/command-line centered development, even when working with VS IDE. On Wed, Dec 9, 2015 at 6:43 PM, Kevin Wojniak wrote: > Looks interesting Tamas! Too bad shell scripts don?t work natively on > Windows :) > > Kevin > > > > > On 8 Dec 2015, at 16:59, Tam?s Ken?z wrote: > > Kevin, I have a shell script for such tasks, see >> https://gist.github.com/tamaskenez/d4509f240f4224eb9853. Feel free to use >> it if that's what you need. >> It extends the `cmake` command by executing multiple, related `cmake` >> calls >> with one command. See docs in gist. >> >> Your 'make release' example looks like this: >> >> cmakex cr -Hsourcedir -Bbuilddir # Configure Release >> >> with additional options you can do many tasks with one command >> >> cmakex cbitdr -Hsourcedir -Bbuilddir -GXcode # Configure, Build, >> Install, Test Debug & Release using Xcode >> >> Tamas >> >> On Tue, Dec 8, 2015 at 7:44 PM, Kevin Wojniak >> wrote: >> >> Functionality like add_custom_target combined with script mode is close, >>> but not quite there. add_custom_target already requires a build directory >>> and a generator, so it?s too late. Script mode requires setting variables >>> on the command line, so it?s too verbose. For example: >>> >>> if(?${ACTION}? STREQUAL ?release?) >>> execute_process(?) >>> endif() >>> >>> cmake -P myscript.cmake -DACTION=release >>> >>> I suppose you could have multiple *.cmake files for each task, and those >>> could then call the master file with necessary variables set, but then >>> you?d need one file per task and that could become excessive. >>> >>> Kevin >>> >>> >>> >>> On 8 Dec 2015, at 10:22, Nils Gladitz wrote: >>> >>> On 08.12.2015 19:04, Kevin Wojniak wrote: >>> >>>> >>>> >>>>> add_task(release >>>>> COMMAND ${CMAKE_COMMAND} -E make_directory ?build_dir? >>>>> COMMAND ${CMAKE_COMMAND} -E chdir ?build_dir? ${CMAKE_COMMAND} >>>>> ?-DCMAKE_BUILD_TYPE=Release?, ?..? >>>>> ) >>>>> >>>>> >>>>> There is add_custom_target(). >>>> >>>> You can e.g. add_custom_target(release ${CMAKE_COMMAND} -E echo foobar) >>>> and with the Makefiles generator run "make release" and with visual >>>> studio trigger the build of the "release" project. >>>> >>>> For scripting you can use cmake in script mode with -P. >>>> >>>> e.g. given a script file release.cmake: >>>> message("Hello World") >>>> >>>> add_custom_target(release ${CMAKE_COMMAND} -P >>>> ${CMAKE_CURRENT_SOURCE_DIR}/release.cmake) >>>> >>>> Nils >>>> >>>> -- >>> >>> 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 >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From humberto at solusrobots.com Wed Dec 9 14:18:37 2015 From: humberto at solusrobots.com (Humberto H`) Date: Wed, 9 Dec 2015 14:18:37 -0500 (EST) Subject: [CMake] To Post to the "CMake" Mailing List Message-ID: <472278003.246133.1449688717465.JavaMail.open-xchange@oxusgaltgw03.schlund.de> An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Wed Dec 9 15:39:03 2015 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 9 Dec 2015 21:39:03 +0100 Subject: [CMake] target_include_directories SYSTEM adds -isystem to Clang, but not GCC In-Reply-To: References: <55D5EE6B.80405@googlemail.com> <564F4A1E.60105@googlemail.com> Message-ID: <56689167.20207@googlemail.com> On 08/12/15 20:21, digitalriptide wrote: > Thank you Gregor! I have tried the Makefile generator, but on OS X -isystem > still seems to be missing with GCC. The -isystem flag appears with Clang, > however. I have installed CMake 3.4.1 and GCC 5.3.0, both through MacPorts. > I can provide a sample project, if that would help. Please file a bug report and attach your test case. That way it does not get lost. Thanks, Gregor From gurenchan at gmail.com Wed Dec 9 18:07:48 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Thu, 10 Dec 2015 07:07:48 +0800 Subject: [CMake] organizing includes statements Message-ID: hi I am building a shared library project that's composed of many smaller shared library files. Here's the main shared library project and a list of all the sub projects. SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/main_lib.h) SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/main_lib.c) SET(TARGET_LIBS core_math point2d line2d quad2d timer_utils) ADD_LIBRARY(main_lib SHARED ${SRC_FILES} ${HEADER_FILES}) TARGET_LINK_LIBRARIES(core_engine ${TARGET_LIBS}) i have each module setup like this. module module/headers/module.h module/module.c then the module.c will look like this #include "headers/module.h" the file main_lib.h depends on all those target libs, which makes my main_lib.h file's include statement look like this #include "../../module/headers/module.h" #include "../../module1/headers/module1.h" #include "../../module2/headers/module2.h" is there any way that I can clean up these includes? For example if I want to use io functions I can just do #include or #include for math functions. I would like to make my include statements not relative to the files actual location, the way it's currently hard coded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Wed Dec 9 22:06:00 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 9 Dec 2015 19:06:00 -0800 (PST) Subject: [CMake] How to set _default_ timeout for the ctest command? In-Reply-To: <5667E506.9080801@astron.nl> References: <5667E506.9080801@astron.nl> Message-ID: On 2015-12-09 09:23+0100 Marcel Loose wrote: > Hi Alan, > > Just by experimenting, I discovered that you also need to set > DART_TESTING_TIMEOUT. I'm not sure what the relationship (if any) is > between CTEST_TEST_TIMEOUT and DART_TESTING_TIMEOUT. I set them both in > the file CTestConfig.cmake. I get the feeling that DART_TESTING_TIMEOUT > is there for less than historic reasons. Maybe someone from Kitware can > shed a light on this. Thanks, Marcel, for trying those experiments. I tried some additional experiments and found that all that is needed is to set the CTEST_TEST_TIMEOUT value before CTest is included in my top-level CMakeLists.txt file. (My previous experiment set that value after the include, but before the first add_test command.) Note that I do not use CTestConfig.cmake at all. So the current experimental logic is # Control the default timeout for all ctests. set(CTEST_TEST_TIMEOUT 1) include(CTest) Those commands generate the following timeout results in the build tree. software at raven> find . -type f |xargs grep -i timeout ./CMakeCache.txt:DART_TESTING_TIMEOUT:STRING=1 ./CMakeCache.txt://ADVANCED property for variable: DART_TESTING_TIMEOUT ./CMakeCache.txt:DART_TESTING_TIMEOUT-ADVANCED:INTERNAL=1 ./DartConfiguration.tcl:# TimeOut is the amount of time in seconds to wait for processes ./DartConfiguration.tcl:# to complete during testing. After TimeOut seconds, the ./DartConfiguration.tcl:TimeOut: 1 ./DartConfiguration.tcl:# For CTest submissions that timeout, these options So for this case, DART_TESTING_TIMEOUT is automatically set to the specified CTEST_TEST_TIMEOUT value. (If CTEST_TEST_TIMEOUT is not set, the cached value of DART_TESTING_TIMEOUT is 1500, and the value of the timeout in DartConfiguration.tcl is also set to 1500). Afterwards, ctest timed out at 1 second for all tests that exceeded that value, but it turns out that is a hard-coded value which cannot be superseded by the ctest --timeout option. So this approach is not really ideal for the lapack developers who will want to increase the default limit by only an order of magnitude or less to substantially reduce the probability someone with a slow computer or special circumstances will have to override using the ctest --timeout option, but that change likely will not reduce that probability to zero so keeping the ability to override the lapack timeout default by the ctest --timeout option is still likely imporatant to them. @CMake developers: The documentation of CTEST_TEST_TIMEOUT (and DART_TESTING_TIMEOUT) includes the following language: "The default timeout for each test if not specified by the `TIMEOUT` test property. Also, the documentation of the ctest --timeout option says: `--timeout ` Set a global timeout on all tests. This option will set a global timeout on all tests that do not already have a timeout set on them. So I guess it could be argued that CTEST_TEST_TIMEOUT does impose a specific timeout on all tests, and that is why the --timeout option is being ignored for this case. But that is not particularly useful behaviour, and it would be far better in my opinion for the --timeout option to work for all tests where the TIMEOUT test property has not been specifically set by the project's build system. I would appreciate some further investigation of these matters by a knowledgable CMake developer, and if it turns out this issue is actually caused by a cmake or ctest bug, then I would be willing to write up the appropriate bug report if it turns out an instantaneous fix could not be made. I also tried the experiment of dropping the setting of CTEST_TEST_TIMEOUT and using set_tests_properties to set the TIMEOUT for individual commands, but consistent with the above wording of the documentation, the ctest --timeout option was ignored for this case. I am OK with that limitation so long (see above) as some change is made so CTEST_TEST_TIMEOUT is interpreted exactly the same as the 1500 default timeout, i.e., the CTEST_TEST_TIMEOUT value can be overridden by the ctest --timeout option. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From dave2008713 at gmail.com Wed Dec 9 23:35:11 2015 From: dave2008713 at gmail.com (Qingping Hou) Date: Wed, 9 Dec 2015 20:35:11 -0800 Subject: [CMake] How to set environment variables with spaces in commands Message-ID: Hi all, I am trying to setup an ExternalProject in cmake but got stuck in the configuration step. I am using ccache to speed up the compilation: ``` ExternalProject_Add( ... CONFIGURE_COMMAND CC="ccache arm-linux-gnueabihf-gcc" ./configure ... ) ``` However, when cmake generates the Makefile, it moves the quotes around and breaks the command: ``` "CC=ccache arm-linux-gnueabihf-gcc" ./configure ``` I have tried various escaping method to try to get it work properly without any luck. Is this a bug or an unintended feature? Thanks, QP From sluge at mail.ru Thu Dec 10 00:19:10 2015 From: sluge at mail.ru (=?UTF-8?B?SWdvciBTb2Jpbm92?=) Date: Thu, 10 Dec 2015 08:19:10 +0300 Subject: [CMake] =?utf-8?q?Parallel_jobs_failed_for_cmake?= In-Reply-To: <1449676663.3241.78.camel@mad-scientist.net> References: <1449667939.717612735@f323.i.mail.ru> <1449676663.3241.78.camel@mad-scientist.net> Message-ID: <1449724750.194715377@f401.i.mail.ru> Hello All, Here is the small description of the issue: OS: RHEL 6.6 cmake ver.?2.8.12.2 gmake ver.?3.81 I launch the build and got the following error: make build_release -j5 make[1]: Entering directory `/home/igor/build_root/release_target' make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. So, make[1] reported that's job server is unavailable. Here is typical process subtree of my make: root 1731 0.0 0.0 66688 580 ? Ss Nov18 0:00 /usr/sbin/sshd root 30968 0.0 0.0 100436 4744 ? Ss 07:44 0:00 \_ sshd: root at pts/3 root 30975 0.0 0.0 108432 1888 pts/3 Ss 07:44 0:00 | \_ -bash root 31043 0.0 0.0 163856 2212 pts/3 S 07:49 0:00 | \_ su - igor igor 31045 0.0 0.0 108472 1896 pts/3 S 07:49 0:00 | \_ -bash igor 5460 0.0 0.0 101152 972 pts/3 S+ 08:10 0:00 | \_ make build_release -j5 igor 5466 0.0 0.0 106096 1164 pts/3 S+ 08:10 0:00 | \_ /bin/sh -c cd /home/igor/build_root/release_target; make release igor 5467 0.0 0.0 101184 1060 pts/3 S+ 08:10 0:00 | \_ make release igor 5470 0.0 0.0 101448 1256 pts/3 S+ 08:10 0:00 | \_ make -f CMakeFiles/Makefile2 release igor 5475 0.0 0.0 101448 1260 pts/3 S+ 08:10 0:00 | \_ make -f CMakeFiles/Makefile2 install/CMakeFiles/release.dir/all igor 5480 0.0 0.0 101052 944 pts/3 S+ 08:10 0:00 | \_ make -f CMakeFiles/make_install.dir/build.make CMakeFiles/make_install.dir/build igor 5481 0.0 0.0 101184 1020 pts/3 S+ 08:10 0:00 | \_ make install igor 5486 0.0 0.0 101448 1256 pts/3 S+ 08:10 0:00 | \_ make -f CMakeFiles/Makefile2 all igor 5880 6.3 0.1 106980 6892 pts/3 S+ 08:11 0:00 | \_ make -f mydaemon/CMakeFiles/snmp.dir/build.make mydaemon/CMakeFiles/snmp.dir/build Hope it helps to find the issue Regards, Igor >?????, 9 ??????? 2015, 10:57 -05:00 ?? Paul Smith : > >On Wed, 2015-12-09 at 07:15 -0800, J Decker wrote: >> Probably you're building on windows; which doesn't do 'fork' so it's >> not possible to parallel make, and you'll have to suffer with >> single-target makes. > >You just need a newer version of GNU make. GNU make for Windows has >supported the jobserver feature since GNU make 4.0 (released in October >2013). There were some issues with that release so I recommend getting >4.1, the latest. There are pre-built versions available for download >from various places, such as Eli's archives: > >http://sourceforge.net/projects/ezwinports/files/make-4.1-2-without-gui >le-w32-bin.zip/download > >http://sourceforge.net/projects/ezwinports/files/make-4.1-2-with-guile- >w32-bin.zip/download Bye, Igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Thu Dec 10 00:46:48 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Thu, 10 Dec 2015 06:46:48 +0100 Subject: [CMake] organizing includes statements In-Reply-To: References: Message-ID: Hi Owen, This seems like a textbook example of using target_include_directories(?) with generator expressions. Let?s take the example where: lib1/headers/lib1.h lib1/lib1.c lib2/headers/lib2.h lib2/lib2.c If you want to be able to include lib1.h and lib2.h with simply #include ?lib1.h? and #include ?lib2.h? in your user code, and in the library code itself, you?d do something like: add_library( lib1 SHARED lib1/lib1.c ) target_include_directories( lib1 PUBLIC $ $ ) add_library( lib2 SHARED lib2/lib2.c ) target_include_directories( lib2 PUBLIC $ $ ) target_link_libraries( lib2 lib1 ) install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include ) install( TARGETS lib1 lib2 DESTINATION lib ) In this setup ?lib1? should get a -I${CMAKE_SOURCE_DIR}/lib1/headers flag, and ?lib2? should get both -I${CMAKE_SOURCE_DIR}/lib1/headers and -I${CMAKE_SOURCE_DIR}/lib2/headers. Finally the headers both get installed into the same include directory, so an outside user will just have to be able to find that one directory. (Or if you export CMake?s targets, the lib1/2 imported targets will know that their header files are in that directory.) Cheers, Attila > On Dec 10, 2015, at 12:07 AM, Owen Alanzo Hogarth wrote: > > hi > > I am building a shared library project that's composed of many smaller shared library files. > > Here's the main shared library project and a list of all the sub projects. > > SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/main_lib.h) > SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/main_lib.c) > SET(TARGET_LIBS core_math point2d line2d quad2d timer_utils) > > ADD_LIBRARY(main_lib SHARED ${SRC_FILES} ${HEADER_FILES}) > TARGET_LINK_LIBRARIES(core_engine ${TARGET_LIBS}) > > i have each module setup like this. > module > module/headers/module.h > module/module.c > > then the module.c will look like this > #include "headers/module.h" > > the file main_lib.h depends on all those target libs, which makes my main_lib.h file's include statement look like this > > #include "../../module/headers/module.h" > #include "../../module1/headers/module1.h" > #include "../../module2/headers/module2.h" > > > is there any way that I can clean up these includes? > > For example if I want to use io functions I can just do #include or #include > > for math functions. > > I would like to make my include statements not relative to the files actual location, the way it's currently hard coded. > -- > > 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 From attila.krasznahorkay at gmail.com Thu Dec 10 00:52:57 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Thu, 10 Dec 2015 06:52:57 +0100 Subject: [CMake] How to set environment variables with spaces in commands In-Reply-To: References: Message-ID: <7BE45809-B42D-42CD-AC30-4368852D99BA@gmail.com> Hi QP, Probably not the intended solution, but what I?m doing in such cases is that in a patch step I create a shell script that does the configuration for me. With all the environment settings and everything. Like: PATCH_COMMAND ${CMAKE_COMMAND} -E echo ?cd someDir/; CC=\?something\? ./configure? > configure.sh CONFIGURE_COMMAND sh configure.sh Unfortunately this makes the code quite unportable, as it will only work on POSIX platforms like this. But I guess that?s the case anyway once you start setting environment variables. Cheers, Attila P.S. I often create build.sh and install.sh scripts as well in additional patch commands. > On Dec 10, 2015, at 5:35 AM, Qingping Hou wrote: > > Hi all, > > I am trying to setup an ExternalProject in cmake but got stuck in the > configuration step. I am using ccache to speed up the compilation: > > ``` > ExternalProject_Add( > ... > CONFIGURE_COMMAND CC="ccache arm-linux-gnueabihf-gcc" ./configure > ... > ) > ``` > > However, when cmake generates the Makefile, it moves the quotes around > and breaks the command: > > ``` > "CC=ccache arm-linux-gnueabihf-gcc" ./configure > ``` > > I have tried various escaping method to try to get it work properly > without any luck. Is this a bug or an unintended feature? > > Thanks, > QP > -- > > 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 From gurenchan at gmail.com Thu Dec 10 02:48:03 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Thu, 10 Dec 2015 15:48:03 +0800 Subject: [CMake] organizing includes statements In-Reply-To: References: Message-ID: my main CMakeLists.txt file already has a few directives that move the libs to an output folder so the binaries go to /bin while static and shared libraries go to /lib set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) it seems like this line in your reply above install( TARGETS lib1 lib2 DESTINATION lib ) moves the shared libraries to the lib folder and this line below moves the header files to the newly created include directory. install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include ) is that right? On Thu, Dec 10, 2015 at 1:46 PM, Attila Krasznahorkay < attila.krasznahorkay at gmail.com> wrote: > Hi Owen, > > This seems like a textbook example of using target_include_directories(?) > with generator expressions. Let?s take the example where: > > lib1/headers/lib1.h > lib1/lib1.c > lib2/headers/lib2.h > lib2/lib2.c > > If you want to be able to include lib1.h and lib2.h with simply > > #include ?lib1.h? > > and > > #include ?lib2.h? > > in your user code, and in the library code itself, you?d do something like: > > add_library( lib1 SHARED lib1/lib1.c ) > target_include_directories( lib1 PUBLIC > $ > $ ) > > add_library( lib2 SHARED lib2/lib2.c ) > target_include_directories( lib2 PUBLIC > $ > $ ) > target_link_libraries( lib2 lib1 ) > > install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include > ) > install( TARGETS lib1 lib2 DESTINATION lib ) > > In this setup ?lib1? should get a -I${CMAKE_SOURCE_DIR}/lib1/headers flag, > and ?lib2? should get both -I${CMAKE_SOURCE_DIR}/lib1/headers and > -I${CMAKE_SOURCE_DIR}/lib2/headers. Finally the headers both get installed > into the same include directory, so an outside user will just have to be > able to find that one directory. (Or if you export CMake?s targets, the > lib1/2 imported targets will know that their header files are in that > directory.) > > Cheers, > Attila > > > On Dec 10, 2015, at 12:07 AM, Owen Alanzo Hogarth > wrote: > > > > hi > > > > I am building a shared library project that's composed of many smaller > shared library files. > > > > Here's the main shared library project and a list of all the sub > projects. > > > > SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/main_lib.h) > > SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/main_lib.c) > > SET(TARGET_LIBS core_math point2d line2d quad2d timer_utils) > > > > ADD_LIBRARY(main_lib SHARED ${SRC_FILES} ${HEADER_FILES}) > > TARGET_LINK_LIBRARIES(core_engine ${TARGET_LIBS}) > > > > i have each module setup like this. > > module > > module/headers/module.h > > module/module.c > > > > then the module.c will look like this > > #include "headers/module.h" > > > > the file main_lib.h depends on all those target libs, which makes my > main_lib.h file's include statement look like this > > > > #include "../../module/headers/module.h" > > #include "../../module1/headers/module1.h" > > #include "../../module2/headers/module2.h" > > > > > > is there any way that I can clean up these includes? > > > > For example if I want to use io functions I can just do #include > or #include > > > > for math functions. > > > > I would like to make my include statements not relative to the files > actual location, the way it's currently hard coded. > > -- > > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iosif.neitzke+cmake at gmail.com Thu Dec 10 03:08:04 2015 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Thu, 10 Dec 2015 02:08:04 -0600 Subject: [CMake] organizing includes statements In-Reply-To: References: Message-ID: I would think add_library( lib1 SHARED lib1/lib1.c ) target_include_directories( lib1 PUBLIC lib1/headers ) is simpler. Are the generator expressions needed for target export install commands, and is exporting targets at install preferred to add_subdirectory() ? On Thu, Dec 10, 2015 at 1:48 AM, Owen Alanzo Hogarth wrote: > my main CMakeLists.txt file already has a few directives that move the libs > to an output folder so the binaries go to /bin while static and shared > libraries go to /lib > > set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) > set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) > set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) > > > it seems like this line in your reply above > install( TARGETS lib1 lib2 DESTINATION lib ) > > moves the shared libraries to the lib folder and this line below moves the > header files to the newly created include directory. > > install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include ) > > is that right? > > On Thu, Dec 10, 2015 at 1:46 PM, Attila Krasznahorkay > wrote: >> >> Hi Owen, >> >> This seems like a textbook example of using target_include_directories(?) >> with generator expressions. Let?s take the example where: >> >> lib1/headers/lib1.h >> lib1/lib1.c >> lib2/headers/lib2.h >> lib2/lib2.c >> >> If you want to be able to include lib1.h and lib2.h with simply >> >> #include ?lib1.h? >> >> and >> >> #include ?lib2.h? >> >> in your user code, and in the library code itself, you?d do something >> like: >> >> add_library( lib1 SHARED lib1/lib1.c ) >> target_include_directories( lib1 PUBLIC >> $ >> $ ) >> >> add_library( lib2 SHARED lib2/lib2.c ) >> target_include_directories( lib2 PUBLIC >> $ >> $ ) >> target_link_libraries( lib2 lib1 ) >> >> install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include >> ) >> install( TARGETS lib1 lib2 DESTINATION lib ) >> >> In this setup ?lib1? should get a -I${CMAKE_SOURCE_DIR}/lib1/headers flag, >> and ?lib2? should get both -I${CMAKE_SOURCE_DIR}/lib1/headers and >> -I${CMAKE_SOURCE_DIR}/lib2/headers. Finally the headers both get installed >> into the same include directory, so an outside user will just have to be >> able to find that one directory. (Or if you export CMake?s targets, the >> lib1/2 imported targets will know that their header files are in that >> directory.) >> >> Cheers, >> Attila >> >> > On Dec 10, 2015, at 12:07 AM, Owen Alanzo Hogarth >> > wrote: >> > >> > hi >> > >> > I am building a shared library project that's composed of many smaller >> > shared library files. >> > >> > Here's the main shared library project and a list of all the sub >> > projects. >> > >> > SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/main_lib.h) >> > SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/main_lib.c) >> > SET(TARGET_LIBS core_math point2d line2d quad2d timer_utils) >> > >> > ADD_LIBRARY(main_lib SHARED ${SRC_FILES} ${HEADER_FILES}) >> > TARGET_LINK_LIBRARIES(core_engine ${TARGET_LIBS}) >> > >> > i have each module setup like this. >> > module >> > module/headers/module.h >> > module/module.c >> > >> > then the module.c will look like this >> > #include "headers/module.h" >> > >> > the file main_lib.h depends on all those target libs, which makes my >> > main_lib.h file's include statement look like this >> > >> > #include "../../module/headers/module.h" >> > #include "../../module1/headers/module1.h" >> > #include "../../module2/headers/module2.h" >> > >> > >> > is there any way that I can clean up these includes? >> > >> > For example if I want to use io functions I can just do #include >> > or #include >> > >> > for math functions. >> > >> > I would like to make my include statements not relative to the files >> > actual location, the way it's currently hard coded. >> > -- >> > >> > 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 From gurenchan at gmail.com Thu Dec 10 03:13:13 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Thu, 10 Dec 2015 16:13:13 +0800 Subject: [CMake] organizing includes statements In-Reply-To: References: Message-ID: oh cool adding target_include_directories(lib1 PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/headers) and then I can just use #include "lib1" where needed. No more of those very static paths! Thank you very much! On Thu, Dec 10, 2015 at 4:08 PM, iosif neitzke < iosif.neitzke+cmake at gmail.com> wrote: > I would think > > add_library( lib1 SHARED lib1/lib1.c ) > target_include_directories( lib1 PUBLIC lib1/headers ) > > is simpler. Are the generator expressions needed for target export > install commands, and is exporting targets at install preferred to > add_subdirectory() ? > > On Thu, Dec 10, 2015 at 1:48 AM, Owen Alanzo Hogarth > wrote: > > my main CMakeLists.txt file already has a few directives that move the > libs > > to an output folder so the binaries go to /bin while static and shared > > libraries go to /lib > > > > set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) > > set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) > > set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) > > > > > > it seems like this line in your reply above > > install( TARGETS lib1 lib2 DESTINATION lib ) > > > > moves the shared libraries to the lib folder and this line below moves > the > > header files to the newly created include directory. > > > > install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION > include ) > > > > is that right? > > > > On Thu, Dec 10, 2015 at 1:46 PM, Attila Krasznahorkay > > wrote: > >> > >> Hi Owen, > >> > >> This seems like a textbook example of using > target_include_directories(?) > >> with generator expressions. Let?s take the example where: > >> > >> lib1/headers/lib1.h > >> lib1/lib1.c > >> lib2/headers/lib2.h > >> lib2/lib2.c > >> > >> If you want to be able to include lib1.h and lib2.h with simply > >> > >> #include ?lib1.h? > >> > >> and > >> > >> #include ?lib2.h? > >> > >> in your user code, and in the library code itself, you?d do something > >> like: > >> > >> add_library( lib1 SHARED lib1/lib1.c ) > >> target_include_directories( lib1 PUBLIC > >> $ > >> $ ) > >> > >> add_library( lib2 SHARED lib2/lib2.c ) > >> target_include_directories( lib2 PUBLIC > >> $ > >> $ ) > >> target_link_libraries( lib2 lib1 ) > >> > >> install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION > include > >> ) > >> install( TARGETS lib1 lib2 DESTINATION lib ) > >> > >> In this setup ?lib1? should get a -I${CMAKE_SOURCE_DIR}/lib1/headers > flag, > >> and ?lib2? should get both -I${CMAKE_SOURCE_DIR}/lib1/headers and > >> -I${CMAKE_SOURCE_DIR}/lib2/headers. Finally the headers both get > installed > >> into the same include directory, so an outside user will just have to be > >> able to find that one directory. (Or if you export CMake?s targets, the > >> lib1/2 imported targets will know that their header files are in that > >> directory.) > >> > >> Cheers, > >> Attila > >> > >> > On Dec 10, 2015, at 12:07 AM, Owen Alanzo Hogarth < > gurenchan at gmail.com> > >> > wrote: > >> > > >> > hi > >> > > >> > I am building a shared library project that's composed of many smaller > >> > shared library files. > >> > > >> > Here's the main shared library project and a list of all the sub > >> > projects. > >> > > >> > SET(HEADER_FILES ${CMAKE_CURRENT_SOURCE_DIR}/headers/main_lib.h) > >> > SET(SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/main_lib.c) > >> > SET(TARGET_LIBS core_math point2d line2d quad2d timer_utils) > >> > > >> > ADD_LIBRARY(main_lib SHARED ${SRC_FILES} ${HEADER_FILES}) > >> > TARGET_LINK_LIBRARIES(core_engine ${TARGET_LIBS}) > >> > > >> > i have each module setup like this. > >> > module > >> > module/headers/module.h > >> > module/module.c > >> > > >> > then the module.c will look like this > >> > #include "headers/module.h" > >> > > >> > the file main_lib.h depends on all those target libs, which makes my > >> > main_lib.h file's include statement look like this > >> > > >> > #include "../../module/headers/module.h" > >> > #include "../../module1/headers/module1.h" > >> > #include "../../module2/headers/module2.h" > >> > > >> > > >> > is there any way that I can clean up these includes? > >> > > >> > For example if I want to use io functions I can just do #include > >> > or #include > >> > > >> > for math functions. > >> > > >> > I would like to make my include statements not relative to the files > >> > actual location, the way it's currently hard coded. > >> > -- > >> > > >> > Powered by www.kitware.com > >> > > >> > Please keep messages on-topic and check the CMake FAQ at: > >> > http://www.cmake.org/Wiki/CMake_FAQ > >> > > >> > Kitware offers various services to support the CMake community. For > more > >> > information on each offering, please visit: > >> > > >> > CMake Support: http://cmake.org/cmake/help/support.html > >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> > CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > > >> > Visit other Kitware open-source projects at > >> > http://www.kitware.com/opensource/opensource.html > >> > > >> > Follow this link to subscribe/unsubscribe: > >> > http://public.kitware.com/mailman/listinfo/cmake > >> > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Thu Dec 10 03:15:06 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 10 Dec 2015 09:15:06 +0100 Subject: [CMake] CMake target_link_libraries items should be quoted or not? Linux/Ubuntu 14.04 cmake 3.4.1 In-Reply-To: <5668636B.7030104@sri.utoronto.ca> References: <5668636B.7030104@sri.utoronto.ca> Message-ID: Hi, yes, that is indeed expected behaviour. target_link_libraries() takes a CMake list of arguments - one library per argument. When you surround the thing with quotes, it's a single argument (containing some spaces). So for this call: target_link_libraries(Debug "${VTK_LIBRARIES} -lsri-spatialfft -lsri-spatial -lsri-memory") CMake will instruct the linker to look for a library named " -sri-spatialfft -lsri-spatial -lsri-memory" (one file name with spaces and semicolons in it). Since such a library does not exist, that fails. Without the quotes, each element of the list VTK_LIBRARIES will be a separate argument to target_link_libraries, as will "-lsri-spatialfft", "-lsri-spatial", and "-lsri-memory". Side note: you probably shouldn't be using the -l prefix with arguments to target_link_libraries(). The arguments are normally supposed to be either CMake target names, or full paths to the libraries you want to link. No need to prefix them with linker command-line options, CMake does that for you accordingly. Petr On Wed, Dec 9, 2015 at 6:22 PM, Normand Robert < normand.robert at sri.utoronto.ca> wrote: > robert at kalymnos:~/Code/Debug/normandBuild$ cmake --version > cmake version 3.4.1 > > Reading docs trying to understand why my build works when I write > > target_link_libraries(Debug ${VTK_LIBRARIES} -lsri-spatialfft > -lsri-spatial -lsri-memory) > > but not when everything is protected in quotes: > > target_link_libraries(Debug "${VTK_LIBRARIES} -lsri-spatialfft > -lsri-spatial -lsri-memory") > > which causes an extra library which does not exist to be passed to the > linker. Is this expected behaviour? > > -- > Normand Robert PhD > Sunnybrook Health Sciences Centre > Room S632, 2075 Bayview Avenue, Toronto, ON M4N 3M5 > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwan.work at gmail.com Thu Dec 10 03:20:38 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Thu, 10 Dec 2015 16:20:38 +0800 Subject: [CMake] organizing includes statements In-Reply-To: References: Message-ID: Hi Owen, Sorry to jump into the discussion, but what you're talking is something I was thinking of just recently... I think the choice between this: On Thu, Dec 10, 2015 at 3:48 PM, Owen Alanzo Hogarth wrote: > set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) > set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) > set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) and this: > it seems like this line in your reply above > install( TARGETS lib1 lib2 DESTINATION lib ) > install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION include ) comes down to whether you want to compile other programs with these libraries. If you will not, then you can set the paths to CMAKE_BINARY_DIR, which is the path to the top of the build tree. As far as I know, after you compile your program, you can/should delete the build tree (i.e., assuming an out-of-source build). So, most likely, you'd want to pick the second option if you need the header files and archives to build something else. This is because when you run cmake, you can set the prefix to install files to (i.e., using "make install"). In my case, I only need header files and archives to build something within a single build (i.e., various inter-related subdirectories, all under one CMakeLists.txt). So, I do something similar to the first option. I did toy with the second option a bit but, in the end, realized that much of what I wrote won't be reused by another project of mine. At least, that's my understanding of the two options above... Ray From gurenchan at gmail.com Thu Dec 10 03:34:41 2015 From: gurenchan at gmail.com (Owen Alanzo Hogarth) Date: Thu, 10 Dec 2015 16:34:41 +0800 Subject: [CMake] organizing includes statements In-Reply-To: References: Message-ID: that's actually a good point. Currently as I am developing this i am doing an out of source build and just testing it from there but eventually what I want is a shared library that can be used by other programs. currently though my other programs is just a simple main.c that includes the main library which includes all the sub libraries. One of the reasons why I chose to just set the paths as I did was that I couldn't get the install command to work, not sure why exactly at that time I was just getting started with cmake so most likely user error. It's been working so far and the main concern right now is to get this c program working then refine the cmake build as I go. I just moved the bin directory to my desktop for testing, that seemed to work but this is something to keep in mind. On Thu, Dec 10, 2015 at 4:20 PM, Raymond Wan wrote: > Hi Owen, > > Sorry to jump into the discussion, but what you're talking is > something I was thinking of just recently... > > I think the choice between this: > > > On Thu, Dec 10, 2015 at 3:48 PM, Owen Alanzo Hogarth > wrote: > > set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) > > set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) > > set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) > > > and this: > > > > it seems like this line in your reply above > > install( TARGETS lib1 lib2 DESTINATION lib ) > > install( FILES lib1/headers/lib1.h lib2/headers/lib2.h DESTINATION > include ) > > > comes down to whether you want to compile other programs with these > libraries. If you will not, then you can set the paths to > CMAKE_BINARY_DIR, which is the path to the top of the build tree. As > far as I know, after you compile your program, you can/should delete > the build tree (i.e., assuming an out-of-source build). > > So, most likely, you'd want to pick the second option if you need the > header files and archives to build something else. This is because > when you run cmake, you can set the prefix to install files to (i.e., > using "make install"). In my case, I only need header files and > archives to build something within a single build (i.e., various > inter-related subdirectories, all under one CMakeLists.txt). So, I do > something similar to the first option. > > I did toy with the second option a bit but, in the end, realized that > much of what I wrote won't be reused by another project of mine. At > least, that's my understanding of the two options above... > > Ray > -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Thu Dec 10 03:53:17 2015 From: d3ck0r at gmail.com (J Decker) Date: Thu, 10 Dec 2015 00:53:17 -0800 Subject: [CMake] CMake target_link_libraries items should be quoted or not? Linux/Ubuntu 14.04 cmake 3.4.1 In-Reply-To: References: <5668636B.7030104@sri.utoronto.ca> Message-ID: On Thu, Dec 10, 2015 at 12:15 AM, Petr Kmoch wrote: > Hi, > > Side note: you probably shouldn't be using the -l prefix with arguments to > target_link_libraries(). The arguments are normally supposed to be either > CMake target names, or full paths to the libraries you want to link. No need > to prefix them with linker command-line options, CMake does that for you > accordingly. CMake/build system will typically search the library path, so you don't need full paths... typically just the name of the library... should be more like .. target_link_libraries(Debug ${VTK_LIBRARIES} sri-spatialfft sri-spatial sri-memory) > > Petr > > On Wed, Dec 9, 2015 at 6:22 PM, Normand Robert > wrote: >> >> robert at kalymnos:~/Code/Debug/normandBuild$ cmake --version >> cmake version 3.4.1 >> >> Reading docs trying to understand why my build works when I write >> >> target_link_libraries(Debug ${VTK_LIBRARIES} -lsri-spatialfft >> -lsri-spatial -lsri-memory) >> >> but not when everything is protected in quotes: >> >> target_link_libraries(Debug "${VTK_LIBRARIES} -lsri-spatialfft >> -lsri-spatial -lsri-memory") >> >> which causes an extra library which does not exist to be passed to the >> linker. Is this expected behaviour? >> >> -- >> Normand Robert PhD >> Sunnybrook Health Sciences Centre >> Room S632, 2075 Bayview Avenue, Toronto, ON M4N 3M5 >> From yves.frederix+cmake at gmail.com Thu Dec 10 06:37:10 2015 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Thu, 10 Dec 2015 12:37:10 +0100 Subject: [CMake] Problem when using variable_watch with Visual Studio generator in 3.4.1 Message-ID: Hi all, I am experiencing problems during the CMake configure step when using the function variable_watch. Consider the following minimal CMakeLists file: cmake_minimum_required(VERSION 3.4) project(test CXX) function(myhook _variable _access _value _current_list_file _stack) if("${_value}" STREQUAL "") # Do nothing endif() endfunction() variable_watch(CMAKE_CURRENT_LIST_DIR myhook) find_package(PythonInterp REQUIRED) When configuring on Windows using CMake 3.4.1 with the Visual Studio generator (I tried both VS2012 and VS2015), the process fails with an error message (notice the strange symbols at the beginning of the line mentioning FindPackageMessage.cmake): -- Detecting CXX compile features - done CMake Error at C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:142 (include): include could not find load file: L?/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageMessage.cmake Call Stack (most recent call first): C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:161 (include) CMakeLists.txt:12 (find_package) CMake Error at C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:379 (FIND_PACKAGE_MESSAGE): Unknown CMake command "FIND_PACKAGE_MESSAGE". Call Stack (most recent call first): C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:162 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:12 (find_package) I did some more testing, and the configuration step is successful when: - using CMake 2.8.12 or 3.4.0 - using 3.4.1 (or older versions) on osx (I did not try linux) - removing the 'CXX' in the project call or removing the project call entirely - removing the check for _value inside the function It seems that for some reason adding the watch (which actually only does read-only access), the contents of the CMAKE_CURRENT_LIST_DIR variable is messed up somehow. Could I have run into some corner case behavior here? Maybe it is also useful to mention how I ended up in this situation. My requirement was to run some custom code as the very last step of the configure process. The solution I found was based on using variable_watch (see http://stackoverflow.com/questions/15760580/execute-command-or-macro-in-cmake-as-last-step-before-configure-step-finishes#15824843), but apparently this is not a very robust solution. Are there possibly better ways of accomplishing the same thing? Thanks! Regards, Yves From DLRdave at aol.com Thu Dec 10 06:58:46 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 10 Dec 2015 06:58:46 -0500 Subject: [CMake] Problem when using variable_watch with Visual Studio generator in 3.4.1 In-Reply-To: References: Message-ID: Out of curiosity, what output do you get (with 3.4.1) when you comment out your call to variable_watch? Do you still get error output, but without strange symbols in it? Or is there no error output in that case? On Thursday, December 10, 2015, Yves Frederix wrote: > Hi all, > > I am experiencing problems during the CMake configure step when using > the function variable_watch. Consider the following minimal CMakeLists > file: > > cmake_minimum_required(VERSION 3.4) > project(test CXX) > > function(myhook _variable _access _value _current_list_file _stack) > if("${_value}" STREQUAL "") > # Do nothing > endif() > endfunction() > > variable_watch(CMAKE_CURRENT_LIST_DIR myhook) > find_package(PythonInterp REQUIRED) > > > When configuring on Windows using CMake 3.4.1 with the Visual Studio > generator (I tried both VS2012 and VS2015), the process fails with an > error message (notice the strange symbols at the beginning of the line > mentioning FindPackageMessage.cmake): > > -- Detecting CXX compile features - done > CMake Error at > C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:142 > (include): > include could not find load file: > > L?/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageMessage.cmake > Call Stack (most recent call first): > C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:161 > (include) > CMakeLists.txt:12 (find_package) > > > CMake Error at > > C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:379 > (FIND_PACKAGE_MESSAGE): > Unknown CMake command "FIND_PACKAGE_MESSAGE". > Call Stack (most recent call first): > C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:162 > (FIND_PACKAGE_HANDLE_STANDARD_ARGS) > CMakeLists.txt:12 (find_package) > > > I did some more testing, and the configuration step is successful when: > - using CMake 2.8.12 or 3.4.0 > - using 3.4.1 (or older versions) on osx (I did not try linux) > - removing the 'CXX' in the project call or removing the project call > entirely > - removing the check for _value inside the function > > It seems that for some reason adding the watch (which actually only > does read-only access), the contents of the CMAKE_CURRENT_LIST_DIR > variable is messed up somehow. Could I have run into some corner case > behavior here? > > Maybe it is also useful to mention how I ended up in this situation. > My requirement was to run some custom code as the very last step of > the configure process. The solution I found was based on using > variable_watch (see > > http://stackoverflow.com/questions/15760580/execute-command-or-macro-in-cmake-as-last-step-before-configure-step-finishes#15824843 > ), > but apparently this is not a very robust solution. Are there possibly > better ways of accomplishing the same thing? > > Thanks! > > Regards, > Yves > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yves.frederix+cmake at gmail.com Thu Dec 10 07:26:35 2015 From: yves.frederix+cmake at gmail.com (Yves Frederix) Date: Thu, 10 Dec 2015 13:26:35 +0100 Subject: [CMake] Problem when using variable_watch with Visual Studio generator in 3.4.1 In-Reply-To: References: Message-ID: After commenting out the call there is no error output: -- The CXX compiler identification is MSVC 17.0.61030.0 -- Check for working CXX compiler using: Visual Studio 11 2012 Win64 -- Check for working CXX compiler using: Visual Studio 11 2012 Win64 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found PythonInterp: C:/Python27/python.exe (found version "2.7.10") -- Configuring done -- Generating done Yves On Thu, Dec 10, 2015 at 12:58 PM, David Cole wrote: > Out of curiosity, what output do you get (with 3.4.1) when you comment out > your call to variable_watch? Do you still get error output, but without > strange symbols in it? Or is there no error output in that case? > > > On Thursday, December 10, 2015, Yves Frederix < > yves.frederix+cmake at gmail.com> wrote: > >> Hi all, >> >> I am experiencing problems during the CMake configure step when using >> the function variable_watch. Consider the following minimal CMakeLists >> file: >> >> cmake_minimum_required(VERSION 3.4) >> project(test CXX) >> >> function(myhook _variable _access _value _current_list_file _stack) >> if("${_value}" STREQUAL "") >> # Do nothing >> endif() >> endfunction() >> >> variable_watch(CMAKE_CURRENT_LIST_DIR myhook) >> find_package(PythonInterp REQUIRED) >> >> >> When configuring on Windows using CMake 3.4.1 with the Visual Studio >> generator (I tried both VS2012 and VS2015), the process fails with an >> error message (notice the strange symbols at the beginning of the line >> mentioning FindPackageMessage.cmake): >> >> -- Detecting CXX compile features - done >> CMake Error at >> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:142 >> (include): >> include could not find load file: >> >> L?/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageMessage.cmake >> Call Stack (most recent call first): >> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:161 >> (include) >> CMakeLists.txt:12 (find_package) >> >> >> CMake Error at >> >> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:379 >> (FIND_PACKAGE_MESSAGE): >> Unknown CMake command "FIND_PACKAGE_MESSAGE". >> Call Stack (most recent call first): >> >> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:162 >> (FIND_PACKAGE_HANDLE_STANDARD_ARGS) >> CMakeLists.txt:12 (find_package) >> >> >> I did some more testing, and the configuration step is successful when: >> - using CMake 2.8.12 or 3.4.0 >> - using 3.4.1 (or older versions) on osx (I did not try linux) >> - removing the 'CXX' in the project call or removing the project call >> entirely >> - removing the check for _value inside the function >> >> It seems that for some reason adding the watch (which actually only >> does read-only access), the contents of the CMAKE_CURRENT_LIST_DIR >> variable is messed up somehow. Could I have run into some corner case >> behavior here? >> >> Maybe it is also useful to mention how I ended up in this situation. >> My requirement was to run some custom code as the very last step of >> the configure process. The solution I found was based on using >> variable_watch (see >> >> http://stackoverflow.com/questions/15760580/execute-command-or-macro-in-cmake-as-last-step-before-configure-step-finishes#15824843 >> ), >> but apparently this is not a very robust solution. Are there possibly >> better ways of accomplishing the same thing? >> >> Thanks! >> >> Regards, >> Yves >> -- >> >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Thu Dec 10 07:38:04 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 10 Dec 2015 19:38:04 +0700 Subject: [CMake] How to set environment variables with spaces in commands In-Reply-To: <7BE45809-B42D-42CD-AC30-4368852D99BA@gmail.com> References: <7BE45809-B42D-42CD-AC30-4368852D99BA@gmail.com> Message-ID: <5669722C.3060904@yahoo.com> On 10-Dec-15 12:52, Attila Krasznahorkay wrote: > Hi QP, > > Probably not the intended solution, but what I?m doing in such cases is that in a patch step I create a shell script that does the configuration for me. With all the environment settings and everything. Like: > > PATCH_COMMAND ${CMAKE_COMMAND} -E echo ?cd someDir/; CC=\?something\? ./configure? > configure.sh > CONFIGURE_COMMAND sh configure.sh ... > Unfortunately this makes the code quite unportable, as it will only work on POSIX platforms like this. Even on *nix platforms such code will not always works as expected. As documentation states (https://cmake.org/cmake/help/v3.4/module/ExternalProject.html): Behavior of shell operators like |&&| is not defined. I've hit this on practice by using `LOG_* 1` feature. You can try this example (I've moved PATCH_COMMAND to CONFIGURE_COMMAND since there is no LOG_PATCH option): https://gist.github.com/ruslo/e8c7be03521f167ae8f0 Result: [ 62%] Performing configure step for 'Foo' cd /.../Foo-prefix/src/Foo-build && /.../cmake -P /.../Foo-prefix/src/Foo-stamp/Foo-configure-.cmake CMake Error at /.../Foo-prefix/src/Foo-stamp/Foo-configure-.cmake:16 (message): Command failed: 1 The reason of the failure is because CMake collect all arguments into one command and run execute_process: set(command "/.../cmake;-E;echo;cd ..;>;configure.sh") execute_process(COMMAND ${command} RESULT_VARIABLE result) which of course doesn't make sense. This makes writing ExternalProject_Add steps with modification of environment quite non-trivial task (at least doing it correctly). This feature definitely missing in CMake. I've mentioned it once already: https://cmake.org/pipermail/cmake-developers/2015-August/026053.html but I've changed my mind about the approach because of LOG_* issue. Now I do the next: * wrap each step with CMake script, i.e. instead of `CC=something ./configure` do set(ENV{CC} "something") execute_process(COMMAND ./configure ...) * run CMake script in *_COMMAND: CONFIGURE_COMMAND "${CMAKE_COMMAND}" -P "/path/to/configure.cmake" This makes it cross-platform and *_LOG friendly but require more tricks. Like if you're building in source (non-cmake packages) you have to copy script before execution since CMake will remove source directory on DOWNLOAD step. Which makes it looks like this: CONFIGURE_COMMAND "${CMAKE_COMMAND}" -E copy "/path/to/source/configure.cmake" "/path/to/unpacked/configure.cmake" COMMAND "${CMAKE_COMMAND}" -P "/path/to/unpacked/configure.cmake" PS I'm hitting problems in ExternalProject with environment variables all the time. E.g. at this moment fixing MinGW + Boost: https://github.com/ruslo/hunter/pull/273 Ruslo > But I guess that?s the case anyway once you start setting environment variables. > > Cheers, > Attila > > P.S. I often create build.sh and install.sh scripts as well in additional patch commands. > >> On Dec 10, 2015, at 5:35 AM, Qingping Hou wrote: >> >> Hi all, >> >> I am trying to setup an ExternalProject in cmake but got stuck in the >> configuration step. I am using ccache to speed up the compilation: >> >> ``` >> ExternalProject_Add( >> ... >> CONFIGURE_COMMAND CC="ccache arm-linux-gnueabihf-gcc" ./configure >> ... >> ) >> ``` >> >> However, when cmake generates the Makefile, it moves the quotes around >> and breaks the command: >> >> ``` >> "CC=ccache arm-linux-gnueabihf-gcc" ./configure >> ``` >> >> I have tried various escaping method to try to get it work properly >> without any luck. Is this a bug or an unintended feature? >> >> Thanks, >> QP >> -- >> >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita.barawade at einfochips.com Thu Dec 10 07:38:11 2015 From: nikita.barawade at einfochips.com (Nikita Barawade) Date: Thu, 10 Dec 2015 12:38:11 +0000 Subject: [CMake] error while loading shared libraries: libLLAPI.so: cannot open shared object file: No such file or directory Message-ID: Hi, getting following error when trying to run LLAPI_TestApp ./LLAPI_TestApp: error while loading shared libraries: libLLAPI.so: cannot open shared object file: No such file or directory Both LLAPI_TestApp and libLLAPI.so are present in same directory Bin/Wind. CMakeLists.txt for LLAPI_TestApp : include_directories (../Include) include_directories (../../LLAPI/Include) # collect all cpp files file (GLOB ALL_SOURCES "*.cpp") # Adds sources to the Solution Explorer add_executable ( LLAPI_TestApp ${ALL_SOURCES}) target_link_libraries (LLAPI_TestApp LLAPI) install (TARGETS LLAPI_TestApp RUNTIME DESTINATION ${PROJECT_BINARY_DIR}/../../../Bin/Wind) set(CMAKE_INSTALL_RPATH "${PROJECT_BINARY_DIR}/../../../Bin/Wind ") set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) Searched whole day on Internet but could not fix it . Pls guide Regards, Nikita ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Thu Dec 10 08:24:14 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Thu, 10 Dec 2015 14:24:14 +0100 Subject: [CMake] How to set environment variables with spaces in commands In-Reply-To: <5669722C.3060904@yahoo.com> References: <7BE45809-B42D-42CD-AC30-4368852D99BA@gmail.com> <5669722C.3060904@yahoo.com> Message-ID: Hi Ruslan, Thanks, this is good to know. I absolutely agree that one needs to avoid using "&&" in the commands themselves. As it also causes problems when you try to use CTEST_USE_LAUNCHERS=1. (I myself ran into that issue...) But I did not have any issues so far with putting "whatever" into a shell script that I then later execute. This is how I got around not being able to use wildcards in some installation commands for instance. However, I quite like your solution of using a CMake script instead of a *nix shell one. As that should be indeed much more portable. Even if my current project will not work on Windows for a lot of reasons anyway... Cheers, Attila > On 10 Dec 2015, at 13:38, Ruslan Baratov wrote: > > On 10-Dec-15 12:52, Attila Krasznahorkay wrote: >> Hi QP, >> >> Probably not the intended solution, but what I?m doing in such cases is that in a patch step I create a shell script that does the configuration for me. With all the environment settings and everything. Like: >> >> PATCH_COMMAND ${CMAKE_COMMAND} -E echo ?cd someDir/; CC=\?something\? ./configure? > configure.sh >> CONFIGURE_COMMAND sh configure.sh >> > ... > >> Unfortunately this makes the code quite unportable, as it will only work on POSIX platforms like this. > Even on *nix platforms such code will not always works as expected. As documentation states (https://cmake.org/cmake/help/v3.4/module/ExternalProject.html): > Behavior of shell operators like && is not defined. > I've hit this on practice by using `LOG_* 1` feature. You can try this example (I've moved PATCH_COMMAND to CONFIGURE_COMMAND since there is no LOG_PATCH option): > > https://gist.github.com/ruslo/e8c7be03521f167ae8f0 > > Result: > [ 62%] Performing configure step for 'Foo' > cd /.../Foo-prefix/src/Foo-build && /.../cmake -P /.../Foo-prefix/src/Foo-stamp/Foo-configure-.cmake > CMake Error at /.../Foo-prefix/src/Foo-stamp/Foo-configure-.cmake:16 (message): > Command failed: 1 > The reason of the failure is because CMake collect all arguments into one command and run execute_process: > set(command "/.../cmake;-E;echo;cd ..;>;configure.sh") > execute_process(COMMAND ${command} RESULT_VARIABLE result) > which of course doesn't make sense. > > This makes writing ExternalProject_Add steps with modification of environment quite non-trivial task (at least doing it correctly). This feature definitely missing in CMake. I've mentioned it once already: https://cmake.org/pipermail/cmake-developers/2015-August/026053.html > > but I've changed my mind about the approach because of LOG_* issue. Now I do the next: > > * wrap each step with CMake script, i.e. instead of `CC=something ./configure` do > set(ENV{CC} "something") > execute_process(COMMAND ./configure ...) > * run CMake script in *_COMMAND: > > CONFIGURE_COMMAND > "${CMAKE_COMMAND}" -P "/path/to/configure.cmake" > This makes it cross-platform and *_LOG friendly but require more tricks. Like if you're building in source (non-cmake packages) you have to copy script before execution since CMake will remove source directory on DOWNLOAD step. Which makes it looks like this: > > CONFIGURE_COMMAND > "${CMAKE_COMMAND}" -E copy "/path/to/source/configure.cmake" "/path/to/unpacked/configure.cmake" > COMMAND > "${CMAKE_COMMAND}" -P "/path/to/unpacked/configure.cmake" > > PS I'm hitting problems in ExternalProject with environment variables all the time. E.g. at this moment fixing MinGW + Boost: https://github.com/ruslo/hunter/pull/273 > > Ruslo > >> But I guess that?s the case anyway once you start setting environment variables. >> >> Cheers, >> Attila >> >> P.S. I often create build.sh and install.sh scripts as well in additional patch commands. >> >> >>> On Dec 10, 2015, at 5:35 AM, Qingping Hou >>> wrote: >>> >>> Hi all, >>> >>> I am trying to setup an ExternalProject in cmake but got stuck in the >>> configuration step. I am using ccache to speed up the compilation: >>> >>> ``` >>> ExternalProject_Add( >>> ... >>> CONFIGURE_COMMAND CC="ccache arm-linux-gnueabihf-gcc" ./configure >>> ... >>> ) >>> ``` >>> >>> However, when cmake generates the Makefile, it moves the quotes around >>> and breaks the command: >>> >>> ``` >>> "CC=ccache arm-linux-gnueabihf-gcc" ./configure >>> ``` >>> >>> I have tried various escaping method to try to get it work properly >>> without any luck. Is this a bug or an unintended feature? >>> >>> Thanks, >>> QP >>> -- >>> >>> 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 > From kornel at lyx.org Thu Dec 10 10:09:40 2015 From: kornel at lyx.org (Kornel Benko) Date: Thu, 10 Dec 2015 16:09:40 +0100 Subject: [CMake] error while loading shared libraries: libLLAPI.so: cannot open shared object file: No such file or directory In-Reply-To: References: Message-ID: <3246737.erdc0WHInP@amd64> Am Donnerstag, 10. Dezember 2015 um 12:38:11, schrieb Nikita Barawade > > Hi, > > getting following error when trying to run LLAPI_TestApp > > ./LLAPI_TestApp: error while loading shared libraries: libLLAPI.so: cannot open shared object file: No such file or directory > > Both LLAPI_TestApp and libLLAPI.so are present in same directory Bin/Wind. > > > CMakeLists.txt for LLAPI_TestApp : > > > include_directories (../Include) > include_directories (../../LLAPI/Include) > > # collect all cpp files > file (GLOB ALL_SOURCES > "*.cpp") > > # Adds sources to the Solution Explorer > add_executable ( LLAPI_TestApp ${ALL_SOURCES}) > > target_link_libraries (LLAPI_TestApp LLAPI) > > install (TARGETS LLAPI_TestApp > RUNTIME DESTINATION ${PROJECT_BINARY_DIR}/../../../Bin/Wind) > > set(CMAKE_INSTALL_RPATH "${PROJECT_BINARY_DIR}/../../../Bin/Wind ") > set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) > > > Searched whole day on Internet but could not fix it . > > Pls guide > And where is your call to create the library? e.g. add_library(LLAPI ${lib_sources}) ? > Regards, > Nikita Kornel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From mauro.ziliani.tmp at gmail.com Thu Dec 10 10:23:20 2015 From: mauro.ziliani.tmp at gmail.com (Mauro Ziliani) Date: Thu, 10 Dec 2015 16:23:20 +0100 Subject: [CMake] Visual Studio 10 and wxWidgets Message-ID: Hi all. I'm in trouble with wxWidgets 3 and Visual Studio 10 express. I need to change the type of libraries depending on the configuration compiler If I compile in debug mode I need wxbase30ud.lib, while in release mode wxbase30u But if I generate the project for VS2010Express the wxbase30u.lib is always linked. How can I setup my CMakeLists to have wxbase30ud when I build Debug and wxbase30u in Release? Thanks to all in advance. MZ -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Thu Dec 10 11:40:18 2015 From: d3ck0r at gmail.com (J Decker) Date: Thu, 10 Dec 2015 08:40:18 -0800 Subject: [CMake] error while loading shared libraries: libLLAPI.so: cannot open shared object file: No such file or directory In-Reply-To: References: Message-ID: is '.' in your LD_LIBRARY_PATH and/or /etc/ld.config? otherwise 'LD_LIBRARY_PATH=. ./LLAPI_TestApp' should work... or export LD_LIBRARY_PATH=. for a more semi-permanent solution? On Thu, Dec 10, 2015 at 4:38 AM, Nikita Barawade wrote: > > > Hi, > > getting following error when trying to run LLAPI_TestApp > > ./LLAPI_TestApp: error while loading shared libraries: libLLAPI.so: cannot > open shared object file: No such file or directory > > Both LLAPI_TestApp and libLLAPI.so are present in same directory Bin/Wind. > > > CMakeLists.txt for LLAPI_TestApp : > > > include_directories (../Include) > include_directories (../../LLAPI/Include) > > # collect all cpp files > file (GLOB ALL_SOURCES > "*.cpp") > > # Adds sources to the Solution Explorer > add_executable ( LLAPI_TestApp ${ALL_SOURCES}) > > target_link_libraries (LLAPI_TestApp LLAPI) > > install (TARGETS LLAPI_TestApp > RUNTIME DESTINATION ${PROJECT_BINARY_DIR}/../../../Bin/Wind) > > set(CMAKE_INSTALL_RPATH "${PROJECT_BINARY_DIR}/../../../Bin/Wind ") > set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) > > > Searched whole day on Internet but could not fix it . > > Pls guide > > > Regards, > Nikita > ************************************************************************************************************************************************************* > eInfochips Business Disclaimer: This e-mail message and all attachments > transmitted with it are intended solely for the use of the addressee and may > contain legally privileged and confidential information. If the reader of > this message is not the intended recipient, or an employee or agent > responsible for delivering this message to the intended recipient, you are > hereby notified that any dissemination, distribution, copying, or other use > of this message or its attachments is strictly prohibited. If you have > received this message in error, please notify the sender immediately by > replying to this message and please delete it from your computer. Any views > expressed in this message are those of the individual sender unless > otherwise stated. Company has taken enough precautions to prevent the spread > of viruses. However the company accepts no liability for any damage caused > by any virus transmitted by this email. > ************************************************************************************************************************************************************* > > -- > > 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 From cedric.doucet at inria.fr Thu Dec 10 12:21:39 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 10 Dec 2015 18:21:39 +0100 (CET) Subject: [CMake] ExternalProject_Add and inheritance In-Reply-To: <1109873377.776022.1449767448295.JavaMail.zimbra@inria.fr> Message-ID: <1576248039.779020.1449768099063.JavaMail.zimbra@inria.fr> Hello, I use the ExternalProject_Add command to manage third-party libraries. In the same time, I need to overcome some compatibility problems between GCC 4 and GCC 5 (strings are not defined in the same way in the STL). The solution I use is the one given here: http://stackoverflow.com/questions/33500337/how-to-handle-dual-abi-in-gcc-5 It allows me to force to use the libstdc++.so given by the GCC repository given to the cmake command. The problem is that trick does not work with the ExternalProject_Add command because configuration steps of third-party libraries are autonomous. Do you know how to solve the problem? For example, if I use the ExternalProject_Add command to manage a third-library whose configuration also depends on a cmake script, how could I tell this script to use the compilers and the libstdc++.so I provided to my own cmake script? Best, C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Dec 10 15:13:43 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 10 Dec 2015 15:13:43 -0500 Subject: [CMake] Problem when using variable_watch with Visual Studio generator in 3.4.1 In-Reply-To: References: Message-ID: I've got a Debug build of current 'master' on Windows, and the problem is also evident with my build: C:\dev\dcole\tmp\variable_watch_problem\b1> "C:\dev\repos\My Tests\cmake Win32-ninja-cl12-Debug\bin\ cmake.exe" -G Ninja .. -- The CXX compiler identification is MSVC 18.0.31101.0 -- Check for working CXX compiler using: Ninja -- Check for working CXX compiler using: Ninja -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Error at N:/repos/cmake/Modules/FindPythonInterp.cmake:161 (include): include could not find load file: ???????????????????????????????????????????????????????????????????????????????????????????A/Fin dPackageHandleStandardArgs.cmake Call Stack (most recent call first): CMakeLists.txt:11 (find_package) CMake Error at N:/repos/cmake/Modules/FindPythonInterp.cmake:162 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) : Unknown CMake command "FIND_PACKAGE_HANDLE_STANDARD_ARGS". Call Stack (most recent call first): CMakeLists.txt:11 (find_package) -- Configuring incomplete, errors occurred! See also "C:/dev/dcole/tmp/variable_watch_problem/b1/CMakeFiles/CMakeOutput.log". On Thu, Dec 10, 2015 at 7:26 AM, Yves Frederix < yves.frederix+cmake at gmail.com> wrote: > After commenting out the call there is no error output: > > -- The CXX compiler identification is MSVC 17.0.61030.0 > -- Check for working CXX compiler using: Visual Studio 11 2012 Win64 > -- Check for working CXX compiler using: Visual Studio 11 2012 Win64 -- > works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Found PythonInterp: C:/Python27/python.exe (found version "2.7.10") > -- Configuring done > -- Generating done > > > Yves > > On Thu, Dec 10, 2015 at 12:58 PM, David Cole wrote: > >> Out of curiosity, what output do you get (with 3.4.1) when you comment >> out your call to variable_watch? Do you still get error output, but without >> strange symbols in it? Or is there no error output in that case? >> >> >> On Thursday, December 10, 2015, Yves Frederix < >> yves.frederix+cmake at gmail.com> wrote: >> >>> Hi all, >>> >>> I am experiencing problems during the CMake configure step when using >>> the function variable_watch. Consider the following minimal CMakeLists >>> file: >>> >>> cmake_minimum_required(VERSION 3.4) >>> project(test CXX) >>> >>> function(myhook _variable _access _value _current_list_file _stack) >>> if("${_value}" STREQUAL "") >>> # Do nothing >>> endif() >>> endfunction() >>> >>> variable_watch(CMAKE_CURRENT_LIST_DIR myhook) >>> find_package(PythonInterp REQUIRED) >>> >>> >>> When configuring on Windows using CMake 3.4.1 with the Visual Studio >>> generator (I tried both VS2012 and VS2015), the process fails with an >>> error message (notice the strange symbols at the beginning of the line >>> mentioning FindPackageMessage.cmake): >>> >>> -- Detecting CXX compile features - done >>> CMake Error at >>> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:142 >>> (include): >>> include could not find load file: >>> >>> L? >>> /Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageMessage.cmake >>> Call Stack (most recent call first): >>> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:161 >>> (include) >>> CMakeLists.txt:12 (find_package) >>> >>> >>> CMake Error at >>> >>> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:379 >>> (FIND_PACKAGE_MESSAGE): >>> Unknown CMake command "FIND_PACKAGE_MESSAGE". >>> Call Stack (most recent call first): >>> >>> C:/Tools/CMake_3.4.1/share/cmake-3.4/Modules/FindPythonInterp.cmake:162 >>> (FIND_PACKAGE_HANDLE_STANDARD_ARGS) >>> CMakeLists.txt:12 (find_package) >>> >>> >>> I did some more testing, and the configuration step is successful when: >>> - using CMake 2.8.12 or 3.4.0 >>> - using 3.4.1 (or older versions) on osx (I did not try linux) >>> - removing the 'CXX' in the project call or removing the project call >>> entirely >>> - removing the check for _value inside the function >>> >>> It seems that for some reason adding the watch (which actually only >>> does read-only access), the contents of the CMAKE_CURRENT_LIST_DIR >>> variable is messed up somehow. Could I have run into some corner case >>> behavior here? >>> >>> Maybe it is also useful to mention how I ended up in this situation. >>> My requirement was to run some custom code as the very last step of >>> the configure process. The solution I found was based on using >>> variable_watch (see >>> >>> http://stackoverflow.com/questions/15760580/execute-command-or-macro-in-cmake-as-last-step-before-configure-step-finishes#15824843 >>> ), >>> but apparently this is not a very robust solution. Are there possibly >>> better ways of accomplishing the same thing? >>> >>> Thanks! >>> >>> Regards, >>> Yves >>> -- >>> >>> 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 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Thu Dec 10 15:48:05 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 10 Dec 2015 15:48:05 -0500 Subject: [CMake] Parallel jobs failed for cmake In-Reply-To: <1449724750.194715377@f401.i.mail.ru> References: <1449667939.717612735@f323.i.mail.ru> <1449676663.3241.78.camel@mad-scientist.net> <1449724750.194715377@f401.i.mail.ru> Message-ID: <5669E505.2010208@kitware.com> On 12/10/2015 12:19 AM, Igor Sobinov wrote: > igor 5460 0.0 0.0 101152 972 pts/3 S+ 08:10 0:00 | \_ make build_release -j5 > igor 5466 0.0 0.0 106096 1164 pts/3 S+ 08:10 0:00 | \_ /bin/sh -c cd > /home/igor/build_root/release_target; make release > igor 5467 0.0 0.0 101184 1060 pts/3 S+ 08:10 0:00 | \_ make release Looks like you created the build_release target as a custom command that does: make release This will strip the -j off of the make process and you get the warning. If you are going to call make recursively like that you have to use $(MAKE) so that all the right env stuff gets passed down. CMake does this with its calls to make. You should be able to do what we do in ExternalProject and use $(MAKE). I would have to see your CMakeLists.txt code and the custom command to help more. -Bill From nicholas.clark at gmail.com Thu Dec 10 16:26:47 2015 From: nicholas.clark at gmail.com (Nicholas Clark) Date: Thu, 10 Dec 2015 14:26:47 -0700 Subject: [CMake] Forcing CMake to rerun Message-ID: Hi all, I'm working on using CMake to create a build system that targets an incredibly hard-to-deal-with IDE/build system, used for doing some embedded programming (Xilinx's Vivado suite). One of the pieces I need to get working is a conditional dependency between two files (a project-file generator script that gets archived in Git, and the actual project files that get generated). The graph basically looks like this: Path 1: .tcl file (in Git) -> .xpr file (used by IDE) Path 2: .xpr file (after a user changes something in the IDE) -> .tcl file (needs to be regenerated) So on any clean build, the source-controlled TCL file autogenerates a bunch of required project files. On iterative builds at a developer's desk, he might change some IDE setting and then the TCL file needs to be regenerated (without triggering a rebuild of the project files as well). It's kind of a conditional and/or psuedo-circular dependency. In pure GNU Make, I can express a conditional dependency with an 'if' statement that uses timestamp checks. It's also easy for me to express this dependency in CMakeLists.txt - I can check the file timestamps, and I can conditionally emit the relevant custom_target/custom_rule. That only works when CMakeLists.txt gets parsed, however. Is there any way for me to force a CMake-generated Makefile to _always_ rerun CMake before trying to build the 'all' target? If not, is there any other clever way that I could express this conditional dependency? -Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Fri Dec 11 02:44:38 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Fri, 11 Dec 2015 07:44:38 +0000 Subject: [CMake] ExternalProject_Add and inheritance Message-ID: <923C806B-EC10-4711-B327-15517DA4DF13@sap.com> With CMake, you can control compilation and link flags with the following environment variables: * CC: specify C compiler * CFLAGS: C compiler flags * CXX: specify C++ compiler * CXXFLAGS: C++ compiler flags * LDFLAGS: linker flags And to finish you can overload make command for generation using CMAKE_COMMAND option of ExternalProject_Add: CMAKE_CMMAND ?${CMAKE_COMMAND}? -E env CXX=${CMAKE_CXX_COMPILER} LDFLAGS=??? ?${CMAKE_COMMAND}? From: CMake > on behalf of Cedric Doucet > Date: Thursday 10 December 2015 at 18:21 To: "cmake at cmake.org" > Subject: [CMake] ExternalProject_Add and inheritance Hello, I use the ExternalProject_Add command to manage third-party libraries. In the same time, I need to overcome some compatibility problems between GCC 4 and GCC 5 (strings are not defined in the same way in the STL). The solution I use is the one given here: http://stackoverflow.com/questions/33500337/how-to-handle-dual-abi-in-gcc-5 It allows me to force to use the libstdc++.so given by the GCC repository given to the cmake command. The problem is that trick does not work with the ExternalProject_Add command because configuration steps of third-party libraries are autonomous. Do you know how to solve the problem? For example, if I use the ExternalProject_Add command to manage a third-library whose configuration also depends on a cmake script, how could I tell this script to use the compilers and the libstdc++.so I provided to my own cmake script? Best, C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita.barawade at einfochips.com Fri Dec 11 03:56:48 2015 From: nikita.barawade at einfochips.com (Nikita Barawade) Date: Fri, 11 Dec 2015 08:56:48 +0000 Subject: [CMake] error while loading shared libraries: libLLAPI.so: cannot open shared object file: No such file or directory In-Reply-To: References: , Message-ID: Hi Decker, Thank you for reply ! export LD_LIBRARY_PATH works but how to achieve by cmake or what are proper settings for RPATH? I tried settings from "Always full RPATH" at https://cmake.org/Wiki/CMake_RPATH_handling , but got same error. >From this link , if RPATH is not set then linker will search the libraries in LD_LIBRARY_PATH ,so setting only RPATH should work . Please correct if I am wrong . Please share your inputs. Regards, Nikita ________________________________________ From: J Decker Sent: 10 December 2015 10:10 PM To: Nikita Barawade Cc: cmake at cmake.org Subject: Re: [CMake] error while loading shared libraries: libLLAPI.so: cannot open shared object file: No such file or directory is '.' in your LD_LIBRARY_PATH and/or /etc/ld.config? otherwise 'LD_LIBRARY_PATH=. ./LLAPI_TestApp' should work... or export LD_LIBRARY_PATH=. for a more semi-permanent solution? On Thu, Dec 10, 2015 at 4:38 AM, Nikita Barawade wrote: > > > Hi, > > getting following error when trying to run LLAPI_TestApp > > ./LLAPI_TestApp: error while loading shared libraries: libLLAPI.so: cannot > open shared object file: No such file or directory > > Both LLAPI_TestApp and libLLAPI.so are present in same directory Bin/Wind. > > > CMakeLists.txt for LLAPI_TestApp : > > > include_directories (../Include) > include_directories (../../LLAPI/Include) > > # collect all cpp files > file (GLOB ALL_SOURCES > "*.cpp") > > # Adds sources to the Solution Explorer > add_executable ( LLAPI_TestApp ${ALL_SOURCES}) > > target_link_libraries (LLAPI_TestApp LLAPI) > > install (TARGETS LLAPI_TestApp > RUNTIME DESTINATION ${PROJECT_BINARY_DIR}/../../../Bin/Wind) > > set(CMAKE_INSTALL_RPATH "${PROJECT_BINARY_DIR}/../../../Bin/Wind ") > set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) > > > Searched whole day on Internet but could not fix it . > > Pls guide > > > Regards, > Nikita > ************************************************************************************************************************************************************* > eInfochips Business Disclaimer: This e-mail message and all attachments > transmitted with it are intended solely for the use of the addressee and may > contain legally privileged and confidential information. If the reader of > this message is not the intended recipient, or an employee or agent > responsible for delivering this message to the intended recipient, you are > hereby notified that any dissemination, distribution, copying, or other use > of this message or its attachments is strictly prohibited. If you have > received this message in error, please notify the sender immediately by > replying to this message and please delete it from your computer. Any views > expressed in this message are those of the individual sender unless > otherwise stated. Company has taken enough precautions to prevent the spread > of viruses. However the company accepts no liability for any damage caused > by any virus transmitted by this email. > ************************************************************************************************************************************************************* > > -- > > 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 ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* From cedric.doucet at inria.fr Fri Dec 11 04:05:35 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Fri, 11 Dec 2015 10:05:35 +0100 (CET) Subject: [CMake] ExternalProject_Add and inheritance In-Reply-To: <923C806B-EC10-4711-B327-15517DA4DF13@sap.com> References: <923C806B-EC10-4711-B327-15517DA4DF13@sap.com> Message-ID: <546748282.910688.1449824735193.JavaMail.zimbra@inria.fr> Hello Marc, thank you very much for your answer! I am not sure to understand how to overcome my problem with these variables. I can explain my problem further. I have a toy example of the problem which contains: - a call to ExternalProject_Add to install boost and yaml-ccp (the latter depends on the former) - a main function which loads a file with yaml-cpp (just one line of code) Everything compiles with GCC 5 and I obtain an executable file (called gcc_example). However, when I run this executable file, I get the following error message : ./gcc_example: relocation error: ./gcc_example: symbol _ZTVNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference And I can overcome this problem by setting LD_LIBRARY_PATH to the right value: LD_LIBRARY_PATH=/home/libraries/gcc/5.2.0/lib64/ ./gcc_example The origin of the problem is that the definition of strings is different since GCC 5. Unfortunately, the default behavior is to call the C++ standard library of my Ubuntu system, and the version of this library is older than the version of GCC 5. I can check it with 'ldd ./gcc_example': linux-vdso.so.1 => (0x00007ffd02ef7000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x0000003a71400000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000003d03a00000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000003a71000000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000003d02e00000) /lib64/ld-linux-x86-64.so.2 (0x0000003d02a00000) But I don't understand why I have still this problem since I put these lines in my CMakeLists file (of course the right value of GCC_ROOT is passed to the cmake command at configuration step): link_directories(${GCC_ROOT}/lib64) target_link_libraries(gcc_example ${GCC_ROOT}/lib64/libstdc++.so) I can provide my simple toy example if it helps to understand. You just need to compile it with GCC 5 to see the problem (with older versions of GCC, everything works fine because strings are defined in the "classical" way). Best, C?dric ----- Mail original ----- > De: "Marc CHEVRIER" > ?: "Cedric Doucet" , cmake at cmake.org > Envoy?: Vendredi 11 D?cembre 2015 08:44:38 > Objet: Re: [CMake] ExternalProject_Add and inheritance > With CMake, you can control compilation and link flags with the following > environment variables: > * CC: specify C compiler > * CFLAGS: C compiler flags > * CXX: specify C++ compiler > * CXXFLAGS: C++ compiler flags > * LDFLAGS: linker flags > And to finish you can overload make command for generation using > CMAKE_COMMAND option of ExternalProject_Add: > CMAKE_CMMAND ?${CMAKE_COMMAND}? -E env CXX=${CMAKE_CXX_COMPILER} LDFLAGS=??? > ?${CMAKE_COMMAND}? > From: CMake < cmake-bounces at cmake.org > on behalf of Cedric Doucet < > cedric.doucet at inria.fr > > Date: Thursday 10 December 2015 at 18:21 > To: " cmake at cmake.org " < cmake at cmake.org > > Subject: [CMake] ExternalProject_Add and inheritance > Hello, > I use the ExternalProject_Add command to manage third-party libraries. > In the same time, I need to overcome some compatibility problems between GCC > 4 and GCC 5 (strings are not defined in the same way in the STL). > The solution I use is the one given here: > http://stackoverflow.com/questions/33500337/how-to-handle-dual-abi-in-gcc-5 > It allows me to force to use the libstdc++.so given by the GCC repository > given to the cmake command. > The problem is that trick does not work with the ExternalProject_Add command > because configuration steps of third-party libraries are autonomous. > Do you know how to solve the problem? > For example, if I use the ExternalProject_Add command to manage a > third-library whose configuration also depends on a cmake script, how could > I tell this script to use the compilers and the libstdc++.so I provided to > my own cmake script? > Best, > C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Fri Dec 11 06:58:16 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Fri, 11 Dec 2015 12:58:16 +0100 Subject: [CMake] Figuring out in a generator expression whether a name is a target Message-ID: Dear All, I'm trying to do something a bit more complicated, so please bear with me... In our project we use a special kind of source code generator. Called a "dictionary generator". (https://root.cern.ch/how/how-use-reflex) To simplify the life of our users a bit, we provide a helper function for generating "dictionary libraries", which has a signature like: atlas_add_dictionary( MyDictLibrary MyDictLibrary/MyDictLibraryDict.h MyDictLibrary/selection.xml INCLUDE_DIRS ... LINK_LIBRARIES ... ) Now, in order to make sure that the dictionary generation command succeeds, we need to pull in the public include paths of all the libraries that this library is supposed to be linked against, recursively. To do this, I do the following behind the scenes: foreach( l ${ARG_LINK_LIBRARIES} ) # Skip physical libraries: if( EXISTS ${l} ) continue() endif() # Skip generator expressions: if( ${l} MATCHES "[$]<" ) continue() endif() # Get the include directories of this library: list( APPEND includes "$" ) endforeach() As long as the users only specify either library targets, or absolute library path names here, this works well. But I just ran into some issues where this function is called with a system library name like "rt". So the project generation bails, complaining that "rt" is not a target. Would it be possible to figure out in a generator expression if a given name is a target or not? Clearly I can't make this decision in an if( TARGET ${l} ) statement, as the target may only get defined after this function call. For now I'll be able to work around this issue, but I wonder if it would be possible to provide a full-proof implementation that would not be killed by the users specifying a low-level system library like this in the future. Cheers, Attila From sluge at mail.ru Fri Dec 11 07:24:55 2015 From: sluge at mail.ru (=?UTF-8?B?SWdvciBTb2Jpbm92?=) Date: Fri, 11 Dec 2015 15:24:55 +0300 Subject: [CMake] =?utf-8?q?Parallel_jobs_failed_for_cmake?= In-Reply-To: <5669E505.2010208@kitware.com> References: <1449667939.717612735@f323.i.mail.ru> <1449724750.194715377@f401.i.mail.ru> <5669E505.2010208@kitware.com> Message-ID: <1449836695.708476596@f391.i.mail.ru> Hello Bill, yes, make release is a custom command but that's not important. I do the following: # cd? /home/igor/build_root/release_target #? make release -j5 and again got an error make[4]: warning: jobserver unavailable: using -j1. ?Add `+' to parent make rule. All Makefiles in? release_target are auto generated by cmake, there are no any user's code. Unfortunately I can't send you? CMakeLists.txt( >???????, 10 ??????? 2015, 15:48 -05:00 ?? Bill Hoffman : > >On 12/10/2015 12:19 AM, Igor Sobinov wrote: >> igor 5460 0.0 0.0 101152 972 pts/3 S+ 08:10 0:00 | \_ make build_release -j5 >> igor 5466 0.0 0.0 106096 1164 pts/3 S+ 08:10 0:00 | \_ /bin/sh -c cd >> /home/igor/build_root/release_target; make release >> igor 5467 0.0 0.0 101184 1060 pts/3 S+ 08:10 0:00 | \_ make release >Looks like you created the build_release target as a custom command that >does: >make release > >This will strip the -j off of the make process and you get the warning. >??If you are going to call make recursively like that you have to use >$(MAKE) so that all the right env stuff gets passed down. CMake does >this with its calls to make. > >You should be able to do what we do in ExternalProject and use $(MAKE). >??I would have to see your CMakeLists.txt code and the custom command to >help more. > >-Bill > >-- > >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 Bye, Igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Fri Dec 11 09:11:08 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Fri, 11 Dec 2015 15:11:08 +0100 Subject: [CMake] Figuring out in a generator expression whether a name is a target In-Reply-To: References: Message-ID: <008A3DD5-F294-4A92-A925-5B7A0565079B@gmail.com> Hi, Just to let people know how I solved it in the end... After wondering for a little while, I realised that the following should actually work more robustly: # Get the interface directories of the linked libraries: if( ARG_LINK_LIBRARIES ) # First declare an interface library that will help us collect the # include paths from them: set( _genLibName ${dictname}GeneratorLib ) add_library( ${_genLibName} INTERFACE ) target_link_libraries( ${_genLibName} INTERFACE ${ARG_LINK_LIBRARIES} ) # Now use this interface library to get the include paths: list( APPEND incdirs "$" ) unset( _genLibName ) endif() In this case it becomes non-important what sort of libraries are given as the LINK_LIBRARIES argument. The intermediate interface library takes care of collecting the include directories from the entities that provide such a thing. Cheers, Attila > On 11 Dec 2015, at 12:58, Attila Krasznahorkay wrote: > > Dear All, > > I'm trying to do something a bit more complicated, so please bear with me... > > In our project we use a special kind of source code generator. Called a "dictionary generator". (https://root.cern.ch/how/how-use-reflex) To simplify the life of our users a bit, we provide a helper function for generating "dictionary libraries", which has a signature like: > > atlas_add_dictionary( MyDictLibrary > MyDictLibrary/MyDictLibraryDict.h > MyDictLibrary/selection.xml > INCLUDE_DIRS ... > LINK_LIBRARIES ... ) > > Now, in order to make sure that the dictionary generation command succeeds, we need to pull in the public include paths of all the libraries that this library is supposed to be linked against, recursively. To do this, I do the following behind the scenes: > > foreach( l ${ARG_LINK_LIBRARIES} ) > # Skip physical libraries: > if( EXISTS ${l} ) > continue() > endif() > # Skip generator expressions: > if( ${l} MATCHES "[$]<" ) > continue() > endif() > # Get the include directories of this library: > list( APPEND includes "$" ) > endforeach() > > As long as the users only specify either library targets, or absolute library path names here, this works well. But I just ran into some issues where this function is called with a system library name like "rt". So the project generation bails, complaining that "rt" is not a target. > > Would it be possible to figure out in a generator expression if a given name is a target or not? Clearly I can't make this decision in an > > if( TARGET ${l} ) > > statement, as the target may only get defined after this function call. > > For now I'll be able to work around this issue, but I wonder if it would be possible to provide a full-proof implementation that would not be killed by the users specifying a low-level system library like this in the future. > > Cheers, > Attila From brlcad at mac.com Fri Dec 11 11:29:10 2015 From: brlcad at mac.com (Christopher Sean Morrison) Date: Fri, 11 Dec 2015 11:29:10 -0500 Subject: [CMake] Build-time override? (was Re: ExternalProject_Add and inheritance) In-Reply-To: <923C806B-EC10-4711-B327-15517DA4DF13@sap.com> References: <923C806B-EC10-4711-B327-15517DA4DF13@sap.com> Message-ID: <5018544C-DC1D-456D-91F0-D44CF084AF4C@mac.com> On Dec 11, 2015, at 2:44 AM, CHEVRIER, Marc wrote: > With CMake, you can control compilation and link flags with the following environment variables: > CC: specify C compiler > CFLAGS: C compiler flags > CXX: specify C++ compiler > CXXFLAGS: C++ compiler flags > LDFLAGS: linker flags > And to finish you can overload make command for generation using CMAKE_COMMAND option of ExternalProject_Add: > CMAKE_CMMAND ?${CMAKE_COMMAND}? -E env CXX=${CMAKE_CXX_COMPILER} LDFLAGS=??? ?${CMAKE_COMMAND}? This has probably been mentioned before, but it would be very useful if the output generators would take environment variable overrides into account. This is particularly useful during adhoc development testing where one wants to override build flags, or two-stage compilation, or when the generated output is unhelpful for a given user?s configuration, etc. It?s also a feature lost for projects converting from Autotools-generated Makefile builds. An example, two-stage compilation might be something like: CC=icc cmake .. make CFLAGS=?-fast -O3 -prof_gen /path/to/filename? # run some tools make CFLAGS=?-fast -O3 prof_use /path/to/filename? Gets even more complicated if one only wants to instrument one/few files down in some subdir. Editing flags.make doesn?t really work well in that situation. Editing a CMakeLists.txt property for those few files is also particularly inconvenient when re-running CMake takes several minutes and/or the build change is merely exploratory development. Apologies if there is already a way to do this now. Last I looked a couple years ago, there was not and the docs on CMAKE_C_COMPILER seem to indicate this is still not possible. Cheers! Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.bielik at dirac.se Fri Dec 11 11:44:31 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Fri, 11 Dec 2015 17:44:31 +0100 Subject: [CMake] CPack and PackageMaker In-Reply-To: <56684F38.1090201@dirac.se> References: <56684F38.1090201@dirac.se> Message-ID: <566AFD6F.6090807@dirac.se> Really ? No one ? :) So it's ok to go ahead and start create a new one ? ;) Rgds, /R Den 2015-12-09 kl. 16:56, skrev Robert Bielik: > Mac OSX: > > Since PackageMaker has been deprecated by Apple, the new tools to use > are pkgbuild [1] and productbuild [2]. > > Simple question: Is there any work being done by the CMake community > on a new OS X CPack backend to support the above tools ? > > Regards > /Robert > [1] > https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html > [2] > https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html > From attila.krasznahorkay at gmail.com Fri Dec 11 11:47:01 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Fri, 11 Dec 2015 17:47:01 +0100 Subject: [CMake] CPack and PackageMaker In-Reply-To: <566AFD6F.6090807@dirac.se> References: <56684F38.1090201@dirac.se> <566AFD6F.6090807@dirac.se> Message-ID: <9FA83955-5B87-4AF3-859F-C99FE79D8FB9@gmail.com> Hi Robert, I'm afraid that the sad situation is that nobody has done this yet, or is working on it at the moment. I'm absolutely sure that if you can help with this by any amount, that will be most welcome by the CMake developers. It will certainly be most welcome by me, as I've been disappointed by the lack of this support as well. (But unfortunately can't spare the time to help out in writing this CPack generator.) Cheers, Attila > On 11 Dec 2015, at 17:44, Robert Bielik wrote: > > Really ? No one ? :) > > So it's ok to go ahead and start create a new one ? ;) > > Rgds, > /R > > Den 2015-12-09 kl. 16:56, skrev Robert Bielik: >> Mac OSX: >> >> Since PackageMaker has been deprecated by Apple, the new tools to use are pkgbuild [1] and productbuild [2]. >> >> Simple question: Is there any work being done by the CMake community on a new OS X CPack backend to support the above tools ? >> >> Regards >> /Robert >> [1] https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html >> [2] https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html >> > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From robert.bielik at dirac.se Fri Dec 11 11:50:42 2015 From: robert.bielik at dirac.se (Robert Bielik) Date: Fri, 11 Dec 2015 17:50:42 +0100 Subject: [CMake] CPack and PackageMaker In-Reply-To: <9FA83955-5B87-4AF3-859F-C99FE79D8FB9@gmail.com> References: <56684F38.1090201@dirac.se> <566AFD6F.6090807@dirac.se> <9FA83955-5B87-4AF3-859F-C99FE79D8FB9@gmail.com> Message-ID: <566AFEE2.1010901@dirac.se> Dear Attila, Ok, been struggling getting an installation package to work with the pkgbuild/productbild tools, so I think I got the gist of what needs to be done, at least to get something going :) Regards /R Den 2015-12-11 kl. 17:47, skrev Attila Krasznahorkay: > Hi Robert, > > I'm afraid that the sad situation is that nobody has done this yet, or is working on it at the moment. > > I'm absolutely sure that if you can help with this by any amount, that will be most welcome by the CMake developers. It will certainly be most welcome by me, as I've been disappointed by the lack of this support as well. (But unfortunately can't spare the time to help out in writing this CPack generator.) > > Cheers, > Attila > >> On 11 Dec 2015, at 17:44, Robert Bielik wrote: >> >> Really ? No one ? :) >> >> So it's ok to go ahead and start create a new one ? ;) >> >> Rgds, >> /R >> >> Den 2015-12-09 kl. 16:56, skrev Robert Bielik: >>> Mac OSX: >>> >>> Since PackageMaker has been deprecated by Apple, the new tools to use are pkgbuild [1] and productbuild [2]. >>> >>> Simple question: Is there any work being done by the CMake community on a new OS X CPack backend to support the above tools ? >>> >>> Regards >>> /Robert >>> [1] https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html >>> [2] https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html >>> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From mauro.ziliani.tmp at gmail.com Fri Dec 11 13:06:05 2015 From: mauro.ziliani.tmp at gmail.com (Mauro Ziliani) Date: Fri, 11 Dec 2015 19:06:05 +0100 Subject: [CMake] Visual Studio 10 and wxWidgets In-Reply-To: References: Message-ID: Hi all. I solved my problem with a custom script. I attach it to this message. The script is very very poor, but for my purpouse it works. The script should be simply included MZ On Thu, Dec 10, 2015 at 4:23 PM, Mauro Ziliani wrote: > Hi all. > I'm in trouble with wxWidgets 3 and Visual Studio 10 express. > > I need to change the type of libraries depending on the configuration > compiler > > If I compile in debug mode I need wxbase30ud.lib, while in release mode > wxbase30u > > But if I generate the project for VS2010Express the wxbase30u.lib is > always linked. > > How can I setup my CMakeLists to have wxbase30ud when I build Debug and > wxbase30u in Release? > > Thanks to all in advance. > > MZ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wxwidgets.cmake Type: application/octet-stream Size: 1015 bytes Desc: not available URL: From mauro.ziliani.tmp at gmail.com Fri Dec 11 14:05:17 2015 From: mauro.ziliani.tmp at gmail.com (Mauro Ziliani) Date: Fri, 11 Dec 2015 20:05:17 +0100 Subject: [CMake] Visual Studio 10 and wxWidgets In-Reply-To: References: Message-ID: I miss some lines. This is that works On Fri, Dec 11, 2015 at 7:06 PM, Mauro Ziliani wrote: > Hi all. > I solved my problem with a custom script. > > I attach it to this message. > The script is very very poor, but for my purpouse it works. > > The script should be simply included > > MZ > > On Thu, Dec 10, 2015 at 4:23 PM, Mauro Ziliani < > mauro.ziliani.tmp at gmail.com> wrote: > >> Hi all. >> I'm in trouble with wxWidgets 3 and Visual Studio 10 express. >> >> I need to change the type of libraries depending on the configuration >> compiler >> >> If I compile in debug mode I need wxbase30ud.lib, while in release mode >> wxbase30u >> >> But if I generate the project for VS2010Express the wxbase30u.lib is >> always linked. >> >> How can I setup my CMakeLists to have wxbase30ud when I build Debug and >> wxbase30u in Release? >> >> Thanks to all in advance. >> >> MZ >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wxwidgets.cmake Type: application/octet-stream Size: 1942 bytes Desc: not available URL: From bill.hoffman at kitware.com Fri Dec 11 14:14:26 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri, 11 Dec 2015 14:14:26 -0500 Subject: [CMake] Parallel jobs failed for cmake In-Reply-To: <1449836695.708476596@f391.i.mail.ru> References: <1449667939.717612735@f323.i.mail.ru> <1449724750.194715377@f401.i.mail.ru> <5669E505.2010208@kitware.com> <1449836695.708476596@f391.i.mail.ru> Message-ID: <566B2092.7070502@kitware.com> On 12/11/2015 7:24 AM, Igor Sobinov wrote: > Hello Bill, > > yes, make release is a custom command but that's not important. > I do the following: > # cd /home/igor/build_root/release_target > # make release -j5 Yes, it is important, it is the reason it is not working. The custom command needs to use $(MAKE) and not make to call make or you will get this error. Child make calls need environment variables to get parallel builds to work. The MAKE env var is used to pass them around. -Bill From robert.bielik at dirac.se Fri Dec 11 14:17:44 2015 From: robert.bielik at dirac.se (=?utf-8?B?cm9iZXJ0LmJpZWxpaw==?=) Date: Fri, 11 Dec 2015 19:17:44 GMT Subject: [CMake] CPack and PackageMaker Message-ID: <000f4242.47dd4f8b0abb6704@dirac.se> Dear Clint, Thank you! Will certainly start with that as a base :) Regards /R ------ Ursprungligt meddelande------ Fr?n: Datum: fre, 11 dec 2015 20:12 Till: Robert Bielik; Kopia: Attila Krasznahorkay;cmake; ?mne:Re: [CMake] CPack and PackageMaker If you are interested, attached is some code I started a couple years ago but never finished, nor did I do much testing. Perhaps that'll help, or maybe you'll find a better way. Clint ----- On Dec 11, 2015, at 9:50 AM, Robert Bielik robert.bielik at dirac.se wrote: > Dear Attila, > > Ok, been struggling getting an installation package to work with the > pkgbuild/productbild tools, so I think I got the gist of what needs to > be done, at least to get something going :) > > Regards > /R > > Den 2015-12-11 kl. 17:47, skrev Attila Krasznahorkay: >> Hi Robert, >> >> I'm afraid that the sad situation is that nobody has done this yet, or is >> working on it at the moment. >> >> I'm absolutely sure that if you can help with this by any amount, that will be >> most welcome by the CMake developers. It will certainly be most welcome by me, >> as I've been disappointed by the lack of this support as well. (But >> unfortunately can't spare the time to help out in writing this CPack >> generator.) >> >> Cheers, >> Attila >> >>> On 11 Dec 2015, at 17:44, Robert Bielik wrote: >>> >>> Really ? No one ? :) >>> >>> So it's ok to go ahead and start create a new one ? ;) >>> >>> Rgds, >>> /R >>> >>> Den 2015-12-09 kl. 16:56, skrev Robert Bielik: >>>> Mac OSX: >>>> >>>> Since PackageMaker has been deprecated by Apple, the new tools to use are >>>> pkgbuild [1] and productbuild [2]. >>>> >>>> Simple question: Is there any work being done by the CMake community on a new OS >>>> X CPack backend to support the above tools ? >>>> >>>> Regards >>>> /Robert >>>> [1] >>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html >>>> [2] >>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html >>>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From sachin.kernel at gmail.com Fri Dec 11 14:27:24 2015 From: sachin.kernel at gmail.com (Sachin Gaikwad) Date: Sat, 12 Dec 2015 00:57:24 +0530 Subject: [CMake] Adding all object files as target Message-ID: Hi all, In GNU make, I can easily do this: "make foo.o" if I have foo.cc file to build and this will only compile foo.cc and create foo.o. This behavior is default one i.e. all object files are added as targets in Makefile. How do I get same behavior with cmake? Sachin -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Dec 11 14:39:19 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 11 Dec 2015 20:39:19 +0100 Subject: [CMake] Adding all object files as target In-Reply-To: References: Message-ID: <566B2667.9000509@gmail.com> On 11.12.2015 20:27, Sachin Gaikwad wrote: > > In GNU make, I can easily do this: "make foo.o" if I have foo.cc file > to build and this will only compile foo.cc and create foo.o. This > behavior is default one i.e. all object files are added as targets in > Makefile. > > How do I get same behavior with cmake? > That should already be the default with CMake. "make help" should list these targets. Nils From clinton at elemtech.com Fri Dec 11 14:12:28 2015 From: clinton at elemtech.com (clinton at elemtech.com) Date: Fri, 11 Dec 2015 12:12:28 -0700 (MST) Subject: [CMake] CPack and PackageMaker In-Reply-To: <566AFEE2.1010901@dirac.se> References: <56684F38.1090201@dirac.se> <566AFD6F.6090807@dirac.se> <9FA83955-5B87-4AF3-859F-C99FE79D8FB9@gmail.com> <566AFEE2.1010901@dirac.se> Message-ID: <1354633708.66302518.1449861148692.JavaMail.zimbra@elemtech.com> If you are interested, attached is some code I started a couple years ago but never finished, nor did I do much testing. Perhaps that'll help, or maybe you'll find a better way. Clint ----- On Dec 11, 2015, at 9:50 AM, Robert Bielik robert.bielik at dirac.se wrote: > Dear Attila, > > Ok, been struggling getting an installation package to work with the > pkgbuild/productbild tools, so I think I got the gist of what needs to > be done, at least to get something going :) > > Regards > /R > > Den 2015-12-11 kl. 17:47, skrev Attila Krasznahorkay: >> Hi Robert, >> >> I'm afraid that the sad situation is that nobody has done this yet, or is >> working on it at the moment. >> >> I'm absolutely sure that if you can help with this by any amount, that will be >> most welcome by the CMake developers. It will certainly be most welcome by me, >> as I've been disappointed by the lack of this support as well. (But >> unfortunately can't spare the time to help out in writing this CPack >> generator.) >> >> Cheers, >> Attila >> >>> On 11 Dec 2015, at 17:44, Robert Bielik wrote: >>> >>> Really ? No one ? :) >>> >>> So it's ok to go ahead and start create a new one ? ;) >>> >>> Rgds, >>> /R >>> >>> Den 2015-12-09 kl. 16:56, skrev Robert Bielik: >>>> Mac OSX: >>>> >>>> Since PackageMaker has been deprecated by Apple, the new tools to use are >>>> pkgbuild [1] and productbuild [2]. >>>> >>>> Simple question: Is there any work being done by the CMake community on a new OS >>>> X CPack backend to support the above tools ? >>>> >>>> Regards >>>> /Robert >>>> [1] >>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html >>>> [2] >>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html >>>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- A non-text attachment was scrubbed... Name: productbuild.patch Type: text/x-patch Size: 11676 bytes Desc: not available URL: From dave2008713 at gmail.com Sat Dec 12 03:22:11 2015 From: dave2008713 at gmail.com (Qingping Hou) Date: Sat, 12 Dec 2015 00:22:11 -0800 Subject: [CMake] How to set environment variables with spaces in commands In-Reply-To: <7BE45809-B42D-42CD-AC30-4368852D99BA@gmail.com> References: <7BE45809-B42D-42CD-AC30-4368852D99BA@gmail.com> Message-ID: On Wed, Dec 9, 2015 at 9:52 PM, Attila Krasznahorkay wrote: > Probably not the intended solution, but what I?m doing in such cases is that in a patch step I create a shell script that does the configuration for me. With all the environment settings and everything. Like: > > PATCH_COMMAND ${CMAKE_COMMAND} -E echo ?cd someDir/; CC=\?something\? ./configure? > configure.sh > CONFIGURE_COMMAND sh configure.sh Thanks Attila for the tip. In fact, since you are already constructing the command as a string, why not just run it through sh? CONFIGURE_COMMAND sh ?cd someDir/; CC=\?something\? ./configure? From dave2008713 at gmail.com Sat Dec 12 03:31:06 2015 From: dave2008713 at gmail.com (Qingping Hou) Date: Sat, 12 Dec 2015 00:31:06 -0800 Subject: [CMake] How to set environment variables with spaces in commands In-Reply-To: <5669722C.3060904@yahoo.com> References: <7BE45809-B42D-42CD-AC30-4368852D99BA@gmail.com> <5669722C.3060904@yahoo.com> Message-ID: On Thu, Dec 10, 2015 at 4:38 AM, Ruslan Baratov wrote: > This makes writing ExternalProject_Add steps with modification of > environment quite non-trivial task (at least doing it correctly). This > feature definitely missing in CMake. I've mentioned it once already: > https://cmake.org/pipermail/cmake-developers/2015-August/026053.html Interesting, good to know that it's actually a missing feature instead of me trying to do something dumb ;) hunter is a pretty cool project! I will read through the code and see how it works around this issue. From jsvanbethlehem at gmail.com Sun Dec 13 05:21:32 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Sun, 13 Dec 2015 11:21:32 +0100 Subject: [CMake] Forcing CMake to rerun In-Reply-To: References: Message-ID: <56997F0C-7D44-45DF-8438-7B81BF0D91D9@gmail.com> Hej, My first guess would be to have a look at the add_custom_command() function. One of the possible invocations of that function creates a target of which the outputs are always considered out-of-date (well, if memory serves me correctly, it seems cmake.org is currently down so I can?t double check). Anyways, if the ?command? you wish to run is actually a CMake script, have a look at the ?cmake -P? option. This allows you to run CMake scripts as a custom command. Sincerely, Jakob > On 10 Dec 2015, at 22:26, Nicholas Clark wrote: > > Hi all, > > I'm working on using CMake to create a build system that targets an incredibly hard-to-deal-with IDE/build system, used for doing some embedded programming (Xilinx's Vivado suite). > > One of the pieces I need to get working is a conditional dependency between two files (a project-file generator script that gets archived in Git, and the actual project files that get generated). > > The graph basically looks like this: > > Path 1: .tcl file (in Git) -> .xpr file (used by IDE) > Path 2: .xpr file (after a user changes something in the IDE) -> .tcl file (needs to be regenerated) > > So on any clean build, the source-controlled TCL file autogenerates a bunch of required project files. On iterative builds at a developer's desk, he might change some IDE setting and then the TCL file needs to be regenerated (without triggering a rebuild of the project files as well). It's kind of a conditional and/or psuedo-circular dependency. > > In pure GNU Make, I can express a conditional dependency with an 'if' statement that uses timestamp checks. It's also easy for me to express this dependency in CMakeLists.txt - I can check the file timestamps, and I can conditionally emit the relevant custom_target/custom_rule. > > That only works when CMakeLists.txt gets parsed, however. Is there any way for me to force a CMake-generated Makefile to _always_ rerun CMake before trying to build the 'all' target? If not, is there any other clever way that I could express this conditional dependency? > > -Nick > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From gurenchan at gmail.com Sun Dec 13 14:44:17 2015 From: gurenchan at gmail.com (Owen Hogarth II) Date: Mon, 14 Dec 2015 03:44:17 +0800 Subject: [CMake] what options Message-ID: If you have a cmake project, what's the way to see what type of configuration options are available? For example I know that I can pass -DCMAKE_PREFIX_PATH the set where the project will be installed. Sometimes project creators add other things, such as building static or share libraries, SSE, NEON or other flags like those. Is there a way to have cmake show all of those that the current project has exposed? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Sun Dec 13 14:56:19 2015 From: rleigh at codelibre.net (Roger Leigh) Date: Sun, 13 Dec 2015 19:56:19 +0000 Subject: [CMake] what options In-Reply-To: References: Message-ID: <566DCD63.3040409@codelibre.net> On 13/12/2015 19:44, Owen Hogarth II wrote: > If you have a cmake project, what's the way to see what type of > configuration options are available? > > For example I know that I can pass -DCMAKE_PREFIX_PATH the set where the > project will be installed. > > Sometimes project creators add other things, such as building static or > share libraries, SSE, NEON or other flags like those. > > Is there a way to have cmake show all of those that the current project > has exposed? cmake -L[A][H] . Lists the cache variables to set, optionally including advanced options and help text. See "List non-advanced cached variables" in https://cmake.org/cmake/help/v3.4/manual/cmake.1.html These are also shown with cmake-gui, which lists them in the user interface. Regards, Roger From gurenchan at gmail.com Sun Dec 13 15:20:54 2015 From: gurenchan at gmail.com (Owen Hogarth II) Date: Mon, 14 Dec 2015 04:20:54 +0800 Subject: [CMake] what options In-Reply-To: <566DCD63.3040409@codelibre.net> References: <566DCD63.3040409@codelibre.net> Message-ID: wow, that's excellent cmake -LAH lead me to the variable that I was looking for. Thank you very much Roger! On Mon, Dec 14, 2015 at 3:56 AM, Roger Leigh wrote: > On 13/12/2015 19:44, Owen Hogarth II wrote: > >> If you have a cmake project, what's the way to see what type of >> configuration options are available? >> >> For example I know that I can pass -DCMAKE_PREFIX_PATH the set where the >> project will be installed. >> >> Sometimes project creators add other things, such as building static or >> share libraries, SSE, NEON or other flags like those. >> >> Is there a way to have cmake show all of those that the current project >> has exposed? >> > > cmake -L[A][H] . > > Lists the cache variables to set, optionally including advanced options > and help text. > > See "List non-advanced cached variables" in > https://cmake.org/cmake/help/v3.4/manual/cmake.1.html > > These are also shown with cmake-gui, which lists them in the user > interface. > > > Regards, > Roger > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mingw.android at gmail.com Sun Dec 13 20:06:15 2015 From: mingw.android at gmail.com (Ray Donnelly) Date: Mon, 14 Dec 2015 01:06:15 +0000 Subject: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally? Message-ID: Hi, I ran into a problem on MSYS2 recently building llvm+clang for mingw-w64 using CMake 3.4.1 (we carry a few local patches, they're fairly minor, except the qt5-static one, and I don't think they are likely related to this: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-cmake) MSYS2 has two shells .. actually it's 3 or 4, but for simplicity we'll ignore the 32-bit ones and pretend there's only 2 64-bit shells, one launched with msys2_shell.bat and one launched with mingw64_shell.bat. Under msys2_shell.bat, the "/mingw64/bin" folder doesn't appear at all in PATH, while under mingw64_shell.bat, it appears at the very front, before "/usr/bin" (which contains the msys2 software). When running CMake to configure the build for libclang, it tries to see if if can find libdl with "find_library (DL_LIBRARY_PATH dl)". Unfortunately it finds the msys-2.0.dll-linked libdl.a in /usr/lib because NO_SYSTEM_ENVIRONMENT_PATH isn't set, which isn't then in /mingw64/bin/g++.exe's linker search path (and even if it was, we don't want to link msys-2.0.dll software into native software!). I wondered what the recommended approach is for handling this scenario? Clearly we need msys2 software to be in our PATH (ls, bash, etc, etc), but it seems CMake is keen to look in a lot of places to find libraries (AFAICT, it takes each element in PATH and appends ../lib to it then looks in there with the usual prefix/suffix rules) .. >From our perspective, as MSYS2 is a distro employing a prefix, we'd be happy for only that to be searched in for libraries. Is there something that can accommodate for this already? Clearly, patching each occurrence of find_library isn't something I can entertain, so I'd like to make a change to how CMake itself behaves somehow. If you can guide me on an acceptable way to achieve this I'd like to try to come up with a patch. -- Best regards, Ray Donnelly. From irwin at beluga.phys.uvic.ca Sun Dec 13 21:42:10 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sun, 13 Dec 2015 18:42:10 -0800 (PST) Subject: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally? In-Reply-To: References: Message-ID: On 2015-12-14 01:06-0000 Ray Donnelly wrote: > Hi, > > I ran into a problem on MSYS2 recently building llvm+clang for > mingw-w64 using CMake 3.4.1 (we carry a few local patches, they're > fairly minor, except the qt5-static one, and I don't think they are > likely related to this: > https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-cmake) > > MSYS2 has two shells .. actually it's 3 or 4, but for simplicity we'll > ignore the 32-bit ones and pretend there's only 2 64-bit shells, one > launched with msys2_shell.bat and one launched with mingw64_shell.bat. > Under msys2_shell.bat, the "/mingw64/bin" folder doesn't appear at all > in PATH, while under mingw64_shell.bat, it appears at the very front, > before "/usr/bin" (which contains the msys2 software). > > When running CMake to configure the build for libclang, it tries to > see if if can find libdl with "find_library (DL_LIBRARY_PATH dl)". > Unfortunately it finds the msys-2.0.dll-linked libdl.a in /usr/lib > because NO_SYSTEM_ENVIRONMENT_PATH isn't set, which isn't then in > /mingw64/bin/g++.exe's linker search path (and even if it was, we > don't want to link msys-2.0.dll software into native software!). Hi Ray: I only have indirect experience with MinGW-w64/MSYS2 (i.e., reading detailed build reports from a tester of PLplot on that platform), but my understanding is to build software for that platform you would normally always use mingw64_shell.bat (or mingw32_shell.bat for the 32-bit case). And if /mingw64/bin is first on the PATH for that shell my understanding is that if libdl is in the correct location in /mingw64, then it should normally and automatically be found by CMake for /mingw64/bin/g++.exe when NO_SYSTEM_ENVIRONMENT_PATH is not set. However, it appears that is not the find result you are getting and you have responded by trying to find a way to set NO_SYSTEM_ENVIRONMENT_PATH globally. But I think it would be better instead to explore the case where the NO_SYSTEM_ENVIRONMENT_PATH command is not used to figure out how to get that scenario to correctly find libdl. Therefore, I suggest you make a simple test project which uses "find_library (DL_LIBRARY_PATH dl)" (without NO_SYSTEM_ENVIRONMENT_PATH) to find dl, and fiddle with your PATH (and also CMake version just in case it turns out you are fighting against some recently introduced find_library regression) to see what the results are. And if nothing works for any cmake version with /mingw64/bin at the very front of your PATH, then you can always fall back to setting the -DCMAKE_LIBRARY_PATH:PATH cmake option to force finding the correct version of libdl. Note in your tests above you might also want to try both the "Unix Makefiles" and "MSYS Makefiles" generators. Our PLplot experience is that choice does make a difference for one find module (wxwidgets) on MinGW-w64/MSYS2, and I suppose it is possible it might also make a difference to the results from a single find_library command as well. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From sluge at mail.ru Mon Dec 14 01:34:47 2015 From: sluge at mail.ru (=?UTF-8?B?SWdvciBTb2Jpbm92?=) Date: Mon, 14 Dec 2015 09:34:47 +0300 Subject: [CMake] =?utf-8?q?Parallel_jobs_failed_for_cmake?= In-Reply-To: <566B2092.7070502@kitware.com> References: <1449667939.717612735@f323.i.mail.ru> <1449836695.708476596@f391.i.mail.ru> <566B2092.7070502@kitware.com> Message-ID: <1450074887.829448764@f310.i.mail.ru> Hello Bill, Thanks, that's clear. So, If I write in makefile build_release: $(RELEASE_DIR) ? ? @cd $(RELEASE_DIR); $(MAKE) release I got an error Also if I write build_release: $(RELEASE_DIR) ? ? $(MAKE) release -C? ?$(RELEASE_DIR) I got an error too But this is successfull command: # cd $ RELEASE_DIR; make release -j10 Why make doesn't support jobs for subdirs? >???????, 11 ??????? 2015, 14:14 -05:00 ?? Bill Hoffman : > >On 12/11/2015 7:24 AM, Igor Sobinov wrote: >> Hello Bill, >> >> yes, make release is a custom command but that's not important. >> I do the following: >> # cd /home/igor/build_root/release_target >> # make release -j5 >Yes, it is important, it is the reason it is not working. The custom >command needs to use $(MAKE) and not make to call make or you will get >this error. Child make calls need environment variables to get parallel >builds to work. The MAKE env var is used to pass them around. > >-Bill > Bye, Igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Mon Dec 14 03:17:15 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Mon, 14 Dec 2015 09:17:15 +0100 Subject: [CMake] Parallel jobs failed for cmake In-Reply-To: <1450074887.829448764@f310.i.mail.ru> References: <1449667939.717612735@f323.i.mail.ru> <1449836695.708476596@f391.i.mail.ru> <566B2092.7070502@kitware.com> <1450074887.829448764@f310.i.mail.ru> Message-ID: <11929BE4-3C1C-46D9-88ED-B059B23F0DD0@gmail.com> Hi Igor, At this point it's really not a CMake question, but a GNU Make one... The answer is actually right there in the first warning that you got. make[4]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. I have to admit that I'm not absolutely sure about all the subtleties of this, but I defined my own build rules in the past that call make themselves, like: core:: +(cd core; make) With this, GNU Make is able to distribute the jobs between the subdirectories. (I have a number of such targets in my main Makefile.) Cheers, Attila > On 14 Dec 2015, at 07:34, Igor Sobinov wrote: > > Hello Bill, > > Thanks, that's clear. > > So, If I write in makefile > > > build_release: $(RELEASE_DIR) > @cd $(RELEASE_DIR); $(MAKE) release > > I got an error > > Also if I write > > build_release: $(RELEASE_DIR) > $(MAKE) release -C $(RELEASE_DIR) > > I got an error too > > But this is successfull command: > # cd $RELEASE_DIR; make release -j10 > > Why make doesn't support jobs for subdirs? > > > ???????, 11 ??????? 2015, 14:14 -05:00 ?? Bill Hoffman : > > On 12/11/2015 7:24 AM, Igor Sobinov wrote: > > Hello Bill, > > > > yes, make release is a custom command but that's not important. > > I do the following: > > # cd /home/igor/build_root/release_target > > # make release -j5 > Yes, it is important, it is the reason it is not working. The custom > command needs to use $(MAKE) and not make to call make or you will get > this error. Child make calls need environment variables to get parallel > builds to work. The MAKE env var is used to pass them around. > > -Bill > > > > Bye, Igor > > -- > > 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 From attila.krasznahorkay at gmail.com Mon Dec 14 03:23:35 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Mon, 14 Dec 2015 09:23:35 +0100 Subject: [CMake] what options In-Reply-To: References: <566DCD63.3040409@codelibre.net> Message-ID: Hi, Just to clarify: CMAKE_INSTALL_PREFIX is the variable that sets where the project will be installed. CMAKE_PREFIX_PATH is used (amongst other things) to find external projects during the configuration. Cheers, Attila > On 13 Dec 2015, at 21:20, Owen Hogarth II wrote: > > wow, that's excellent cmake -LAH lead me to the variable that I was looking for. > > Thank you very much Roger! > > On Mon, Dec 14, 2015 at 3:56 AM, Roger Leigh wrote: > On 13/12/2015 19:44, Owen Hogarth II wrote: > If you have a cmake project, what's the way to see what type of > configuration options are available? > > For example I know that I can pass -DCMAKE_PREFIX_PATH the set where the > project will be installed. > > Sometimes project creators add other things, such as building static or > share libraries, SSE, NEON or other flags like those. > > Is there a way to have cmake show all of those that the current project > has exposed? > > cmake -L[A][H] . > > Lists the cache variables to set, optionally including advanced options and help text. > > See "List non-advanced cached variables" in https://cmake.org/cmake/help/v3.4/manual/cmake.1.html > > These are also shown with cmake-gui, which lists them in the user interface. > > > Regards, > Roger > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > -- > > 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 From gurenchan at gmail.com Mon Dec 14 03:26:07 2015 From: gurenchan at gmail.com (Owen Hogarth II) Date: Mon, 14 Dec 2015 08:26:07 +0000 Subject: [CMake] what options In-Reply-To: References: <566DCD63.3040409@codelibre.net> Message-ID: Thanks for the clarification. On Mon, Dec 14, 2015, 16:23 Attila Krasznahorkay < attila.krasznahorkay at gmail.com> wrote: > Hi, > > Just to clarify: CMAKE_INSTALL_PREFIX is the variable that sets where the > project will be installed. CMAKE_PREFIX_PATH is used (amongst other things) > to find external projects during the configuration. > > Cheers, > Attila > > > On 13 Dec 2015, at 21:20, Owen Hogarth II wrote: > > > > wow, that's excellent cmake -LAH lead me to the variable that I was > looking for. > > > > Thank you very much Roger! > > > > On Mon, Dec 14, 2015 at 3:56 AM, Roger Leigh > wrote: > > On 13/12/2015 19:44, Owen Hogarth II wrote: > > If you have a cmake project, what's the way to see what type of > > configuration options are available? > > > > For example I know that I can pass -DCMAKE_PREFIX_PATH the set where the > > project will be installed. > > > > Sometimes project creators add other things, such as building static or > > share libraries, SSE, NEON or other flags like those. > > > > Is there a way to have cmake show all of those that the current project > > has exposed? > > > > cmake -L[A][H] . > > > > Lists the cache variables to set, optionally including advanced options > and help text. > > > > See "List non-advanced cached variables" in > https://cmake.org/cmake/help/v3.4/manual/cmake.1.html > > > > These are also shown with cmake-gui, which lists them in the user > interface. > > > > > > Regards, > > Roger > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > > > > -- > > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.miniussi at oca.eu Mon Dec 14 05:03:23 2015 From: alain.miniussi at oca.eu (Alain Miniussi) Date: Mon, 14 Dec 2015 11:03:23 +0100 Subject: [CMake] try_compile, again Message-ID: <566E93EB.6020505@oca.eu> Hi, I tried using try_compile, and, as usual, fail to understand how it's supposed to work (2.8.12). The documentation says: Some extra flags that can be included are, INCLUDE_DIRECTORIES, LINK_DIRECTORIES, and LINK_LIBRARIES. but does not mention where they can be included (none of the two mentioned form indicate those flags). I tried putting "INCLUDE_DIRECTORIES ${Boost_INCLUDE_DIRS}" just after the CMAKE_FLAGS., but it is just ignored. Also: COMPILE_DEFINITIONS are -Ddefinition that will be passed to the compile line. but that seems incorrect (which is good) as I can use them to pass "-std=c++11" which is not a -D option (and I don't know how I could pass that option otherwise). Thanks -- --- Alain From mingw.android at gmail.com Mon Dec 14 07:43:33 2015 From: mingw.android at gmail.com (Ray Donnelly) Date: Mon, 14 Dec 2015 12:43:33 +0000 Subject: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally? In-Reply-To: References: Message-ID: On Mon, Dec 14, 2015 at 2:42 AM, Alan W. Irwin wrote: > On 2015-12-14 01:06-0000 Ray Donnelly wrote: > >> Hi, >> >> I ran into a problem on MSYS2 recently building llvm+clang for >> mingw-w64 using CMake 3.4.1 (we carry a few local patches, they're >> fairly minor, except the qt5-static one, and I don't think they are >> likely related to this: >> https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-cmake) >> >> MSYS2 has two shells .. actually it's 3 or 4, but for simplicity we'll >> ignore the 32-bit ones and pretend there's only 2 64-bit shells, one >> launched with msys2_shell.bat and one launched with mingw64_shell.bat. >> Under msys2_shell.bat, the "/mingw64/bin" folder doesn't appear at all >> in PATH, while under mingw64_shell.bat, it appears at the very front, >> before "/usr/bin" (which contains the msys2 software). >> >> When running CMake to configure the build for libclang, it tries to >> see if if can find libdl with "find_library (DL_LIBRARY_PATH dl)". >> Unfortunately it finds the msys-2.0.dll-linked libdl.a in /usr/lib >> because NO_SYSTEM_ENVIRONMENT_PATH isn't set, which isn't then in >> /mingw64/bin/g++.exe's linker search path (and even if it was, we >> don't want to link msys-2.0.dll software into native software!). > > > Hi Ray: > > I only have indirect experience with MinGW-w64/MSYS2 (i.e., reading detailed > build reports from a tester of PLplot on that platform), but my > understanding is > to build software for that platform you would normally > always use mingw64_shell.bat (or mingw32_shell.bat for the 32-bit > case). And if /mingw64/bin is first on the PATH for that shell my > understanding is that if libdl is in the correct location in /mingw64, > then it should normally and automatically be found by CMake for > /mingw64/bin/g++.exe when NO_SYSTEM_ENVIRONMENT_PATH is not set. Hi Alan, I'm one of the founders of MSYS2 (not that that means I know what I'm talking about mind you!) .. You are right, that normally for building mingw-w64 x86_64 software on MSYS2 you'd use mingw64_shell.bat, but when building MSYS2 packages via makepkg-mingw, you'd run msys2_shell.bat instead since that builds both the 32-bit and 64-bit variants setting the correct environment up beforehand each time. The issue I've got here is that on MSYS2 we've decided that we don't want to provide libdl for mingw-w64 but do provide it for msys2, so there'll never be a /mingw{64,32}/lib/libdl.a or /mingw{64,32}/lib/libdl.dll.a, but there is a /usr/lib/libdl.a. When building mingw-w64 software, the front of PATH will be "/mingw64/bin:/usr/bin" or "/mingw32/bin:/usr/bin" and that causes CMake to find /usr/lib/libdl.a due to NO_SYSTEM_ENVIRONMENT_PATH. I think the best I can do is to edit each of our CMake using PKGBUILD scripts to set PATH to a clean value just before invoking CMake. This is something I didn't really want to have to do. To my mind, this rummaging around the user's system path feature seems too prone to randomness and a large source of build variance. Some of this comes from my liking for reproducible builds where environmental differences are kept out of the equation. > > However, it appears that is not the find result you are getting and > you have responded by trying to find a way to set > NO_SYSTEM_ENVIRONMENT_PATH globally. But I think it would be better > instead to explore the case where the NO_SYSTEM_ENVIRONMENT_PATH > command is not used to figure out how to get that scenario to > correctly find libdl. > > Therefore, I suggest you make a simple test > project which uses "find_library (DL_LIBRARY_PATH dl)" (without > NO_SYSTEM_ENVIRONMENT_PATH) to find dl, and fiddle with your PATH (and > also CMake version just in case it turns out you are fighting against > some recently introduced find_library regression) to see what the > results are. And if nothing works for any cmake version with > /mingw64/bin at the very front of your PATH, then you can always fall > back to setting the -DCMAKE_LIBRARY_PATH:PATH cmake option to force > finding the correct version of libdl. > > Note in your tests above you might also want to try both the "Unix > Makefiles" and "MSYS Makefiles" generators. Our PLplot experience is > that choice does make a difference for one find module (wxwidgets) on > MinGW-w64/MSYS2, and I suppose it is possible it might also make a > difference to the results from a single find_library command as well. > "MSYS Makefiles" should be the correct choice on MSYS2 if you are compiling with native compilers. If you are using cross compilers then "Unix makefiles" should be the correct choice. There is a bug in wxwidget's wx-config not being sympathetic towards the idiosyncrasies of MSYS2 that I will push a fix for soon-ish (the prefix variable needs to be modified through cygpath -m if MSYSTEM is MINGW32 or MINGW64). However, due to person-power issues, the package will not be rebuilt for a while, but hopefully you can build your own to test? -- Thanks, Ray. > Alan > > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ From mingw.android at gmail.com Mon Dec 14 07:53:06 2015 From: mingw.android at gmail.com (Ray Donnelly) Date: Mon, 14 Dec 2015 12:53:06 +0000 Subject: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally? In-Reply-To: References: Message-ID: On Mon, Dec 14, 2015 at 12:43 PM, Ray Donnelly wrote: > On Mon, Dec 14, 2015 at 2:42 AM, Alan W. Irwin > wrote: >> On 2015-12-14 01:06-0000 Ray Donnelly wrote: >> >>> Hi, >>> >>> I ran into a problem on MSYS2 recently building llvm+clang for >>> mingw-w64 using CMake 3.4.1 (we carry a few local patches, they're >>> fairly minor, except the qt5-static one, and I don't think they are >>> likely related to this: >>> https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-cmake) >>> >>> MSYS2 has two shells .. actually it's 3 or 4, but for simplicity we'll >>> ignore the 32-bit ones and pretend there's only 2 64-bit shells, one >>> launched with msys2_shell.bat and one launched with mingw64_shell.bat. >>> Under msys2_shell.bat, the "/mingw64/bin" folder doesn't appear at all >>> in PATH, while under mingw64_shell.bat, it appears at the very front, >>> before "/usr/bin" (which contains the msys2 software). >>> >>> When running CMake to configure the build for libclang, it tries to >>> see if if can find libdl with "find_library (DL_LIBRARY_PATH dl)". >>> Unfortunately it finds the msys-2.0.dll-linked libdl.a in /usr/lib >>> because NO_SYSTEM_ENVIRONMENT_PATH isn't set, which isn't then in >>> /mingw64/bin/g++.exe's linker search path (and even if it was, we >>> don't want to link msys-2.0.dll software into native software!). >> >> >> Hi Ray: >> >> I only have indirect experience with MinGW-w64/MSYS2 (i.e., reading detailed >> build reports from a tester of PLplot on that platform), but my >> understanding is >> to build software for that platform you would normally >> always use mingw64_shell.bat (or mingw32_shell.bat for the 32-bit >> case). And if /mingw64/bin is first on the PATH for that shell my >> understanding is that if libdl is in the correct location in /mingw64, >> then it should normally and automatically be found by CMake for >> /mingw64/bin/g++.exe when NO_SYSTEM_ENVIRONMENT_PATH is not set. > > Hi Alan, > > I'm one of the founders of MSYS2 (not that that means I know what I'm > talking about mind you!) .. You are right, that normally for building > mingw-w64 x86_64 software on MSYS2 you'd use mingw64_shell.bat, but > when building MSYS2 packages via makepkg-mingw, you'd run > msys2_shell.bat instead since that builds both the 32-bit and 64-bit > variants setting the correct environment up beforehand each time. > > The issue I've got here is that on MSYS2 we've decided that we don't > want to provide libdl for mingw-w64 but do provide it for msys2, so > there'll never be a /mingw{64,32}/lib/libdl.a or > /mingw{64,32}/lib/libdl.dll.a, but there is a /usr/lib/libdl.a. When > building mingw-w64 software, the front of PATH will be > "/mingw64/bin:/usr/bin" or "/mingw32/bin:/usr/bin" and that causes > CMake to find /usr/lib/libdl.a due to NO_SYSTEM_ENVIRONMENT_PATH. > > I think the best I can do is to edit each of our CMake using PKGBUILD > scripts to set PATH to a clean value just before invoking CMake. This > is something I didn't really want to have to do. Replying to myself; first sign of something --good .. but I've thought immediately of a case where I can't modify PATH like I suggested. We have some packages (e.g. hlsl2glslfork) that use bison and flex, and those packages use msys2 flex and bison. For those to work, I can't remove /usr/bin from PATH for all PKGBUILDs that invoke CMake as I had planned, so how should I proceed here? (I wouldn't be surprised if clang/llvm also call bison and flex). > > To my mind, this rummaging around the user's system path feature seems > too prone to randomness and a large source of build variance. Some of > this comes from my liking for reproducible builds where environmental > differences are kept out of the equation. > >> >> However, it appears that is not the find result you are getting and >> you have responded by trying to find a way to set >> NO_SYSTEM_ENVIRONMENT_PATH globally. But I think it would be better >> instead to explore the case where the NO_SYSTEM_ENVIRONMENT_PATH >> command is not used to figure out how to get that scenario to >> correctly find libdl. >> >> Therefore, I suggest you make a simple test >> project which uses "find_library (DL_LIBRARY_PATH dl)" (without >> NO_SYSTEM_ENVIRONMENT_PATH) to find dl, and fiddle with your PATH (and >> also CMake version just in case it turns out you are fighting against >> some recently introduced find_library regression) to see what the >> results are. And if nothing works for any cmake version with >> /mingw64/bin at the very front of your PATH, then you can always fall >> back to setting the -DCMAKE_LIBRARY_PATH:PATH cmake option to force >> finding the correct version of libdl. >> >> Note in your tests above you might also want to try both the "Unix >> Makefiles" and "MSYS Makefiles" generators. Our PLplot experience is >> that choice does make a difference for one find module (wxwidgets) on >> MinGW-w64/MSYS2, and I suppose it is possible it might also make a >> difference to the results from a single find_library command as well. >> > > "MSYS Makefiles" should be the correct choice on MSYS2 if you are > compiling with native compilers. If you are using cross compilers then > "Unix makefiles" should be the correct choice. There is a bug in > wxwidget's wx-config not being sympathetic towards the idiosyncrasies > of MSYS2 that I will push a fix for soon-ish (the prefix variable > needs to be modified through cygpath -m if MSYSTEM is MINGW32 or > MINGW64). However, due to person-power issues, the package will not be > rebuilt for a while, but hopefully you can build your own to test? > > -- > Thanks, > > Ray. > >> Alan >> >> __________________________ >> Alan W. Irwin >> >> Astronomical research affiliation with Department of Physics and Astronomy, >> University of Victoria (astrowww.phys.uvic.ca). >> >> Programming affiliations with the FreeEOS equation-of-state >> implementation for stellar interiors (freeeos.sf.net); the Time >> Ephemerides project (timeephem.sf.net); PLplot scientific plotting >> software package (plplot.sf.net); the libLASi project >> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); >> and the Linux Brochure Project (lbproject.sf.net). >> __________________________ >> >> Linux-powered Science >> __________________________ From cedric.doucet at inria.fr Mon Dec 14 08:36:10 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Mon, 14 Dec 2015 14:36:10 +0100 (CET) Subject: [CMake] HowTo: write install_package function In-Reply-To: <469636334.2151336.1450099494494.JavaMail.zimbra@inria.fr> Message-ID: <1782532474.2155422.1450100170129.JavaMail.zimbra@inria.fr> Hello, I would like to write a function called install_package which works like the find_package function, but for installation of external packages (thanks to ExternalProject). Thus, I would like to write modules InstallFoo.cmake so as to be able to call my function like this: install_package(Foo) # installation of Foo library Do you know if it is possible to implement such a thing? Is there another function I could study to understand how to do it? I tried to look at the implementation of the find_package function in my CMake's installation but I did not manage to find it. C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Mon Dec 14 08:32:32 2015 From: paul at mad-scientist.net (Paul Smith) Date: Mon, 14 Dec 2015 08:32:32 -0500 Subject: [CMake] Parallel jobs failed for cmake In-Reply-To: <1450074887.829448764@f310.i.mail.ru> References: <1449667939.717612735@f323.i.mail.ru> <1449836695.708476596@f391.i.mail.ru> <566B2092.7070502@kitware.com> <1450074887.829448764@f310.i.mail.ru> Message-ID: <1450099952.6979.82.camel@mad-scientist.net> On Mon, 2015-12-14 at 09:34 +0300, Igor Sobinov wrote: > So, If I write in makefile > > > build_release: $(RELEASE_DIR) > @cd $(RELEASE_DIR); $(MAKE) release > > I got an error > > Also if I write > build_release: $(RELEASE_DIR) > $(MAKE) release -C $(RELEASE_DIR) > > I got an error too > > But this is successfull command: > # cd $RELEASE_DIR; make release -j10 > > Why make doesn't support jobs for subdirs? All three of these work for me, so it must be something else in your makefile that you haven't shown us that's causing the problem. Can you provide a SSCCE (http://sscce.org/)? As Bill points out this is a make issue, NOT a cmake issue. I recommend you re-start this thread with all details (operating system, version of make, SSCCE, etc.) on the help-make at gnu.org mailing list rather than here. I'll offer one possible suggestion, first: you haven't by any chance changed the SHELL variable in your external makefile to use csh, have you? SHELL = /bin/csh (or tcsh either). Because if you have, that's the problem. Csh is a terrible shell for many reasons but in particular it cannot be used as the shell for makefiles, if you want the jobserver feature to work. > core:: > +(cd core; make) > > With this, GNU Make is able to distribute the jobs between the > subdirectories. (I have a number of such targets in my main Makefile.) Bill's comment, that you should use $(MAKE) and never plain "make", is correct. It's better to use $(MAKE) for many reasons, only some of which are handled by prefixing the recipe with "+". From tom.kacvinsky at vectorcast.com Mon Dec 14 09:34:33 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Mon, 14 Dec 2015 09:34:33 -0500 Subject: [CMake] transitive dependencies (again) Message-ID: I am getting link errors because cmake is adding transitive dependencies. I am building a DLL which depends on a static archive (and is marked as such with add_dependencies), but when I link an executable that depends on the DLL, both libraries (import library for the DLL and static archive) are specified on the link. leading to duplicate symbol errors as the symbol are exported form the DLL and defined in the static archive. How do I work around this? This is the one thing that has frustrated me over the last couple of years - I have never received an answer telling me how to turn off transitive dependencies. Sorry for the minor rant. Regards, Tom From rcdailey.lists at gmail.com Mon Dec 14 10:24:46 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 14 Dec 2015 09:24:46 -0600 Subject: [CMake] Eclipse not showing custom targets Message-ID: I have a few custom targets I create, but they do not appear in the list of projects when I generate for Eclipse (using CMAKE_ECLIPSE_VERSION=4.2). These particular custom targets are generated all in the same directory, same script. They happen to depend on each other. Example: add_library( TargetA ) add_custom_target( TargetA_foo ) # depends on TargetA add_custom_target( TargetA_bar ) # depends on TargetA_foo I find Eclipse usage with CMake to be very unreliable in general, so maybe this is just a bug? Unrelated but I also have issues with being unable to set directory filters for the C++ indexer via CMake, to prevent it from indexing my third party lib directories. Boost library crashes the CDT indexer. From petr.kmoch at gmail.com Mon Dec 14 10:53:56 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 14 Dec 2015 16:53:56 +0100 Subject: [CMake] transitive dependencies (again) In-Reply-To: References: Message-ID: Hi Tom, linking the static archive into the DLL should not be done by add_dependencies(), but by target_link_libraries(). There, you can explicitly list the archive as PRIVATE so that it does not become a part of the linking interface of the DLL: add_library(staticArchive STATIC ...) add_library(theDLL SHARED ...) target_link_libraries(theDLL PRIVATE staticArchive) Petr On Mon, Dec 14, 2015 at 3:34 PM, Tom Kacvinsky wrote: > I am getting link errors because cmake is adding transitive > dependencies. I am building a DLL which depends on a static archive > (and is marked as such with add_dependencies), but when I link an > executable that depends on the DLL, both libraries (import library for > the DLL and static archive) are specified on the link. leading to > duplicate symbol errors as the symbol are exported form the DLL and > defined in the static archive. > > How do I work around this? This is the one thing that has frustrated > me over the last couple of years - I have never received an answer > telling me how to turn off transitive dependencies. > > Sorry for the minor rant. > > Regards, > > Tom > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.kacvinsky at vectorcast.com Mon Dec 14 10:54:28 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Mon, 14 Dec 2015 10:54:28 -0500 Subject: [CMake] transitive dependencies (again) In-Reply-To: References: Message-ID: On Mon, Dec 14, 2015 at 9:34 AM, Tom Kacvinsky wrote: > I am getting link errors because cmake is adding transitive > dependencies. I am building a DLL which depends on a static archive > (and is marked as such with add_dependencies), but when I link an > executable that depends on the DLL, both libraries (import library for > the DLL and static archive) are specified on the link. leading to > duplicate symbol errors as the symbol are exported form the DLL and > defined in the static archive. > > How do I work around this? This is the one thing that has frustrated > me over the last couple of years - I have never received an answer > telling me how to turn off transitive dependencies. More details: Windows 7, 64 bit, cmake 2.8.12.11 from cmake.org website. DLL built with gnatdll, import library built with MSVC's lib utility, static library built with the MSVC tool chain. I'll try to come up with a simple reproducer. I hope to do this completely with the MSVC tool chain as I don't expect people to jump through the hoops of configuring cmake to use an Ada tool chain. Unless Alan Irwin chimes in, that is. From tom.kacvinsky at vectorcast.com Mon Dec 14 10:59:06 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Mon, 14 Dec 2015 10:59:06 -0500 Subject: [CMake] transitive dependencies (again) In-Reply-To: References: Message-ID: Hi Petr, On Mon, Dec 14, 2015 at 10:53 AM, Petr Kmoch wrote: > Hi Tom, > > linking the static archive into the DLL should not be done by > add_dependencies(), but by target_link_libraries(). There, you can > explicitly list the archive as PRIVATE so that it does not become a part of > the linking interface of the DLL: > > add_library(staticArchive STATIC ...) > > add_library(theDLL SHARED ...) > > target_link_libraries(theDLL PRIVATE staticArchive) > Thanks for the tip. I'll try it out. I hope it works as I am not using the MSVC tool chain to build the DLL (i.e., not using add_library and target_link_libraries). I sent a separate reply detailing what I am using to build the DLL. > > On Mon, Dec 14, 2015 at 3:34 PM, Tom Kacvinsky > wrote: >> >> I am getting link errors because cmake is adding transitive >> dependencies. I am building a DLL which depends on a static archive >> (and is marked as such with add_dependencies), but when I link an >> executable that depends on the DLL, both libraries (import library for >> the DLL and static archive) are specified on the link. leading to >> duplicate symbol errors as the symbol are exported form the DLL and >> defined in the static archive. >> >> How do I work around this? This is the one thing that has frustrated >> me over the last couple of years - I have never received an answer >> telling me how to turn off transitive dependencies. >> >> Sorry for the minor rant. >> >> Regards, >> >> Tom >> -- >> >> 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 > > From bill.hoffman at kitware.com Mon Dec 14 10:59:45 2015 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 14 Dec 2015 10:59:45 -0500 Subject: [CMake] Parallel jobs failed for cmake In-Reply-To: <1450074887.829448764@f310.i.mail.ru> References: <1449667939.717612735@f323.i.mail.ru> <1449836695.708476596@f391.i.mail.ru> <566B2092.7070502@kitware.com> <1450074887.829448764@f310.i.mail.ru> Message-ID: <566EE771.2060702@kitware.com> On 12/14/2015 1:34 AM, Igor Sobinov wrote: > > Thanks, that's clear. > > So, If I write in makefile No not really clear. The problem is NOT in your makefile. The problem is in your custom command that calls make again. That is where the problem is. In your custom command (which you have not provided the code for), it is clear that you call make without $(MAKE) If you go back to your second post on this topic: igor 5460 0.0 0.0 101152 972 pts/3 S+ 08:10 0:00 | \_ make build_release -j5 igor 5466 0.0 0.0 106096 1164 pts/3 S+ 08:10 0:00 | \_ /bin/sh -c cd /home/igor/build_root/release_target; make release Right there is the problem. The custom command does this: /bin/sh -c cd /home/igor/build_root/release_target; make release It needs to do this: /bin/sh -c cd /home/igor/build_root/release_target; $(MAKE) release You will need to escape the $ to get this right. You can check the generated makefile if you are having trouble. -Bill From irwin at beluga.phys.uvic.ca Mon Dec 14 15:02:12 2015 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 14 Dec 2015 12:02:12 -0800 (PST) Subject: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally? In-Reply-To: References: Message-ID: On 2015-12-14 12:43-0000 Ray Donnelly wrote: > The issue I've got here is that on MSYS2 we've decided that we don't > want to provide libdl for mingw-w64 but do provide it for msys2, so > there'll never be a /mingw{64,32}/lib/libdl.a or > /mingw{64,32}/lib/libdl.dll.a, but there is a /usr/lib/libdl.a. When > building mingw-w64 software, the front of PATH will be > "/mingw64/bin:/usr/bin" or "/mingw32/bin:/usr/bin" and that causes > CMake to find /usr/lib/libdl.a due to NO_SYSTEM_ENVIRONMENT_PATH. Hi Ray: Did you mean "due to NO_SYSTEM_ENVIRONMENT_PATH _not_ being set"? That is the only way that sentence makes sense to me and is also consistent with the subject line, but I may be missing something. So if my interpretation of what you said is correct, your special build problem on the MinGW-w64/MSYS2 platform is you want to reject msys2 variants of the libraries (thus avoiding a dependency on the msys2 dll) while still using msys2 build tools. Assuming I have stated the problem correctly, then the solution normally is to put /mingw{64,32} first on your PATH (like the appropriate shell does as you have discussed) and that should guarantee the /mingw{64,32} version of the library is found. However, for the special case where there is no /mingw{64,32} version of the library (from what you said above libdl is an example of this special case) the CMake-based build systems will incorrectly find the msys2 version of the library (because msys2 is necessarily on the PATH because you need access to those build tools) rather than your desired result that CMake finds no library at all for this special case. I believe the MinGW-w64/MSYS2 distribution should address this problem in general by making sure that /mingw{64,32} does provide all libraries that msys2 provides if at all possible. However, whenever there is some absolutely ironclad reason not to provide a /mingw{64,32} variant (as appears to be the case for libdl although you may want to review that reason to make sure it is really ironclad) then you must patch all build systems for software packages that have a soft dependency on libdl to simply ignore any libdl that is found on the MinGW-w64/MSYS2 platform. My impression is that build system patches are required quite often for distributions of free software to help enforce some policy decisions they have made so it appears that MinGW-w64/MSYS2 is also not immune to such a requirement. Of course, this is not a very good solution if there are tonnes of such package build systems to patch, but my guess is that patches for just a handful of packages would be required to deal completely with this special libdl case. By the way, you will be glad to know that I have a strong spectator interest in MinGW-w64/MSYS2 because it turns out (thanks to the testing reports sent to me by Greg Jung which allowed me to adjust the PLplot build system to work properly for the MinGW-w64/MSYS2 case) that has recently become one of our most powerful and reliable PLplot platforms on Windows. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From iosif.neitzke+cmake at gmail.com Mon Dec 14 15:36:49 2015 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Mon, 14 Dec 2015 14:36:49 -0600 Subject: [CMake] transitive dependencies (again) In-Reply-To: References: Message-ID: If you can build Ada sources first, you might wish to make that a standalone project that is consumed downstream natively as an Imported Library. Do you generate the import library from a .def file, or via some other means? On Mon, Dec 14, 2015 at 9:59 AM, Tom Kacvinsky wrote: > Hi Petr, > > > On Mon, Dec 14, 2015 at 10:53 AM, Petr Kmoch wrote: >> Hi Tom, >> >> linking the static archive into the DLL should not be done by >> add_dependencies(), but by target_link_libraries(). There, you can >> explicitly list the archive as PRIVATE so that it does not become a part of >> the linking interface of the DLL: >> >> add_library(staticArchive STATIC ...) >> >> add_library(theDLL SHARED ...) >> >> target_link_libraries(theDLL PRIVATE staticArchive) >> > > Thanks for the tip. I'll try it out. I hope it works as I am not > using the MSVC tool chain > to build the DLL (i.e., not using add_library and target_link_libraries). > > I sent a separate reply detailing what I am using to build the DLL. >> >> On Mon, Dec 14, 2015 at 3:34 PM, Tom Kacvinsky >> wrote: >>> >>> I am getting link errors because cmake is adding transitive >>> dependencies. I am building a DLL which depends on a static archive >>> (and is marked as such with add_dependencies), but when I link an >>> executable that depends on the DLL, both libraries (import library for >>> the DLL and static archive) are specified on the link. leading to >>> duplicate symbol errors as the symbol are exported form the DLL and >>> defined in the static archive. >>> >>> How do I work around this? This is the one thing that has frustrated >>> me over the last couple of years - I have never received an answer >>> telling me how to turn off transitive dependencies. >>> >>> Sorry for the minor rant. >>> >>> Regards, >>> >>> Tom >>> -- >>> >>> 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 From brad.king at kitware.com Mon Dec 14 15:52:26 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 14 Dec 2015 15:52:26 -0500 Subject: [CMake] How to set _default_ timeout for the ctest command? In-Reply-To: References: <5667E506.9080801@astron.nl> Message-ID: <566F2C0A.6070809@kitware.com> On 12/09/2015 10:06 PM, Alan W. Irwin wrote: > Also, the documentation of the ctest --timeout option says: > > `--timeout ` > Set a global timeout on all tests. > > This option will set a global timeout on all tests that do not > already have a timeout set on them. Yes, one can see that implemented here: https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/CTest/cmCTestTestHandler.cxx;hb=v3.4.1#l1112 https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmCTest.cxx#l2108 Here is a commit that set the order of precedence: Local test timeouts will now always take precedence over the global --timeout option. https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c32088cf >From the history of that code it looks like --timeout was added with no consideration of its relationship to CTEST_TEST_TIMEOUT. Some other CTest options in the same scope as CTEST_TEST_TIMEOUT can be overridden by the command line, so I agree that --timeout should override it too. -Brad From mingw.android at gmail.com Mon Dec 14 16:05:46 2015 From: mingw.android at gmail.com (Ray Donnelly) Date: Mon, 14 Dec 2015 21:05:46 +0000 Subject: [CMake] NO_SYSTEM_ENVIRONMENT_PATH globally? In-Reply-To: References: Message-ID: On Mon, Dec 14, 2015 at 8:02 PM, Alan W. Irwin wrote: > On 2015-12-14 12:43-0000 Ray Donnelly wrote: > >> The issue I've got here is that on MSYS2 we've decided that we don't >> want to provide libdl for mingw-w64 but do provide it for msys2, so >> there'll never be a /mingw{64,32}/lib/libdl.a or >> /mingw{64,32}/lib/libdl.dll.a, but there is a /usr/lib/libdl.a. When >> building mingw-w64 software, the front of PATH will be >> "/mingw64/bin:/usr/bin" or "/mingw32/bin:/usr/bin" and that causes >> CMake to find /usr/lib/libdl.a due to NO_SYSTEM_ENVIRONMENT_PATH. > > > Hi Ray: > > Did you mean "due to NO_SYSTEM_ENVIRONMENT_PATH _not_ being set"? That is > the only way that sentence makes sense to me and is also > consistent with the subject line, but I may be missing something. Sure, that's what I meant. > > So if my interpretation of what you said is correct, your special > build problem on the MinGW-w64/MSYS2 platform is you want to reject > msys2 variants of the libraries (thus avoiding a dependency on the > msys2 dll) while still using msys2 build tools. Exactly. > > Assuming I have stated the problem correctly, then the solution > normally is to put /mingw{64,32} first on your PATH (like the > appropriate shell does as you have discussed) and that should > guarantee the /mingw{64,32} version of the library is found. However, > for the special case where there is no /mingw{64,32} version of the > library (from what you said above libdl is an example of this special > case) the CMake-based build systems will incorrectly find the msys2 > version of the library (because msys2 is necessarily on the PATH > because you need access to those build tools) rather than your desired > result that CMake finds no library at all for this special case. > > I believe the MinGW-w64/MSYS2 distribution should address this problem > in general by making sure that /mingw{64,32} does provide all > libraries that msys2 provides if at all possible. However, whenever > there is some absolutely ironclad reason not to provide a > /mingw{64,32} variant (as appears to be the case for libdl although > you may want to review that reason to make sure it is really ironclad) > then you must patch all build systems for software packages that have > a soft dependency on libdl to simply ignore any libdl that is found on > the MinGW-w64/MSYS2 platform. My impression is that build system > patches are required quite often for distributions of free software to > help enforce some policy decisions they have made so it appears that > MinGW-w64/MSYS2 is also not immune to such a requirement. Of course, > this is not a very good solution if there are tonnes of such package > build systems to patch, but my guess is that patches for just a > handful of packages would be required to deal completely with this > special libdl case. Generally speaking msys2 software is POSIX-y and mingw-w64 software is Windows-y, so the library setup doesn't overlap very much and we won't force it (actually we try to limit msys2 packages since Cygwin exists to fill that need). We also want to apply as light a touch as possible when it comes to patching software, but of course will when necessary. For this issue, I think I've figured out what to do: PATH=${MINGW_PREFIX}/bin:/usr/bin cmake -DCMAKE_SYSTEM_IGNORE_PATH=/usr/lib > > By the way, you will be glad to know that I have a strong spectator > interest in MinGW-w64/MSYS2 because it turns out (thanks to the > testing reports sent to me by Greg Jung which allowed me to adjust the > PLplot build system to work properly for the MinGW-w64/MSYS2 case) > that has recently become one of our most powerful and reliable PLplot > platforms on Windows. > Great to hear. Hopefully MSYS2 can continue to prove useful and gain momentum. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ From mishchea at gmail.com Mon Dec 14 17:58:45 2015 From: mishchea at gmail.com (Andrey Mishchenko) Date: Mon, 14 Dec 2015 17:58:45 -0500 Subject: [CMake] Specifying dependencies in a project containing built-from-source artifact generators Message-ID: I have a project where I hope to build a binary, named `final_exe`. The build directory where `final_exe` ends up needs to contain a file called `final_resource` in order for `final_exe` to be considered "built." The file `final_resource` is generated by another binary, called `generating_exe`, which I also build from source as part of my project. Furthermore, for `generating_exe` to be considered "built" or "usable," a file called `generating_resource` needs to be present in the directory where `generating_exe` ends up. The file `generating_resource` is, say, copied verbatim from the source tree. There are many binaries in the project whose builds depend on `generating_exe` (and, transitively, on `generating_resource`) in this manner. I can't think of a way to express this dependency graph cleanly in CMake. First, the easiest thing to do is to add `POST_BUILD` custom commands to the `final_exe` and `generating_exe` targets. I don't like this approach, for a couple of reasons. If the copy of `generating_resource` located in the source tree changes, without some extra work the `POST_BUILD` custom commands won't get called. Developers would need to somehow convince the build system to re-link `generating_exe`. (I am not even clear about how to work around this from within my project's CMake scripts.) Then, even once `generating_exe` is rebuilt, the developer _again_ has to convince the build system to re-link `final_exe` (and any other executable, library, etc., that depends on `final_resource`) in order to obtain a correctly updated build. (Suppose that `final_resource` is not a CPP file, etc., so it is not natural to shove it into the list of sources of `final_exe`.) (The above problem can be summed up by asking, how do you create a custom command in the flavor of, e.g., a `POST_BUILD` command invoking `${CMAKE_COMMAND} -E copy_if_different`, but which will be re-run if the "source files" of the custom command are modified?) A nice(r) solution to the above problems would be to create a custom target, called `copy_generating_resource`, which invokes `${CMAKE_COMMAND} -E copy_if_different`, and which would be run every build (because those are the semantics of custom targets). This approach actually solves the above issues in a reasonable way, except for the following problem: A natural definition of `copy_generating_resource` involves the use of `$` to specify the directory into which to place `generating_resource`, which would make `copy_generating_resource` a dependency of `generating_exe`. It is natural that `final_exe` depends on `generating_exe`. However `generating_exe` is not actually usable until `copy_generating_resource` is run. Furthermore, we cannot even awkwardly declare `copy_generating_resource` to be a dependency of `generating_exe`, because there is already a dependency between these two targets going in the other direction. It is very annoying to insist that the author of the `CMakeLists.txt` file corresponding to `final_exe` must be aware that he needs to encode that `final_exe` depends on `copy_generating_resource` manually. If he fails to do so, he risks `generating_exe` being run (to generate `final_resource`) before it is actually usable, in particular, before `copy_generating_resource` is run. Am I missing something? Andrey Mishchenko -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesbigler at gmail.com Mon Dec 14 18:35:39 2015 From: jamesbigler at gmail.com (James Bigler) Date: Mon, 14 Dec 2015 16:35:39 -0700 Subject: [CMake] VS's /Zo flag Message-ID: Has anyone been able to use the /Zo flag? I tried to add it to my RelWithDebInfo build, but the flag doesn't seem to be showing up in the command line (in the GUI). My flags are: /MT /O2 /Ob2 /D NDEBUG /Zi /Zo I'm using cmake 3.2.1. Documentation on /Zo (available in VS2013.3+: https://msdn.microsoft.com/en-us/library/dn785163.aspx Thanks, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesbigler at gmail.com Mon Dec 14 18:51:33 2015 From: jamesbigler at gmail.com (James Bigler) Date: Mon, 14 Dec 2015 16:51:33 -0700 Subject: [CMake] VS's /Zo flag In-Reply-To: References: Message-ID: OK, so it is there in the project file and if I enable detailed build output, the flag is there. I wonder why the the AdditionalOptions aren't appearing in the GUI. They used to. /w34101 /w34189 /w34018 /w34389 /Zo %(AdditionalOptions) Nothing in the "Additional Options" section in the "Command Line" section of the project settings. On Mon, Dec 14, 2015 at 4:35 PM, James Bigler wrote: > Has anyone been able to use the /Zo flag? I tried to add it to my > RelWithDebInfo build, but the flag doesn't seem to be showing up in the > command line (in the GUI). > > My flags are: > > /MT /O2 /Ob2 /D NDEBUG /Zi /Zo > > I'm using cmake 3.2.1. > > Documentation on /Zo (available in VS2013.3+: > https://msdn.microsoft.com/en-us/library/dn785163.aspx > > Thanks, > James > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r_e_lang at hotmail.com Mon Dec 14 23:03:17 2015 From: r_e_lang at hotmail.com (Richard Lang) Date: Tue, 15 Dec 2015 17:03:17 +1300 Subject: [CMake] Can CMake intelligently support GCC "-include" directive Message-ID: Hi all, Porting a collection of IAR Embedded Workbench projects to CMake/GCC. The IAR projects make use of "preinclude headers" (header files that are automatically included in every source file in the project without being explicitly pulled in with a #include statement - not to be confused with precompiled headers). These map nicely to the GCC "-include " directive and I can manually implement it in my CMakeList.txt file as follows set(PREINCLUDE_FILE "${PROJ_BASE_DIR}/some-path/preinclude.h") ... if (PREINCLUDE_FILE) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -include ${PREINCLUDE_FILE}") endif() and generate a makefile that builds OK. However when I use CMake to generate an Eclipse project there is no consideration given to the preinclude header file(s). In my case the preinclude contains several preprocessor definitions that effectively drive the configuration of the rest of the system during compilation - without them the Eclipse CDT Indexer does not get all the definitions required to make sense of the codebase and requires additional manual configuration before it will do anything useful. Is there any way to automate this from the CMakeList.txt file? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurenchan at gmail.com Tue Dec 15 03:01:22 2015 From: gurenchan at gmail.com (Owen Hogarth II) Date: Tue, 15 Dec 2015 16:01:22 +0800 Subject: [CMake] adding external project Message-ID: I have been reading this: https://cmake.org/cmake/help/v3.0/module/ExternalProject.html trying to add sdl external project but I am having issues. I created a new cmake project to test. I already downloaded the sdl library and can build it correctly by manually calling cmake commands but this is how I'd like to distribute sdl w/ my library. here's my new test cmake: cmake_minimum_required(VERSION2.8) project(sdl_external) include(ExternalProject) ExternalProject_Add(sdl HG_REPOSITORY clone http://hg.libsdl.org/SDL # PREFIX ${CMAKE_SOURCE_DIR}/sdl # SOURCE_DIR ${CMAKE_SOURCE_DIR}/sdl # INSTALL_COMMAND cmake ../ PREFIX=${CMAKE_CURRENT_BINARY_DIR} ) I get this build output: cmake ../ -- The C compiler identification is GNU 4.9.2 -- The CXX compiler identification is GNU 4.9.2 -- 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 -- 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 -- Found Hg: /usr/bin/hg (found version "3.1.2") -- Configuring done -- Generating done -- Build files have been written to: /home/blubee/sdk/test/build Scanning dependencies of target sdl [ 12%] Creating directories for 'sdl' [ 25%] Performing download step (hg clone) for 'sdl' -- Avoiding repeated hg clone, stamp file is up to date: '/home/blubee/sdk/_b/build/test/ build/sdl-prefix/src/sdl-stamp/sdl-hginfo.txt' [ 37%] No patch step for 'sdl' [ 50%] Performing update step (hg pull) for 'sdl' abort: no repository found in ' /home/blubee/sdk/test/build/sdl-prefix/src/sdl' ( .hg not found)! CMakeFiles/sdl.dir/build.make:89: recipe for target 'sdl-prefix/src/sdl-stamp/sdl-update' failed make[2]: *** [sdl-prefix/src/sdl-stamp/sdl-update] Error 255 CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/sdl.dir/all' failed make[1]: *** [CMakeFiles/sdl.dir/all] Error 2 Makefile:76: recipe for target 'all' failed make: *** [all] Error 2 my external build file isn't very verbose but I don't get the error why is it reporting that no repository found. abort: no repository found in '/home/blubee/sdk/test/build/sdl-prefix/src/sdl' ( .hg not found)! Why isn't the mercurial project not being downloaded? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas11braden at gmail.com Tue Dec 15 05:26:53 2015 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Tue, 15 Dec 2015 04:26:53 -0600 Subject: [CMake] adding external project In-Reply-To: References: Message-ID: What's the word "clone" doing in there? That should be a URL, not command parameters. On Tue, Dec 15, 2015 at 2:01 AM, Owen Hogarth II wrote: > I have been reading this: > https://cmake.org/cmake/help/v3.0/module/ExternalProject.html > > trying to add sdl external project but I am having issues. I created a new > cmake project to test. > > I already downloaded the sdl library and can build it correctly by manually > calling cmake commands but this is how I'd like to distribute sdl w/ my > library. > > here's my new test cmake: > > cmake_minimum_required(VERSION2.8) > project(sdl_external) > > include(ExternalProject) > > ExternalProject_Add(sdl > HG_REPOSITORY clone http://hg.libsdl.org/SDL > # PREFIX ${CMAKE_SOURCE_DIR}/sdl > > # SOURCE_DIR ${CMAKE_SOURCE_DIR}/sdl > > # INSTALL_COMMAND cmake ../ PREFIX=${CMAKE_CURRENT_BINARY_DIR} > ) > > I get this build output: > cmake ../ > -- The C compiler identification is GNU 4.9.2 > -- The CXX compiler identification is GNU 4.9.2 > -- 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 > -- 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 > -- Found Hg: /usr/bin/hg (found version "3.1.2") > -- Configuring done > -- Generating done > -- Build files have been written to: /home/blubee/sdk/test/build > Scanning dependencies of target sdl > [ 12%] Creating directories for 'sdl' > [ 25%] Performing download step (hg clone) for 'sdl' > -- Avoiding repeated hg clone, stamp file is up to date: > '/home/blubee/sdk/_b/build/test/ > build/sdl-prefix/src/sdl-stamp/sdl-hginfo.txt' > [ 37%] No patch step for 'sdl' > [ 50%] Performing update step (hg pull) for 'sdl' > abort: no repository found in ' > /home/blubee/sdk/test/build/sdl-prefix/src/sdl' ( > .hg not found)! > CMakeFiles/sdl.dir/build.make:89: recipe for target > 'sdl-prefix/src/sdl-stamp/sdl-update' > failed > make[2]: *** [sdl-prefix/src/sdl-stamp/sdl-update] Error 255 > CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/sdl.dir/all' failed > make[1]: *** [CMakeFiles/sdl.dir/all] Error 2 > Makefile:76: recipe for target 'all' failed > make: *** [all] Error 2 > > my external build file isn't very verbose but I don't get the error > > why is it reporting that no repository found. > abort: no repository found in > '/home/blubee/sdk/test/build/sdl-prefix/src/sdl' ( > .hg not found)! > > Why isn't the mercurial project not being downloaded? > > -- > > 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 From gurenchan at gmail.com Tue Dec 15 05:57:16 2015 From: gurenchan at gmail.com (Owen Hogarth II) Date: Tue, 15 Dec 2015 18:57:16 +0800 Subject: [CMake] adding external project In-Reply-To: References: Message-ID: oh, that was it a typo! A few more questions. I build the project like this: ExternalProject_Add(sdl HG_REPOSITORY http://hg.libsdl.org/SDL UPDATE_COMMAND "" CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/lib SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR}/bin ) That seems to build everything and put everything in the right place. Another thing that I did with other parts of my code was add these lines to the end of the cmakelists.txt files TARGET_INCLUDE_DIRECTORIES(mylib PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/headers) so that I can just #include "mylib" instead of the path to the file. With this setup, I can't do target_include_directories from the external_project_add command, how do I get those headers? On Tue, Dec 15, 2015 at 6:26 PM, Nicholas Braden wrote: > What's the word "clone" doing in there? That should be a URL, not > command parameters. > > On Tue, Dec 15, 2015 at 2:01 AM, Owen Hogarth II > wrote: > > I have been reading this: > > https://cmake.org/cmake/help/v3.0/module/ExternalProject.html > > > > trying to add sdl external project but I am having issues. I created a > new > > cmake project to test. > > > > I already downloaded the sdl library and can build it correctly by > manually > > calling cmake commands but this is how I'd like to distribute sdl w/ my > > library. > > > > here's my new test cmake: > > > > cmake_minimum_required(VERSION2.8) > > project(sdl_external) > > > > include(ExternalProject) > > > > ExternalProject_Add(sdl > > HG_REPOSITORY clone http://hg.libsdl.org/SDL > > # PREFIX ${CMAKE_SOURCE_DIR}/sdl > > > > # SOURCE_DIR ${CMAKE_SOURCE_DIR}/sdl > > > > # INSTALL_COMMAND cmake ../ PREFIX=${CMAKE_CURRENT_BINARY_DIR} > > ) > > > > I get this build output: > > cmake ../ > > -- The C compiler identification is GNU 4.9.2 > > -- The CXX compiler identification is GNU 4.9.2 > > -- 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 > > -- 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 > > -- Found Hg: /usr/bin/hg (found version "3.1.2") > > -- Configuring done > > -- Generating done > > -- Build files have been written to: /home/blubee/sdk/test/build > > Scanning dependencies of target sdl > > [ 12%] Creating directories for 'sdl' > > [ 25%] Performing download step (hg clone) for 'sdl' > > -- Avoiding repeated hg clone, stamp file is up to date: > > '/home/blubee/sdk/_b/build/test/ > > build/sdl-prefix/src/sdl-stamp/sdl-hginfo.txt' > > [ 37%] No patch step for 'sdl' > > [ 50%] Performing update step (hg pull) for 'sdl' > > abort: no repository found in ' > > /home/blubee/sdk/test/build/sdl-prefix/src/sdl' ( > > .hg not found)! > > CMakeFiles/sdl.dir/build.make:89: recipe for target > > 'sdl-prefix/src/sdl-stamp/sdl-update' > > failed > > make[2]: *** [sdl-prefix/src/sdl-stamp/sdl-update] Error 255 > > CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/sdl.dir/all' > failed > > make[1]: *** [CMakeFiles/sdl.dir/all] Error 2 > > Makefile:76: recipe for target 'all' failed > > make: *** [all] Error 2 > > > > my external build file isn't very verbose but I don't get the error > > > > why is it reporting that no repository found. > > abort: no repository found in > > '/home/blubee/sdk/test/build/sdl-prefix/src/sdl' ( > > .hg not found)! > > > > Why isn't the mercurial project not being downloaded? > > > > -- > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at sap.com Tue Dec 15 07:06:01 2015 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Tue, 15 Dec 2015 12:06:01 +0000 Subject: [CMake] ExternalProject_Add and inheritance In-Reply-To: <546748282.910688.1449824735193.JavaMail.zimbra@inria.fr> References: <923C806B-EC10-4711-B327-15517DA4DF13@sap.com> <546748282.910688.1449824735193.JavaMail.zimbra@inria.fr> Message-ID: <4678D073-84D8-449F-94E6-989277ECFF04@sap.com> The problem is not a CMake one but a runtime environment one. You built an executable with a specific environment (GCC 5) but try to execute it in a different environment (default platform): When an executable is built, system libraries paths are not stored as part of the executable so without specific env, wrong library is used. You can solve this problem using, as you already found, LD_LIBRARY_PATH or, may be (not tried), using various CMake related RPATH variables and properties to force storage of system library path. From: Cedric Doucet > Date: Friday 11 December 2015 at 10:05 To: SAP SAP > Cc: "cmake at cmake.org" > Subject: Re: [CMake] ExternalProject_Add and inheritance Hello Marc, thank you very much for your answer! I am not sure to understand how to overcome my problem with these variables. I can explain my problem further. I have a toy example of the problem which contains: - a call to ExternalProject_Add to install boost and yaml-ccp (the latter depends on the former) - a main function which loads a file with yaml-cpp (just one line of code) Everything compiles with GCC 5 and I obtain an executable file (called gcc_example). However, when I run this executable file, I get the following error message : ./gcc_example: relocation error: ./gcc_example: symbol _ZTVNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference And I can overcome this problem by setting LD_LIBRARY_PATH to the right value: LD_LIBRARY_PATH=/home/libraries/gcc/5.2.0/lib64/ ./gcc_example The origin of the problem is that the definition of strings is different since GCC 5. Unfortunately, the default behavior is to call the C++ standard library of my Ubuntu system, and the version of this library is older than the version of GCC 5. I can check it with 'ldd ./gcc_example': linux-vdso.so.1 => (0x00007ffd02ef7000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x0000003a71400000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x0000003d03a00000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x0000003a71000000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x0000003d02e00000) /lib64/ld-linux-x86-64.so.2 (0x0000003d02a00000) But I don't understand why I have still this problem since I put these lines in my CMakeLists file (of course the right value of GCC_ROOT is passed to the cmake command at configuration step): link_directories(${GCC_ROOT}/lib64) target_link_libraries(gcc_example ${GCC_ROOT}/lib64/libstdc++.so) I can provide my simple toy example if it helps to understand. You just need to compile it with GCC 5 to see the problem (with older versions of GCC, everything works fine because strings are defined in the "classical" way). Best, C?dric ________________________________ De: "Marc CHEVRIER" > ?: "Cedric Doucet" >, cmake at cmake.org Envoy?: Vendredi 11 D?cembre 2015 08:44:38 Objet: Re: [CMake] ExternalProject_Add and inheritance With CMake, you can control compilation and link flags with the following environment variables: * CC: specify C compiler * CFLAGS: C compiler flags * CXX: specify C++ compiler * CXXFLAGS: C++ compiler flags * LDFLAGS: linker flags And to finish you can overload make command for generation using CMAKE_COMMAND option of ExternalProject_Add: CMAKE_CMMAND ?${CMAKE_COMMAND}? -E env CXX=${CMAKE_CXX_COMPILER} LDFLAGS=??? ?${CMAKE_COMMAND}? From: CMake > on behalf of Cedric Doucet > Date: Thursday 10 December 2015 at 18:21 To: "cmake at cmake.org" > Subject: [CMake] ExternalProject_Add and inheritance Hello, I use the ExternalProject_Add command to manage third-party libraries. In the same time, I need to overcome some compatibility problems between GCC 4 and GCC 5 (strings are not defined in the same way in the STL). The solution I use is the one given here: http://stackoverflow.com/questions/33500337/how-to-handle-dual-abi-in-gcc-5 It allows me to force to use the libstdc++.so given by the GCC repository given to the cmake command. The problem is that trick does not work with the ExternalProject_Add command because configuration steps of third-party libraries are autonomous. Do you know how to solve the problem? For example, if I use the ExternalProject_Add command to manage a third-library whose configuration also depends on a cmake script, how could I tell this script to use the compilers and the libstdc++.so I provided to my own cmake script? Best, C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurenchan at gmail.com Tue Dec 15 07:47:48 2015 From: gurenchan at gmail.com (Owen Hogarth II) Date: Tue, 15 Dec 2015 20:47:48 +0800 Subject: [CMake] external project add and configure Message-ID: I was able to build the external project that required cmake like this: include(ExternalProject) ExternalProject_Add(sdl HG_REPOSITORY http://hg.libsdl.org/SDL UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/lib SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL INSTALL_DIR ${CMAKE_BINARY_DIR} ) ExternalProject_Get_Property(sdl install_dir) SET(SDL_INSTALL_DIR ${install_dir}) now this second file uses ./configure to set up it's environment. I can build it by going into the folder first running ./autogen.sh then ./configure ... or If I use this external project script below ExternalProject_Add(sdl_image DEPENDS sdl HG_REPOSITORY http://hg.libsdl.org/SDL_image/ UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL_image/ # MAKE_COMMAND make CONFIGURE_COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./configure --prefix=${SDL_INSTALL_DIR}/lib #adding this prefix I get further in my build then I get an error SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR} ) error: missing: line 81: aclocal-1.13: command not found WARNING: 'aclocal-1.13' is missing on your system. You should only need it if you modified 'acinclude.m4' or 'configure.ac' or m4 files included by 'configure.ac'. The 'aclocal' program is part of the GNU Automake package: It also requires GNU Autoconf, GNU m4 and Perl in order to run: I can't actually get cmake to run the autogen script for me. If I leave and manually go run ./autogen.sh and then re-run this cmake command things will built correctly. How can I run the autogen.sh command from within that "ExternalProject_Add(sdl_image ..)" block? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.kacvinsky at vectorcast.com Tue Dec 15 09:28:31 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Tue, 15 Dec 2015 09:28:31 -0500 Subject: [CMake] transitive dependencies (again) In-Reply-To: References: Message-ID: On Mon, Dec 14, 2015 at 3:36 PM, iosif neitzke wrote: > If you can build Ada sources first, you might wish to make that a > standalone project that is consumed downstream natively as an Imported > Library. Do you generate the import library from a .def file, or via > some other means? > Via a def file. I first call gnatdll to make the DLL, then call MSVC's lib tool to create the import library from a def file. I pored through the cmake configuration removing everything that the would appear to give a transitivedependency, yet the dependencies linger. I'll keep digging, this didn't happen before so something must have changed in the configuration when I merged against master for our code base. > On Mon, Dec 14, 2015 at 9:59 AM, Tom Kacvinsky > wrote: >> Hi Petr, >> >> >> On Mon, Dec 14, 2015 at 10:53 AM, Petr Kmoch wrote: >>> Hi Tom, >>> >>> linking the static archive into the DLL should not be done by >>> add_dependencies(), but by target_link_libraries(). There, you can >>> explicitly list the archive as PRIVATE so that it does not become a part of >>> the linking interface of the DLL: >>> >>> add_library(staticArchive STATIC ...) >>> >>> add_library(theDLL SHARED ...) >>> >>> target_link_libraries(theDLL PRIVATE staticArchive) >>> >> >> Thanks for the tip. I'll try it out. I hope it works as I am not >> using the MSVC tool chain >> to build the DLL (i.e., not using add_library and target_link_libraries). >> >> I sent a separate reply detailing what I am using to build the DLL. >>> >>> On Mon, Dec 14, 2015 at 3:34 PM, Tom Kacvinsky >>> wrote: >>>> >>>> I am getting link errors because cmake is adding transitive >>>> dependencies. I am building a DLL which depends on a static archive >>>> (and is marked as such with add_dependencies), but when I link an >>>> executable that depends on the DLL, both libraries (import library for >>>> the DLL and static archive) are specified on the link. leading to >>>> duplicate symbol errors as the symbol are exported form the DLL and >>>> defined in the static archive. >>>> >>>> How do I work around this? This is the one thing that has frustrated >>>> me over the last couple of years - I have never received an answer >>>> telling me how to turn off transitive dependencies. >>>> >>>> Sorry for the minor rant. >>>> >>>> Regards, >>>> >>>> Tom >>>> -- >>>> >>>> Powered by www.kitware.com >>>> >>>> Please keep messages on-topic and check the CMake FAQ at: >>>> http://www.cmake.org/Wiki/CMake_FAQ >>>> >>>> Kitware offers various services to support the CMake community. For more >>>> information on each offering, please visit: >>>> >>>> CMake Support: http://cmake.org/cmake/help/support.html >>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Follow this link to subscribe/unsubscribe: >>>> http://public.kitware.com/mailman/listinfo/cmake >>> >>> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From nicholas11braden at gmail.com Tue Dec 15 09:57:29 2015 From: nicholas11braden at gmail.com (Nicholas Braden) Date: Tue, 15 Dec 2015 08:57:29 -0600 Subject: [CMake] adding external project In-Reply-To: References: Message-ID: I think the issue you are running into is order of execution - when using external projects it is often a good idea to have all the ExternalProject_Add commands in a superproject file with your own project source directory as one of the external projects. This way you can use the DEPENDS parameter to guarantee order of execution - this also makes it so people can just build your project from the source directory if they already have the dependencies, and you can use things like find_package and such. On Tue, Dec 15, 2015 at 4:57 AM, Owen Hogarth II wrote: > oh, that was it a typo! > > A few more questions. I build the project like this: > ExternalProject_Add(sdl > HG_REPOSITORY http://hg.libsdl.org/SDL > UPDATE_COMMAND "" > > CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE > -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/lib > > SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL > > INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR}/bin > ) > > That seems to build everything and put everything in the right place. > Another thing that I did with other parts of my code was add these lines to > the end of the cmakelists.txt files > > TARGET_INCLUDE_DIRECTORIES(mylib PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/headers) > > so that I can just #include "mylib" instead of the path to the file. With > this setup, I can't do target_include_directories from the > external_project_add command, how do I get those headers? > > On Tue, Dec 15, 2015 at 6:26 PM, Nicholas Braden > wrote: >> >> What's the word "clone" doing in there? That should be a URL, not >> command parameters. >> >> On Tue, Dec 15, 2015 at 2:01 AM, Owen Hogarth II >> wrote: >> > I have been reading this: >> > https://cmake.org/cmake/help/v3.0/module/ExternalProject.html >> > >> > trying to add sdl external project but I am having issues. I created a >> > new >> > cmake project to test. >> > >> > I already downloaded the sdl library and can build it correctly by >> > manually >> > calling cmake commands but this is how I'd like to distribute sdl w/ my >> > library. >> > >> > here's my new test cmake: >> > >> > cmake_minimum_required(VERSION2.8) >> > project(sdl_external) >> > >> > include(ExternalProject) >> > >> > ExternalProject_Add(sdl >> > HG_REPOSITORY clone http://hg.libsdl.org/SDL >> > # PREFIX ${CMAKE_SOURCE_DIR}/sdl >> > >> > # SOURCE_DIR ${CMAKE_SOURCE_DIR}/sdl >> > >> > # INSTALL_COMMAND cmake ../ PREFIX=${CMAKE_CURRENT_BINARY_DIR} >> > ) >> > >> > I get this build output: >> > cmake ../ >> > -- The C compiler identification is GNU 4.9.2 >> > -- The CXX compiler identification is GNU 4.9.2 >> > -- 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 >> > -- 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 >> > -- Found Hg: /usr/bin/hg (found version "3.1.2") >> > -- Configuring done >> > -- Generating done >> > -- Build files have been written to: /home/blubee/sdk/test/build >> > Scanning dependencies of target sdl >> > [ 12%] Creating directories for 'sdl' >> > [ 25%] Performing download step (hg clone) for 'sdl' >> > -- Avoiding repeated hg clone, stamp file is up to date: >> > '/home/blubee/sdk/_b/build/test/ >> > build/sdl-prefix/src/sdl-stamp/sdl-hginfo.txt' >> > [ 37%] No patch step for 'sdl' >> > [ 50%] Performing update step (hg pull) for 'sdl' >> > abort: no repository found in ' >> > /home/blubee/sdk/test/build/sdl-prefix/src/sdl' ( >> > .hg not found)! >> > CMakeFiles/sdl.dir/build.make:89: recipe for target >> > 'sdl-prefix/src/sdl-stamp/sdl-update' >> > failed >> > make[2]: *** [sdl-prefix/src/sdl-stamp/sdl-update] Error 255 >> > CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/sdl.dir/all' >> > failed >> > make[1]: *** [CMakeFiles/sdl.dir/all] Error 2 >> > Makefile:76: recipe for target 'all' failed >> > make: *** [all] Error 2 >> > >> > my external build file isn't very verbose but I don't get the error >> > >> > why is it reporting that no repository found. >> > abort: no repository found in >> > '/home/blubee/sdk/test/build/sdl-prefix/src/sdl' ( >> > .hg not found)! >> > >> > Why isn't the mercurial project not being downloaded? >> > >> > -- >> > >> > 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 > > From gurenchan at gmail.com Tue Dec 15 11:53:44 2015 From: gurenchan at gmail.com (Owen Hogarth II) Date: Wed, 16 Dec 2015 00:53:44 +0800 Subject: [CMake] external project add and configure In-Reply-To: References: Message-ID: In response to myself I've figure it out with using add_step function and calling some commands. Full source for what's working building both external libraries. include(ExternalProject) ExternalProject_Add(sdl HG_REPOSITORY http://hg.libsdl.org/SDL UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR} SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL INSTALL_DIR ${CMAKE_BINARY_DIR} ) ExternalProject_Get_Property(sdl install_dir) SET(SDL_INSTALL_DIR ${install_dir}) ExternalProject_Add(sdl_image DEPENDS sdl HG_REPOSITORY http://hg.libsdl.org/SDL_image/ UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL_image/ COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./autogen.sh #this works CONFIGURE_COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./configure --prefix=${SDL_INSTALL_DIR} SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR} ) ExternalProject_Get_Property(sdl_image install_dir) SET(SDL_IMAGE_INSTALL_DIR ${install_dir}) this installs the sdl things in build-tree/lib build-tree/include build-tree/share but even if I try to hardcode the path's they don't get picked up. The other libraries not build with external project add cannot find those files. How do I get those files to be picked up by the regular cmake build? Also I have one further question though they might be related and can be solved at the same time. I would like to add this to my external projects, their include directories are located in TARGET_INCLUDE_DIRECTORIES(sdl PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include) On Tue, Dec 15, 2015 at 8:47 PM, Owen Hogarth II wrote: > I was able to build the external project that required cmake like this: > include(ExternalProject) > > ExternalProject_Add(sdl > HG_REPOSITORY http://hg.libsdl.org/SDL > UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL > > CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE > -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/lib > > SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL > > INSTALL_DIR ${CMAKE_BINARY_DIR} > ) > ExternalProject_Get_Property(sdl install_dir) > SET(SDL_INSTALL_DIR ${install_dir}) > > > now this second file uses ./configure to set up it's environment. > I can build it by going into the folder first running ./autogen.sh then > ./configure ... > > or If I use this external project script below > ExternalProject_Add(sdl_image > DEPENDS sdl > HG_REPOSITORY http://hg.libsdl.org/SDL_image/ > UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL_image/ > > # MAKE_COMMAND make > CONFIGURE_COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./configure > --prefix=${SDL_INSTALL_DIR}/lib > #adding this prefix I get further in my build then I get an error > > SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image > > INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR} > ) > > error: > missing: line 81: aclocal-1.13: > command not found > WARNING: 'aclocal-1.13' is missing on your system. > You should only need it if you modified 'acinclude.m4' or > 'configure.ac' or m4 files included by 'configure.ac'. > The 'aclocal' program is part of the GNU Automake package: > > It also requires GNU Autoconf, GNU m4 and Perl in order to run: > > > > > I can't actually get cmake to run the autogen script for me. If I leave > and manually go run ./autogen.sh and then re-run this cmake command things > will built correctly. > > How can I run the autogen.sh command from within that > "ExternalProject_Add(sdl_image ..)" block? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.a.mcdonald at gmail.com Tue Dec 15 12:43:20 2015 From: rob.a.mcdonald at gmail.com (Rob McDonald) Date: Tue, 15 Dec 2015 09:43:20 -0800 Subject: [CMake] FindFLTK behavior changes between Ubuntu 14.04 and 15.10 Message-ID: On Ubuntu 14.04 (CMake 2.8.12.2), FindFLTK.cmake sets FLTK_FLUID_EXECUTABLE to '/usr/bin/fluid'. This is good. On 15.10 (CMake 3.2.2), FLTK_FLUID_EXECUTABLE gets set to 'fluid'. This is bad. An eyeball comparison of the FindFLTK.cmake scripts included with each doesn't reveal anything suspicious. On another mailing list, someone suggested that the root cause of the change could be a change in bash behavior. Does anyone know what caused this? Does anyone have a workaround? Is there a way to set the CMake variable to the result of a 'which' command? Thanks for any help, Rob From sothy.e98 at gmail.com Tue Dec 15 15:09:36 2015 From: sothy.e98 at gmail.com (sothy shan) Date: Tue, 15 Dec 2015 21:09:36 +0100 Subject: [CMake] Determining if the function pthread_create exists in the pthreads failed with the following output: Message-ID: Hello, I am compiling the source code from https://github.com/flowgrammable/onf2013/ My platform is cmake version 2.8.12.2 Ubunutu 14.04 Error from CmakeError.Log is File /home/sothy/T?l?chargements/onfc/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c: /* */ #include int main(int argc, char** argv) { (void)argv; #ifndef pthread_create return ((int*)(&pthread_create))[argc]; #else (void)argc; return 0; #endif } Determining if the function pthread_create exists in the pthreads failed with the following output: Change Dir: /home/sothy/T?l?chargements/onfc/build/CMakeFiles/CMakeTmp Run Build Command:/usr/bin/make "cmTryCompileExec779452178/fast" /usr/bin/make -f CMakeFiles/cmTryCompileExec779452178.dir/build.make CMakeFiles/cmTryCompileExec779452178.dir/build make[1]: Entering directory `/home/sothy/T?l?chargements/onfc/build/CMakeFiles/CMakeTmp' /usr/bin/cmake -E cmake_progress_report /home/sothy/T?l?chargements/onfc/build/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C object CMakeFiles/cmTryCompileExec779452178.dir/CheckFunctionExists.c.o /usr/bin/cc -DCHECK_FUNCTION_EXISTS=pthread_create -o CMakeFiles/cmTryCompileExec779452178.dir/CheckFunctionExists.c.o -c /usr/share/cmake-2.8/Modules/CheckFunctionExists.c Linking C executable cmTryCompileExec779452178 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec779452178.dir/link.txt --verbose=1 /usr/bin/cc -DCHECK_FUNCTION_EXISTS=pthread_create CMakeFiles/cmTryCompileExec779452178.dir/CheckFunctionExists.c.o -o cmTryCompileExec779452178 -rdynamic -lpthreads /usr/bin/ld: cannot find -lpthreads collect2: error: ld returned 1 exit status make[1]: Leaving directory `/home/sothy/T?l?chargements/onfc/build/CMakeFiles/CMakeTmp' make[1]: *** [cmTryCompileExec779452178] Error 1 make: *** [cmTryCompileExec779452178/fast] Error 2 Can you give me suggestion how to solve the problem? Best regards Sothy From gurenchan at gmail.com Tue Dec 15 16:22:46 2015 From: gurenchan at gmail.com (Owen Hogarth II) Date: Wed, 16 Dec 2015 05:22:46 +0800 Subject: [CMake] external project add and configure In-Reply-To: References: Message-ID: can I bump this, I have the build working just fine now and installing the files in the correct directories, but I can't seem to get my non external projects [the ones I wrote] to link or include with the external projects. how can I get my local cmake projects to link with the files built with ExternalProject_Add? On Wed, Dec 16, 2015 at 12:53 AM, Owen Hogarth II wrote: > In response to myself I've figure it out with using add_step function and > calling some commands. > > Full source for what's working building both external libraries. > > include(ExternalProject) > > ExternalProject_Add(sdl > HG_REPOSITORY http://hg.libsdl.org/SDL > UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL > > CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE > -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR} > > SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL > > INSTALL_DIR ${CMAKE_BINARY_DIR} > ) > > ExternalProject_Get_Property(sdl install_dir) > SET(SDL_INSTALL_DIR ${install_dir}) > > ExternalProject_Add(sdl_image > DEPENDS sdl > HG_REPOSITORY http://hg.libsdl.org/SDL_image/ > UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL_image/ > COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./autogen.sh #this works > > CONFIGURE_COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./configure > --prefix=${SDL_INSTALL_DIR} > > SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image > > INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR} > ) > ExternalProject_Get_Property(sdl_image install_dir) > SET(SDL_IMAGE_INSTALL_DIR ${install_dir}) > > this installs the sdl things in > build-tree/lib > build-tree/include > build-tree/share > > but even if I try to hardcode the path's they don't get picked up. The > other libraries not build with external project add cannot find those > files. How do I get those files to be picked up by the regular cmake build? > > Also I have one further question though they might be related and can be > solved at the same time. > > I would like to add this to my external projects, their include > directories are located in > TARGET_INCLUDE_DIRECTORIES(sdl PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include) > > > > On Tue, Dec 15, 2015 at 8:47 PM, Owen Hogarth II > wrote: > >> I was able to build the external project that required cmake like this: >> include(ExternalProject) >> >> ExternalProject_Add(sdl >> HG_REPOSITORY http://hg.libsdl.org/SDL >> UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL >> >> CMAKE_ARGS -DSDL_STATIC:BOOL=FALSE >> -DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/lib >> >> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL >> >> INSTALL_DIR ${CMAKE_BINARY_DIR} >> ) >> ExternalProject_Get_Property(sdl install_dir) >> SET(SDL_INSTALL_DIR ${install_dir}) >> >> >> now this second file uses ./configure to set up it's environment. >> I can build it by going into the folder first running ./autogen.sh then >> ./configure ... >> >> or If I use this external project script below >> ExternalProject_Add(sdl_image >> DEPENDS sdl >> HG_REPOSITORY http://hg.libsdl.org/SDL_image/ >> UPDATE_COMMAND hg pull -u http://hg.libsdl.org/SDL_image/ >> >> # MAKE_COMMAND make >> CONFIGURE_COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image/./configure >> --prefix=${SDL_INSTALL_DIR}/lib >> #adding this prefix I get further in my build then I get an error >> >> SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/SDL_image >> >> INSTALL_DIR ${CMAKE_CURRENT_BINARY_DIR} >> ) >> >> error: >> missing: line 81: aclocal-1.13: >> command not found >> WARNING: 'aclocal-1.13' is missing on your system. >> You should only need it if you modified 'acinclude.m4' or >> 'configure.ac' or m4 files included by 'configure.ac'. >> The 'aclocal' program is part of the GNU Automake package: >> >> It also requires GNU Autoconf, GNU m4 and Perl in order to run: >> >> >> >> >> I can't actually get cmake to run the autogen script for me. If I leave >> and manually go run ./autogen.sh and then re-run this cmake command things >> will built correctly. >> >> How can I run the autogen.sh command from within that >> "ExternalProject_Add(sdl_image ..)" block? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Tue Dec 15 17:21:49 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 15 Dec 2015 23:21:49 +0100 Subject: [CMake] Determining if the function pthread_create exists in the pthreads failed with the following output: In-Reply-To: References: Message-ID: <65921178.mOoT7Wn5Uu@caliban.sf-tec.de> Am Dienstag, 15. Dezember 2015, 21:09:36 schrieb sothy shan: > Hello, > > I am compiling the source code from > https://github.com/flowgrammable/onf2013/ > My platform is > cmake version 2.8.12.2 > Ubunutu 14.04 > /usr/bin/ld: cannot find -lpthreads This shouldn't be a problem, as that library is call pthread on Linux. I hope this is just calling find_package(Threads), which should handle all this. Greetings, Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From layus.on at gmail.com Wed Dec 16 08:29:08 2015 From: layus.on at gmail.com (Layus) Date: Wed, 16 Dec 2015 14:29:08 +0100 Subject: [CMake] Generate sources Message-ID: <56716724.70907@gmail.com> Hi, I am looking for a way to share an archive of a partially compiled project to speedup compilation time and configuration hassle for the users. I have a project that works in two steps. First a source generator is built (based on clang) and generates some extra source files based on the existing source files. Then the normal compilation process takes places, building the application from both original and generated sources. Here is a pseudo-Makefile. application: $GENERATED_SOURCES $SOURCES cc $^ -o $@ $GENERATED_SOURCES: generator $SOURCES # generate more sources generator $SOURCES generate: $GENERATED_SOURCES generator: generator.cc clang(external) llvm(external) cc $< -o $@ -lclang -lllvm Of course, all the project is using CMake. Now, is it possible to distribute a source archive with the generated sources, in such a way that any user unpacking the archive and running cmake would not have to generate the extra sources ? This would be useful because i) the project is tricky to configure and ii) the generated sources are not dependent on the user config, so building the generator is just useless computation time on the user. The ideal scheme would be something like [developper] $ cmake -DCLANG=config $ make generate $ make package_source [user] $ unpack $ cmake -DUSER=config $ make # builds only the application, reusing the shipped generated sources. $ make install ... but when the user runs cmake, he overwrites the generated Makefiles and the extra sources are generated again. Any idea ? layus. From mark.stijnman at gmail.com Wed Dec 16 11:53:49 2015 From: mark.stijnman at gmail.com (Mark Stijnman) Date: Wed, 16 Dec 2015 17:53:49 +0100 Subject: [CMake] Generate sources In-Reply-To: <56716724.70907@gmail.com> References: <56716724.70907@gmail.com> Message-ID: On Wed, Dec 16, 2015 at 2:29 PM, Layus wrote: > Hi, > > I am looking for a way to share an archive of a partially compiled project > to speedup compilation time and configuration hassle for the users. > > I have a project that works in two steps. > First a source generator is built (based on clang) and generates some > extra source files based on the existing source files. > Then the normal compilation process takes places, building the application > from both original and generated sources. > > > Now, is it possible to distribute a source archive with the generated > sources, in such a way that any user unpacking the archive and running > cmake would not have to generate the extra sources ? > > This would be useful because > i) the project is tricky to configure and > ii) the generated sources are not dependent on the user config, so > building the generator is just useless computation time on the user. > > The ideal scheme would be something like > > [developper] > $ cmake -DCLANG=config > $ make generate > $ make package_source > > [user] > $ unpack > $ cmake -DUSER=config > $ make # builds only the application, reusing the shipped generated > sources. > $ make install > > ... but when the user runs cmake, he overwrites the generated Makefiles > and the extra sources are generated again. > > Any idea ? > > layus. > > -- > I'd probably just make it such that the CMake script automatically detects the presence of the generated files, and if they don't exist, generate them. For example: 1. Set a variable GENERATED_FOLDER to ${CMAKE_CURRENT_SOURCE_DIR}/generated 2. If ${GENERATED_FOLDER} doesn't exist, set it to ${CMAKE_CURRENT_BINARY_DIR}/generated instead, and set up the targets that will generate the files in that folder. 3. Simply use the ${GENERATED_FOLDER} variable to add the generated files to your application. 4. Set up the package_source target so that it packages the files from ${GENERATED_FOLDER} to a folder called "generated" (such that if a user unpacks from there, they will end up in ${CMAKE_CURRENT_SOURCE_DIR}/generated), and you're done. 5. Recommended: add a check for the existence of target "generate", and if so, set it as a dependency for your application and package_source. This way, you don't need to remember what switches to use, or when to use "make generate". If you need to make it possible for a user to force generation, you can alter step 2 to also run when a command line option is supplied. Hope that helps, Best regards Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From MillerHenry at JohnDeere.com Wed Dec 16 11:26:02 2015 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Wed, 16 Dec 2015 16:26:02 +0000 Subject: [CMake] How can I export source code that needs to be built by downstream projects? Message-ID: <35F6921410093E4CA40D524BD5C18D4C3040439F@EDXMB57.jdnet.deere.com> I'm using cmake to build a set of libraries that then gets packaged and shipped to other groups that are also using cmake to use the library. Since I use google mock to mock my libraries, and the downstreams also want to mock my library I just provide the mock header for their use. This works, but there are some quirks of google mock that make it not work well. It turns out the it takes a significant amount of time to build the constructor and destructor for a mock class. So we have moved those to a separate .cpp file that is compiled and exported into another library to link against. INSTALL(FILES MyMock.h DESTINATION include/) INSTALL(TARGETS ${PROJECT_NAME} EXPORT my-target LIBRARY DESTINATION lib COMPONENT ${MY_COMPONENT}) Now I'm looking at upgrading the version of google mock I compile against, but I cannot force my down streams to upgrade (I expect that they will, but politically I cannot force it). The new version is not binary compatible with the old version, even though the headers are source compatible. What I want to do is INSTALL(FILES MyMock.h DESTINATION include/) INSTALL(FILES MyMock.cpp DESTINATION src/) INSTALL(TARGETS MyLibraryMock EXPORT my-target SOURCE_LIBRARY DESTINATION src COMPONENT ${MY_COMPONENT}) Then when the downstreams have TARGET_LINK_LIBRARIES(THEIR_PROJECT MyLibraryMock) Cmake knows to build MyLibraryMock, but if they don't link to the mock (I none of their tests use it) don't build it. Does anyone have any idea on how I might be able to achieve that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakep at arqux.com Wed Dec 16 21:32:10 2015 From: jakep at arqux.com (DJ) Date: Wed, 16 Dec 2015 21:32:10 -0500 Subject: [CMake] Link errors - can I get more verbose messages? Message-ID: <56721EAA.4040807@arqux.com> I recently purchased the OpenGL SuperBible ed. 7. I downloaded the sample code and tried to build it. This is my very first exposure to cmake; I am reading through the documentation and did a quick scan of the gmane archive but cannot seem find an answer to my question. (Probably my fault; my search skills may be bad because I have been up programming for 30 hours :-P AFAIK there is no mailing list or forum for OpenGL SuperBible; could be wrong on this too. I am running Linux Mint 17.1. I did: cmake . make Then cmake gave output: . . . Linking CXX executable bin/alienrain CMakeFiles/alienrain.dir/src/alienrain/alienrain.cpp.o: In function `sb6::application::run(sb6::application*)': alienrain.cpp:(.text._ZN3sb611application3runEPS0_[_ZN3sb611application3runEPS0_]+0x21): undefined reference to `glfwInit' So "glfwInit" is a reference to an entrypoint in libglfw.so; this library exists on my machine at /usr/lib/libglfw.so. Moreover, when I do ldconfig -p I see that this library is listed. QUESTION: Is there a quick way to get cmake to generate more output about how it is linking the executable? Or do I have another problem? Best, -- Jake -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From calebwherry at gmail.com Wed Dec 16 22:53:34 2015 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Wed, 16 Dec 2015 22:53:34 -0500 Subject: [CMake] Link errors - can I get more verbose messages? In-Reply-To: <56721EAA.4040807@arqux.com> References: <56721EAA.4040807@arqux.com> Message-ID: (forgot to reply-all) First: looks like you aren't doing an out-of-source build. If OpenGL expects an out-of-source build (not sure if it does), then you need to do it that way otherwise things could get screwy: $ mkdir build $ cd build $ cmake ${SRC_ROOT} $ make VERBOSE=1 Second, the VERBOSE option to make should spit out a bunch of stuff. You'll have to dig through to find the link lines but it would at least allow you to grep for the lib to make sure it is actually linking against it. -Caleb On Wed, Dec 16, 2015 at 9:32 PM, DJ wrote: > I recently purchased the OpenGL SuperBible ed. 7. I downloaded the sample > code and tried to build it. > > This is my very first exposure to cmake; I am reading through the > documentation and did a quick scan of the gmane archive but cannot seem > find an answer to my question. (Probably my fault; my search skills may be > bad because I have been up programming for 30 hours :-P > > AFAIK there is no mailing list or forum for OpenGL SuperBible; could be > wrong on this too. > > I am running Linux Mint 17.1. > > I did: > > cmake . > make > > Then cmake gave output: > . > . > . > Linking CXX executable bin/alienrain > CMakeFiles/alienrain.dir/src/alienrain/alienrain.cpp.o: In function > `sb6::application::run(sb6::application*)': > alienrain.cpp:(.text._ZN3sb611application3runEPS0_[_ZN3sb611application3runEPS0_]+0x21): > undefined reference to `glfwInit' > > So "glfwInit" is a reference to an entrypoint in libglfw.so; this library > exists on my machine at /usr/lib/libglfw.so. Moreover, when I do > > ldconfig -p > > I see that this library is listed. > > QUESTION: Is there a quick way to get cmake to generate more output about > how it is linking the executable? Or do I have another problem? > > Best, > > -- Jake -- > > -- > > 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 > -- J. Caleb Wherry *Scientific Software Engineer* http://www.calebwherry.com +1 (615) 708-5651 calebwherry at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakep at arqux.com Thu Dec 17 00:02:27 2015 From: jakep at arqux.com (DJ) Date: Thu, 17 Dec 2015 00:02:27 -0500 Subject: [CMake] Link errors - can I get more verbose messages? In-Reply-To: References: <56721EAA.4040807@arqux.com> Message-ID: <567241E3.4000606@arqux.com> On 15-12-16 10:53 PM, J. Caleb Wherry wrote: > (forgot to reply-all) > > First: looks like you aren't doing an out-of-source build. If OpenGL > expects an out-of-source build (not sure if it does), then you need to > do it that way otherwise things could get screwy: > > $ mkdir build > $ cd build > $ cmake ${SRC_ROOT} > $ make VERBOSE=1 > > Second, the VERBOSE option to make should spit out a bunch of stuff. > You'll have to dig through to find the link lines but it would at > least allow you to grep for the lib to make sure it is actually > linking against it. > > -Caleb > Thanks for the reply. I am following the directions supplied with the software, which tells me which directory to run cmake and make in. When I tried your suggestion for out-of-source build, which did not help. However, the make VERBOSE=1 did allow me to locate the file used by cmake to do the linking, so I can see the gcc flags etc. It does appear to me that libraries are not specified as I would expect, but I shall have to re-acquaint myself with what all the link option flags do. I'll probably end up trying to reach the author of the software on this. But meanwhile, could you or anyone give me a hint as to where I would look in cmake files to find out where DSO or static libraries might be specified? This is no doubt in the cmake documentation, but so far I find that documentation less than friendly. Best, - Jake - -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakep at arqux.com Thu Dec 17 00:37:37 2015 From: jakep at arqux.com (DJ) Date: Thu, 17 Dec 2015 00:37:37 -0500 Subject: [CMake] Link errors - can I get more verbose messages? In-Reply-To: <56721EAA.4040807@arqux.com> References: <56721EAA.4040807@arqux.com> Message-ID: <56724A21.1050106@arqux.com> Ok, I found the problem. First (facepalm), the spot where libraries are defined is now pretty obvious to me. Anyway, the original author included tests for systems WIN32, UNIX, and APPLE in CMakeLists.txt. None of these matched for my Linux Mint system, apparently, so I just edited the file to force use of the UNIX library options. At least building works without error now. I shall contact the original author (if possible) to discuss this. But I don't need further help on this mailing list for now. Thanks. Best, - Jake - On 15-12-16 09:32 PM, DJ wrote: > I recently purchased the OpenGL SuperBible ed. 7. I downloaded the > sample code and tried to build it. > > This is my very first exposure to cmake; I am reading through the > documentation and did a quick scan of the gmane archive but cannot > seem find an answer to my question. (Probably my fault; my search > skills may be bad because I have been up programming for 30 hours :-P > > AFAIK there is no mailing list or forum for OpenGL SuperBible; could > be wrong on this too. > > I am running Linux Mint 17.1. > > I did: > > cmake . > make > > Then cmake gave output: > . > . > . > Linking CXX executable bin/alienrain > CMakeFiles/alienrain.dir/src/alienrain/alienrain.cpp.o: In function > `sb6::application::run(sb6::application*)': > alienrain.cpp:(.text._ZN3sb611application3runEPS0_[_ZN3sb611application3runEPS0_]+0x21): > undefined reference to `glfwInit' > > So "glfwInit" is a reference to an entrypoint in libglfw.so; this > library exists on my machine at /usr/lib/libglfw.so. Moreover, when I do > > ldconfig -p > > I see that this library is listed. > > QUESTION: Is there a quick way to get cmake to generate more output > about how it is linking the executable? Or do I have another problem? > > Best, > > -- Jake -- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakep at arqux.com Thu Dec 17 00:55:00 2015 From: jakep at arqux.com (DJ) Date: Thu, 17 Dec 2015 00:55:00 -0500 Subject: [CMake] Link errors - can I get more verbose messages? In-Reply-To: <56721EAA.4040807@arqux.com> References: <56721EAA.4040807@arqux.com> Message-ID: <56724E34.9070308@arqux.com> My bad. Just in case the original author of the OpenGL SuperBible should happen to read this: The problem was that I was using an old codebase - one for the previous edition of the book. The current one IS properly set up. So, now I need to send myself to bed without supper. Sigh. Best, - Jake - From iosif.neitzke+cmake at gmail.com Thu Dec 17 01:39:02 2015 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Thu, 17 Dec 2015 00:39:02 -0600 Subject: [CMake] Link errors - can I get more verbose messages? In-Reply-To: <56724E34.9070308@arqux.com> References: <56721EAA.4040807@arqux.com> <56724E34.9070308@arqux.com> Message-ID: If this [0] is the current code, I also could not get it to build on Xubuntu 15.10. FindPkgConfig.cmake failed with "package 'glfw3' not found" at line 506 (_pkg_check_modules_internal). Running pkg-config --modversion glfw3 returns 3.1.1. [0] https://github.com/openglsuperbible/sb7code On Wed, Dec 16, 2015 at 11:55 PM, DJ wrote: > My bad. > > Just in case the original author of the OpenGL SuperBible should happen to > read this: > > The problem was that I was using an old codebase - one for the previous > edition of the book. The current one IS properly set up. > > So, now I need to send myself to bed without supper. Sigh. > > Best, > > - Jake - > > -- > > 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 From dtvictorious at gmail.com Thu Dec 17 10:27:18 2015 From: dtvictorious at gmail.com (Victorious) Date: Thu, 17 Dec 2015 23:27:18 +0800 Subject: [CMake] organizing source files with CMake Message-ID: <000601d138df$6df1f150$49d5d3f0$@gmail.com> Hi, I'd like to have all my source files in an src folder. The src folder may have .cpp/.h files, and can also have subfolders. This is how I've been doing it, but it only seems to work with files in the src folder (not sure how to extend this to subfolders inside src). Src/cmake list.txt: set(SOURCE ${SOURCE} ${CMAKE_CURRENT_SOURCE_DIR}/file1.cpp ${CMAKE_CURRENT_SOURCE_DIR}/file2.cpp PARENT_SCOPE ) set(HEADERS ${HEADERS} ${CMAKE_CURRENT_SOURCE_DIR}/file1.h ${CMAKE_CURRENT_SOURCE_DIR}/file2.h PARENT_SCOPE add_subdirectory("subdir1") Src/subdir1's cmake list looks similar minus the last line. Then in the top cmake list.txt, add_executable("app" ${SOURCE} ${HEADERS}) A follow-up question: is it possible to do this without specifying each file manually? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.krasznahorkay at gmail.com Thu Dec 17 10:43:23 2015 From: attila.krasznahorkay at gmail.com (Attila Krasznahorkay) Date: Thu, 17 Dec 2015 16:43:23 +0100 Subject: [CMake] organizing source files with CMake In-Reply-To: <000601d138df$6df1f150$49d5d3f0$@gmail.com> References: <000601d138df$6df1f150$49d5d3f0$@gmail.com> Message-ID: <2C1B8E7E-EF99-4CBF-AA19-654AA8554012@gmail.com> Hi Victor, (Without a name I don't have anything better to go on here...) You could do the following in your subdirectory's CMakeLists.txt file: set( SOURCE ${SOURCE} ${CMAKE_CURRENT_SOURCE_DIR}/file1.cpp ... ) set( SOURCE ${SOURCE} PARENT_SCOPE ) The second line will make sure that the variable is updated in the parent's scope (the main CMakeLists.txt file) as well. Cheers, Attila > On 17 Dec 2015, at 16:27, Victorious wrote: > > Hi, > > I?d like to have all my source files in an src folder. The src folder may have .cpp/.h files, and can also have subfolders. > > This is how I?ve been doing it, but it only seems to work with files in the src folder (not sure how to extend this to subfolders inside src). > Src/cmake list.txt: > > set(SOURCE > ${SOURCE} > ${CMAKE_CURRENT_SOURCE_DIR}/file1.cpp > ${CMAKE_CURRENT_SOURCE_DIR}/file2.cpp > PARENT_SCOPE > ) > > set(HEADERS > ${HEADERS} > ${CMAKE_CURRENT_SOURCE_DIR}/file1.h > ${CMAKE_CURRENT_SOURCE_DIR}/file2.h > PARENT_SCOPE > add_subdirectory("subdir1") > > Src/subdir1?s cmake list looks similar minus the last line. Then in the top cmake list.txt, > add_executable("app" ${SOURCE} ${HEADERS}) > > A follow-up question: is it possible to do this without specifying each file manually? > > Thanks > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From dtvictorious at gmail.com Thu Dec 17 12:10:48 2015 From: dtvictorious at gmail.com (Victorious) Date: Fri, 18 Dec 2015 01:10:48 +0800 Subject: [CMake] structured introduction to CMake? Message-ID: <000b01d138ed$e2cc9d00$a865d700$@gmail.com> Hi, While there's plenty of documentation for CMake, it seems to be targeted more towards experienced users, and is in the style of reference documentation. I haven't been able to find many good tutorials that teach the concepts incrementally, e.g how the custom scripting language works etc. Does anyone have any suggestions on where I could look? Thanks, -Vic -------------- next part -------------- An HTML attachment was scrubbed... URL: From krueger at ind.rwth-aachen.de Thu Dec 17 12:03:06 2015 From: krueger at ind.rwth-aachen.de (=?UTF-8?Q?Hauke_Kr=c3=bcger?=) Date: Thu, 17 Dec 2015 18:03:06 +0100 Subject: [CMake] CMake, QT5 and cross compilation Message-ID: <5672EACA.9010406@ind.rwth-aachen.de> Hi everybody, I have a project which builds to realize a Qt5 application. I use the latest CMAKE Qt5 mechanisms such as AUTOMOC etc with good success. The project builds on Raspberry Pi if cmake is run on the Raspberry Pi itself since all Qt tools are available and run also on the Raspberry Pi. Lately, I wanted to compile this project in a cross compile approach. For this purpose, I mount the Raspberry Pi file system to be part of the directory tree on my host Linux PC. Of course, I use find_package to locate the Qt5 package in the directory branch related to the Raspberry Pi. The corresponding moc, uic and rcc tools have been built for arm. Therefore, I can not run the moc from the location as reported by find_package in the cross build approach. So, here is my question: How can I overwrite the moc-executable (and uic etc) path to use another moc version than the one found by the find_package mechanism? If I use the moc which is part of my Linux host PC rather than the arm compiled moc in the Raspberry file system, the code generation should be fine, and afterwards, I will link against the Raspberry Pi Qt5 libraries. Thank you for any help and best regards Hauke From r_e_lang at hotmail.com Thu Dec 17 19:05:33 2015 From: r_e_lang at hotmail.com (Richard Lang) Date: Fri, 18 Dec 2015 13:05:33 +1300 Subject: [CMake] Can CMake intelligently support GCC "-include" directive Message-ID: Posted same question on stack overflow (http://stackoverflow.com/questions/34296887/can-cmake-intelligently-support-gcc-include-directive?noredirect=1#comment56386884_34296887) and got the suggestion that I use add_definitions() to pass the preprocessor defines from the preinclude file to cmake. I used target_compile_definitions() (rather than add_definitions(), as my CMakeList.txt is not in the workspace root) and while the defines in question are correctly included in the "C" build, there is no sign of them in the Eclipse .project/.cproject files and I am no closer to an Eclipse CDT Indexer configured ready-to-go from the CMake project generation. Is this a CMake bug/omission? From jakep at arqux.com Thu Dec 17 22:45:47 2015 From: jakep at arqux.com (DJ) Date: Thu, 17 Dec 2015 22:45:47 -0500 Subject: [CMake] Link errors - can I get more verbose messages? In-Reply-To: References: <56721EAA.4040807@arqux.com> <56724E34.9070308@arqux.com> Message-ID: <5673816B.2080508@arqux.com> On 15-12-17 01:39 AM, iosif neitzke wrote: > If this [0] is the current code, I also could not get it to build on > Xubuntu 15.10. FindPkgConfig.cmake failed with "package 'glfw3' not > found" at line 506 (_pkg_check_modules_internal). > > Running > > pkg-config --modversion glfw3 > > Well, I'm a bit shaky on all this technically. However, on my Mint 17.1 system I had only glfw2 installed (via deb package). So I went into sb7 code directory, then to subdirectory extern/glfw-3.0.4/ and did cmake . make sudo make install and then the overall build of sb7 code worked. From gregoryvv at packz.com Fri Dec 18 08:12:37 2015 From: gregoryvv at packz.com (Gregory Van Vooren) Date: Fri, 18 Dec 2015 14:12:37 +0100 Subject: [CMake] fixup bundle vs Qy 5.5.1 and rpaths Message-ID: <618056F1-CFFF-45F6-BC8D-757EF24F0104@packz.com> I have a project containing several applications (which are sub projects), each of which links against some Qt libraries which are built as dylibs, but are not part of the project. Qt libraries and headers are found using find-package which is working perfectly. I?m currently trying to switch from Qt 5.3.1 to Qt 5.5.1, but am experiencing problems with fixup_bundle on OS X (everything else seems to work fine). As far as I?ve gathered Qt has introduced support for rpaths between those two version and this seems to be the cause of my problems. Building a single application works and said application starts up correctly, but building the install target will give me the following output: -- fixup_bundle: preparing... -- warning: cannot resolve item 'libQt5Core_debug.5.dylib' possible problems: need more directories? need to use InstallRequiredSystemLibraries? run in install tree instead of build tree? -- warning: gp_resolved_file_type non-absolute file 'libQt5Core_debug.5.dylib' returning type 'other' -- possibly incorrect -- warning: cannot resolve item 'libQt5Core_debug.5.dylib' possible problems: need more directories? need to use InstallRequiredSystemLibraries? run in install tree instead of build tree? warning: target 'libQt5Core_debug.5.dylib' is not absolute... warning: target 'libQt5Core_debug.5.dylib' does not exist... CMake Error at /Applications/CMake.app/Contents/share/cmake-3.4/Modules/GetPrerequisites.cmake:800 (message): /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool failed: 1 error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool: can't open file: libQt5Core_debug.5.dylib (No such file or directory) Call Stack (most recent call first): /Applications/CMake.app/Contents/share/cmake-3.4/Modules/GetPrerequisites.cmake:925 (get_prerequisites) /Applications/CMake.app/Contents/share/cmake-3.4/Modules/BundleUtilities.cmake:555 (get_prerequisites) /Applications/CMake.app/Contents/share/cmake-3.4/Modules/BundleUtilities.cmake:804 (get_bundle_keys) someApplication/someApplication/cmake_install.cmake:115 (fixup_bundle) I?ll try to provide sufficient yet minimal information to pinpoint the root cause of the problem. In my top CMakeLists.txt I have the following: set ( QT_REQUIRED_PACKAGES Core Gui Widgets ) set( QT_ROOT_PATH "/usr/local/Qt-5.5.1" ) set( QT_REQUIRED_PACKAGES ${QT_REQUIRED_PACKAGES} MacExtras ) set( QT_PLUGINS_DIR "${QT_ROOT_PATH}/plugins" ) set ( CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH} "${QT_ROOT_PATH}/bin/" ) FOREACH(QT_PACKAGE ${QT_REQUIRED_PACKAGES}) set( QT_PACKAGE_WITH_PREFIX "Qt5${QT_PACKAGE}" ) set( "${QT_PACKAGE_WITH_PREFIX}_DIR" "${QT_ROOT_PATH}/lib/cmake/${QT_PACKAGE_WITH_PREFIX}" ) find_package( "${QT_PACKAGE_WITH_PREFIX}" REQUIRED ) include_directories( ${${QT_PACKAGE_WITH_PREFIX}_INCLUDE_DIRS} ) set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES MAP_IMPORTED_CONFIG_DEBUG "DEBUG") set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES MAP_IMPORTED_CONFIG_RELEASE "RELEASE") set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES MAP_IMPORTED_CONFIG_RELWITHDEBINFO "RELEASE") ENDFOREACH(QT_PACKAGE) add_definitions( ${QT_DEFINITIONS} ) set( CMAKE_INSTALL_PREFIX ${CMAKE_CURRENT_BINARY_DIR} ) set( CMAKE_MACOSX_RPATH ?" ) set_property( GLOBAL PROPERTY USE_FOLDERS ON ) add_subdirectory( someApplication ) in the someApplication CMakeLists.txt I have the following: set( someApplication_Qt_LIBRARIES ${Qt5Core_LIBRARIES} ${Qt5Widgets_LIBRARIES} ) set_target_properties( someApplication PROPERTIES INSTALL_RPATH "${QT_ROOT_PATH}/lib" ) foreach( OUTPUTCONFIG ${CMAKE_CONFIGURATION_TYPES} ) install( TARGETS someApplication DESTINATION bin/${OUTPUTCONFIG} CONFIGURATIONS ${OUTPUTCONFIG} ) endforeach() add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Debug/plugins/platforms/ ) add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf "${QT_PLUGINS_DIR}/platforms/libqcocoa_debug.dylib" ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Debug/plugins/platforms/ ) add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Release/plugins/platforms/ ) add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf "${QT_PLUGINS_DIR}/platforms/libqcocoa.dylib" ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Release/plugins/platforms/ ) add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p `dirname $`/../plugins ) add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/$<$:Debug>$<$>:Release>/plugins/ `dirname $`/../plugins/ ) add_custom_command( TARGET someApplication POST_BUILD COMMAND chmod -R +w `dirname $` ) set( APP "${CMAKE_INSTALL_PREFIX}/bin/\${CMAKE_INSTALL_CONFIG_NAME}/someApplication.app" ) set( DIRS ${APP}/Contents/plugins/platforms ) install( CODE " file( WRITE \"${APP}/Contents/Resources/qt.conf\" \"[Paths]\\nPlugins = plugins\\n\" ) " COMPONENT Runtime ) foreach( DYNAMIC_LIBRARY ${someApplication_DYNAMIC_LIBRARIES} ) add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf $ `dirname $` ) endforeach() install( CODE " file( GLOB_RECURSE QT_PLATFORM_PLUGINS \"${APP}/Contents/plugins/platforms/*${CMAKE_SHARED_LIBRARY_SUFFIX}\" ) include( BundleUtilities ) fixup_bundle( \"${APP}\" \"\${QT_PLATFORM_PLUGINS}\" \"${DIRS}\" ) " COMPONENT Runtime ) Any help is greatly appreciated. Kind regards, Greg. -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at therning.org Fri Dec 18 08:55:42 2015 From: magnus at therning.org (Magnus Therning) Date: Fri, 18 Dec 2015 14:55:42 +0100 Subject: [CMake] Tests with assert and Release build type Message-ID: <87egejhndt.fsf@sobel.cipherstone.com> I'm sure I'm not the first one to run into the conflict between a desire to test the code shipped to customers and the desire to at the same time define NDEBUG to make sure tests don't have their `assert` turned into NOOPs. Is there some nice way of handling this? I can always remove -DNDEBUG from the CFLAGS for tests (possibly by defining a new macro, `ADD_EXECUTABLE_TEST()` or something). Another option is to `#undef NDEBUG` in the source of tests. If there's some more or less standard way to address this I'd like to use that. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus There's a big difference between making something easy to use and making it productive. -- Adam Bosworth -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From clinton at elemtech.com Fri Dec 18 10:15:53 2015 From: clinton at elemtech.com (clinton at elemtech.com) Date: Fri, 18 Dec 2015 08:15:53 -0700 (MST) Subject: [CMake] fixup bundle vs Qy 5.5.1 and rpaths In-Reply-To: <618056F1-CFFF-45F6-BC8D-757EF24F0104@packz.com> References: <618056F1-CFFF-45F6-BC8D-757EF24F0104@packz.com> Message-ID: <1293958247.75789219.1450451753534.JavaMail.zimbra@elemtech.com> It appears you need to add the directory(ies) in the Qt installation containing the Qt libraries to your DIRS. set( DIRS ${APP}/Contents/plugins/platforms ${QT_BINARY_DIR} ${QT_LIBRARY_DIR} ) I think it should have been that way, even with Qt 5.3. Clint ----- On Dec 18, 2015, at 6:12 AM, Gregory Van Vooren wrote: > I have a project containing several applications (which are sub projects), each > of which links against some Qt libraries which are built as dylibs, but are not > part of the project. Qt libraries and headers are found using find-package > which is working perfectly. > I?m currently trying to switch from Qt 5.3.1 to Qt 5.5.1, but am experiencing > problems with fixup_bundle on OS X (everything else seems to work fine). > As far as I?ve gathered Qt has introduced support for rpaths between those two > version and this seems to be the cause of my problems. > Building a single application works and said application starts up correctly, > but building the install target will give me the following output: > -- fixup_bundle: preparing... > -- > warning: cannot resolve item 'libQt5Core_debug.5.dylib' > possible problems: > need more directories? > need to use InstallRequiredSystemLibraries? > run in install tree instead of build tree? > -- warning: gp_resolved_file_type non-absolute file 'libQt5Core_debug.5.dylib' > returning type 'other' -- possibly incorrect > -- > warning: cannot resolve item 'libQt5Core_debug.5.dylib' > possible problems: > need more directories? > need to use InstallRequiredSystemLibraries? > run in install tree instead of build tree? > warning: target 'libQt5Core_debug.5.dylib' is not absolute... > warning: target 'libQt5Core_debug.5.dylib' does not exist... > CMake Error at > /Applications/CMake.app/Contents/share/cmake-3.4/Modules/GetPrerequisites.cmake:800 > (message): > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool > failed: 1 > error: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool: > can't open file: libQt5Core_debug.5.dylib (No such file or directory) > Call Stack (most recent call first): > /Applications/CMake.app/Contents/share/cmake-3.4/Modules/GetPrerequisites.cmake:925 > (get_prerequisites) > /Applications/CMake.app/Contents/share/cmake-3.4/Modules/BundleUtilities.cmake:555 > (get_prerequisites) > /Applications/CMake.app/Contents/share/cmake-3.4/Modules/BundleUtilities.cmake:804 > (get_bundle_keys) > someApplication/someApplication/cmake_install.cmake:115 (fixup_bundle) > I?ll try to provide sufficient yet minimal information to pinpoint the root > cause of the problem. > In my top CMakeLists.txt I have the following: > set ( > QT_REQUIRED_PACKAGES > Core > Gui > Widgets > ) > set( QT_ROOT_PATH "/usr/local/Qt-5.5.1" ) > set( QT_REQUIRED_PACKAGES ${QT_REQUIRED_PACKAGES} MacExtras ) > set( > QT_PLUGINS_DIR > "${QT_ROOT_PATH}/plugins" > ) > set ( CMAKE_PREFIX_PATH ${CMAKE_PREFIX_PATH} "${QT_ROOT_PATH}/bin/" ) > FOREACH(QT_PACKAGE ${QT_REQUIRED_PACKAGES}) > set( QT_PACKAGE_WITH_PREFIX "Qt5${QT_PACKAGE}" ) > set( "${QT_PACKAGE_WITH_PREFIX}_DIR" > "${QT_ROOT_PATH}/lib/cmake/${QT_PACKAGE_WITH_PREFIX}" ) > find_package( "${QT_PACKAGE_WITH_PREFIX}" REQUIRED ) > include_directories( ${${QT_PACKAGE_WITH_PREFIX}_INCLUDE_DIRS} ) > set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES MAP_IMPORTED_CONFIG_DEBUG > "DEBUG") > set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES > MAP_IMPORTED_CONFIG_RELEASE "RELEASE") > set_target_properties( "Qt5::${QT_PACKAGE}" PROPERTIES > MAP_IMPORTED_CONFIG_RELWITHDEBINFO "RELEASE") > ENDFOREACH(QT_PACKAGE) > add_definitions( ${QT_DEFINITIONS} ) > set( CMAKE_INSTALL_PREFIX ${CMAKE_CURRENT_BINARY_DIR} ) > set( CMAKE_MACOSX_RPATH ?" ) > set_property( GLOBAL PROPERTY USE_FOLDERS ON ) > add_subdirectory( someApplication ) > in the someApplication CMakeLists.txt I have the following: > set( > someApplication_Qt_LIBRARIES > ${Qt5Core_LIBRARIES} > ${Qt5Widgets_LIBRARIES} > ) > set_target_properties( someApplication PROPERTIES INSTALL_RPATH > "${QT_ROOT_PATH}/lib" ) > foreach( OUTPUTCONFIG ${CMAKE_CONFIGURATION_TYPES} ) > install( TARGETS someApplication DESTINATION bin/${OUTPUTCONFIG} CONFIGURATIONS > ${OUTPUTCONFIG} ) > endforeach() > add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p > ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Debug/plugins/platforms/ > ) > add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf > "${QT_PLUGINS_DIR}/platforms/libqcocoa_debug.dylib" > ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Debug/plugins/platforms/ > ) > add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p > ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Release/plugins/platforms/ > ) > add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf > "${QT_PLUGINS_DIR}/platforms/libqcocoa.dylib" > ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/Release/plugins/platforms/ > ) > add_custom_command( TARGET someApplication POST_BUILD COMMAND mkdir -p `dirname > $`/../plugins ) > add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf > ${CMAKE_INSTALL_PREFIX}/LocalizationTools/someApplication/$<$:Debug>$<$>:Release>/plugins/ > `dirname $`/../plugins/ ) > add_custom_command( TARGET someApplication POST_BUILD COMMAND chmod -R +w > `dirname $` ) > set( APP > "${CMAKE_INSTALL_PREFIX}/bin/\${CMAKE_INSTALL_CONFIG_NAME}/someApplication.app" > ) > set( DIRS > ${APP}/Contents/plugins/platforms > ) > install( CODE " > file( WRITE \"${APP}/Contents/Resources/qt.conf\" \"[Paths] \\nPlugins = > plugins\\n\" ) > " COMPONENT Runtime > ) > foreach( DYNAMIC_LIBRARY ${someApplication_DYNAMIC_LIBRARIES} ) > add_custom_command( TARGET someApplication POST_BUILD COMMAND cp -Rf > $ `dirname $` ) > endforeach() > install( CODE " > file( GLOB_RECURSE QT_PLATFORM_PLUGINS > \"${APP}/Contents/plugins/platforms/*${CMAKE_SHARED_LIBRARY_SUFFIX}\" ) > include( BundleUtilities ) > fixup_bundle( \"${APP}\" \"\${QT_PLATFORM_PLUGINS}\" \"${DIRS}\" ) > " COMPONENT Runtime > ) > Any help is greatly appreciated. > Kind regards, > Greg. > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cary at txcorp.com Fri Dec 18 11:12:35 2015 From: cary at txcorp.com (JR Cary) Date: Fri, 18 Dec 2015 09:12:35 -0700 Subject: [CMake] Is there a way to disable adding extra libraries at the end of a link line? Message-ID: <56743073.7000101@txcorp.com> Working on a just delivered Cray I am again challenged by the way that CMake adds libraries to the end of the link line that I did not specify. The Cray requires use of the compiler wrappers. After adding the appropriate libraries (hdf5, z) to my target, the link line is /opt/cray/craype/2.4.2/bin/CC -DMPICH_IGNORE_CXX_SEEK -std=c++11 -O3 -DNDEBUG -msse2 CMakeFiles/io.dir/io.cxx.o -o io -L/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib ../libtxio.a ../../txstreams/libtxstreams.a /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a -Wl,-Bstatic -lz -Wl,-Bdynamic /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a -Wl,-Bstatic -lz -Wl,-Bdynamic -Wl,-rpath,/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib and the link fails with ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/usr/lib/../lib64/libc.a(strcmp.o)' can not be used when making an executable; recompile with -fPIE and relink with -pie Now I believe that Cray has the appropriate libraries in its compiler wrapper, because if I just link without all the additions: /opt/cray/craype/2.4.2/bin/CC -DMPICH_IGNORE_CXX_SEEK -std=c++11 -O3 -DNDEBUG -msse2 CMakeFiles/io.dir/io.cxx.o -o io -L/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib ../libtxio.a ../../txstreams/libtxstreams.a /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a -lz it all just works. Is there a way to tell cmake not to append "-Wl,-Bdynamic /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a -Wl,-Bstatic -lz -Wl,-Bdynamic -Wl,-rpath,/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib" to the link line and not to insert -Wl,-Bstatic in front of -lz ? Thx....John Cary From iosif.neitzke+cmake at gmail.com Fri Dec 18 13:59:46 2015 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Fri, 18 Dec 2015 12:59:46 -0600 Subject: [CMake] Feature request: expose curl to cmake -E Message-ID: It would be nice to have curl as a platform-independent command like 'md5sum', 'tar', and 'compare_files'. From iosif.neitzke+cmake at gmail.com Fri Dec 18 14:24:23 2015 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Fri, 18 Dec 2015 13:24:23 -0600 Subject: [CMake] structured introduction to CMake? In-Reply-To: <000b01d138ed$e2cc9d00$a865d700$@gmail.com> References: <000b01d138ed$e2cc9d00$a865d700$@gmail.com> Message-ID: some CMake introductory references: CMake's own Tutorial: https://cmake.org/cmake-tutorial/ (probably want to start here) Mastering CMake (by Kitware): http://www.amazon.com/Mastering-CMake-Ken-Martin/dp/1930934319/ref=sr_1_1?s=books&ie=UTF8&qid=1450465685&sr=1-1 Introduction to CMake: http://www.amazon.com/Introduction-CMake-Software-Tool-Book-ebook/dp/B00KE807Q0/ref=la_B00GPU8HLS_1_1?s=books&ie=UTF8&qid=1450465758&sr=1-1 John Lamp's CMake Tutorial: https://www.johnlamp.net/cmake-tutorial.html Eric Noulard's Tutorial Presentation: https://github.com/TheErk/CMake-tutorial Jan Engels' CMake Tutorial: http://docslide.us/documents/cmake-tutorial.html Daniel Pfeifer's CMake Introduction and best practices: http://www.slideshare.net/DanielPfeifer1/cmake-48475415 On Thu, Dec 17, 2015 at 11:10 AM, Victorious wrote: > Hi, > > > > While there?s plenty of documentation for CMake, it seems to be targeted > more towards experienced users, and is in the style of reference > documentation. I haven?t been able to find many good tutorials that teach > the concepts incrementally, e.g how the custom scripting language works etc. > > > > Does anyone have any suggestions on where I could look? > > > > Thanks, > > -Vic > > > -- > > 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 From layus.on at gmail.com Fri Dec 18 14:53:19 2015 From: layus.on at gmail.com (Layus) Date: Fri, 18 Dec 2015 20:53:19 +0100 Subject: [CMake] Generate sources In-Reply-To: References: <56716724.70907@gmail.com> Message-ID: <5674642F.4060107@gmail.com> On 16/12/15 17:53, Mark Stijnman wrote: > On Wed, Dec 16, 2015 at 2:29 PM, Layus > wrote: > > Hi, > > I am looking for a way to share an archive of a partially compiled > project to speedup compilation time and configuration hassle for > the users. > > I have a project that works in two steps. > First a source generator is built (based on clang) and generates > some extra source files based on the existing source files. > Then the normal compilation process takes places, building the > application from both original and generated sources. > > > > Now, is it possible to distribute a source archive with the > generated sources, in such a way that any user unpacking the > archive and running cmake would not have to generate the extra > sources ? > > This would be useful because > i) the project is tricky to configure and > ii) the generated sources are not dependent on the user config, so > building the generator is just useless computation time on the user. > > The ideal scheme would be something like > > [developper] > $ cmake -DCLANG=config > $ make generate > $ make package_source > > [user] > $ unpack > $ cmake -DUSER=config > $ make # builds only the application, reusing the shipped > generated sources. > $ make install > > ... but when the user runs cmake, he overwrites the generated > Makefiles and the extra sources are generated again. > > Any idea ? > > layus. > > -- > > > I'd probably just make it such that the CMake script automatically > detects the presence of the generated files, and if they don't exist, > generate them. For example: > 1. Set a variable GENERATED_FOLDER to > ${CMAKE_CURRENT_SOURCE_DIR}/generated > 2. If ${GENERATED_FOLDER} doesn't exist, set it to > ${CMAKE_CURRENT_BINARY_DIR}/generated instead, and set up the targets > that will generate the files in that folder. > 3. Simply use the ${GENERATED_FOLDER} variable to add the generated > files to your application. > 4. Set up the package_source target so that it packages the files from > ${GENERATED_FOLDER} to a folder called "generated" (such that if a > user unpacks from there, they will end up in > ${CMAKE_CURRENT_SOURCE_DIR}/generated), and you're done. > 5. Recommended: add a check for the existence of target "generate", > and if so, set it as a dependency for your application and package_source. > > This way, you don't need to remember what switches to use, or when to > use "make generate". If you need to make it possible for a user to > force generation, you can alter step 2 to also run when a command line > option is supplied. > > Hope that helps, > > Best regards Mark Works like a charm. (See https://github.com/layus/mozart2/tree/cache_generated_code) Thanks ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsvanbethlehem at gmail.com Fri Dec 18 15:18:03 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Fri, 18 Dec 2015 21:18:03 +0100 Subject: [CMake] Feature request: expose curl to cmake -E In-Reply-To: References: Message-ID: <87F925C9-B932-4F32-BECC-4FCFA72E2CD1@gmail.com> Depending on what you precisely wish to achieve, maybe file(DOWNLOAD) already fits your needs? https://cmake.org/cmake/help/v3.1/command/file.html Sincerely, Jakob van Bethlehem > On 18 Dec 2015, at 19:59, iosif neitzke wrote: > > It would be nice to have curl as a platform-independent command like > 'md5sum', 'tar', and 'compare_files'. > -- > > 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 From jsvanbethlehem at gmail.com Fri Dec 18 15:22:33 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Fri, 18 Dec 2015 21:22:33 +0100 Subject: [CMake] CMake, QT5 and cross compilation In-Reply-To: <5672EACA.9010406@ind.rwth-aachen.de> References: <5672EACA.9010406@ind.rwth-aachen.de> Message-ID: Maybe you can do something with the ?HINTS? option to find_package()? https://cmake.org/cmake/help/v3.4/command/find_package.html Sincerely, Jakob > On 17 Dec 2015, at 18:03, Hauke Kr?ger wrote: > > Hi everybody, > > I have a project which builds to realize a Qt5 application. I use the > latest CMAKE Qt5 mechanisms such as AUTOMOC etc with good success. > > The project builds on Raspberry Pi if cmake is run on the Raspberry Pi > itself since all Qt tools are available and run also on the Raspberry Pi. > > Lately, I wanted to compile this project in a cross compile approach. > For this purpose, I mount the Raspberry Pi file system to be part of the > directory tree on my host Linux PC. > Of course, I use find_package to locate the Qt5 package in the directory > branch related to the Raspberry Pi. The corresponding > moc, uic and rcc tools have been built for arm. Therefore, I can not > run the moc from the location as reported by find_package in the cross > build approach. > > So, here is my question: How can I overwrite the moc-executable (and uic > etc) path to use another moc version than the one found by the > find_package mechanism? If I use the moc which is part of my Linux host > PC rather than the arm compiled moc in the Raspberry file system, the > code generation should be fine, and afterwards, I will link against the > Raspberry Pi Qt5 libraries. > > Thank you for any help and best regards > > Hauke > > -- > > 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 From gurenchan at gmail.com Fri Dec 18 15:29:16 2015 From: gurenchan at gmail.com (Owen Hogarth II) Date: Sat, 19 Dec 2015 04:29:16 +0800 Subject: [CMake] build order Message-ID: If you download, compile and install a cmake project through external project How can I make sure that the external project is built before something that depends on that external project? -------------- next part -------------- An HTML attachment was scrubbed... URL: From iosif.neitzke+cmake at gmail.com Fri Dec 18 15:42:13 2015 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Fri, 18 Dec 2015 14:42:13 -0600 Subject: [CMake] Feature request: expose curl to cmake -E In-Reply-To: <87F925C9-B932-4F32-BECC-4FCFA72E2CD1@gmail.com> References: <87F925C9-B932-4F32-BECC-4FCFA72E2CD1@gmail.com> Message-ID: On Fri, Dec 18, 2015 at 2:18 PM, Jakob van Bethlehem wrote: > Depending on what you precisely wish to achieve, maybe file(DOWNLOAD) already fits your needs? > https://cmake.org/cmake/help/v3.1/command/file.html It does, generally, in the way that ExternalProject also fits, but I think would require writing wrapper scripts. My specific use case was something like: cmake -E curl http://jenkins/buildA/artifacts/stuff.tar cmake -E tar xzf stuff.tar cmake -Hstuff/path/to/CMakeLists/ -Bbuild_dir cmake --build build_dir I thought 'curl' is sort of at the level of 'tar', in being a useful tool that could be exposed fairly easily in a cmake portable command. Those portable commands are another thing that CMake offers that makes working on Windows a little easier, if you don't already have Cygwin or the like. From jakep at arqux.com Fri Dec 18 16:02:47 2015 From: jakep at arqux.com (DJ) Date: Fri, 18 Dec 2015 16:02:47 -0500 Subject: [CMake] Are the poor reviews of Mastering CMake Justified? Message-ID: <56747477.4050400@arqux.com> I have only very recently encountered the need to use cmake. It seems this need came all at once out of the blue. It appears to me that there is a general perception that good tutorial material is in short supply. I have followed various tutorials that are available online and find them less than stellar. I am mostly familiar with gnu toolchain stuff. I admit that I am biased here because my own work presents zero requirement for cross-platform builds. So far I find cmake documentation to be considerably inferior to gnu documentation, but that's just me. This all led me to consider purchasing the book Mastering CMake. However, reviews on Amazon are generally very critical of the book. It is indeed expensive. Should I bother to shell out for it, or do others here share this negative evaluation of it? I don't want to waste my money. Best, - Jake - From digitalriptide at gmail.com Fri Dec 18 19:48:42 2015 From: digitalriptide at gmail.com (digitalriptide) Date: Fri, 18 Dec 2015 16:48:42 -0800 Subject: [CMake] Change the linker and archiver for cmake? Message-ID: Hello, How does one select the linker and archiver for use with cmake? I can change my C compiler by doing this 'CC=icc cmake ..', but I would also like to use the Intel archiver and linker (xiar and xild). Thank you for the advices. From ps_ml at gmx.de Fri Dec 18 20:19:10 2015 From: ps_ml at gmx.de (Patrick Spendrin) Date: Sat, 19 Dec 2015 02:19:10 +0100 Subject: [CMake] Change the linker and archiver for cmake? In-Reply-To: References: Message-ID: <5674B08E.1000802@gmx.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 19.12.2015 um 01:48 schrieb digitalriptide: > Hello, > > How does one select the linker and archiver for use with cmake? I > can change my C compiler by doing this 'CC=icc cmake ..', but I > would also like to use the Intel archiver and linker (xiar and > xild). > > Thank you for the advices. > There has been a similar question: https://cmake.org/pipermail/cmake/2014-August/058268.html In short: You have to provide new linker rules to cmake to replace the current default (linking using the compiler itself). I hope that helps a bit. regards, Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (MingW32) iQIcBAEBAgAGBQJWdLCNAAoJEPAKI6QtGt1x6skP/3daLIg7qc+al33pWJeFY9LM UCvIuZ2CO5HVj/oKDYqi22ae+751HVQ9t39X5oe5xtcNXeITjl+uX02Uw4h772jt Hb25dZWXG8wAovuofEHuI273qNpOfUtY/tvRxzbMCf8dxXYfp45p5uE+NBeTZ23w QxcKyZv6ixmd8npwu1nsesGDmeMzB8DkzUFUPykUAqV2m/xuOH1FLmJ3wSwmnlTl Uq5QWnJmOmduh6XJYK58NxGrnZkDV0Hy1km+tGnKBNoNwpG0bHNQLqJFWf2FGP4S S4nHWhjmROwFbLT6iRdqk0uyzCnYHlA2cwIYvMipLTaCxZNvdeDZK9rZps1CiqsL cA82IC4mP4Ivtv6qw+2QqOIlQ+dbjLlCG44mm5SKHf9BF+JYuj6REAuv6QdTdOJ1 A2u4NRugxzebwsUyOPO5DzJZeVv7hSB9ivtB9qI4yOrKGh9Eg73x+ptPPrAsLxn6 9xAN2TnIUIkFxlf450GC2pEBuf/n25eyTbby6dVtbO9ADtQ4Y0uyTR+5lSRhTPpC vpACrHBCJNdqPMLEAVYkmjnAZxm9LvxVNQjwW5SN/yHHOlOgElI8dk/CvphvYiz9 miQz1EQiQjS/RFl876brpAbTq33rBn+EEYJD8hHRaaAflaL9CA7c6+h4A4X4DJ7e Z86rA5CPliKgmQdNR3ub =7D3M -----END PGP SIGNATURE----- From ruslan_baratov at yahoo.com Fri Dec 18 21:06:59 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Sat, 19 Dec 2015 09:06:59 +0700 Subject: [CMake] Tests with assert and Release build type In-Reply-To: <87egejhndt.fsf@sobel.cipherstone.com> References: <87egejhndt.fsf@sobel.cipherstone.com> Message-ID: <5674BBC3.7020905@yahoo.com> How about using RelWithDebInfo? See: http://stackoverflow.com/a/28124715/2288008 Ruslo On 18-Dec-15 20:55, Magnus Therning wrote: > I'm sure I'm not the first one to run into the conflict between a desire > to test the code shipped to customers and the desire to at the same time > define NDEBUG to make sure tests don't have their `assert` turned into > NOOPs. > > Is there some nice way of handling this? > > I can always remove -DNDEBUG from the CFLAGS for tests (possibly by > defining a new macro, `ADD_EXECUTABLE_TEST()` or something). Another > option is to `#undef NDEBUG` in the source of tests. > > If there's some more or less standard way to address this I'd like to > use that. > > /M > > -- > Magnus Therning OpenPGP: 0x927912051716CE39 > email: magnus at therning.org jabber: magnus at therning.org > twitter: magthe http://therning.org/magnus > > There's a big difference between making something easy to use and > making it productive. > -- Adam Bosworth > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Sat Dec 19 08:18:30 2015 From: DLRdave at aol.com (David Cole) Date: Sat, 19 Dec 2015 08:18:30 -0500 Subject: [CMake] build order In-Reply-To: References: Message-ID: <107D618B-CDDF-427D-BF6E-AFC680B82246@aol.com> Build the second thing as an ExternalProject, too, and use the DEPENDS keyword to make it build after the first thing. Don't try to mix-and-match external projects and non-external projects in the same CMake configure... It's just too much work to get things working in a reasonable cross-platform way. It's possible, but certainly not easy. David > On Dec 18, 2015, at 3:29 PM, Owen Hogarth II wrote: > > If you download, compile and install a cmake project through external project > > How can I make sure that the external project is built before something that depends on that external project? > -- > > 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 From iosif.neitzke+cmake at gmail.com Sat Dec 19 09:56:26 2015 From: iosif.neitzke+cmake at gmail.com (iosif neitzke) Date: Sat, 19 Dec 2015 08:56:26 -0600 Subject: [CMake] Feature request: expose curl to cmake -E In-Reply-To: <10cc46807d324f8dae6781e1b38bdca6@BN1PR79MB006.MGDADSK.autodesk.com> References: <87F925C9-B932-4F32-BECC-4FCFA72E2CD1@gmail.com> <10cc46807d324f8dae6781e1b38bdca6@BN1PR79MB006.MGDADSK.autodesk.com> Message-ID: Mostly yes. On Sat, Dec 19, 2015 at 8:45 AM, Greg Marr wrote: > iosif neitzke wrote: >>On Fri, Dec 18, 2015 at 2:18 PM, Jakob van Bethlehem wrote: >>> Depending on what you precisely wish to achieve, maybe file(DOWNLOAD) already fits your needs? >>> https://cmake.org/cmake/help/v3.1/command/file.html >> >>It does, generally, in the way that ExternalProject also fits, but I think would require writing wrapper >scripts. My specific use case was something like: >> >>cmake -E curl http://jenkins/buildA/artifacts/stuff.tar >>cmake -E tar xzf stuff.tar >>cmake -Hstuff/path/to/CMakeLists/ -Bbuild_dir cmake --build build_dir >> >>I thought 'curl' is sort of at the level of 'tar', in being a useful tool that >>could be exposed fairly easily in a cmake portable command. >>Those portable commands are another thing that CMake offers that makes working >>on Windows a little easier, if you don't already have Cygwin or the like. > > curl is already portable. Are you just trying to avoid installing curl? > From jsvanbethlehem at gmail.com Sat Dec 19 10:00:01 2015 From: jsvanbethlehem at gmail.com (Jakob van Bethlehem) Date: Sat, 19 Dec 2015 16:00:01 +0100 Subject: [CMake] Feature request: expose curl to cmake -E In-Reply-To: References: <87F925C9-B932-4F32-BECC-4FCFA72E2CD1@gmail.com> Message-ID: > > I thought 'curl' is sort of at the level of 'tar', in being a useful > tool that could be exposed fairly easily in a cmake portable command. Have you ever checked out the full man page of curl and the full feature list? (http://curl.haxx.se/docs/manpage.html) This is certainly not ?easy? to simply port ;-) Sincerely, Jakob From greg.marr at autodesk.com Sat Dec 19 09:45:54 2015 From: greg.marr at autodesk.com (Greg Marr) Date: Sat, 19 Dec 2015 14:45:54 +0000 Subject: [CMake] Feature request: expose curl to cmake -E In-Reply-To: References: <87F925C9-B932-4F32-BECC-4FCFA72E2CD1@gmail.com> Message-ID: <10cc46807d324f8dae6781e1b38bdca6@BN1PR79MB006.MGDADSK.autodesk.com> iosif neitzke wrote: >On Fri, Dec 18, 2015 at 2:18 PM, Jakob van Bethlehem wrote: >> Depending on what you precisely wish to achieve, maybe file(DOWNLOAD) already fits your needs? >> https://cmake.org/cmake/help/v3.1/command/file.html > >It does, generally, in the way that ExternalProject also fits, but I think would require writing wrapper >scripts. My specific use case was something like: > >cmake -E curl http://jenkins/buildA/artifacts/stuff.tar >cmake -E tar xzf stuff.tar >cmake -Hstuff/path/to/CMakeLists/ -Bbuild_dir cmake --build build_dir > >I thought 'curl' is sort of at the level of 'tar', in being a useful tool that >could be exposed fairly easily in a cmake portable command. >Those portable commands are another thing that CMake offers that makes working >on Windows a little easier, if you don't already have Cygwin or the like. curl is already portable. Are you just trying to avoid installing curl? From gurenchan at gmail.com Sat Dec 19 10:51:20 2015 From: gurenchan at gmail.com (Owen Hogarth II) Date: Sat, 19 Dec 2015 23:51:20 +0800 Subject: [CMake] build order In-Reply-To: <107D618B-CDDF-427D-BF6E-AFC680B82246@aol.com> References: <107D618B-CDDF-427D-BF6E-AFC680B82246@aol.com> Message-ID: Hi David Thank you for the response, I thought that I was doing something wrong. I mean it's documented and I followed the docs as close as possible to write my scripts but there's literally no mention about how to solve this external/ internal project setup in the official docs. I saw some things online but I honestly it seemed overly complicated and really prone to breaking. I'll edit my project to make them all external projects and work from that angle. Thanks On Sat, Dec 19, 2015 at 9:18 PM, David Cole wrote: > Build the second thing as an ExternalProject, too, and use the DEPENDS > keyword to make it build after the first thing. > > Don't try to mix-and-match external projects and non-external projects in > the same CMake configure... It's just too much work to get things working > in a reasonable cross-platform way. It's possible, but certainly not easy. > > > David > > > > On Dec 18, 2015, at 3:29 PM, Owen Hogarth II > wrote: > > > > If you download, compile and install a cmake project through external > project > > > > How can I make sure that the external project is built before something > that depends on that external project? > > -- > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dflogeras2 at gmail.com Sat Dec 19 12:48:49 2015 From: dflogeras2 at gmail.com (Dave Flogeras) Date: Sat, 19 Dec 2015 13:48:49 -0400 Subject: [CMake] Tests with assert and Release build type In-Reply-To: <87egejhndt.fsf@sobel.cipherstone.com> References: <87egejhndt.fsf@sobel.cipherstone.com> Message-ID: On Fri, Dec 18, 2015 at 9:55 AM, Magnus Therning wrote: > > I'm sure I'm not the first one to run into the conflict between a desire > to test the code shipped to customers and the desire to at the same time > define NDEBUG to make sure tests don't have their `assert` turned into > NOOPs. > > Is there some nice way of handling this? I've also wondered this. My solution of choice has always been to keep my tests in a subdirectory with a test header like you described: .... #fidef NDEBUG #undef NDEBUG #include // or assert.h for C #define NDEBUG #else #include #endif .... And include this in each of the unit tests. However, I have found sometimes this is not foolproof. In particular I recall on one version of OSX one of the system headers would undo this and make assert() disappear again, requiring me to play the #include shell game. I usually place my "test_assert.hpp" include after all others in the unit test, but this is brittle. I have always just left it as a "good enough" solution, but I too would love to hear if someone has a more robust solution. From dflogeras2 at gmail.com Sat Dec 19 13:27:10 2015 From: dflogeras2 at gmail.com (Dave Flogeras) Date: Sat, 19 Dec 2015 14:27:10 -0400 Subject: [CMake] CMake, QT5 and cross compilation In-Reply-To: <5672EACA.9010406@ind.rwth-aachen.de> References: <5672EACA.9010406@ind.rwth-aachen.de> Message-ID: On Thu, Dec 17, > > So, here is my question: How can I overwrite the moc-executable (and uic > etc) path to use another moc version than the one found by the > find_package mechanism? If I use the moc which is part of my Linux host > PC rather than the arm compiled moc in the Raspberry file system, the > code generation should be fine, and afterwards, I will link against the > Raspberry Pi Qt5 libraries. > Hi Hauke, In the past, I have done this (wth Qt4) by generating, then hand editing the CMakeCache.txt to change the location of the moc executable to the native one. Now that reading your post made me re-visit this it seems to have two problems. First, with Qt5 finder, it doesn't seem to expose the moc location in the cache. Also I recall doing it the way I described works only if your native version is exactly the same as the arm version, otherwise you get errors like "this header was generated with a different version of Qt".... It always seemed pretty brittle. Another way that I do this, is by generating a toolchain file, which forces cmake to look only inside the RPi root directory. This means it will find the cross compiled moc executable. Then I have qemu set up with the Linux binfmt driver so that I can execute arm binaries 'natively'.. This is not trivial, and requires setting up a wrapper so that qemu can find the arm linker-loader etc. but you may be able to use this as a solution. I (loosely) followed this guide, modifying the wrapper to my system. https://gentoo-handbook.lugons.org/proj/en/base/embedded/handbook/index.xml?style=printable&part=1&chap=5 Good luck. I'd also like to hear if there is a different solution to this problem. From magnus at therning.org Sat Dec 19 13:31:24 2015 From: magnus at therning.org (Magnus Therning) Date: Sat, 19 Dec 2015 19:31:24 +0100 Subject: [CMake] Tests with assert and Release build type In-Reply-To: <5674BBC3.7020905@yahoo.com> References: <87egejhndt.fsf@sobel.cipherstone.com> <5674BBC3.7020905@yahoo.com> Message-ID: <87poy2cmtf.fsf@therning.org> Ruslan Baratov writes: > How about using RelWithDebInfo? See: > http://stackoverflow.com/a/28124715/2288008 Hmm, I'm probably missing something but how does that solve the issue with some targets requiring NDEBUG to be *undefined* and other targets requiring NDEBUG to be defined? /M > On 18-Dec-15 20:55, Magnus Therning wrote: >> I'm sure I'm not the first one to run into the conflict between a desire >> to test the code shipped to customers and the desire to at the same time >> define NDEBUG to make sure tests don't have their `assert` turned into >> NOOPs. >> >> Is there some nice way of handling this? >> >> I can always remove -DNDEBUG from the CFLAGS for tests (possibly by >> defining a new macro, `ADD_EXECUTABLE_TEST()` or something). Another >> option is to `#undef NDEBUG` in the source of tests. >> >> If there's some more or less standard way to address this I'd like to >> use that. >> >> /M >> >> -- >> Magnus Therning OpenPGP: 0x927912051716CE39 >> email: magnus at therning.org jabber: magnus at therning.org >> twitter: magthe http://therning.org/magnus >> >> There's a big difference between making something easy to use and >> making it productive. >> -- Adam Bosworth >> >> -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus C++ is history repeated as tragedy. Java is history repeated as farce. -- Scott McKay -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From magnus at therning.org Sat Dec 19 13:59:01 2015 From: magnus at therning.org (Magnus Therning) Date: Sat, 19 Dec 2015 19:59:01 +0100 Subject: [CMake] Tests with assert and Release build type In-Reply-To: References: <87egejhndt.fsf@sobel.cipherstone.com> Message-ID: <87oadmclje.fsf@therning.org> Dave Flogeras writes: > On Fri, Dec 18, 2015 at 9:55 AM, Magnus Therning wrote: >> >> I'm sure I'm not the first one to run into the conflict between a >> desire to test the code shipped to customers and the desire to at the >> same time define NDEBUG to make sure tests don't have their `assert` >> turned into NOOPs. >> >> Is there some nice way of handling this? > > I've also wondered this. My solution of choice has always been to keep > my tests in a subdirectory with a test header like you described: > > .... > #fidef NDEBUG > #undef NDEBUG > #include // or assert.h for C > #define NDEBUG > #else > #include > #endif > .... > > And include this in each of the unit tests. However, I have found > sometimes this is not foolproof. In particular I recall on one version > of OSX one of the system headers would undo this and make assert() > disappear again, requiring me to play the #include shell game. I > usually place my "test_assert.hpp" include after all others in the > unit test, but this is brittle. > > I have always just left it as a "good enough" solution, but I too > would love to hear if someone has a more robust solution. I did a bit of testing and found that 1. CMAKE_C_FLAGS_* is, very irritatingly, *not* a list, so it's not easy to remove '-DNDEBUG' from them in the CMakeLists.txt for the tests. 2. Compile options added by target_compile_options() are added *after* CMAKE_C_FLAGS_* so I settled on using it to pass -UNDEBUG to gcc. Far from nice, but it works for now (which feels quite typical for CMake). /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus If you can explain how you do something, then you're very very bad at it. -- John Hopfield -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From krueger at ind.rwth-aachen.de Sun Dec 20 05:06:23 2015 From: krueger at ind.rwth-aachen.de (=?UTF-8?Q?Hauke_Kr=c3=bcger?=) Date: Sun, 20 Dec 2015 11:06:23 +0100 Subject: [CMake] CMake, QT5 and cross compilation In-Reply-To: References: <5672EACA.9010406@ind.rwth-aachen.de> Message-ID: <56767D9F.8080501@ind.rwth-aachen.de> Hi Dave, hi Jakob, thank you for the responses to my question. I finally found "my" solution: It seems that the creators of the cmake Qt5 toolchain have created some undocumented hooks: In Qt5CoreConfigExtras, the moc is specified as an imported target: >> if (NOT TARGET Qt5::moc) >> add_executable(Qt5::moc IMPORTED) >> set(imported_location "${_qt5Core_install_prefix}/bin/moc.exe") >> _qt5_Core_check_file_exists(${imported_location}) >> set_target_properties(Qt5::moc PROPERTIES >> IMPORTED_LOCATION ${imported_location} >> ) >> # For CMake automoc feature >> get_target_property(QT_MOC_EXECUTABLE Qt5::moc LOCATION) >> endif() The if-statement can be used to install another Qt5::moc imported target if desired: In my cmake file, I use >> add_executable(Qt5::moc IMPORTED) >> set(imported_location "/path/tp/moc") >> set_target_properties(Qt5::moc PROPERTIES >> IMPORTED_LOCATION ${imported_location} >> ) >> # For CMake automoc feature >> get_target_property(QT_MOC_EXECUTABLE Qt5::moc LOCATION) to point to another moc location RIGHT before the Qt5 find_package calls. The same works for uic and rcc. Dave, you are right, I may run into a version conflict. I think there is no other solution than making sure that I use the same version of qt in both systems, host and target. And I am not yet sure if I will run into linker problems later, in particular with the rcc, since I am stuck now at another point regarding my crosstool chain. Plan B will be to follow your QEMU hints if I encounter additional problems. I though about this but this does not really feel to me as what I understand as a "cross-compile". Thank you and best regards Hauke Am 19.12.2015 um 19:27 schrieb Dave Flogeras: > On Thu, Dec 17, >> So, here is my question: How can I overwrite the moc-executable (and uic >> etc) path to use another moc version than the one found by the >> find_package mechanism? If I use the moc which is part of my Linux host >> PC rather than the arm compiled moc in the Raspberry file system, the >> code generation should be fine, and afterwards, I will link against the >> Raspberry Pi Qt5 libraries. >> > Hi Hauke, > > In the past, I have done this (wth Qt4) by generating, then hand > editing the CMakeCache.txt to change the location of the moc > executable to the native one. Now that reading your post made me > re-visit this it seems to have two problems. First, with Qt5 finder, > it doesn't seem to expose the moc location in the cache. Also I > recall doing it the way I described works only if your native version > is exactly the same as the arm version, otherwise you get errors like > "this header was generated with a different version of Qt".... It > always seemed pretty brittle. > > Another way that I do this, is by generating a toolchain file, which > forces cmake to look only inside the RPi root directory. This means > it will find the cross compiled moc executable. Then I have qemu set > up with the Linux binfmt driver so that I can execute arm binaries > 'natively'.. This is not trivial, and requires setting up a wrapper > so that qemu can find the arm linker-loader etc. but you may be able > to use this as a solution. I (loosely) followed this guide, modifying > the wrapper to my system. > > https://gentoo-handbook.lugons.org/proj/en/base/embedded/handbook/index.xml?style=printable&part=1&chap=5 > > Good luck. > > I'd also like to hear if there is a different solution to this problem. From csiga.biga at aol.com Sun Dec 20 12:24:10 2015 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Sun, 20 Dec 2015 18:24:10 +0100 Subject: [CMake] Are the poor reviews of Mastering CMake Justified? In-Reply-To: <56747477.4050400@arqux.com> References: <56747477.4050400@arqux.com> Message-ID: Hi DJ, I had the same feeling when I started out with CMake. Tutorials are generally of low quality, and the price of the book is steep. I asked a while back if there would be a digital version of it, that could come cheaper due to the lack of paper and distribution hassle, but Kitware said there is no intent on having a digital copy. CMake however is a fine piece of software (not the best, but it gets the job done with a tolerable amount of frustration), and once you have it mastered, you can get serious *hit done in a matter of minutes. Even without cross-platform, dependency finding is alone worth it, not to mention unit tests built in. As for learning, I would highly suggest reading CMake scripts of other projects, as there are some very nice scripts. SFML?s scripts are easy to read (though get complicated towards the end), and also some FindModule.cmake scripts (FindOpenCL.cmake that ships with CMake starting from version 3.0 is nice) are useful. After reading some scripts, cooking up some of your own isn?t hard. Cheers, M?t? Felad?: DJ Elk?ldve: 2015. december 18., p?ntek 22:03 C?mzett: cmake at cmake.org T?rgy: [CMake] Are the poor reviews of Mastering CMake Justified? I have only very recently encountered the need to use cmake. It seems this need came all at once out of the blue. It appears to me that there is a general perception that good tutorial material is in short supply. I have followed various tutorials that are available online and find them less than stellar. I am mostly familiar with gnu toolchain stuff. I admit that I am biased here because my own work presents zero requirement for cross-platform builds. So far I find cmake documentation to be considerably inferior to gnu documentation, but that's just me. This all led me to consider purchasing the book Mastering CMake. However, reviews on Amazon are generally very critical of the book. It is indeed expensive. Should I bother to shell out for it, or do others here share this negative evaluation of it? I don't want to waste my money. Best, - Jake - -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwan.work at gmail.com Mon Dec 21 03:38:41 2015 From: rwan.work at gmail.com (Raymond Wan) Date: Mon, 21 Dec 2015 16:38:41 +0800 Subject: [CMake] Are the poor reviews of Mastering CMake Justified? In-Reply-To: <56747477.4050400@arqux.com> References: <56747477.4050400@arqux.com> Message-ID: Hi Jake, On Sat, Dec 19, 2015 at 5:02 AM, DJ wrote: > This all led me to consider purchasing the book Mastering CMake. However, > reviews on Amazon are generally very critical of the book. It is indeed > expensive. Should I bother to shell out for it, or do others here share this > negative evaluation of it? I don't want to waste my money. I've purchased the book (the older edition) and it is fine. I mean, I'm a bit old-school and do prefer a printed book. Online docs seem more of an excuse to easily swap between reading and a distraction (i.e. Facebook) -- but that's just me. Indeed, it is similar to the online manuals. And those will get updated with each subsequent version; a book will not (e-book or on paper). I had a hard time getting into CMake and the book isn't written like a tutorial. I mean, it explains the first few steps and then jumps to a reference book (I don't have it with me, but this is from memory). I guess there is value in having a CMake book that is entirely a tutorial or even one of "recipes" -- Mastering CMake (as far as I can remember) isn't that. For that, you'd probably have to use the Web... Ray PS: I don't regret buying the book. At the time, I was really stuck and overwhelmed by the online documentation. Having it printed made it a bit easier for me. Each person learns differently, but skimming over the Amazon comments, they seem accurate. Of course, buy the latest edition if you end up buying. From cedric.doucet at inria.fr Mon Dec 21 07:12:08 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Mon, 21 Dec 2015 13:12:08 +0100 (CET) Subject: [CMake] How to pass a configuration file to CMake? In-Reply-To: <1703394343.4113760.1450699712465.JavaMail.zimbra@inria.fr> Message-ID: <653657175.4114402.1450699928888.JavaMail.zimbra@inria.fr> Hello, I would like to know if it's possible to pass a configuration file to CMake. I have to pass a lot of information to CMake and the resulting command line is very long to type. Would it be possible to create a file containing all needed definitions and pass it to CMake? For exemple, instead of typing cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++ would it be possible to create a file containing CMAKE_BUILD_TYPE=Debug CMAKE_INSTALL_PREFIX=/home/me/there CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++ and pass it to CMake? C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Mon Dec 21 07:25:53 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 21 Dec 2015 13:25:53 +0100 Subject: [CMake] How to pass a configuration file to CMake? In-Reply-To: <653657175.4114402.1450699928888.JavaMail.zimbra@inria.fr> References: <1703394343.4113760.1450699712465.JavaMail.zimbra@inria.fr> <653657175.4114402.1450699928888.JavaMail.zimbra@inria.fr> Message-ID: Hi Cedric. I have never used it myself, but I believe you're looking for CMake's command-line option '-C ': https://cmake.org/cmake/help/latest/manual/cmake.1.html Petr On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet wrote: > > Hello, > > I would like to know if it's possible to pass a configuration file to > CMake. > I have to pass a lot of information to CMake and the resulting command > line is very long to type. > Would it be possible to create a file containing all needed definitions > and pass it to CMake? > > For exemple, instead of typing > > cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D > CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++ > > would it be possible to create a file containing > > CMAKE_BUILD_TYPE=Debug > CMAKE_INSTALL_PREFIX=/home/me/there > CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++ > > and pass it to CMake? > > C?dric > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.doucet at inria.fr Mon Dec 21 07:29:05 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Mon, 21 Dec 2015 13:29:05 +0100 (CET) Subject: [CMake] How to pass a configuration file to CMake? In-Reply-To: References: <1703394343.4113760.1450699712465.JavaMail.zimbra@inria.fr> <653657175.4114402.1450699928888.JavaMail.zimbra@inria.fr> Message-ID: <726390889.4117381.1450700945898.JavaMail.zimbra@inria.fr> Hi Peter! Thank you very much! It seems to be exactly what I want. :) I will try to use it. C?dric ----- Mail original ----- > De: "Petr Kmoch" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Lundi 21 D?cembre 2015 13:25:53 > Objet: Re: [CMake] How to pass a configuration file to CMake? > Hi Cedric. > I have never used it myself, but I believe you're looking for CMake's > command-line option '-C ': > https://cmake.org/cmake/help/latest/manual/cmake.1.html > Petr > On Mon, Dec 21, 2015 at 1:12 PM, Cedric Doucet < cedric.doucet at inria.fr > > wrote: > > Hello, > > > I would like to know if it's possible to pass a configuration file to > > CMake. > > > I have to pass a lot of information to CMake and the resulting command line > > is very long to type. > > > Would it be possible to create a file containing all needed definitions and > > pass it to CMake? > > > For exemple, instead of typing > > > cmake -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX=/home/me/there -D > > CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++ > > > would it be possible to create a file containing > > > CMAKE_BUILD_TYPE=Debug > > > CMAKE_INSTALL_PREFIX=/home/me/there > > > CMAKE_CXX_COMPILER=/usr/local/gcc/4.9.3/g++ > > > and pass it to CMake? > > > C?dric > > > -- > > > Powered by www.kitware.com > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > CMake Support: http://cmake.org/cmake/help/support.html > > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > Follow this link to subscribe/unsubscribe: > > > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Mon Dec 21 09:18:57 2015 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 21 Dec 2015 08:18:57 -0600 Subject: [CMake] CMake with VS 2015 using Android? Message-ID: Is it possible for CMake 3.4 to generate VS2015 projects targeting their new Android functionality? Is this just a matter of configuring the toolset (-T)? Or is there more to it? From layus.on at gmail.com Mon Dec 21 10:11:53 2015 From: layus.on at gmail.com (Guillaume Maudoux (Layus)) Date: Mon, 21 Dec 2015 16:11:53 +0100 Subject: [CMake] Generate sources (smartly :-)) In-Reply-To: <5674642F.4060107@gmail.com> References: <56716724.70907@gmail.com> <5674642F.4060107@gmail.com> Message-ID: <567816B9.2070607@gmail.com> Hi, I am generating files with some executable called "generator" built with cmake. Apparently I am unable to avoid the generator being built even when the generated files are up to date. IIRC, EXCLUDE_FROM_ALL should do just that: avoid a target being build if not strictly needed. I have reproduced the issue in a small project : $ tree . ??? build/... ??? CMakeLists.txt ??? generator ? ??? CMakeLists.txt ? ??? generator.cc ??? step1 ??? CMakeLists.txt $ tail -n +0 **/* ==> CMakeLists.txt <== cmake_minimum_required(VERSION 3.4) add_subdirectory(generator EXCLUDE_FROM_ALL) add_subdirectory(step1) ==> generator/CMakeLists.txt <== add_executable(generator EXCLUDE_FROM_ALL generator.cc) ==> generator/generator.cc <== #include #include using namespace std; int main(int argc, char** argv) { ofstream myfile; myfile.open (argv[1]); myfile << "Writing this to a file." << endl; myfile << argv[2] << endl; myfile.close(); return 0; } ==> step1/CMakeLists.txt <== add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/task1.txt COMMAND ${CMAKE_CURRENT_BINARY_DIR}/../generator/generator ${CMAKE_CURRENT_BINARY_DIR}/task1.txt none WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} DEPENDS generator VERBATIM) add_custom_target(task1 ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/task1.txt VERBATIM) $ cd build $ cmake .. $ touch step1/task1.txt # Simulate import of generated files. $ make [ !!! still builds generator, but it is not needed as task1.txt is up to date ] I am really annoyed by this issue, as it defeats the advantage of caching generated files. Is there something I am missing in my usage of EXCLUDE_FROM_ALL ? Thx, Guillaume. Le 18/12/15 20:53, Layus a ?crit : > On 16/12/15 17:53, Mark Stijnman wrote: >> On Wed, Dec 16, 2015 at 2:29 PM, Layus > > wrote: >> >> Hi, >> >> I am looking for a way to share an archive of a partially >> compiled project to speedup compilation time and configuration >> hassle for the users. >> >> I have a project that works in two steps. >> First a source generator is built (based on clang) and generates >> some extra source files based on the existing source files. >> Then the normal compilation process takes places, building the >> application from both original and generated sources. >> >> >> >> >> Now, is it possible to distribute a source archive with the >> generated sources, in such a way that any user unpacking the >> archive and running cmake would not have to generate the extra >> sources ? >> >> This would be useful because >> i) the project is tricky to configure and >> ii) the generated sources are not dependent on the user config, >> so building the generator is just useless computation time on the >> user. >> >> The ideal scheme would be something like >> >> [developper] >> $ cmake -DCLANG=config >> $ make generate >> $ make package_source >> >> [user] >> $ unpack >> $ cmake -DUSER=config >> $ make # builds only the application, reusing the shipped >> generated sources. >> $ make install >> >> ... but when the user runs cmake, he overwrites the generated >> Makefiles and the extra sources are generated again. >> >> Any idea ? >> >> layus. >> >> -- >> >> >> I'd probably just make it such that the CMake script automatically >> detects the presence of the generated files, and if they don't exist, >> generate them. For example: >> 1. Set a variable GENERATED_FOLDER to >> ${CMAKE_CURRENT_SOURCE_DIR}/generated >> 2. If ${GENERATED_FOLDER} doesn't exist, set it to >> ${CMAKE_CURRENT_BINARY_DIR}/generated instead, and set up the targets >> that will generate the files in that folder. >> 3. Simply use the ${GENERATED_FOLDER} variable to add the generated >> files to your application. >> 4. Set up the package_source target so that it packages the files >> from ${GENERATED_FOLDER} to a folder called "generated" (such that if >> a user unpacks from there, they will end up in >> ${CMAKE_CURRENT_SOURCE_DIR}/generated), and you're done. >> 5. Recommended: add a check for the existence of target "generate", >> and if so, set it as a dependency for your application and >> package_source. >> >> This way, you don't need to remember what switches to use, or when to >> use "make generate". If you need to make it possible for a user to >> force generation, you can alter step 2 to also run when a command >> line option is supplied. >> >> Hope that helps, >> >> Best regards Mark > > Works like a charm. > > (See https://github.com/layus/mozart2/tree/cache_generated_code) > > Thanks ! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.marr at autodesk.com Mon Dec 21 11:32:59 2015 From: greg.marr at autodesk.com (Greg Marr) Date: Mon, 21 Dec 2015 16:32:59 +0000 Subject: [CMake] CMake with VS 2015 using Android? In-Reply-To: References: Message-ID: Is it possible for CMake 3.4 to generate VS2015 projects targeting their new Android functionality? Is this just a matter of configuring the toolset (-T)? Or is there more to it? No, but Microsoft has added this functionality to their own fork, and is working to contribute it back to CMake. http://blogs.msdn.com/b/vcblog/archive/2015/12/15/support-for-android-cmake-projects-in-visual-studio.aspx From tamas.kenez at gmail.com Mon Dec 21 12:17:42 2015 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Mon, 21 Dec 2015 18:17:42 +0100 Subject: [CMake] Are the poor reviews of Mastering CMake Justified? In-Reply-To: <56747477.4050400@arqux.com> References: <56747477.4050400@arqux.com> Message-ID: Jake, I've read the older edition. Yes, I also think it could be written better and most of the information is available online. Still, it provided me with authorative information, concentrated into a single book, (as opposed to be scattered over the internet). It really helped me to lay down the foundations of my CMake knowledge. Tamas On Friday, December 18, 2015, DJ wrote: > I have only very recently encountered the need to use cmake. It seems this > need came all at once out of the blue. > > It appears to me that there is a general perception that good tutorial > material is in short supply. I have followed various tutorials that are > available online and find them less than stellar. I am mostly familiar with > gnu toolchain stuff. I admit that I am biased here because my own work > presents zero requirement for cross-platform builds. So far I find cmake > documentation to be considerably inferior to gnu documentation, but that's > just me. > > This all led me to consider purchasing the book Mastering CMake. However, > reviews on Amazon are generally very critical of the book. It is indeed > expensive. Should I bother to shell out for it, or do others here share > this negative evaluation of it? I don't want to waste my money. > > Best, > > - Jake - > > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boud at valdyas.org Mon Dec 21 13:26:55 2015 From: boud at valdyas.org (Boudewijn Rempt) Date: Mon, 21 Dec 2015 19:26:55 +0100 (CET) Subject: [CMake] still having rpath problems on osx Message-ID: I'm still having rpath problems when creating libraries on OSX... And I'm not sure what's going on here. Here's the output for a single library: otool -L ../i/lib/libkritaimage.dylib ../i/lib/libkritaimage.dylib: /Users/boud/dev/i/lib/libkritaimage.15.dylib (compatibility version 15.0.0, current version 15.0.0) /Users/boud/dev/i/lib/libkritawidgets.15.dylib (compatibility version 15.0.0, current version 15.0.0) /Users/boud/dev/i/lib/libkritapsd.15.dylib (compatibility version 15.0.0, current version 15.0.0) libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libImath.12.dylib (compatibility version 12.0.0, current version 12.0.0) @rpath/libIlmImf.22.dylib (compatibility version 22.0.0, current version 22.0.0) @rpath/libIex.12.dylib (compatibility version 12.0.0, current version 12.0.0) @rpath/libHalf.12.dylib (compatibility version 12.0.0, current version 12.0.0) @rpath/libIlmThread.12.dylib (compatibility version 12.0.0, current version 12.0.0) /Users/boud/dev/i/lib/libfftw3.3.dylib (compatibility version 8.0.0, current version 8.4.0) @rpath/libgsl.dylib (compatibility version 0.0.0, current version 0.0.0) /Users/boud/dev/i/lib/libkritaflake.15.dylib (compatibility version 15.0.0, current version 15.0.0) /Users/boud/dev/i/lib/libkritaodf.15.dylib (compatibility version 15.0.0, current version 15.0.0) /Users/boud/dev/i/lib/libkritaversion.15.dylib (compatibility version 15.0.0, current version 15.0.0) /Users/boud/dev/i/lib/libkritastore.15.dylib (compatibility version 15.0.0, current version 15.0.0) /Users/boud/dev/i/lib/libKF5Archive.5.dylib (compatibility version 5.0.0, current version 5.17.0) /Users/boud/dev/i/lib/libkritaundo2.15.dylib (compatibility version 15.0.0, current version 15.0.0) /Users/boud/dev/i/lib/libkritawidgetutils.15.dylib (compatibility version 15.0.0, current version 15.0.0) /Users/boud/dev/i/lib/libKF5ItemViews.5.dylib (compatibility version 5.0.0, current version 5.17.0) @rpath/QtPrintSupport.framework/Versions/5/QtPrintSupport (compatibility version 5.6.0, current version 5.6.0) /Users/boud/dev/i/lib/libKF5GuiAddons.5.dylib (compatibility version 5.0.0, current version 5.17.0) /Users/boud/dev/i/lib/libKF5Completion.5.dylib (compatibility version 5.0.0, current version 5.17.0) /Users/boud/dev/i/lib/libKF5ConfigGui.5.dylib (compatibility version 5.0.0, current version 5.17.0) /Users/boud/dev/i/lib/libKF5WidgetsAddons.5.dylib (compatibility version 5.0.0, current version 5.17.0) /Users/boud/dev/i/lib/libkritaglobal.15.dylib (compatibility version 15.0.0, current version 15.0.0) @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (compatibility version 5.6.0, current version 5.6.0) @rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.6.0, current version 5.6.0) /Users/boud/dev/i/lib/libkritapigment.15.dylib (compatibility version 15.0.0, current version 15.0.0) @rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.6.0, current version 5.6.0) @rpath/QtXml.framework/Versions/5/QtXml (compatibility version 5.6.0, current version 5.6.0) /Users/boud/dev/i/lib/libkritaplugin.15.dylib (compatibility version 15.0.0, current version 15.0.0) /Users/boud/dev/i/lib/libKF5CoreAddons.5.dylib (compatibility version 5.0.0, current version 5.17.0) /Users/boud/dev/i/lib/libKF5ConfigCore.5.dylib (compatibility version 5.0.0, current version 5.17.0) /Users/boud/dev/i/lib/libKF5I18n.5.dylib (compatibility version 5.0.0, current version 5.17.0) @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1) All libraries I link to are built. Some come with a cmake build system, some with an automake build system, boost with something else altogether... But I wouldn't have expected the way a library is built to make a difference for the link lines in the library that links to the other library. Obviously, libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0) is wrong -- it's got neither an @rpath, nor a full path. I'm not sure even why some libraries are linked to with @rpath and others with a full path after running a make install, but I cannot figure out why libboost_system doesn't have anything. libkritaimage is build with these settings: * CMake is version 3.4.0 * Policy CMP0042 is set to NEW * in the toplevel cmakelists.txt, there's if (APPLE) set(CMAKE_MACOSX_RPATH ON) SET(CMAKE_SKIP_BUILD_RPATH TRUE) SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) endif () I'm feeling dense, but I just cannot make out the documentation for these variables... CMAKE_INSTALL_RPATH_USE_LINK_PATH sounds like it should change the rpath on doing making install, but apparently that doesn't happen. * And for the library itself, I explicitly set: if (APPLE) set_target_properties(kritaimage PROPERTIES INSTALL_RPATH "@loader_path/../../../../lib;@loader_path/../lib;@loader_path/../Frameworks;@executable_path/../lib;@executable_path/../Frameworks") endif() Though I sort of feel that it shouldn't be necessary to explicitly set an rpath to something I build. But it results in: otool -l libkritaimage.dylib Load command 48 cmd LC_RPATH cmdsize 48 path @loader_path/../../../../lib (offset 12) Load command 49 cmd LC_RPATH cmdsize 32 path @loader_path/../lib (offset 12) Load command 50 cmd LC_RPATH cmdsize 40 path @loader_path/../Frameworks (offset 12) Load command 51 cmd LC_RPATH cmdsize 40 path @executable_path/../lib (offset 12) Load command 52 cmd LC_RPATH cmdsize 48 path @executable_path/../Frameworks (offset 12) and since everything gets installed to lib, the secodn LC_RPATH points to the place where the library is really installed. So I have to manually do install_name_tool -change /Users/boud/dev/i/lib/libboost_system.dylib @rpath/libboost_system.dylib libkritaimage.dylib to make the libkritaimage finr libboost_system -- and that just cannot be right... -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org From ruslan_baratov at yahoo.com Mon Dec 21 14:03:21 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 22 Dec 2015 02:03:21 +0700 Subject: [CMake] Tests with assert and Release build type In-Reply-To: <87poy2cmtf.fsf@therning.org> References: <87egejhndt.fsf@sobel.cipherstone.com> <5674BBC3.7020905@yahoo.com> <87poy2cmtf.fsf@therning.org> Message-ID: <56784CF9.3030507@yahoo.com> On 20-Dec-15 01:31, Magnus Therning wrote: > Ruslan Baratov writes: > >> How about using RelWithDebInfo? See: >> http://stackoverflow.com/a/28124715/2288008 > Hmm, I'm probably missing something but how does that solve the issue > with some targets requiring NDEBUG to be *undefined* and other targets > requiring NDEBUG to be defined? I don't think that building targets with different NDEBUG values is a good idea. More correct approach will be to introduce custom macro to allow checks (i.e. FOO_NDEBUG/FOO_DEBUG). > > /M > >> On 18-Dec-15 20:55, Magnus Therning wrote: >>> I'm sure I'm not the first one to run into the conflict between a desire >>> to test the code shipped to customers and the desire to at the same time >>> define NDEBUG to make sure tests don't have their `assert` turned into >>> NOOPs. >>> >>> Is there some nice way of handling this? >>> >>> I can always remove -DNDEBUG from the CFLAGS for tests (possibly by >>> defining a new macro, `ADD_EXECUTABLE_TEST()` or something). Another >>> option is to `#undef NDEBUG` in the source of tests. >>> >>> If there's some more or less standard way to address this I'd like to >>> use that. >>> >>> /M >>> >>> -- >>> Magnus Therning OpenPGP: 0x927912051716CE39 >>> email: magnus at therning.org jabber: magnus at therning.org >>> twitter: magthe http://therning.org/magnus >>> >>> There's a big difference between making something easy to use and >>> making it productive. >>> -- Adam Bosworth >>> >>> > > -- > Magnus Therning OpenPGP: 0x927912051716CE39 > email: magnus at therning.org jabber: magnus at therning.org > twitter: magthe http://therning.org/magnus > > C++ is history repeated as tragedy. Java is history repeated as farce. > -- Scott McKay From magnus at therning.org Mon Dec 21 16:07:59 2015 From: magnus at therning.org (Magnus Therning) Date: Mon, 21 Dec 2015 22:07:59 +0100 Subject: [CMake] Tests with assert and Release build type In-Reply-To: <56784CF9.3030507@yahoo.com> References: <87egejhndt.fsf@sobel.cipherstone.com> <5674BBC3.7020905@yahoo.com> <87poy2cmtf.fsf@therning.org> <56784CF9.3030507@yahoo.com> Message-ID: <87wps7zf0w.fsf@therning.org> Ruslan Baratov writes: > On 20-Dec-15 01:31, Magnus Therning wrote: >> Ruslan Baratov writes: >> >>> How about using RelWithDebInfo? See: >>> http://stackoverflow.com/a/28124715/2288008 >> Hmm, I'm probably missing something but how does that solve the issue >> with some targets requiring NDEBUG to be *undefined* and other targets >> requiring NDEBUG to be defined? > I don't think that building targets with different NDEBUG values is a > good idea. More correct approach will be to introduce custom macro to > allow checks (i.e. FOO_NDEBUG/FOO_DEBUG). Why not? /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about. -- Albert Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From jakep at arqux.com Mon Dec 21 17:11:12 2015 From: jakep at arqux.com (DJ) Date: Mon, 21 Dec 2015 17:11:12 -0500 Subject: [CMake] Are the poor reviews of Mastering CMake Justified? In-Reply-To: <56747477.4050400@arqux.com> References: <56747477.4050400@arqux.com> Message-ID: <56787900.1060801@arqux.com> Thanks for the feedback everyone. I think I may be stuck having to learn cmake because several software libraries that I am starting to use build with cmake. Based on the feedback, for no I'll pass on the book and see what I can do by reading online. One of the things that seems to me to be missing is some kind of quick description of the overall "theory of cmake". I am a top-down kind of person, so I really dislike being left with nothing but "here, type this in" which is what a lot of the web stuff seems to be. A sketch of how it works conceptually would help me. (Of course, I need examples too.) Just sayin'. Best, - Jake - On 15-12-18 04:02 PM, DJ wrote: > I have only very recently encountered the need to use cmake. It seems > this need came all at once out of the blue. > > It appears to me that there is a general perception that good tutorial > material is in short supply. I have followed various tutorials that > are available online and find them less than stellar. I am mostly > familiar with gnu toolchain stuff. I admit that I am biased here > because my own work presents zero requirement for cross-platform > builds. So far I find cmake documentation to be considerably inferior > to gnu documentation, but that's just me. > > This all led me to consider purchasing the book Mastering CMake. > However, reviews on Amazon are generally very critical of the book. It > is indeed expensive. Should I bother to shell out for it, or do others > here share this negative evaluation of it? I don't want to waste my > money. > > Best, > > - Jake - > > From pgquiles at elpauer.org Mon Dec 21 17:51:18 2015 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Mon, 21 Dec 2015 23:51:18 +0100 Subject: [CMake] Are the poor reviews of Mastering CMake Justified? In-Reply-To: <56787900.1060801@arqux.com> References: <56747477.4050400@arqux.com> <56787900.1060801@arqux.com> Message-ID: On Mon, Dec 21, 2015 at 11:11 PM, DJ wrote: > > One of the things that seems to me to be missing is some kind of quick > description of the overall "theory of cmake". I am a top-down kind of > person, so I really dislike being left with nothing but "here, type this > in" which is what a lot of the web stuff seems to be. A sketch of how it > works conceptually would help me. (Of course, I need examples too.) > > It's old but it still gets a few hundreds downloads a month: http://www.elpauer.org/stuff/learning_cmake.pdf -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.r.stephens at gmail.com Mon Dec 21 18:01:52 2015 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Mon, 21 Dec 2015 23:01:52 +0000 Subject: [CMake] Are the poor reviews of Mastering CMake Justified? In-Reply-To: <56787900.1060801@arqux.com> References: <56747477.4050400@arqux.com> <56787900.1060801@arqux.com> Message-ID: On Mon, Dec 21, 2015 at 10:11 PM, DJ wrote: > One of the things that seems to me to be missing is some kind of quick > description of the overall "theory of cmake". I am a top-down kind of > person, so I really dislike being left with nothing but "here, type this > in" which is what a lot of the web stuff seems to be. A sketch of how it > works conceptually would help me. (Of course, I need examples too.) > There's the manages. Specifically cmake-buildsystem(7) and cmake-language(7) (and the others, though those are more reference lists of details). -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.wueger at gmx.at Tue Dec 22 01:56:39 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 22 Dec 2015 07:56:39 +0100 Subject: [CMake] CPack and PackageMaker In-Reply-To: <000f4242.47dd4f8b0abb6704@dirac.se> References: <000f4242.47dd4f8b0abb6704@dirac.se> Message-ID: <9A894BB6-8BC9-4092-8052-B83C022EB97D@gmx.at> Is there anything I can do to support? Best regards > Am 11.12.2015 um 20:17 schrieb robert.bielik : > > Dear Clint, > > Thank you! Will certainly start with that as a base :) > > Regards > /R > > ------ Ursprungligt meddelande------ > Fr?n: > Datum: fre, 11 dec 2015 20:12 > Till: Robert Bielik; > Kopia: Attila Krasznahorkay;cmake; > ?mne:Re: [CMake] CPack and PackageMaker > > If you are interested, attached is some code I started a couple years ago but never finished, nor did I do much testing. > Perhaps that'll help, or maybe you'll find a better way. > > Clint > > ----- On Dec 11, 2015, at 9:50 AM, Robert Bielik robert.bielik at dirac.se wrote: > > > Dear Attila, > > > > Ok, been struggling getting an installation package to work with the > > pkgbuild/productbild tools, so I think I got the gist of what needs to > > be done, at least to get something going :) > > > > Regards > > /R > > > > Den 2015-12-11 kl. 17:47, skrev Attila Krasznahorkay: > >> Hi Robert, > >> > >> I'm afraid that the sad situation is that nobody has done this yet, or is > >> working on it at the moment. > >> > >> I'm absolutely sure that if you can help with this by any amount, that will be > >> most welcome by the CMake developers. It will certainly be most welcome by me, > >> as I've been disappointed by the lack of this support as well. (But > >> unfortunately can't spare the time to help out in writing this CPack > >> generator.) > >> > >> Cheers, > >> Attila > >> > >>> On 11 Dec 2015, at 17:44, Robert Bielik wrote: > >>> > >>> Really ? No one ? :) > >>> > >>> So it's ok to go ahead and start create a new one ? ;) > >>> > >>> Rgds, > >>> /R > >>> > >>> Den 2015-12-09 kl. 16:56, skrev Robert Bielik: > >>>> Mac OSX: > >>>> > >>>> Since PackageMaker has been deprecated by Apple, the new tools to use are > >>>> pkgbuild [1] and productbuild [2]. > >>>> > >>>> Simple question: Is there any work being done by the CMake community on a new OS > >>>> X CPack backend to support the above tools ? > >>>> > >>>> Regards > >>>> /Robert > >>>> [1] > >>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/pkgbuild.1.html > >>>> [2] > >>>> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/productbuild.1.html > >>>> > >>> -- > >>> > >>> Powered by www.kitware.com > >>> > >>> Please keep messages on-topic and check the CMake FAQ at: > >>> http://www.cmake.org/Wiki/CMake_FAQ > >>> > >>> Kitware offers various services to support the CMake community. For more > >>> information on each offering, please visit: > >>> > >>> CMake Support: http://cmake.org/cmake/help/support.html > >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >>> CMake Training Courses: http://cmake.org/cmake/help/training.html > >>> > >>> Visit other Kitware open-source projects at > >>> http://www.kitware.com/opensource/opensource.html > >>> > >>> Follow this link to subscribe/unsubscribe: > >>> http://public.kitware.com/mailman/listinfo/cmake > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2601 bytes Desc: not available URL: From gurenchan at gmail.com Tue Dec 22 06:54:49 2015 From: gurenchan at gmail.com (Owen Hogarth II) Date: Tue, 22 Dec 2015 19:54:49 +0800 Subject: [CMake] cross platform way to unzip Message-ID: Hi Is there a standardized way to unzip a file with cmake that can work on all of cmake's target platforms? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Dec 22 06:57:16 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 22 Dec 2015 12:57:16 +0100 Subject: [CMake] cross platform way to unzip In-Reply-To: References: Message-ID: <56793A9C.30807@gmail.com> On 22.12.2015 12:54, Owen Hogarth II wrote: > > Is there a standardized way to unzip a file with cmake that can work > on all of cmake's target platforms? cmake -E tar x foo.zip Nils From ghisvail at gmail.com Tue Dec 22 13:40:16 2015 From: ghisvail at gmail.com (Ghislain Vaillant) Date: Tue, 22 Dec 2015 18:40:16 +0000 Subject: [CMake] Comments and improvement on find modules Message-ID: <56799910.9060501@gmail.com> Dear CMake users, I have recently written a set of find modules [1][2][3] for dependencies I use for the project I am currently working on. I made sure to write them in a style that is close to what is currently maintained in CMake, with the goal to submit them for inclusion upstream and benefit the whole community. I wanted to ask you guys for comments regarding their content. Some things may be superfluous, others may be missing or improved. Any piece of feedback is warmly welcome. I was also wondering whether there is some sort of best practice with regards to the handling of user-defined prefixes for custom locations of dependencies. I saw some modules using ${Pkg}_ROOT, others using ${Pkg}_DIR, some using a cached variable...Could you guys point me to what is considered good examples here. [1] https://github.com/ghisvail/IRTK/blob/enh/cmake-find-modules/CMake/FindFLANN.cmake [2] https://github.com/ghisvail/IRTK/blob/enh/cmake-find-modules/CMake/FindLibLBFGS.cmake [3] https://github.com/ghisvail/IRTK/blob/enh/cmake-find-modules/CMake/FindNiftiCLib.cmake Many thanks, Ghislain From paul at mad-scientist.net Tue Dec 22 14:57:55 2015 From: paul at mad-scientist.net (Paul Smith) Date: Tue, 22 Dec 2015 14:57:55 -0500 Subject: [CMake] CMake doesn't preserve command line overrides on restart Message-ID: <1450814275.11255.73.camel@mad-scientist.net> If my compiler changes between the last invocation of cmake and this one, then cmake will restart itself; this part works fine. The problem is that if I've invoked cmake with some command line overrides, they are lost when I restart. For example if I have in my makefile: set(BUILDNUM "0" CACHE STRING "Build Number") message(STATUS "Build number = ${BUILDNUM}") by default this is 0, so when developers build locally the build number is 0. When cmake is invoked through our CI build system, it is run like this: cmake -DBUILDNUM=125 . or whatever the current build number is for that build. However, if the compiler has changed and we need to restart the build, this breaks: -- Build number = 125 -- Configuring done You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: CMAKE_C_COMPILER= /new/bin/x86_64-rh55-linux-gnu-gcc CMAKE_CXX_COMPILER= /new/bin/x86_64-rh55-linux-gnu-g++ -- Build number = 0 -- Configuring done -- Generating done -- Build files have been written to: /home/psmith/src/cmake/restart Note that when cmake re-runs itself the command line setting for BUILDNUM has been lost and it reverts to the default value. To me this is a bug... thoughts? From clinton at elemtech.com Tue Dec 22 23:11:44 2015 From: clinton at elemtech.com (clinton at elemtech.com) Date: Tue, 22 Dec 2015 22:11:44 -0600 Subject: [CMake] still having rpath problems on osx In-Reply-To: Message-ID: <5a06fcc5-f638-4b8e-a64c-1334397e7317@email.android.com> On Dec 21, 2015 12:26 PM, Boudewijn Rempt wrote: > > I'm still having rpath problems when creating libraries on OSX... And I'm not sure what's going on here. Here's the output for a single library: > > otool -L ../i/lib/libkritaimage.dylib > ../i/lib/libkritaimage.dylib: > ???? /Users/boud/dev/i/lib/libkritaimage.15.dylib (compatibility version 15.0.0, current version 15.0.0) > ???? /Users/boud/dev/i/lib/libkritawidgets.15.dylib (compatibility version 15.0.0, current version 15.0.0) > ???? /Users/boud/dev/i/lib/libkritapsd.15.dylib (compatibility version 15.0.0, current version 15.0.0) > ???? libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0) > ???? @rpath/libImath.12.dylib (compatibility version 12.0.0, current version 12.0.0) > ???? @rpath/libIlmImf.22.dylib (compatibility version 22.0.0, current version 22.0.0) > ???? @rpath/libIex.12.dylib (compatibility version 12.0.0, current version 12.0.0) > ???? @rpath/libHalf.12.dylib (compatibility version 12.0.0, current version 12.0.0) > ???? @rpath/libIlmThread.12.dylib (compatibility version 12.0.0, current version 12.0.0) > ???? /Users/boud/dev/i/lib/libfftw3.3.dylib (compatibility version 8.0.0, current version 8.4.0) > ???? @rpath/libgsl.dylib (compatibility version 0.0.0, current version 0.0.0) > ???? /Users/boud/dev/i/lib/libkritaflake.15.dylib (compatibility version 15.0.0, current version 15.0.0) > ???? /Users/boud/dev/i/lib/libkritaodf.15.dylib (compatibility version 15.0.0, current version 15.0.0) > ???? /Users/boud/dev/i/lib/libkritaversion.15.dylib (compatibility version 15.0.0, current version 15.0.0) > ???? /Users/boud/dev/i/lib/libkritastore.15.dylib (compatibility version 15.0.0, current version 15.0.0) > ???? /Users/boud/dev/i/lib/libKF5Archive.5.dylib (compatibility version 5.0.0, current version 5.17.0) > ???? /Users/boud/dev/i/lib/libkritaundo2.15.dylib (compatibility version 15.0.0, current version 15.0.0) > ???? /Users/boud/dev/i/lib/libkritawidgetutils.15.dylib (compatibility version 15.0.0, current version 15.0.0) > ???? /Users/boud/dev/i/lib/libKF5ItemViews.5.dylib (compatibility version 5.0.0, current version 5.17.0) > ???? @rpath/QtPrintSupport.framework/Versions/5/QtPrintSupport (compatibility version 5.6.0, current version 5.6.0) > ???? /Users/boud/dev/i/lib/libKF5GuiAddons.5.dylib (compatibility version 5.0.0, current version 5.17.0) > ???? /Users/boud/dev/i/lib/libKF5Completion.5.dylib (compatibility version 5.0.0, current version 5.17.0) > ???? /Users/boud/dev/i/lib/libKF5ConfigGui.5.dylib (compatibility version 5.0.0, current version 5.17.0) > ???? /Users/boud/dev/i/lib/libKF5WidgetsAddons.5.dylib (compatibility version 5.0.0, current version 5.17.0) > ???? /Users/boud/dev/i/lib/libkritaglobal.15.dylib (compatibility version 15.0.0, current version 15.0.0) > ???? @rpath/QtConcurrent.framework/Versions/5/QtConcurrent (compatibility version 5.6.0, current version 5.6.0) > ???? @rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.6.0, current version 5.6.0) > ???? /Users/boud/dev/i/lib/libkritapigment.15.dylib (compatibility version 15.0.0, current version 15.0.0) > ???? @rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.6.0, current version 5.6.0) > ???? @rpath/QtXml.framework/Versions/5/QtXml (compatibility version 5.6.0, current version 5.6.0) > ???? /Users/boud/dev/i/lib/libkritaplugin.15.dylib (compatibility version 15.0.0, current version 15.0.0) > ???? /Users/boud/dev/i/lib/libKF5CoreAddons.5.dylib (compatibility version 5.0.0, current version 5.17.0) > ???? /Users/boud/dev/i/lib/libKF5ConfigCore.5.dylib (compatibility version 5.0.0, current version 5.17.0) > ???? /Users/boud/dev/i/lib/libKF5I18n.5.dylib (compatibility version 5.0.0, current version 5.17.0) > ???? @rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0) > ???? /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) > ???? /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1) > > All libraries I link to are built. Some come with a cmake build system, some with an automake build system, boost with something else altogether... But I wouldn't have expected the way a library is built to make a difference for the link lines in the library that links to the other library. You may not expect this, but this is how it works. @rpath is a way for a library to say, "i want to be found using rpaths" > > Obviously, > ????? libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0) > is wrong -- it's got neither an @rpath, nor a full path. If it is wrong, you need to fix it in boost, or fix it with install_name_tool before linking against it. > > I'm not sure even why some libraries are linked to with @rpath and others with a > full path after running a make install, but I cannot figure out why libboost_system > doesn't have anything. Because each of those dependent libraries indicate how they want to be found. > > libkritaimage is build with these settings: > > * CMake is version 3.4.0 > > * Policy CMP0042 is set to NEW > > * in the toplevel cmakelists.txt, there's > > if (APPLE) > ???? set(CMAKE_MACOSX_RPATH ON) > ???? SET(CMAKE_SKIP_BUILD_RPATH TRUE) > ???? SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE) > ???? SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) > endif () > > I'm feeling dense, but I just cannot make out the documentation for these variables... CMAKE_INSTALL_RPATH_USE_LINK_PATH sounds like it should change the rpath on doing making install, but apparently that doesn't happen. I think you are trying to hard to fix the problem in your cmake, by setting too many variables. The libraries you link against need fixed to behave how you want. By setting set(CMAKE_MACOSX_RPATH ON) you are setting @rpath for the install name of any library you build. By setting INSTALL_RPATH, you are indicating directories to substitute @rpath at runtime. > > * And for the library itself, I explicitly set: > > if (APPLE) > ???? set_target_properties(kritaimage PROPERTIES INSTALL_RPATH "@loader_path/../../../../lib;@loader_path/../lib;@loader_path/../Frameworks;@executable_path/../lib;@executable_path/../Frameworks") > endif() > > Though I sort of feel that it shouldn't be necessary to explicitly set an rpath to something I build. If you are going to install the library, you should set INSTALL_RPATH. > But it results in: > > otool -l libkritaimage.dylib > > Load command 48 > ?????????? cmd LC_RPATH > ?????? cmdsize 48 > ????????? path @loader_path/../../../../lib (offset 12) > Load command 49 > ?????????? cmd LC_RPATH > ?????? cmdsize 32 > ????????? path @loader_path/../lib (offset 12) > Load command 50 > ?????????? cmd LC_RPATH > ?????? cmdsize 40 > ????????? path @loader_path/../Frameworks (offset 12) > Load command 51 > ?????????? cmd LC_RPATH > ?????? cmdsize 40 > ????????? path @executable_path/../lib (offset 12) > Load command 52 > ?????????? cmd LC_RPATH > ?????? cmdsize 48 > ????????? path @executable_path/../Frameworks (offset 12) > > and since everything gets installed to lib, the secodn LC_RPATH points to the place where the library is really installed. > > So I have to manually do > > install_name_tool -change /Users/boud/dev/i/lib/libboost_system.dylib @rpath/libboost_system.dylib libkritaimage.dylib > > to make the libkritaimage finr libboost_system -- and that just cannot be right... It is partly right. However, you may find it simpler to change the id of libraries before you link against them. For example install_name_tool -id @rpath/libboost_system.dylib libboost_system.dylib And use "install_name_tool -change" for any libraries that link against the library with the changed id, but only if you change the id after linking. Clint From cedric.doucet at inria.fr Wed Dec 23 05:32:12 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Wed, 23 Dec 2015 11:32:12 +0100 (CET) Subject: [CMake] Correct usage of add_library In-Reply-To: <277153709.4492007.1450866294879.JavaMail.zimbra@inria.fr> Message-ID: <788059090.4493915.1450866732414.JavaMail.zimbra@inria.fr> Hello, I have a code which consist in a kernel and several independent modules which depend on this kernel. I would like to let users build the module they want by typing, for example, make module1 to build the first module. But, as this first module depends on the kernel, I need this kernel to be built BEFORE module1. My file organization is the following: project_directory/ CMakeLists.txt src/ CMakeLists.txt kernel/ CMakeLists.txt modules/ CMakeLists.txt module1/ module2/ I guess I should use the add_library command to build the kernel first, but I don't know exactly how to do it since there are many possible usages of this command: https://cmake.org/cmake/help/latest/command/add_library.html Does someone know what is the cleanest way to do it? C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.nikulov at gmail.com Wed Dec 23 05:38:38 2015 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Wed, 23 Dec 2015 13:38:38 +0300 Subject: [CMake] Correct usage of add_library In-Reply-To: <788059090.4493915.1450866732414.JavaMail.zimbra@inria.fr> References: <277153709.4492007.1450866294879.JavaMail.zimbra@inria.fr> <788059090.4493915.1450866732414.JavaMail.zimbra@inria.fr> Message-ID: Hello, 2015-12-23 13:32 GMT+03:00 Cedric Doucet : > > Hello, > > I have a code which consist in a kernel and several independent modules > which depend on this kernel. > I would like to let users build the module they want by typing, for example, > > make module1 > > to build the first module. > But, as this first module depends on the kernel, I need this kernel to be > built BEFORE module1. > You should add add_dependencies(module1 kernel) in your module1 CMakeLists.txt https://cmake.org/cmake/help/latest/command/add_dependencies.html HTH, -- Best Regards, Sergei Nikulov From cedric.doucet at inria.fr Wed Dec 23 06:59:48 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Wed, 23 Dec 2015 12:59:48 +0100 (CET) Subject: [CMake] Correct usage of add_library In-Reply-To: References: <277153709.4492007.1450866294879.JavaMail.zimbra@inria.fr> <788059090.4493915.1450866732414.JavaMail.zimbra@inria.fr> Message-ID: <288465377.4510827.1450871988327.JavaMail.zimbra@inria.fr> Hello, thank you very much, it works fine! Do you know how to create a target so that make mykernel creates a library libkernel.so? For the moment, I create a library with the command add_library(kernel SHARED ${src}) and I build libkernel.so by typing make. I have found there exists a command add_custom_target but I don't know how to use it. I tried add_custom_target(mykernel DEPENDS kernel) but it does not seems to take my include_directories instructions into account since some headers are not found anymore (they're found when I type 'make'). C?dric ----- Mail original ----- > De: "Sergei Nikulov" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Mercredi 23 D?cembre 2015 11:38:38 > Objet: Re: [CMake] Correct usage of add_library > > Hello, > > 2015-12-23 13:32 GMT+03:00 Cedric Doucet : > > > > Hello, > > > > I have a code which consist in a kernel and several independent modules > > which depend on this kernel. > > I would like to let users build the module they want by typing, for > > example, > > > > make module1 > > > > to build the first module. > > But, as this first module depends on the kernel, I need this kernel to be > > built BEFORE module1. > > > > You should add > > add_dependencies(module1 kernel) > > in your module1 CMakeLists.txt > > https://cmake.org/cmake/help/latest/command/add_dependencies.html > > HTH, > > -- > Best Regards, > Sergei Nikulov > From cedric.doucet at inria.fr Wed Dec 23 07:08:01 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Wed, 23 Dec 2015 13:08:01 +0100 (CET) Subject: [CMake] Correct usage of add_library In-Reply-To: <288465377.4510827.1450871988327.JavaMail.zimbra@inria.fr> References: <277153709.4492007.1450866294879.JavaMail.zimbra@inria.fr> <788059090.4493915.1450866732414.JavaMail.zimbra@inria.fr> <288465377.4510827.1450871988327.JavaMail.zimbra@inria.fr> Message-ID: <1366448647.4511846.1450872481209.JavaMail.zimbra@inria.fr> Sorry, it was a mistake! Everything works fine! Best, C?dric ----- Mail original ----- > De: "Cedric Doucet" > ?: "Sergei Nikulov" > Cc: cmake at cmake.org > Envoy?: Mercredi 23 D?cembre 2015 12:59:48 > Objet: Re: [CMake] Correct usage of add_library > > > Hello, > > thank you very much, it works fine! > > Do you know how to create a target so that > > make mykernel > > creates a library libkernel.so? > > > For the moment, I create a library with the command > > add_library(kernel SHARED ${src}) > > and I build libkernel.so by typing make. > > I have found there exists a command add_custom_target but I don't know how to > use it. > I tried > > add_custom_target(mykernel DEPENDS kernel) > > but it does not seems to take my include_directories instructions into > account since some headers are not found anymore (they're found when I type > 'make'). > > C?dric > > ----- Mail original ----- > > De: "Sergei Nikulov" > > ?: "Cedric Doucet" > > Cc: cmake at cmake.org > > Envoy?: Mercredi 23 D?cembre 2015 11:38:38 > > Objet: Re: [CMake] Correct usage of add_library > > > > Hello, > > > > 2015-12-23 13:32 GMT+03:00 Cedric Doucet : > > > > > > Hello, > > > > > > I have a code which consist in a kernel and several independent modules > > > which depend on this kernel. > > > I would like to let users build the module they want by typing, for > > > example, > > > > > > make module1 > > > > > > to build the first module. > > > But, as this first module depends on the kernel, I need this kernel to be > > > built BEFORE module1. > > > > > > > You should add > > > > add_dependencies(module1 kernel) > > > > in your module1 CMakeLists.txt > > > > https://cmake.org/cmake/help/latest/command/add_dependencies.html > > > > HTH, > > > > -- > > Best Regards, > > Sergei Nikulov > > > -- > > 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 > From sergey.nikulov at gmail.com Wed Dec 23 07:18:33 2015 From: sergey.nikulov at gmail.com (Sergei Nikulov) Date: Wed, 23 Dec 2015 15:18:33 +0300 Subject: [CMake] Correct usage of add_library In-Reply-To: <1366448647.4511846.1450872481209.JavaMail.zimbra@inria.fr> References: <277153709.4492007.1450866294879.JavaMail.zimbra@inria.fr> <788059090.4493915.1450866732414.JavaMail.zimbra@inria.fr> <288465377.4510827.1450871988327.JavaMail.zimbra@inria.fr> <1366448647.4511846.1450872481209.JavaMail.zimbra@inria.fr> Message-ID: 2015-12-23 15:08 GMT+03:00 Cedric Doucet : > > Sorry, it was a mistake! > Everything works fine! > Nice to hear that. And another update to my previous answer. If your module depends on kernel library (as I understand now it should be linked to module) you'd better use target_link_libraries(module1 kernel) https://cmake.org/cmake/help/v3.4/command/target_link_libraries.html This dependency also should be resolved first and add kernel library to linker command. > > > > ----- Mail original ----- >> De: "Cedric Doucet" >> ?: "Sergei Nikulov" >> Cc: cmake at cmake.org >> Envoy?: Mercredi 23 D?cembre 2015 12:59:48 >> Objet: Re: [CMake] Correct usage of add_library >> >> >> Hello, >> >> thank you very much, it works fine! >> >> Do you know how to create a target so that >> >> make mykernel >> >> creates a library libkernel.so? >> >> >> For the moment, I create a library with the command >> >> add_library(kernel SHARED ${src}) >> >> and I build libkernel.so by typing make. >> >> I have found there exists a command add_custom_target but I don't know how to >> use it. >> I tried >> >> add_custom_target(mykernel DEPENDS kernel) >> >> but it does not seems to take my include_directories instructions into >> account since some headers are not found anymore (they're found when I type >> 'make'). >> >> C?dric >> >> ----- Mail original ----- >> > De: "Sergei Nikulov" >> > ?: "Cedric Doucet" >> > Cc: cmake at cmake.org >> > Envoy?: Mercredi 23 D?cembre 2015 11:38:38 >> > Objet: Re: [CMake] Correct usage of add_library >> > >> > Hello, >> > >> > 2015-12-23 13:32 GMT+03:00 Cedric Doucet : >> > > >> > > Hello, >> > > >> > > I have a code which consist in a kernel and several independent modules >> > > which depend on this kernel. >> > > I would like to let users build the module they want by typing, for >> > > example, >> > > >> > > make module1 >> > > >> > > to build the first module. >> > > But, as this first module depends on the kernel, I need this kernel to be >> > > built BEFORE module1. >> > > >> > >> > You should add >> > >> > add_dependencies(module1 kernel) >> > >> > in your module1 CMakeLists.txt >> > >> > https://cmake.org/cmake/help/latest/command/add_dependencies.html >> > >> > HTH, >> > >> > -- >> > Best Regards, >> > Sergei Nikulov >> > >> -- >> >> 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 >> -- Best Regards, Sergei Nikulov From cedric.doucet at inria.fr Wed Dec 23 07:22:16 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Wed, 23 Dec 2015 13:22:16 +0100 (CET) Subject: [CMake] Correct usage of add_library In-Reply-To: References: <277153709.4492007.1450866294879.JavaMail.zimbra@inria.fr> <788059090.4493915.1450866732414.JavaMail.zimbra@inria.fr> <288465377.4510827.1450871988327.JavaMail.zimbra@inria.fr> <1366448647.4511846.1450872481209.JavaMail.zimbra@inria.fr> Message-ID: <267761734.4513169.1450873336659.JavaMail.zimbra@inria.fr> Thank you very much! :) Managing modules is indeed the very next step for me! I will try that right now! C?dric ----- Mail original ----- > De: "Sergei Nikulov" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Mercredi 23 D?cembre 2015 13:18:33 > Objet: Re: [CMake] Correct usage of add_library > > 2015-12-23 15:08 GMT+03:00 Cedric Doucet : > > > > Sorry, it was a mistake! > > Everything works fine! > > > > Nice to hear that. > > And another update to my previous answer. > > If your module depends on kernel library (as I understand now it > should be linked to module) you'd better use > > target_link_libraries(module1 kernel) > > https://cmake.org/cmake/help/v3.4/command/target_link_libraries.html > > This dependency also should be resolved first and add kernel library > to linker command. > > > > > > > > > ----- Mail original ----- > >> De: "Cedric Doucet" > >> ?: "Sergei Nikulov" > >> Cc: cmake at cmake.org > >> Envoy?: Mercredi 23 D?cembre 2015 12:59:48 > >> Objet: Re: [CMake] Correct usage of add_library > >> > >> > >> Hello, > >> > >> thank you very much, it works fine! > >> > >> Do you know how to create a target so that > >> > >> make mykernel > >> > >> creates a library libkernel.so? > >> > >> > >> For the moment, I create a library with the command > >> > >> add_library(kernel SHARED ${src}) > >> > >> and I build libkernel.so by typing make. > >> > >> I have found there exists a command add_custom_target but I don't know how > >> to > >> use it. > >> I tried > >> > >> add_custom_target(mykernel DEPENDS kernel) > >> > >> but it does not seems to take my include_directories instructions into > >> account since some headers are not found anymore (they're found when I > >> type > >> 'make'). > >> > >> C?dric > >> > >> ----- Mail original ----- > >> > De: "Sergei Nikulov" > >> > ?: "Cedric Doucet" > >> > Cc: cmake at cmake.org > >> > Envoy?: Mercredi 23 D?cembre 2015 11:38:38 > >> > Objet: Re: [CMake] Correct usage of add_library > >> > > >> > Hello, > >> > > >> > 2015-12-23 13:32 GMT+03:00 Cedric Doucet : > >> > > > >> > > Hello, > >> > > > >> > > I have a code which consist in a kernel and several independent > >> > > modules > >> > > which depend on this kernel. > >> > > I would like to let users build the module they want by typing, for > >> > > example, > >> > > > >> > > make module1 > >> > > > >> > > to build the first module. > >> > > But, as this first module depends on the kernel, I need this kernel to > >> > > be > >> > > built BEFORE module1. > >> > > > >> > > >> > You should add > >> > > >> > add_dependencies(module1 kernel) > >> > > >> > in your module1 CMakeLists.txt > >> > > >> > https://cmake.org/cmake/help/latest/command/add_dependencies.html > >> > > >> > HTH, > >> > > >> > -- > >> > Best Regards, > >> > Sergei Nikulov > >> > > >> -- > >> > >> 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 > >> > > > > -- > Best Regards, > Sergei Nikulov > From Jakub.Golebiewski at dnvgl.com Wed Dec 23 07:29:16 2015 From: Jakub.Golebiewski at dnvgl.com (Golebiewski, Jakub) Date: Wed, 23 Dec 2015 12:29:16 +0000 Subject: [CMake] Modify command in RUN_TESTS Message-ID: Hi, Is there a way to add options to ctest invocation used in RUN_TESTS target? I'm just trying to pass -jX and -output-on-failure... Regards, J ************************************************************************************** This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited. ************************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.doucet at inria.fr Wed Dec 23 08:26:38 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Wed, 23 Dec 2015 14:26:38 +0100 (CET) Subject: [CMake] change add_executable to add_library leads to an error In-Reply-To: <220236314.4522573.1450876965646.JavaMail.zimbra@inria.fr> Message-ID: <449619872.4523264.1450877198652.JavaMail.zimbra@inria.fr> Hello, I have the following script: ================================= file(GLOB_RECURSE statphys "*.cpp") #add_library(simol-statphys SHARED ${statphys}) add_executable(simol-statphys ${statphys}) add_dependencies(simol-statphys simol-core) add_custom_target(statphys simol-statphys) target_link_libraries(simol-statphys simol-core) target_link_libraries(simol-statphys ${ARMADILLO_INSTALL_DIR}/lib/libarmadillo.so) target_link_libraries(simol-statphys ${YAMLCPP_INSTALL_DIR}/lib/libyaml-cpp.a) ================================= I would like generate a shared library simol-statphys instead of an executable simol-statphys. In other words, I would like to replace the call to add_executable, to the one which is contained in the comment below this call. However, if I do this, and I type make statphys I get the following error message: Scanning dependencies of target statphys /bin/sh: 1: simol-statphys: not found make[3]: *** [src/modules/statphys/CMakeFiles/statphys] Erreur 127 make[2]: *** [src/modules/statphys/CMakeFiles/statphys.dir/all] Erreur 2 make[1]: *** [src/modules/statphys/CMakeFiles/statphys.dir/rule] Erreur 2 make: *** [statphys] Erreur 2 Does someone can explain me where do the problem come from? C?dric -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan_baratov at yahoo.com Wed Dec 23 08:29:14 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Wed, 23 Dec 2015 20:29:14 +0700 Subject: [CMake] Tests with assert and Release build type In-Reply-To: <87wps7zf0w.fsf@therning.org> References: <87egejhndt.fsf@sobel.cipherstone.com> <5674BBC3.7020905@yahoo.com> <87poy2cmtf.fsf@therning.org> <56784CF9.3030507@yahoo.com> <87wps7zf0w.fsf@therning.org> Message-ID: <567AA1AA.7060607@yahoo.com> On 22-Dec-15 04:07, Magnus Therning wrote: > Ruslan Baratov writes: > >> On 20-Dec-15 01:31, Magnus Therning wrote: >>> Ruslan Baratov writes: >>> >>>> How about using RelWithDebInfo? See: >>>> http://stackoverflow.com/a/28124715/2288008 >>> Hmm, I'm probably missing something but how does that solve the issue >>> with some targets requiring NDEBUG to be *undefined* and other targets >>> requiring NDEBUG to be defined? >> I don't think that building targets with different NDEBUG values is a >> good idea. More correct approach will be to introduce custom macro to >> allow checks (i.e. FOO_NDEBUG/FOO_DEBUG). > Why not? It is possible to hit situation when ODR will be violated, e.g. if somebody define optional member in structure with "#if defined(NDEBUG)" condition. Something like this: http://stackoverflow.com/questions/20833226/library-headers-and-define > > /M > > -- > Magnus Therning OpenPGP: 0x927912051716CE39 > email: magnus at therning.org jabber: magnus at therning.org > twitter: magthe http://therning.org/magnus > > We act as though comfort and luxury were the chief requirements of > life, when all that we need to make us happy is something to be > enthusiastic about. > -- Albert Einstein From petr.kmoch at gmail.com Wed Dec 23 08:41:55 2015 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Wed, 23 Dec 2015 14:41:55 +0100 Subject: [CMake] change add_executable to add_library leads to an error In-Reply-To: <449619872.4523264.1450877198652.JavaMail.zimbra@inria.fr> References: <220236314.4522573.1450876965646.JavaMail.zimbra@inria.fr> <449619872.4523264.1450877198652.JavaMail.zimbra@inria.fr> Message-ID: Hi Cedric. add_custom_target() does not work the way you think it does. The arguments given after the target name are commands which the custom target will execute. So what your custom target `statphys` does is execute a program named `simol-statphys`. When `simol-statphys` was the name of an executable target, CMake figured out a dependency based on this and arranged it so that `simol-statphys` is built first and then executed. However, when `simol-statphys` is a library target, it does not receive this special treatment; and why would it, since you cannot execute a library. Therefore, it simply tries to execute a program named `simol-statphys` and, expectedly, fails. If I understand your intention with the custom target correctly, you want to have a shorthand alias for the target in the makefile. The correct syntax to achieve that would be: add_custom_target(statphys) add_dependencies(statphys simol-statphys) Hope this helps. Petr On Wed, Dec 23, 2015 at 2:26 PM, Cedric Doucet wrote: > > Hello, > > I have the following script: > ================================= > > file(GLOB_RECURSE statphys "*.cpp") > > > #add_library(simol-statphys SHARED ${statphys}) > add_executable(simol-statphys ${statphys}) > > > add_dependencies(simol-statphys simol-core) > > add_custom_target(statphys simol-statphys) > > > target_link_libraries(simol-statphys simol-core) > > target_link_libraries(simol-statphys > ${ARMADILLO_INSTALL_DIR}/lib/libarmadillo.so) > target_link_libraries(simol-statphys > ${YAMLCPP_INSTALL_DIR}/lib/libyaml-cpp.a) > > ================================= > > > I would like generate a shared library simol-statphys instead of an > executable simol-statphys. > > In other words, I would like to replace the call to add_executable, to the > one which is contained in the comment below this call. > > > However, if I do this, and I type > > > make statphys > > > I get the following error message: > > > Scanning dependencies of target statphys > /bin/sh: 1: simol-statphys: not found > make[3]: *** [src/modules/statphys/CMakeFiles/statphys] Erreur 127 > make[2]: *** [src/modules/statphys/CMakeFiles/statphys.dir/all] Erreur 2 > make[1]: *** [src/modules/statphys/CMakeFiles/statphys.dir/rule] Erreur 2 > make: *** [statphys] Erreur 2 > > > Does someone can explain me where do the problem come from? > > > C?dric > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.doucet at inria.fr Wed Dec 23 08:54:43 2015 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Wed, 23 Dec 2015 14:54:43 +0100 (CET) Subject: [CMake] change add_executable to add_library leads to an error In-Reply-To: References: <220236314.4522573.1450876965646.JavaMail.zimbra@inria.fr> <449619872.4523264.1450877198652.JavaMail.zimbra@inria.fr> Message-ID: <1173688230.4526873.1450878883939.JavaMail.zimbra@inria.fr> Hi Petr! Yes, it helps me a lot! I have tried to apply your approach and this is exactly what I want. Thank you! :) C?dric ----- Mail original ----- > De: "Petr Kmoch" > ?: "Cedric Doucet" > Cc: cmake at cmake.org > Envoy?: Mercredi 23 D?cembre 2015 14:41:55 > Objet: Re: [CMake] change add_executable to add_library leads to an error > Hi Cedric. > add_custom_target() does not work the way you think it does. The arguments > given after the target name are commands which the custom target will > execute. So what your custom target `statphys` does is execute a program > named `simol-statphys`. When `simol-statphys` was the name of an executable > target, CMake figured out a dependency based on this and arranged it so that > `simol-statphys` is built first and then executed. > However, when `simol-statphys` is a library target, it does not receive this > special treatment; and why would it, since you cannot execute a library. > Therefore, it simply tries to execute a program named `simol-statphys` and, > expectedly, fails. > If I understand your intention with the custom target correctly, you want to > have a shorthand alias for the target in the makefile. The correct syntax to > achieve that would be: > add_custom_target(statphys) > add_dependencies(statphys simol-statphys) > Hope this helps. > Petr > On Wed, Dec 23, 2015 at 2:26 PM, Cedric Doucet < cedric.doucet at inria.fr > > wrote: > > Hello, > > > I have the following script: > > > ================================= > > > file(GLOB_RECURSE statphys "*.cpp") > > > #add_library(simol-statphys SHARED ${statphys}) > > > add_executable(simol-statphys ${statphys}) > > > add_dependencies(simol-statphys simol-core) > > > add_custom_target(statphys simol-statphys) > > > target_link_libraries(simol-statphys simol-core) > > > target_link_libraries(simol-statphys > > ${ARMADILLO_INSTALL_DIR}/lib/libarmadillo.so) > > > target_link_libraries(simol-statphys > > ${YAMLCPP_INSTALL_DIR}/lib/libyaml-cpp.a) > > > ================================= > > > I would like generate a shared library simol-statphys instead of an > > executable simol-statphys. > > > In other words, I would like to replace the call to add_executable, to the > > one which is contained in the comment below this call. > > > However, if I do this, and I type > > > make statphys > > > I get the following error message: > > > Scanning dependencies of target statphys > > > /bin/sh: 1: simol-statphys: not found > > > make[3]: *** [src/modules/statphys/CMakeFiles/statphys] Erreur 127 > > > make[2]: *** [src/modules/statphys/CMakeFiles/statphys.dir/all] Erreur 2 > > > make[1]: *** [src/modules/statphys/CMakeFiles/statphys.dir/rule] Erreur 2 > > > make: *** [statphys] Erreur 2 > > > Does someone can explain me where do the problem come from? > > > C?dric > > > -- > > > Powered by www.kitware.com > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > CMake Support: http://cmake.org/cmake/help/support.html > > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > Follow this link to subscribe/unsubscribe: > > > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From burlen.loring at gmail.com Wed Dec 23 11:54:21 2015 From: burlen.loring at gmail.com (Burlen Loring) Date: Wed, 23 Dec 2015 08:54:21 -0800 Subject: [CMake] PythonInterp and PythonLibs find different versions on Apple Message-ID: <567AD1BD.7030109@gmail.com> Hi, I'm having this issue that cmake using version 3.3.0. Python detection is finding different versions of interpreter and libraries. There are two version of Python installed, system one and homebrew one. cmake finds Interpreter from homebrew while libs are from system install. Here's my CmakeLists find_package(PythonInterp) find_package(PythonLibs) and configure output -- Found PythonInterp: /usr/local/bin/python (found version "2.7.11") -- Found PythonLibs: /usr/lib/libpython2.7.dylib (found version "2.7.10") I also tried find_package(PythonInterp) find_package(PythonLibs ${PYTHON_VERSION_STRING}) but got -- Found PythonInterp: /usr/local/bin/python (found version "2.7.11") -- Could NOT find PythonLibs: Found unsuitable version "2.7.10", but required is at least "2.7.11" (found /usr/lib/libpython2.7.dylib) I suppose I can just over ride these manually, but shouldn't this just work? or am I doing it wrong? Burlen ps. I tried to install cmake 3.4 on my system but bootstrap has a compile error. I observed the same with cmake 3.4.1 on a colleagues Apple system that has system Python plus Annaconda Python. This leads me to think that it's not addressed in 3.4.1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From burlen.loring at gmail.com Wed Dec 23 12:00:49 2015 From: burlen.loring at gmail.com (Burlen Loring) Date: Wed, 23 Dec 2015 09:00:49 -0800 Subject: [CMake] cmake 3.4.1 bootstrap compile error Message-ID: <567AD341.4050705@gmail.com> I tried to download and compile 3.4.1 on Apple 10.10.5. I did ./configure prefix=blah && make here is the error: g++ -I/Users/bloring/apps/cmake/builds/cmake-3.4.1/Bootstrap.cmk -I/Users/bloring/apps/cmake/builds/cmake-3.4.1/Source -I/Users/bloring/apps/cmake/builds/cmake-3.4.1/Bootstrap.cmk -c /Users/bloring/apps/cmake/builds/cmake-3.4.1/Source/cmBootstrapCommands1.cxx -o cmBootstrapCommands1.o In file included from /usr/include/dispatch/dispatch.h:51:0, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13, from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55, from /Users/bloring/apps/cmake/builds/cmake-3.4.1/Source/cmFindProgramCommand.cxx:16, from /Users/bloring/apps/cmake/builds/cmake-3.4.1/Source/cmBootstrapCommands1.cxx:52: /usr/include/dispatch/object.h:143:15: error: expected unqualified-id before ?^? token typedef void (^dispatch_block_t)(void); ^ /usr/include/dispatch/object.h:143:15: error: expected ?)? before ?^? token /usr/include/dispatch/object.h:362:3: error: ?dispatch_block_t? has not been declared dispatch_block_t notification_block); ^ make: *** [cmBootstrapCommands1.o] Error 1 I guess that this is because homebrew installed gcc. All the same, shouldn't this just work? If Cmake can't work with homebrew gcc then should it ignore it? Burlen -------------- next part -------------- An HTML attachment was scrubbed... URL: From boud at valdyas.org Wed Dec 23 12:02:48 2015 From: boud at valdyas.org (Boudewijn Rempt) Date: Wed, 23 Dec 2015 18:02:48 +0100 (CET) Subject: [CMake] still having rpath problems on osx In-Reply-To: <5a06fcc5-f638-4b8e-a64c-1334397e7317@email.android.com> References: <5a06fcc5-f638-4b8e-a64c-1334397e7317@email.android.com> Message-ID: On Tue, 22 Dec 2015, clinton at elemtech.com wrote: > > On Dec 21, 2015 12:26 PM, Boudewijn Rempt wrote: >> >> All libraries I link to are built. Some come with a cmake build system, some with an automake build system, boost with something else altogether... But I wouldn't have expected the way a library is built to make a difference for the link lines in the library that links to the other library. > > You may not expect this, but this is how it works. @rpath is a way for a library to say, "i want to be found using rpaths" > Hm... Okay -- so, since I all my dependencies myself as cmake external projects, I guess I want all of them set to rpath. I guess that for boost, with its own build system, I'll need to add a separate fix-up step to my cmake externals project for boost. I have to check how I can fix the dependencies that are still automake/autoconf based. And I'll try what you suggest below for my own project. > I think you are trying to hard to fix the problem in your cmake, by setting too many variables. The libraries you link against need fixed to behave how you want. > > By setting > set(CMAKE_MACOSX_RPATH ON) > you are setting @rpath for the install name of any library you build. > > By setting INSTALL_RPATH, you are indicating directories to substitute @rpath at runtime. > > >> >> * And for the library itself, I explicitly set: >> >> if (APPLE) >> ???? set_target_properties(kritaimage PROPERTIES INSTALL_RPATH "@loader_path/../../../../lib;@loader_path/../lib;@loader_path/../Frameworks;@executable_path/../lib;@executable_path/../Frameworks") >> endif() >> >> Though I sort of feel that it shouldn't be necessary to explicitly set an rpath to something I build. > > > If you are going to install the library, you should set INSTALL_RPATH. > Well, the way I set it up, which may be wrong of course, I install all the dependecies to ~/dev/i, then build the main application that uses those dependencies. When developing, I run the app bundle directly, linked to the dependencies in ~/dev/i/lib; when distributing, I use macdeployqt to populate the app bundle with all the dependencies and data. > > It is partly right. However, you may find it simpler to change the id of libraries before you link against them. > For example > install_name_tool -id @rpath/libboost_system.dylib libboost_system.dylib > > And use "install_name_tool -change" for any libraries that link against the library with the changed id, but only if you change the id after linking. > Thanks! I think I'm finally beginning to grasp the idea :-) -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org From mike.jackson at bluequartz.net Wed Dec 23 12:57:50 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Wed, 23 Dec 2015 12:57:50 -0500 Subject: [CMake] still having rpath problems on osx In-Reply-To: References: <5a06fcc5-f638-4b8e-a64c-1334397e7317@email.android.com> Message-ID: > On Dec 23, 2015, at 12:02 PM, Boudewijn Rempt wrote: > > On Tue, 22 Dec 2015, clinton at elemtech.com wrote: > >> >> On Dec 21, 2015 12:26 PM, Boudewijn Rempt wrote: >>> >>> All libraries I link to are built. Some come with a cmake build system, some with an automake build system, boost with something else altogether... But I wouldn't have expected the way a library is built to make a difference for the link lines in the library that links to the other library. >> >> You may not expect this, but this is how it works. @rpath is a way for a library to say, "i want to be found using rpaths" >> > > Hm... Okay -- so, since I all my dependencies myself as cmake external projects, I guess I want all of them set to rpath. I guess that for boost, with its own build system, I'll need to add a separate fix-up step to my cmake externals project for boost. I have to check how I can fix the dependencies that are still automake/autoconf based. And I'll try what you suggest below for my own project. I have written scripts to do things like that for boost and ITK where the libraries do not have anything like @rpath or the absolute path to the installed library. After installing I run those scripts to ?fix? the libraries so when I debug I can just run the application. During packaging I then run CMake?s BundleUtilities to copy in the libraries and adjust the libraries to have @rpath or @executable_path. When fixing up a library make sure you also fix all the dependent libraries that might be there. For things like Boost or ITK their higher level libraries depend on their lower level libraries. Using ?otool -L? you can see this. Make sure you update EVERY path in the library. Also using MacDeployQt will NOT fix up any NON-Qt libraries (like Boost, HDF5.. ) so you will still need to run/write something that fixes all of those libraries. For our project we wrote a pure CMake script that does everything we need to fix up our bundles so that everything is self contained. ? Mike Jackson > >> I think you are trying to hard to fix the problem in your cmake, by setting too many variables. The libraries you link against need fixed to behave how you want. >> >> By setting >> set(CMAKE_MACOSX_RPATH ON) you are setting @rpath for the install name of any library you build. >> >> By setting INSTALL_RPATH, you are indicating directories to substitute @rpath at runtime. >> >> >>> >>> * And for the library itself, I explicitly set: >>> if (APPLE) set_target_properties(kritaimage PROPERTIES INSTALL_RPATH "@loader_path/../../../../lib;@loader_path/../lib;@loader_path/../Frameworks;@executable_path/../lib;@executable_path/../Frameworks") endif() >>> Though I sort of feel that it shouldn't be necessary to explicitly set an rpath to something I build. >> >> >> If you are going to install the library, you should set INSTALL_RPATH. >> > > Well, the way I set it up, which may be wrong of course, I install all the dependecies to ~/dev/i, then build the main application that uses those dependencies. When developing, I run the app bundle directly, linked to the dependencies in ~/dev/i/lib; when distributing, I use macdeployqt to populate the app bundle with all the dependencies and data. > > >> >> It is partly right. However, you may find it simpler to change the id of libraries before you link against them. >> For example >> install_name_tool -id @rpath/libboost_system.dylib libboost_system.dylib >> >> And use "install_name_tool -change" for any libraries that link against the library with the changed id, but only if you change the id after linking. >> > > Thanks! I think I'm finally beginning to grasp the idea :-) > > > -- > Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org-- > From DLRdave at aol.com Wed Dec 23 14:08:42 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 23 Dec 2015 14:08:42 -0500 Subject: [CMake] Tests with assert and Release build type In-Reply-To: <567AA1AA.7060607@yahoo.com> References: <87egejhndt.fsf@sobel.cipherstone.com> <5674BBC3.7020905@yahoo.com> <87poy2cmtf.fsf@therning.org> <56784CF9.3030507@yahoo.com> <87wps7zf0w.fsf@therning.org> <567AA1AA.7060607@yahoo.com> Message-ID: Not only is it possible ... it WILL happen if you use the Microsoft C++ compiler and try to mix and match Release and Debug compilation units. The MS compiler has some very nice memory tracking facilities built into the Debug runtime libraries, but it is accomplished via different structs for Debug and Release builds with extra stuff in the Debug structs. So allocations from a Debug compilation unit will not be accessed correctly in a linked-in Release compilation unit when a pointer to it is passed across the boundary. You will see access violations and hard crashes happening in builds from the Microsoft compiler unless you ensure that everything in a build has matching Debug/Release defines and compiler settings. It is only safe to mix-n-match if all calls which cross a boundary between compilation units have NO differences in their struct and class definitions from an ABI perspective. Since it is difficult to verify when this is the case (in general) for large C++ projects, it's best to avoid mixing and matching... HTH, David C. On Wed, Dec 23, 2015 at 8:29 AM, Ruslan Baratov via CMake wrote: > On 22-Dec-15 04:07, Magnus Therning wrote: >> >> Ruslan Baratov writes: >> >>> On 20-Dec-15 01:31, Magnus Therning wrote: >>>> >>>> Ruslan Baratov writes: >>>> >>>>> How about using RelWithDebInfo? See: >>>>> http://stackoverflow.com/a/28124715/2288008 >>>> >>>> Hmm, I'm probably missing something but how does that solve the issue >>>> with some targets requiring NDEBUG to be *undefined* and other targets >>>> requiring NDEBUG to be defined? >>> >>> I don't think that building targets with different NDEBUG values is a >>> good idea. More correct approach will be to introduce custom macro to >>> allow checks (i.e. FOO_NDEBUG/FOO_DEBUG). >> >> Why not? > > It is possible to hit situation when ODR will be violated, e.g. if somebody > define optional member in structure with "#if defined(NDEBUG)" condition. > Something like this: > http://stackoverflow.com/questions/20833226/library-headers-and-define > >> >> /M >> >> -- >> Magnus Therning OpenPGP: 0x927912051716CE39 >> email: magnus at therning.org jabber: magnus at therning.org >> twitter: magthe http://therning.org/magnus >> >> We act as though comfort and luxury were the chief requirements of >> life, when all that we need to make us happy is something to be >> enthusiastic about. >> -- Albert Einstein > > > -- > > 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 From boud at valdyas.org Thu Dec 24 02:24:03 2015 From: boud at valdyas.org (Boudewijn Rempt) Date: Thu, 24 Dec 2015 08:24:03 +0100 (CET) Subject: [CMake] still having rpath problems on osx In-Reply-To: References: <5a06fcc5-f638-4b8e-a64c-1334397e7317@email.android.com> Message-ID: On Wed, 23 Dec 2015, Michael Jackson wrote: >> >> Hm... Okay -- so, since I all my dependencies myself as cmake external projects, I guess I want all of them set to rpath. I guess that for boost, with its own build system, I'll need to add a separate fix-up step to my cmake externals project for boost. I have to check how I can fix the dependencies that are still automake/autoconf based. And I'll try what you suggest below for my own project. > > I have written scripts to do things like that for boost and ITK where the libraries do not have anything like @rpath or the absolute path to the installed library. After installing I run those scripts to ?fix? the libraries so when I debug I can just run the application. During packaging I then run CMake?s BundleUtilities to copy in the libraries and adjust the libraries to have @rpath or @executable_path. > > When fixing up a library make sure you also fix all the dependent libraries that might be there. For things like Boost or ITK their higher level libraries depend on their lower level libraries. Using ?otool -L? you can see this. Make sure you update EVERY path in the library. > > Also using MacDeployQt will NOT fix up any NON-Qt libraries (like Boost, HDF5.. ) so you will still need to run/write something that fixes all of those libraries. For our project we wrote a pure CMake script that does everything we need to fix up our bundles so that everything is self contained. Hm... And it all did work when my project was still Qt4-based and I built on Mavericks... And I've got about 300 libraries in the project, including plugins. Resetting the id of broken libraries and then rebuilding my project works. Are your scripts public so I can take a look and maybe reuse them? -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org From magnus at therning.org Thu Dec 24 07:46:08 2015 From: magnus at therning.org (Magnus Therning) Date: Thu, 24 Dec 2015 13:46:08 +0100 Subject: [CMake] Tests with assert and Release build type In-Reply-To: References: <87egejhndt.fsf@sobel.cipherstone.com> <5674BBC3.7020905@yahoo.com> <87poy2cmtf.fsf@therning.org> <56784CF9.3030507@yahoo.com> <87wps7zf0w.fsf@therning.org> <567AA1AA.7060607@yahoo.com> Message-ID: <871tac10bz.fsf@therning.org> David Cole writes: > Not only is it possible ... it WILL happen if you use the Microsoft > C++ compiler and try to mix and match Release and Debug compilation > units. > > The MS compiler has some very nice memory tracking facilities built > into the Debug runtime libraries, but it is accomplished via different > structs for Debug and Release builds with extra stuff in the Debug > structs. > So allocations from a Debug compilation unit will not be accessed > correctly in a linked-in Release compilation unit when a pointer to it > is passed across the boundary. > > You will see access violations and hard crashes happening in builds > from the Microsoft compiler unless you ensure that everything in a > build has matching Debug/Release defines and compiler settings. > > It is only safe to mix-n-match if all calls which cross a boundary > between compilation units have NO differences in their struct and > class definitions from an ABI perspective. Since it is difficult to > verify when this is the case (in general) for large C++ projects, it's > best to avoid mixing and matching... I'm *not* mixing stuff built with `-g` and stuff built without it. I'm also *not* mixing linking with debug- and non-debug libraries. I'm only mixing stuff build with `-DNDEBUG` and stuff built without it. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Software isn't finished until the last user is dead. -- head on FLOSS Weekly -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From magnus at therning.org Thu Dec 24 07:48:59 2015 From: magnus at therning.org (Magnus Therning) Date: Thu, 24 Dec 2015 13:48:59 +0100 Subject: [CMake] Tests with assert and Release build type In-Reply-To: <567AA1AA.7060607@yahoo.com> References: <87egejhndt.fsf@sobel.cipherstone.com> <5674BBC3.7020905@yahoo.com> <87poy2cmtf.fsf@therning.org> <56784CF9.3030507@yahoo.com> <87wps7zf0w.fsf@therning.org> <567AA1AA.7060607@yahoo.com> Message-ID: <87zix0yptw.fsf@therning.org> Ruslan Baratov writes: > On 22-Dec-15 04:07, Magnus Therning wrote: >> Ruslan Baratov writes: >> >>> On 20-Dec-15 01:31, Magnus Therning wrote: >>>> Ruslan Baratov writes: >>>> >>>>> How about using RelWithDebInfo? See: >>>>> http://stackoverflow.com/a/28124715/2288008 >>>> Hmm, I'm probably missing something but how does that solve the issue >>>> with some targets requiring NDEBUG to be *undefined* and other targets >>>> requiring NDEBUG to be defined? >>> I don't think that building targets with different NDEBUG values is a >>> good idea. More correct approach will be to introduce custom macro to >>> allow checks (i.e. FOO_NDEBUG/FOO_DEBUG). >> Why not? > It is possible to hit situation when ODR will be violated, e.g. if > somebody define optional member in structure with "#if defined(NDEBUG)" > condition. Something like this: > http://stackoverflow.com/questions/20833226/library-headers-and-define Yes, if we ever start using the NDEBUG macro to control anything in our code then I'll have to worry about this, as it stands right now it's only the `assert` from `assert.h` that cares about it. If I'm reading you correctly you are advocating I simply get rid of the use of those asserts altogether instead. /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus The results point out the fragility of programmer expertise: advanced programmers have strong expectations about what programs should look like, and when those expectations are violated--in seemingly innocuous ways--their performance drops drastically. -- Elliot Soloway and Kate Ehrlich -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From ruslan_baratov at yahoo.com Thu Dec 24 11:20:59 2015 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Thu, 24 Dec 2015 23:20:59 +0700 Subject: [CMake] Tests with assert and Release build type In-Reply-To: <87zix0yptw.fsf@therning.org> References: <87egejhndt.fsf@sobel.cipherstone.com> <5674BBC3.7020905@yahoo.com> <87poy2cmtf.fsf@therning.org> <56784CF9.3030507@yahoo.com> <87wps7zf0w.fsf@therning.org> <567AA1AA.7060607@yahoo.com> <87zix0yptw.fsf@therning.org> Message-ID: <567C1B6B.1020703@yahoo.com> On 24-Dec-15 19:46, Magnus Therning wrote: > I'm *not* mixing stuff built with `-g` and stuff built without it. Actually I don't see anything bad about mixing `-g` code with code without `-g`. > I'm > also *not* mixing linking with debug- and non-debug libraries. Since we cover a lot of aspects please specify what you mean by debug and non-debug libraries. > I'm only mixing stuff build with `-DNDEBUG` and stuff built without it. see below On 24-Dec-15 19:48, Magnus Therning wrote: > Ruslan Baratov writes: > >> On 22-Dec-15 04:07, Magnus Therning wrote: >> >> It is possible to hit situation when ODR will be violated, e.g. if >> somebody define optional member in structure with "#if defined(NDEBUG)" >> condition. Something like this: >> http://stackoverflow.com/questions/20833226/library-headers-and-define > Yes, if we ever start using the NDEBUG macro to control anything in our > code then I'll have to worry about this, as it stands right now it's > only the `assert` from `assert.h` that cares about it. Even if you care only about `assert` somebody can define different type of structures based on value of NDEBUG. I'm talking about 3rd party library that you can use and you can't control. If this will lead to ODR violation then bug is NOT in 3rd party code, but in YOUR code. That's my point. You can mix c++11 with c++98, libc++ with libstdc++, mingw with cygwin, mingw with Visual Studio, NDEBUG with non NDEBUG, and it MAY works, but when something suddenly will stop working with very obscure errors that it's YOUR fault and not 3rd party.// > If I'm reading you correctly you are advocating I simply get rid of the > use of those asserts altogether instead. I'm not sure what you mean. I'm just telling that if you want do some runtime checks even when NDEBUG is OFF then you should introduce your own macro FOO_DEBUG. Difference is about global/local affects. Ruslo -------------- next part -------------- An HTML attachment was scrubbed... URL: From burlen.loring at gmail.com Thu Dec 24 11:27:24 2015 From: burlen.loring at gmail.com (Burlen Loring) Date: Thu, 24 Dec 2015 08:27:24 -0800 Subject: [CMake] cmake 3.4.1 bootstrap compile error In-Reply-To: <567AD341.4050705@gmail.com> References: <567AD341.4050705@gmail.com> Message-ID: <567C1CEC.90205@gmail.com> I found that there is an install of gcc in /usr/local/ and this was causing the issue. once I removed that things went smoothly. On 12/23/2015 09:00 AM, Burlen Loring wrote: > I tried to download and compile 3.4.1 on Apple 10.10.5. I did > > ./configure prefix=blah && make > > here is the error: > > g++ -I/Users/bloring/apps/cmake/builds/cmake-3.4.1/Bootstrap.cmk > -I/Users/bloring/apps/cmake/builds/cmake-3.4.1/Source > -I/Users/bloring/apps/cmake/builds/cmake-3.4.1/Bootstrap.cmk -c > /Users/bloring/apps/cmake/builds/cmake-3.4.1/Source/cmBootstrapCommands1.cxx > -o cmBootstrapCommands1.o > In file included from /usr/include/dispatch/dispatch.h:51:0, > from > /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15, > from > /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13, > from > /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55, > from > /Users/bloring/apps/cmake/builds/cmake-3.4.1/Source/cmFindProgramCommand.cxx:16, > from > /Users/bloring/apps/cmake/builds/cmake-3.4.1/Source/cmBootstrapCommands1.cxx:52: > /usr/include/dispatch/object.h:143:15: error: expected > unqualified-id before ?^? token > typedef void (^dispatch_block_t)(void); > ^ > /usr/include/dispatch/object.h:143:15: error: expected ?)? before > ?^? token > /usr/include/dispatch/object.h:362:3: error: ?dispatch_block_t? > has not been declared > dispatch_block_t notification_block); > ^ > make: *** [cmBootstrapCommands1.o] Error 1 > > I guess that this is because homebrew installed gcc. All the same, > shouldn't this just work? If Cmake can't work with homebrew gcc then > should it ignore it? > > Burlen -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidshen84 at gmail.com Fri Dec 25 04:36:05 2015 From: davidshen84 at gmail.com (Xi Shen) Date: Fri, 25 Dec 2015 09:36:05 +0000 Subject: [CMake] How to get current visualstudio version? Message-ID: Hi, I know I can check MSVC to determine if the Visual Studio generator is used. But how do I find out which version is been used? The reason I want to find the the version of VS being used, is because I need to link to the Boost libraries. Boost create its libraries with suffixes like "-vs120-mt", etc. and "vs120" indicates Visual Studio 2013. Thanks, David -- Regards, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Dec 25 07:40:09 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 25 Dec 2015 13:40:09 +0100 Subject: [CMake] How to get current visualstudio version? In-Reply-To: References: Message-ID: <567D3929.5050901@gmail.com> On 25.12.2015 10:36, Xi Shen wrote: > Hi, > > I know I can check MSVC to determine if the Visual Studio generator is > used. But how do I find out which version is been used? MSVC indicates that the Visual C++ compiler (or something compatible) is being used; which does not necessarily mean a Visual Studio generator. If you do need to make that distinction you can check MSVC_IDE [1] instead. > > The reason I want to find the the version of VS being used, is because > I need to link to the Boost libraries. Boost create its libraries with > suffixes like "-vs120-mt", etc. and "vs120" indicates Visual Studio 2013. Why aren't you using the Boost find module[2] included with CMake? It already accounts for Boost's library name mangling. The module uses e.g. the MSVC12 [3] variable to detect "vc120". But I am guessing CMAKE__COMPILER_VERSION [4] might work for this use case nowadays as well. Nils [1] https://cmake.org/cmake/help/v3.4/variable/MSVC_IDE.html [2] https://cmake.org/cmake/help/v3.4/module/FindBoost.html [3] https://cmake.org/cmake/help/v3.4/variable/MSVC12.html [4] https://cmake.org/cmake/help/v3.4/variable/CMAKE_LANG_COMPILER_VERSION.html From nazarmx at gmail.com Sun Dec 27 03:02:28 2015 From: nazarmx at gmail.com (Nazar Mishturak) Date: Sun, 27 Dec 2015 10:02:28 +0200 Subject: [CMake] How to check if CMake install script is being run by CPack? Message-ID: Hi, I am new here! I have a problem with my install(SCRIPT), it does fixup_bundle for all targets under ${CMAKE_INSTALL_PREFIX} and strip & upx all executables + .dlls under it. But I want to do upx and strip only when I am creating a package(make package, not make install). I have tried using: if(DEFINED CPACK_OUTPUT_CONFIG_FILE) if(DEFINED CPACK_PROJECT_CONFIG_FILE) if(DEFINED CPACK_GENERATOR) As far as I understand CPack just installs using CMake somewhere into package directory. But I don't know if its possible to use this. Should I check these variables in CMakeLists.txt and use configure_file to pass variables to the script? From mike.jackson at bluequartz.net Sun Dec 27 12:25:37 2015 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Sun, 27 Dec 2015 12:25:37 -0500 Subject: [CMake] still having rpath problems on osx In-Reply-To: References: <5a06fcc5-f638-4b8e-a64c-1334397e7317@email.android.com> Message-ID: <00DE5D72-AC5F-4198-A827-1A5DCEBDB309@bluequartz.net> > On Dec 24, 2015, at 2:24 AM, Boudewijn Rempt wrote: > > On Wed, 23 Dec 2015, Michael Jackson wrote: > >>> >>> Hm... Okay -- so, since I all my dependencies myself as cmake external projects, I guess I want all of them set to rpath. I guess that for boost, with its own build system, I'll need to add a separate fix-up step to my cmake externals project for boost. I have to check how I can fix the dependencies that are still automake/autoconf based. And I'll try what you suggest below for my own project. >> >> I have written scripts to do things like that for boost and ITK where the libraries do not have anything like @rpath or the absolute path to the installed library. After installing I run those scripts to ?fix? the libraries so when I debug I can just run the application. During packaging I then run CMake?s BundleUtilities to copy in the libraries and adjust the libraries to have @rpath or @executable_path. >> >> When fixing up a library make sure you also fix all the dependent libraries that might be there. For things like Boost or ITK their higher level libraries depend on their lower level libraries. Using ?otool -L? you can see this. Make sure you update EVERY path in the library. >> >> Also using MacDeployQt will NOT fix up any NON-Qt libraries (like Boost, HDF5.. ) so you will still need to run/write something that fixes all of those libraries. For our project we wrote a pure CMake script that does everything we need to fix up our bundles so that everything is self contained. > > Hm... And it all did work when my project was still Qt4-based and I built on Mavericks... And I've got about 300 libraries in the project, including plugins. Resetting the id of broken libraries and then rebuilding my project works. Are your scripts public so I can take a look and maybe reuse them? https://github.com/dream3d/DREAM3D/blob/develop/Support/cmp/OSX_Tools/CompleteBundle.cmake.in Note that the file is ?configured? during our make process but you should be able to figure out what we are doing. We also ensure ALL of our 3rd Party Libraries (except Qt) are built with absolute paths as their ?install_name? so that BundleUtilities can more easily find the libraries. With additional arguments BundleUtilities can find about any library you need. Mike Jackson > > -- > Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org-- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidshen84 at gmail.com Mon Dec 28 00:15:02 2015 From: davidshen84 at gmail.com (Xi Shen) Date: Mon, 28 Dec 2015 05:15:02 +0000 Subject: [CMake] How to get current visualstudio version? In-Reply-To: <567D3929.5050901@gmail.com> References: <567D3929.5050901@gmail.com> Message-ID: Yes, the official FindBoost works better xD On Fri, Dec 25, 2015 at 8:40 PM Nils Gladitz wrote: > On 25.12.2015 10:36, Xi Shen wrote: > > Hi, > > > > I know I can check MSVC to determine if the Visual Studio generator is > > used. But how do I find out which version is been used? > > MSVC indicates that the Visual C++ compiler (or something compatible) is > being used; which does not necessarily mean a Visual Studio generator. > If you do need to make that distinction you can check MSVC_IDE [1] instead. > > > > > The reason I want to find the the version of VS being used, is because > > I need to link to the Boost libraries. Boost create its libraries with > > suffixes like "-vs120-mt", etc. and "vs120" indicates Visual Studio 2013. > > Why aren't you using the Boost find module[2] included with CMake? It > already accounts for Boost's library name mangling. > > The module uses e.g. the MSVC12 [3] variable to detect "vc120". > But I am guessing CMAKE__COMPILER_VERSION [4] might work for this > use case nowadays as well. > > Nils > > [1] https://cmake.org/cmake/help/v3.4/variable/MSVC_IDE.html > [2] https://cmake.org/cmake/help/v3.4/module/FindBoost.html > [3] https://cmake.org/cmake/help/v3.4/variable/MSVC12.html > [4] > https://cmake.org/cmake/help/v3.4/variable/CMAKE_LANG_COMPILER_VERSION.html > -- Regards, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidshen84 at gmail.com Mon Dec 28 00:50:24 2015 From: davidshen84 at gmail.com (Xi Shen) Date: Mon, 28 Dec 2015 05:50:24 +0000 Subject: [CMake] How to get current visualstudio version? In-Reply-To: References: <567D3929.5050901@gmail.com> Message-ID: Strange, the FindBoost module expects boost libraries start with "boost_" by default. But the libraries I got from the default build configuration start with "libboost_". No wonder it did not work the first I tried. Thanks, David On Mon, Dec 28, 2015 at 1:15 PM Xi Shen wrote: > Yes, the official FindBoost works better xD > > > On Fri, Dec 25, 2015 at 8:40 PM Nils Gladitz > wrote: > >> On 25.12.2015 10:36, Xi Shen wrote: >> > Hi, >> > >> > I know I can check MSVC to determine if the Visual Studio generator is >> > used. But how do I find out which version is been used? >> >> MSVC indicates that the Visual C++ compiler (or something compatible) is >> being used; which does not necessarily mean a Visual Studio generator. >> If you do need to make that distinction you can check MSVC_IDE [1] >> instead. >> >> > >> > The reason I want to find the the version of VS being used, is because >> > I need to link to the Boost libraries. Boost create its libraries with >> > suffixes like "-vs120-mt", etc. and "vs120" indicates Visual Studio >> 2013. >> >> Why aren't you using the Boost find module[2] included with CMake? It >> already accounts for Boost's library name mangling. >> >> The module uses e.g. the MSVC12 [3] variable to detect "vc120". >> But I am guessing CMAKE__COMPILER_VERSION [4] might work for this >> use case nowadays as well. >> >> Nils >> >> [1] https://cmake.org/cmake/help/v3.4/variable/MSVC_IDE.html >> [2] https://cmake.org/cmake/help/v3.4/module/FindBoost.html >> [3] https://cmake.org/cmake/help/v3.4/variable/MSVC12.html >> [4] >> >> https://cmake.org/cmake/help/v3.4/variable/CMAKE_LANG_COMPILER_VERSION.html >> > -- > > Regards, > David > -- Regards, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From boud at valdyas.org Mon Dec 28 03:46:44 2015 From: boud at valdyas.org (Boudewijn Rempt) Date: Mon, 28 Dec 2015 09:46:44 +0100 (CET) Subject: [CMake] still having rpath problems on osxZ In-Reply-To: <00DE5D72-AC5F-4198-A827-1A5DCEBDB309@bluequartz.net> References: <5a06fcc5-f638-4b8e-a64c-1334397e7317@email.android.com> <00DE5D72-AC5F-4198-A827-1A5DCEBDB309@bluequartz.net> Message-ID: On Sun, 27 Dec 2015, Michael Jackson wrote: > https://github.com/dream3d/DREAM3D/blob/develop/Support/cmp/OSX_Tools/CompleteBundle.cmake.in > > Note that the file is ?configured? during our make process but you should be able to figure out what we are > doing. We also ensure ALL of our 3rd Party Libraries (except Qt) are built with absolute paths as their > ?install_name? so that BundleUtilities can more easily find the libraries. With additional arguments > BundleUtilities can find about any library you need. Thanks! -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org From nilsgladitz at gmail.com Mon Dec 28 06:07:48 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 28 Dec 2015 12:07:48 +0100 Subject: [CMake] How to get current visualstudio version? In-Reply-To: References: <567D3929.5050901@gmail.com> Message-ID: <56811804.7090300@gmail.com> On 28.12.2015 06:50, Xi Shen wrote: > Strange, the FindBoost module expects boost libraries start with > "boost_" by default. But the libraries I got from the default build > configuration start with "libboost_". No wonder it did not work the > first I tried. This somewhat depends on platform but as far as I remember e.g. on Windows the Boost static libraries begin with "lib". While the import libraries for the DLL version of the library do not. To locate the static libraries you would e.g. set(Boost_USE_STATIC_LIBS ON) before calling find_package() for Boost. Nils From davidshen84 at gmail.com Mon Dec 28 23:12:30 2015 From: davidshen84 at gmail.com (Xi Shen) Date: Tue, 29 Dec 2015 04:12:30 +0000 Subject: [CMake] How to get current visualstudio version? In-Reply-To: <56811804.7090300@gmail.com> References: <567D3929.5050901@gmail.com> <56811804.7090300@gmail.com> Message-ID: awesome! thanks~ On Mon, Dec 28, 2015 at 7:07 PM Nils Gladitz wrote: > On 28.12.2015 06:50, Xi Shen wrote: > > Strange, the FindBoost module expects boost libraries start with > > "boost_" by default. But the libraries I got from the default build > > configuration start with "libboost_". No wonder it did not work the > > first I tried. > > This somewhat depends on platform but as far as I remember e.g. on > Windows the Boost static libraries begin with "lib". > While the import libraries for the DLL version of the library do not. > > To locate the static libraries you would e.g. set(Boost_USE_STATIC_LIBS > ON) before calling find_package() for Boost. > > Nils > -- Regards, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From mauro.ziliani.tmp at gmail.com Tue Dec 29 03:53:14 2015 From: mauro.ziliani.tmp at gmail.com (Mauro Ziliani) Date: Tue, 29 Dec 2015 09:53:14 +0100 Subject: [CMake] How to include config.h.in in VS project Message-ID: Hi all. I'm using CMake 3.4.1 for my projects. I'm working with Visual studio 10 2010 express and wxFormBuilder I'd like to include config.h.in and the wxFormBuilder projects (which has .fbp extension) in source_group. In CMakeLists.txt i put ... source_group("FormBiulder FBP" FILES main.fbp) source_group("Config IN" FILES config.h.in) But when I generate the final solution for visual studio the tree project has not the group I define. It seems the problem is the extestion .fbp or .in. that Cmake ignores How can I include .in e .fbp extensions has wel-known extension to put in the vcxproject list? Best regards, Mauro -------------- next part -------------- An HTML attachment was scrubbed... URL: From mauro.ziliani.tmp at gmail.com Tue Dec 29 04:34:09 2015 From: mauro.ziliani.tmp at gmail.com (Mauro Ziliani) Date: Tue, 29 Dec 2015 10:34:09 +0100 Subject: [CMake] BitDefender and cmakecompilerid.exe ot cmakecxxcompilerid.exe Message-ID: Hi all. BitDefender puts the files cmakecompilerid.exe and cmakecxxcompilerid.exe in quarantena. It find Gen:Variant.Midie.5130 It's a fake or is it true? Mauro -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Tue Dec 29 04:40:29 2015 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 29 Dec 2015 10:40:29 +0100 Subject: [CMake] BitDefender and cmakecompilerid.exe ot cmakecxxcompilerid.exe In-Reply-To: References: Message-ID: <1531504.lVax2GubBM@caliban.sf-tec.de> Am Dienstag, 29. Dezember 2015, 10:34:09 schrieb Mauro Ziliani: > Hi all. > BitDefender puts the files cmakecompilerid.exe and cmakecxxcompilerid.exe > in quarantena. > > It find Gen:Variant.Midie.5130 > > It's a fake or is it true? Look at the source code, what do you think? Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From DLRdave at aol.com Tue Dec 29 08:52:01 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 29 Dec 2015 08:52:01 -0500 Subject: [CMake] BitDefender and cmakecompilerid.exe ot cmakecxxcompilerid.exe In-Reply-To: References: Message-ID: If BitDefender is quarantining those files, I would suspect the compiler you are using has somehow become virus-infected... What does BitDefender say if you ask it to analyze your compiler *.exe? Maybe you should run a full scan of all the drives you are using here... HTH, David > On Dec 29, 2015, at 4:34 AM, Mauro Ziliani wrote: > > Hi all. > BitDefender puts the files cmakecompilerid.exe and cmakecxxcompilerid.exe in quarantena. > > It find Gen:Variant.Midie.5130 > > It's a fake or is it true? > > Mauro > -- > > 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 From scott at towel42.com Tue Dec 29 12:25:16 2015 From: scott at towel42.com (Scott Aron Bloom) Date: Tue, 29 Dec 2015 17:25:16 +0000 Subject: [CMake] BitDefender and cmakecompilerid.exe ot cmakecxxcompilerid.exe In-Reply-To: References: Message-ID: While a possibility, not necessarily.. I would white list your projects directory. Scott -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of David Cole via CMake Sent: Tuesday, December 29, 2015 5:52 AM To: Mauro Ziliani Cc: cmake at cmake.org Subject: Re: [CMake] BitDefender and cmakecompilerid.exe ot cmakecxxcompilerid.exe If BitDefender is quarantining those files, I would suspect the compiler you are using has somehow become virus-infected... What does BitDefender say if you ask it to analyze your compiler *.exe? Maybe you should run a full scan of all the drives you are using here... HTH, David > On Dec 29, 2015, at 4:34 AM, Mauro Ziliani wrote: > > Hi all. > BitDefender puts the files cmakecompilerid.exe and cmakecxxcompilerid.exe in quarantena. > > It find Gen:Variant.Midie.5130 > > It's a fake or is it true? > > Mauro > -- > > 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 From yannsuisini at gmail.com Wed Dec 30 05:29:13 2015 From: yannsuisini at gmail.com (yann suisini) Date: Wed, 30 Dec 2015 11:29:13 +0100 Subject: [CMake] Get target name from command line for IF statement Message-ID: Hi, I have a cmake file with 2 targets defined inside. For each target I have to specify a different scatter file for my linker so I want to use : if (TARGET target_1) SET (LINKER_SCATTER_FILE file_1) else () SET (LINKER_SCATTER_FILE file_2) endif () add_executable(target_1 ${srcs_target_1}) add_executable(target_2 ${srcs_target_2}) But if I'm calling cmake from my IDE to build my target using the --target command line option does it set the TARGET variable ? If not the case how I can link the targer name from the command line to my IF statement ? Regards, Yann. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Wed Dec 30 11:04:22 2015 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 30 Dec 2015 11:04:22 -0500 Subject: [CMake] Is there a way to disable adding extra libraries at the end of a link line? In-Reply-To: <56743073.7000101@txcorp.com> References: <56743073.7000101@txcorp.com> Message-ID: Hi John, Can you try using the new Cray platform file? It should better handle the implicit libs and dirs used by the compiler wrappers if you have the appropriate modules loaded (cray-hdf5 for HDF5 libs, craype-sandybridge or whatever your compute node CPU is for the -msse2 flag, etc.): cmake -DCMAKE_SYSTEM_NAME=CrayLinuxEnvironment /path/to/source It's not available in a release yet so you'll need to build cmake from the git master branch to try it. Just be sure to build cmake using the system compilers, i.e. /usr/bin/gcc and /usr/bin/g++ on the login node and not the Cray PrgEnv compiler wrappers. - Chuck On Fri, Dec 18, 2015 at 11:12 AM, JR Cary wrote: > Working on a just delivered Cray I am again challenged by the way that > CMake adds libraries to the end of the link line that I did not specify. > > The Cray requires use of the compiler wrappers. After adding the > appropriate libraries (hdf5, z) to my target, the link line is > > /opt/cray/craype/2.4.2/bin/CC -DMPICH_IGNORE_CXX_SEEK -std=c++11 -O3 > -DNDEBUG -msse2 CMakeFiles/io.dir/io.cxx.o -o io > -L/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib ../libtxio.a > ../../txstreams/libtxstreams.a > /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a -Wl,-Bstatic -lz > -Wl,-Bdynamic /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a > -Wl,-Bstatic -lz -Wl,-Bdynamic > -Wl,-rpath,/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib > > and the link fails with > > ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in > `/usr/lib/../lib64/libc.a(strcmp.o)' can not be used when making an > executable; recompile with -fPIE and relink with -pie > > Now I believe that Cray has the appropriate libraries in its compiler > wrapper, because > if I just link without all the additions: > > /opt/cray/craype/2.4.2/bin/CC -DMPICH_IGNORE_CXX_SEEK -std=c++11 -O3 > -DNDEBUG -msse2 CMakeFiles/io.dir/io.cxx.o -o io > -L/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib ../libtxio.a > ../../txstreams/libtxstreams.a > /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a -lz > > it all just works. > > Is there a way to tell cmake not to append > "-Wl,-Bdynamic /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a > -Wl,-Bstatic -lz -Wl,-Bdynamic > -Wl,-rpath,/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib" > to the link line and not to insert -Wl,-Bstatic in front of -lz > ? > > Thx....John Cary > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Wed Dec 30 11:22:18 2015 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 30 Dec 2015 11:22:18 -0500 Subject: [CMake] Is there a way to disable adding extra libraries at the end of a link line? In-Reply-To: <56743073.7000101@txcorp.com> References: <56743073.7000101@txcorp.com> Message-ID: The error itself I believe is a side effect of CMake trying to operate assuming it's using normal Linux, which makes some assumptions regarding shared runtime libraries for libc, position independent code, etc. The default behaviour of the Cray compiler wrappers, however, is to create fully static executables, which CMake has a bit of difficulty with using the defaault Linux platform. This behaviour of the wrappers can be changed by setting the env var CRAYPE_LINK_TYPE=dynamic, but really the right way is to use the CrayLinuxEnvironment platform file which puts CMake into cross-compiling mode for the Cray-specific link environment instead of generic Linux and tests for static, shared, implicit link and include dirs, implicit libraries, etc. - Chuck On Fri, Dec 18, 2015 at 11:12 AM, JR Cary wrote: > Working on a just delivered Cray I am again challenged by the way that > CMake adds libraries to the end of the link line that I did not specify. > > The Cray requires use of the compiler wrappers. After adding the > appropriate libraries (hdf5, z) to my target, the link line is > > /opt/cray/craype/2.4.2/bin/CC -DMPICH_IGNORE_CXX_SEEK -std=c++11 -O3 > -DNDEBUG -msse2 CMakeFiles/io.dir/io.cxx.o -o io > -L/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib ../libtxio.a > ../../txstreams/libtxstreams.a > /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a -Wl,-Bstatic -lz > -Wl,-Bdynamic /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a > -Wl,-Bstatic -lz -Wl,-Bdynamic > -Wl,-rpath,/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib > > and the link fails with > > ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in > `/usr/lib/../lib64/libc.a(strcmp.o)' can not be used when making an > executable; recompile with -fPIE and relink with -pie > > Now I believe that Cray has the appropriate libraries in its compiler > wrapper, because > if I just link without all the additions: > > /opt/cray/craype/2.4.2/bin/CC -DMPICH_IGNORE_CXX_SEEK -std=c++11 -O3 > -DNDEBUG -msse2 CMakeFiles/io.dir/io.cxx.o -o io > -L/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib ../libtxio.a > ../../txstreams/libtxstreams.a > /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a -lz > > it all just works. > > Is there a way to tell cmake not to append > "-Wl,-Bdynamic /opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib/libhdf5.a > -Wl,-Bstatic -lz -Wl,-Bdynamic > -Wl,-rpath,/opt/cray/hdf5-parallel/1.8.14/INTEL/14.0/lib" > to the link line and not to insert -Wl,-Bstatic in front of -lz > ? > > Thx....John Cary > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjklaim at gmail.com Wed Dec 30 14:52:42 2015 From: mjklaim at gmail.com (=?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?=) Date: Wed, 30 Dec 2015 20:52:42 +0100 Subject: [CMake] Cannot set FOLDER property to an interface (header-only) target Message-ID: The following CMake script: cmake_minimum_required(VERSION 3.4) add_library( mylib INTERFACE ) set_property( TARGET mylib PROPERTY FOLDER /some/dir ) Will trigger this error on configuration: CMake Error at CMakeLists.txt:4 (set_property): INTERFACE_LIBRARY targets may only have whitelisted properties. The property "FOLDER" is not allowed. This prevent any interface library to be organized in Visual Studio virtual folders. Unfortunately it also mean that header-only targets can't be organized. I have no idea how this should be solved. Should the property just be white-listed? Or should a better have a another specific library mode for header-only targets? Is there any workaround? Jo?l Lamotte -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.kuhl at windriver.com Wed Dec 30 15:38:02 2015 From: brian.kuhl at windriver.com (Kuhl, Brian) Date: Wed, 30 Dec 2015 20:38:02 +0000 Subject: [CMake] Add support for cross compiling to VxWorks Message-ID: <6C486AB80682E24095E3E77A408D68F2F60DB12B@ALA-MBA.corp.ad.wrs.com> Hi CMake Experts, I'm trying to add support for VxWorks to CMake. My current dilemma is that the Compiler ID link test is failing because my library link path isn't being used, and libraries aren't being found. I've set the library path in all the obvious places ( or so I thought,) what setting am I missing? Why isn't CMAKE_C_LINK_FLAGS being used? My end goal is to compile Eigen and OpenCV Best of the season, and thanks, Brian Kuhl Manager, Technical Content Engineering Wind River ----------------------------------------build log------------------------------------------ building EIGEN: eigen cd C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/src/EIGEN/eigen-eigen-b30b87236a1b && C:/git/vx7-ux-ports/vxworks-7/host/binutils/x86-win32/bin/make -f vxworks.lib.mak CPU=SIMNT TOOL=gnu TOOL_VERSION=gnu_4_8_1 _CC_VERSION=gnu_4_8_1_5 _WRS_CONFIG_ENDIAN=little _WRS_CONFIG_FP=hard VSB_DIR=C:/git/vx7-ux-ports/workbench-4/workspace/VSB64 ROOT_DIR=C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/root VXE=eigen _mk make[3]: Entering directory 'C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/src/EIGEN/eigen-eigen-b30b87236a1b' C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/CMake/bin/cmake -DCMAKE_TOOLCHAIN_FILE=vxworks-env.cmake -- The C compiler identification is GNU 4.8.1 -- The CXX compiler identification is GNU 4.8.1 -- Check for working C compiler: C:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/ccpentium.exe CMake Error: Generator: execution of make failed. Make command was: "nmake" "/NOLOGO" "cmTC_2d1fb\fast" -- Check for working C compiler: C:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/ccpentium.exe -- broken CMake Error at C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/CMake/share/cmake-3.4/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "C:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/ccpentium.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/src/EIGEN/eigen-eigen-b30b87236a1b/CMakeFiles/CMakeTmp Run Build Command:"nmake" "/NOLOGO" "cmTC_2d1fb\fast" The system cannot find the file specified Generator: execution of make failed. Make command was: "nmake" "/NOLOGO" "cmTC_2d1fb\fast" CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:1 (project) -- Configuring incomplete, errors occurred! See also "C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/src/EIGEN/eigen-eigen-b30b87236a1b/CMakeFiles/CMakeOutput.log". See also "C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/src/EIGEN/eigen-eigen-b30b87236a1b/CMakeFiles/CMakeError.log". vxworks.lib.mak:26: recipe for target 'cmake_build' failed ----------------------------- a generated vxworks-env.cmake -------------------------- SET(CMAKE_SYSTEM_NAME VxWorks) SET(CMAKE_SYSTEM_VERSION 7 ) SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) SET(CMAKE_C_COMPILER C:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/ccpentium.exe ) SET(CMAKE_CXX_COMPILER C:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/c++pentium.exe ) SET(CMAKE_C_FLAGS -m64 -mcmodel=large -mno-red-zone -fno-implicit-fp -fno-builtin -fno-omit-frame-pointer -mrtp -fno-strict-aliasing -D_C99 -D_HAS_C9X -std=c99 -fasm -O2 -fno-defer-pop -Wall -IC:/git/vx7-ux-ports/vxworks-7/pkgs/os/utils/unix/friend_h/ -D_WRS_CONFIG_VSB_USR_H=C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h -D_VX_CPU=_VX_SIMNT -D_VX_TOOL_FAMILY=gnu -D_VX_TOOL=gnu -D_WRS_CONFIG_DEPENDS_LAYER_CMAKE -D_WRS_CONFIG_DEPENDS_LAYER_UNIX -D_nq_VSB_CONFIG_FILE=C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/h/config/vsbConfig.h -save-temps -IC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/share/h -isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h -isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h/system -isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h/public -I. -includeC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/src/EIGEN/eigen-eigen-b30b87236a1b/autoconf_vsbConfig_quote.h ) SET(CMAKE_CXX_FLAGS -m64 -mcmodel=large -mno-red-zone -fno-implicit-fp -fno-builtin -fno-omit-frame-pointer -ansi -mrtp -fno-strict-aliasing -D_C99 -D_HAS_C9X -std=c++11 -isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h/public/c++11 -O2 -fno-defer-pop -Wall -IC:/git/vx7-ux-ports/vxworks-7/pkgs/os/utils/unix/friend_h/ -D_WRS_CONFIG_VSB_USR_H=C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h -D_VX_CPU=_VX_SIMNT -D_VX_TOOL_FAMILY=gnu -D_VX_TOOL=gnu -D_WRS_CONFIG_DEPENDS_LAYER_CMAKE -D_WRS_CONFIG_DEPENDS_LAYER_UNIX -D_nq_VSB_CONFIG_FILE=C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/h/config/vsbConfig.h -save-temps -IC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/share/h -isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h -isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h/system -isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h/public -includeC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/src/EIGEN/eigen-eigen-b30b87236a1b/autoconf_vsbConfig_quote.h ) SET(CMAKE_C_LINK_FLAGS -Wl,--defsym,__wrs_rtp_base=0x200000000 -mrtp -Wl,--defsym,_GLOBAL_OFFSET_TABLE_=0 -Wl,-T,C:/git/vx7-ux-ports/vxworks-7/build/tool/gnu_4_8_1/usr/ldscript.exe.lp64.SIMCOMMON -LC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/lib/common/ ) SET(CMAKE_FIND_ROOT_PATH C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/root ) SET(LIBS -lunix -lsupc++ -lstdc++11 ) set(CMAKE_SYSTEM_INCLUDE_PATH C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h/public C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h ) set(CMAKE_SYSTEM_LIBRARY_PATH C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/libcommon ) set(CMAKE_SYSTEM_PROGRAM_PATH C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/root/gnu/bin ) -------------------------------cmake-3.4/Modules/Platform/VxWorks.cmake--------------------------- # Indicate that this is a cross compiled unix-like system # set(UNIX 1) set(CMAKE_CROSSCOMPILING TRUE) # # Library prefixes, suffixes, extra libs. # set(CMAKE_LINK_LIBRARY_SUFFIX "") set(CMAKE_STATIC_LIBRARY_PREFIX "lib") # lib set(CMAKE_STATIC_LIBRARY_SUFFIX ".a") # .a set(CMAKE_SHARED_LIBRARY_PREFIX "lib") # lib set(CMAKE_SHARED_LIBRARY_SUFFIX ".so") # .so set(CMAKE_EXECUTABLE_SUFFIX ".vxe") # .vxe #set(CMAKE_DL_LIBS "dl") #set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS TRUE) set(CMAKE_FIND_LIBRARY_PREFIXES "lib") #ignor build host paths set(CMAKE_SYSTEM_IGNORE_PATH /lib /lib64 /include /usr/lib /usr/lib64 /usr/include /usr/local/lib /usr/local/lib64 /usr/local/include /usr/X11/lib /usr/X11/lib64 /usr/X11/include /usr/lib/X11 /usr/lib64/X11 /usr/include/X11 /usr/X11R6/lib /usr/X11R6/lib64 /usr/X11R6/include /usr/X11R7/lib /usr/X11R7/lib64 /usr/X11R7/include ) # generally use C++ compiler as linker set(CMAKE_C_LINK_EXECUTABLE " -o " ) set(CMAKE_CXX_LINK_EXECUTABLE " -o " ) ----------------------------------- eigen-eigen-b30b87236a1b\CMakeFiles\CMakeError.log ------------------------------------- Compiling the C compiler identification source file "CMakeCCompilerId.c" failed. Compiler: C:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/ccpentium.exe Build flags: -m64;-mcmodel=large;-mno-red-zone;-fno-implicit-fp;-fno-builtin;-fno-omit-frame-pointer;-mrtp;-fno-strict-aliasing;-D_C99;-D_HAS_C9X;-std=c99;-fasm;-O2;-fno-defer-pop;-Wall;-IC:/git/vx7-ux-ports/vxworks-7/pkgs/os/utils/unix/friend_h/;-D_WRS_CONFIG_VSB_USR_H=C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h;-D_VX_CPU=_VX_SIMNT;-D_VX_TOOL_FAMILY=gnu;-D_VX_TOOL=gnu;-D_WRS_CONFIG_DEPENDS_LAYER_CMAKE;-D_WRS_CONFIG_DEPENDS_LAYER_UNIX;-D_nq_VSB_CONFIG_FILE=C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/h/config/vsbConfig.h;-save-temps;-IC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/share/h;-isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h;-isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h/system;-isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h/public;-I.;-includeC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/src/EIGEN/eigen-eigen-b30b87236a1b/autoconf_vsbConfig_quote.h Id flags: The output was: 1 c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find crt0.o c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find -lc_internal c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find -lc c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find -lc_internal c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find -lnet c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find -ldsi c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find -lsyscall collect2.exe: error: ld returned 1 exit status The C compiler identification could not be found in "C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/src/EIGEN/eigen-eigen-b30b87236a1b/CMakeFiles/3.4.0/CompilerIdC/CMakeCCompilerId.i" Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed. Compiler: C:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/c++pentium.exe Build flags: -m64;-mcmodel=large;-mno-red-zone;-fno-implicit-fp;-fno-builtin;-fno-omit-frame-pointer;-ansi;-mrtp;-fno-strict-aliasing;-D_C99;-D_HAS_C9X;-std=c++11;-isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h/public/c++11;-O2;-fno-defer-pop;-Wall;-IC:/git/vx7-ux-ports/vxworks-7/pkgs/os/utils/unix/friend_h/;-D_WRS_CONFIG_VSB_USR_H=C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h;-D_VX_CPU=_VX_SIMNT;-D_VX_TOOL_FAMILY=gnu;-D_VX_TOOL=gnu;-D_WRS_CONFIG_DEPENDS_LAYER_CMAKE;-D_WRS_CONFIG_DEPENDS_LAYER_UNIX;-D_nq_VSB_CONFIG_FILE=C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/h/config/vsbConfig.h;-save-temps;-IC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/share/h;-isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h;-isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h/system;-isystemC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/h/public;-includeC:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/src/EIGEN/eigen-eigen-b30b87236a1b/autoconf_vsbConfig_quote.h Id flags: The output was: 1 c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find crt0.o c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find -lc_internal c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find -lc c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find -lc_internal c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find -lnet c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find -ldsi c:/git/vx7-ux-ports/compilers/gnu-4.8.1.5/x86-win32/bin/../../lib/gcc/i586-wrs-vxworks/4.8.1/../../../../x86-win32/i586-wrs-vxworks/bin/ld.exe: cannot find -lsyscall collect2.exe: error: ld returned 1 exit status The CXX compiler identification could not be found in "C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/src/EIGEN/eigen-eigen-b30b87236a1b/CMakeFiles/3.4.0/CompilerIdCXX/CMakeCXXCompilerId.ii" Determining if the C compiler works failed with the following output: Change Dir: C:/git/vx7-ux-ports/workbench-4/workspace/VSB64/usr/src/EIGEN/eigen-eigen-b30b87236a1b/CMakeFiles/CMakeTmp Run Build Command:"nmake" "/NOLOGO" "cmTC_2d1fb\fast" The system cannot find the file specified Generator: execution of make failed. Make command was: "nmake" "/NOLOGO" "cmTC_2d1fb\fast" From burlen.loring at gmail.com Wed Dec 30 21:21:46 2015 From: burlen.loring at gmail.com (Burlen Loring) Date: Wed, 30 Dec 2015 18:21:46 -0800 Subject: [CMake] PythonInterp and PythonLibs find different versions on Apple In-Reply-To: <567AD1BD.7030109@gmail.com> References: <567AD1BD.7030109@gmail.com> Message-ID: <5684913A.9020806@gmail.com> After digging though a number of closed bug reports I found an open issue in mantis that describes the problem exactly and has a number of proposed solution. I took one of them(c39236) and this seems to do the trick. https://cmake.org/Bug/view.php?id=14809 On 12/23/2015 08:54 AM, Burlen Loring wrote: > Hi, > > I'm having this issue that cmake using version 3.3.0. Python detection > is finding different versions of interpreter and libraries. There are > two version of Python installed, system one and homebrew one. cmake > finds Interpreter from homebrew while libs are from system install. > > Here's my CmakeLists > > find_package(PythonInterp) > find_package(PythonLibs) > > and configure output > > -- Found PythonInterp: /usr/local/bin/python (found version "2.7.11") > -- Found PythonLibs: /usr/lib/libpython2.7.dylib (found version > "2.7.10") > > I also tried > > find_package(PythonInterp) > find_package(PythonLibs ${PYTHON_VERSION_STRING}) > > but got > > -- Found PythonInterp: /usr/local/bin/python (found version "2.7.11") > -- Could NOT find PythonLibs: Found unsuitable version "2.7.10", > but required is at least "2.7.11" (found /usr/lib/libpython2.7.dylib) > > I suppose I can just over ride these manually, but shouldn't this just > work? or am I doing it wrong? > > Burlen > > ps. > > I tried to install cmake 3.4 on my system but bootstrap has a compile > error. > > I observed the same with cmake 3.4.1 on a colleagues Apple system that > has system Python plus Annaconda Python. This leads me to think that > it's not addressed in 3.4.1. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From boud at valdyas.org Thu Dec 31 03:41:00 2015 From: boud at valdyas.org (Boudewijn Rempt) Date: Thu, 31 Dec 2015 09:41:00 +0100 (CET) Subject: [CMake] still having rpath problems on osxZ In-Reply-To: References: <5a06fcc5-f638-4b8e-a64c-1334397e7317@email.android.com> <00DE5D72-AC5F-4198-A827-1A5DCEBDB309@bluequartz.net> Message-ID: I think I've finally figured out why I didn't get the results the cmake documentation suggested I should be getting... It's the extra-cmake-modules that I use, Krita being a KDE application. With these settings: set(KDE_SKIP_RPATH_SETTINGS 1) set(CMAKE_MACOSX_RPATH 1) set(BUILD_WITH_INSTALL_RPATH 1) My libraries are built with an @rpath id, instead of an absolute path id. Now only the executable needs to have its rpath set correctly after install and after making a bundle, and all libraries are found and all plugins find the libraries, too. Without KDE_SKIP_RPATH_SETTINGS, everything gets set to full, absolute paths on doing a make install. That might make sense on Linux, I guess... But no wonder that I was confused all the time. So, to check that I really understand it: On OSX, every library has an id. That id can be /abs/o/lute/path/to/library.dylib or library.dylib or @rpath/library.dylib. The exectutable has a bunch of paths where it can look for libraries, and the path + library.dylib has to match the library id. so, if the executable has @path = ../lib;../Frameworks and links to @path/library.dylib and a library with that id is in ../lib (or ../Frameworks) from the executable's location, everything will be fine. Which makes it easiest for me, I guess to have @rpath in the id for every library, and on make install set the exectables' rpath to where I install the libraries to, and on creating the bundle update the rpaths in the executable to the Frameworks folder. The only thing that won't work is running unittests without installing, but that's not a big problem, for me... -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org From boud at valdyas.org Thu Dec 31 03:46:15 2015 From: boud at valdyas.org (Boudewijn Rempt) Date: Thu, 31 Dec 2015 09:46:15 +0100 (CET) Subject: [CMake] still having rpath problems on osxZ In-Reply-To: References: <5a06fcc5-f638-4b8e-a64c-1334397e7317@email.android.com> <00DE5D72-AC5F-4198-A827-1A5DCEBDB309@bluequartz.net> Message-ID: Oh, and for reference, it's this code block: ################# RPATH handling ################################## if(NOT KDE_SKIP_RPATH_SETTINGS) # Set the default RPATH to point to useful locations, namely where the # libraries will be installed and the linker search path if(NOT LIB_INSTALL_DIR) message(FATAL_ERROR "LIB_INSTALL_DIR not set. This is necessary for using the RPATH settings.") endif() set(_abs_LIB_INSTALL_DIR "${LIB_INSTALL_DIR}") if (NOT IS_ABSOLUTE "${_abs_LIB_INSTALL_DIR}") set(_abs_LIB_INSTALL_DIR "${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR}") endif() if (UNIX) # for mac os: add install name dir in addition # check: is the rpath stuff below really required on mac os? at least it seems so to use a stock qt from qt.io if (APPLE) set(CMAKE_INSTALL_NAME_DIR ${_abs_LIB_INSTALL_DIR}) endif () # add our LIB_INSTALL_DIR to the RPATH (but only when it is not one of # the standard system link directories - such as /usr/lib on UNIX) list(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES "${_abs_LIB_INSTALL_DIR}" _isSystemLibDir) list(FIND CMAKE_CXX_IMPLICIT_LINK_DIRECTORIES "${_abs_LIB_INSTALL_DIR}" _isSystemCxxLibDir) list(FIND CMAKE_C_IMPLICIT_LINK_DIRECTORIES "${_abs_LIB_INSTALL_DIR}" _isSystemCLibDir) if("${_isSystemLibDir}" STREQUAL "-1" AND "${_isSystemCxxLibDir}" STREQUAL "-1" AND "${_isSystemCLibDir}" STREQUAL "-1") set(CMAKE_INSTALL_RPATH "${_abs_LIB_INSTALL_DIR}") endif() # Append directories in the linker search path (but outside the project) set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) endif (UNIX) endif() -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org From DLRdave at aol.com Thu Dec 31 08:19:49 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 31 Dec 2015 08:19:49 -0500 Subject: [CMake] Cannot set FOLDER property to an interface (header-only) target In-Reply-To: References: Message-ID: I can't think of a reason why we would not whitelist the FOLDER property... Unless somebody else chimes in with one, perhaps you could submit a proposed patch to whitelist it? D On Wednesday, December 30, 2015, Klaim - Jo?l Lamotte wrote: > The following CMake script: > > cmake_minimum_required(VERSION 3.4) > > add_library( mylib INTERFACE ) > set_property( TARGET mylib PROPERTY FOLDER /some/dir ) > > > Will trigger this error on configuration: > > CMake Error at CMakeLists.txt:4 (set_property): > INTERFACE_LIBRARY targets may only have whitelisted properties. The > property "FOLDER" is not allowed. > > > This prevent any interface library to be organized in Visual Studio > virtual folders. > Unfortunately it also mean that header-only targets can't be organized. > > I have no idea how this should be solved. Should the property just be > white-listed? > Or should a better have a another specific library mode for header-only > targets? > > Is there any workaround? > > Jo?l Lamotte > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Thu Dec 31 11:19:06 2015 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 31 Dec 2015 17:19:06 +0100 Subject: [CMake] Cannot set FOLDER property to an interface (header-only) target In-Reply-To: References: Message-ID: <5685557A.1090600@gmail.com> On 31.12.2015 14:19, David Cole via CMake wrote: > I can't think of a reason why we would not whitelist the FOLDER > property... Unless somebody else chimes in with one, perhaps you could > submit a proposed patch to whitelist it? As far as I remember INTERFACE libraries don't generate visual studio projects. Without generated projects there is nothing to be organized by the FOLDER property. Nils From roman.wueger at gmx.at Thu Dec 31 12:53:40 2015 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Thu, 31 Dec 2015 18:53:40 +0100 Subject: [CMake] How to include config.h.in in VS project In-Reply-To: References: Message-ID: <55AEEA6E-C956-412B-B999-032A33056385@gmx.at> Hi, You must add those sources to add_executable/add_library as well. Wish you a happy new year. Best regards Roman > Am 29.12.2015 um 09:53 schrieb Mauro Ziliani : > > Hi all. > I'm using CMake 3.4.1 for my projects. > I'm working with Visual studio 10 2010 express and wxFormBuilder > I'd like to include config.h.in and the wxFormBuilder projects (which has .fbp extension) in source_group. > > In CMakeLists.txt i put > > ... > > source_group("FormBiulder FBP" FILES main.fbp) > source_group("Config IN" FILES config.h.in) > > But when I generate the final solution for visual studio the tree project has not the group I define. > > It seems the problem is the extestion .fbp or .in. that Cmake ignores > > How can I include .in e .fbp extensions has wel-known extension to put in the vcxproject list? > > Best regards, > Mauro > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at elemtech.com Thu Dec 31 15:06:48 2015 From: clinton at elemtech.com (clinton at elemtech.com) Date: Thu, 31 Dec 2015 13:06:48 -0700 (MST) Subject: [CMake] still having rpath problems on osxZ In-Reply-To: References: <5a06fcc5-f638-4b8e-a64c-1334397e7317@email.android.com> <00DE5D72-AC5F-4198-A827-1A5DCEBDB309@bluequartz.net> Message-ID: <1046855986.89964320.1451592408831.JavaMail.zimbra@elemtech.com> ----- On Dec 31, 2015, at 1:41 AM, Boudewijn Rempt boud at valdyas.org wrote: > I think I've finally figured out why I didn't get the results the cmake > documentation suggested I should be getting... It's the extra-cmake-modules > that I use, Krita being a KDE application. With these settings: > > set(KDE_SKIP_RPATH_SETTINGS 1) > set(CMAKE_MACOSX_RPATH 1) > set(BUILD_WITH_INSTALL_RPATH 1) > > My libraries are built with an @rpath id, instead of an absolute path id. Now > only the executable needs to have its rpath set correctly after install and > after making a bundle, and all libraries are found and all plugins find the > libraries, too. > > Without KDE_SKIP_RPATH_SETTINGS, everything gets set to full, absolute paths on > doing a make install. That might make sense on Linux, I guess... But no wonder > that I was confused all the time. > > So, to check that I really understand it: > > On OSX, every library has an id. That id can be > /abs/o/lute/path/to/library.dylib or library.dylib or @rpath/library.dylib. Yes, there is an id. @executable_path and @loader_path are a couple other that can used in addition to the list you provided. > > The exectutable has a bunch of paths where it can look for libraries, and the > path + library.dylib has to match the library id. I'm not sure what you mean by that. The library id is used only at link time, and not at runtime. There is no matching to the library id at runtime. At link time, the id is taken as-is and put into the executable as a dependency. If you are familiar with SONAME on ELF platforms, think of the id in a dylib being similar. > > so, if the executable has > > @path = ../lib;../Frameworks > > and links to > > @path/library.dylib > > and a library with that id is in ../lib (or ../Frameworks) from the executable's > location, everything will be fine. I think you have the idea there. But just in case, let me enumerate how the runtime loader looks at these: 1. an exectuable with a /absolute/path/to/library.dylib dependency The library is searched for at the absolute path. If not found, library.dylib is searched in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. 2. an executable with a library.dylib dependency library.dylib is searched in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. 3. a binary with a @executable_path/library.dylib dependency The library is located in the same directory as the executable If the binary is another shared library, whether in another directory or not, library.dylib will be searched for in the same directory as the executable. If not found, a search is made in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. both exectuables and libraries can have @executable_path 3. a binary with @loader_path/library.dylib dependency the library is located in the same directory as the binary (may be the same directory as the executable or not). If not found, a search is made in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. 4. a binary with @rpath/library.dylib dependency the binary can also have a list of rpaths embedded. Each rpath is used to replace the "@rpath" portion of the dependency to locate the dependency. For flexibility, rpaths may contain absolute paths, @executable_path or @loader_path. For example, a binary can have an rpath @loader_path/../lib, and a dependency @rpath/library.dylib. After substitution, you have: @loader_path/../lib/library.dylib. With that, go see how @loader_path is handled. If not found, a search is made in /usr/local/lib:/lib:/usr/lib environment variables such as DYLD_LIBRARY_PATH can override search locations. > > Which makes it easiest for me, I guess to have @rpath in the id for every > library, and on make install set the exectables' rpath to where I install the > libraries to, and on creating the bundle update the rpaths in the executable to > the Frameworks folder. The only thing that won't work is running unittests > without installing, but that's not a big problem, for me... > I also find @rpath easiest for me. I make sure all my 3rd party non-system dependencies use @rpath. In my case, these libraries are built once and shared among multiple developers. Using @rpath also allows multiple developers to place these libraries in their own home directories, and CMake's automatic rpath handling helps simplify things. Then when I build my bundles or create packages, I don't need to do any "install_name_tool -change" work. I do set the rpaths on exectuables during install, which is nearly identical to what I do on Linux. I'm curious why the unit tests do not work. Mine work just fine for me. If you have a setting to skip rpaths in the build tree, I guess that would prevent them from working. Clint