Re: [CMake] Copying shared libraries in a post-build step

> > > I'm now calling it out as a design problem in > CMake, especially as the winds have shifted to more platforms focusing > on shipping binaries than the former and now treat packaging as a > first class citizen. It is an impediment to the natural workflow on > those platforms, it is an impedime

Re: [CMake] Copying shared libraries in a post-build step

>> Your scripts would still only work for one target... since you'd have to > pick one to build the rest of the package around, so if I have a build > product that has a dozen utilities, rather than having one place they can > all work from, I have now to either duplicate all files to all runnable

Re: [CMake] Copying shared libraries in a post-build step

On Tue, Dec 9, 2014 at 4:58 PM, Eric Wing wrote: > On 12/9/14, J Decker wrote: > > This is all handled by install. > > I already addressed INSTALL. I know you can change the directory. That > is irrelevant to the point which I already addressed. > > You gave a personal opinion about install... n

Re: [CMake] Copying shared libraries in a post-build step

On 12/9/14, J Decker wrote: > This is all handled by install. I already addressed INSTALL. I know you can change the directory. That is irrelevant to the point which I already addressed. > > Sounds really like you're working to build a package, which install is > intended to do. Another proble

Re: [CMake] Copying shared libraries in a post-build step

This is all handled by install. Plugins get installed in their correct directory resources; data files etc get installed in their correct directory... each type of target is handled with INSTALL( TARGET ) but you get 3 destinations; RUNTIME (exe), LIBRARY(.dll,.so) and ARCHIVE (.lib,.a) ; they clai

Re: [CMake] Copying shared libraries in a post-build step

On 12/9/14, Walter Gray wrote: > Hey all, > I'm working on a module that will allow me to automatically copy all the > required .dll files as defined by well-formed import library targets to > the appropriate location (same folder for windows, Frameworks folder for > OSX bundle, ect). I've got th

Re: [CMake] Copying shared libraries in a post-build step

Mind you 'install' doesn't have to be '/usr' or 'program files/whatever' but could be 'output' which will be relative to ${CMAKE_BINARY_DIR} if not absolute On Tue, Dec 9, 2014 at 4:15 PM, J Decker wrote: > This sounds more like an install phase... to bring the whole package > together in one a

Re: [CMake] Copying shared libraries in a post-build step

This sounds more like an install phase... to bring the whole package together in one appropriate place. if( WIN32 ) INSTALL( TARGET RUNTIME DESTINATION bin LIBRARY DESTINATION bin ARCHIVE DESTINATION lib ) else( WIN32 ) INSTALL( TARGET RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DEST

[CMake] Copying shared libraries in a post-build step

Hey all, I'm working on a module that will allow me to automatically copy all the required .dll files as defined by well-formed import library targets to the appropriate location (same folder for windows, Frameworks folder for OSX bundle, ect). I've got the code that scans an executable's INT

[CMake] [ANNOUNCE] CMake 3.1.0-rc3 is now ready!

I am proud to announce the CMake 3.1 third release candidate. Sources and binaries are available at: http://www.cmake.org/files/v3.1/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.1 Release notes appear below and are also published at http://www.cmake.org/cmake/

Re: [CMake] ExternalProject with target_link_library produces incorrect linking?

Works like a charm, I knew I was overlooking something small. Thanks, Brad! -Caleb On Tue, Dec 9, 2014 at 2:30 PM, Brad King wrote: > On 12/09/2014 12:26 PM, J. Caleb Wherry wrote: > > add_library(ExtLib SHARED IMPORTED) > > set_property(TARGET ExtLib PROPERTY IMPORTED_LOCATION > "${CMAKE_BINAR

Re: [CMake] Is this expected behavior?

That's the strange thing. All the dependencies in those files in the real project look right. It's as if they are just not getting used during the library compile, although they do get used when the program is linked to the library and the "current-ness" of the library is checked before the actua

Re: [CMake] ExternalProject with target_link_library produces incorrect linking?

On 12/09/2014 12:26 PM, J. Caleb Wherry wrote: > add_library(ExtLib SHARED IMPORTED) > set_property(TARGET ExtLib PROPERTY IMPORTED_LOCATION > "${CMAKE_BINARY_DIR}/${EXT_LIB_NAME}") > add_dependencies(ExtLib ExtLibBuild) Thanks for the complete/simple example. The problem is that the libExtLib.s

Re: [CMake] Books on cmake

Pretty much. There is also the slim e-book Introduction to CMake [0]. [0] http://www.amazon.com/Introduction-CMake-Software-Tool-Book-ebook/dp/B00KE807Q0/ref=la_B00GPU8HLS_1_1?s=books&ie=UTF8&qid=1418153199&sr=1-1 On Tue, Dec 9, 2014 at 9:47 AM, Dan Kegel wrote: > Is "Mastering CMake" still th

Re: [CMake] Debugging check_cxx_source_compiles

On 12/9/2014 1:53 PM, Vince Harron via CMake wrote: How do I see the command line that cmake is trying? Look in CMakeFiles/CMakeError.log. -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x

[CMake] Debugging check_cxx_source_compiles

Hi all, check_cxx_source_compiles is failing for me. I can compile the test program from the command line, no problem. I'm taking the flags passed to the working command line and setting them to CMAKE_REQUIRED_FLAGS before check_cxx_source_compiles. How do I see the command line that cmake is t

[CMake] ExternalProject with target_link_library produces incorrect linking?

Let's try again... I submitted a question last week but got no responses so I have assumed my question and/or example was not explicit enough. I have stripped out all unnecessary structure from the code and am posing the question better (I hope)... The functionality that I am using is expressed i

Re: [CMake] Is this expected behavior?

On 12/9/2014 9:45 AM, Chris Johnson wrote: Well of course it had to not be all that simple. My first attempt to create a simple (2 header files in library) example failed to fail in the same way as my much more complex real-life project. :-p I will continue to try to whittle down the real prob

[CMake] Books on cmake

Is "Mastering CMake" still the only book out there? BTW, the doc site for 3.0 is great, I really appreciate the effort that went into it. - Dan -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various se

Re: [CMake] Green Hills Generator #0014992

On 12/09/2014 03:25 PM, NoRulez wrote: No one? The patch is already working. 3.1 has been closed for a while now since it is being prepared for release. New features are unlikely to get accepted at this stage. Looking at the mailing list thread it sounds like the patch is still work in pro

Re: [CMake] Is this expected behavior?

Well of course it had to not be all that simple. My first attempt to create a simple (2 header files in library) example failed to fail in the same way as my much more complex real-life project. :-p I will continue to try to whittle down the real problem to the smallest possible set, but it may

Re: [CMake] Green Hills Generator #0014992

No one? The patch is already working. > Am 12.11.2014 um 09:45 schrieb NoRulez : > > Hi, > > is it possible to get the patch for the green hills generator into CMake 3.1 > > Thanks in advance > > Best Regards > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and ch

Re: [CMake] Unclear warning

Am Dienstag, den 09.12.2014, 01:52 -0800 schrieb Alan W. Irwin: > Hi Nils: > > I have never understood CMP0054 until now when I read your above > clear explanation. So thanks very much for that! > Same from me. Excellent work. It makes things clearer. Greetings Michael -- Powered by ww

Re: [CMake] CMakePackageConfigHelpers.cmake support "Sematic Versioning"?

On 12/8/2014 10:05 PM, Bartlett, Roscoe A. wrote: > The problem with the current implementation of > CMakePackageConfigHelpers.cmake is that it does not have a mode where X > in X.Y.Z defines a backward compatible set. It has a "SameMajorVersion" mode which is close, but IIUC a "SemanticVersion" m

Re: [CMake] Unclear warning

Hi Nils: I have never understood CMP0054 until now when I read your above clear explanation. So thanks very much for that! My problem was the bad/ambiguous documentation of CMP0054 at which states "Only interpret if() arguments as vari

Re: [CMake] Unclear warning

On 2014-12-09 08:56+0100 Nils Gladitz wrote: On 12/09/2014 08:30 AM, Micha Renner wrote: Hi, what does this message mean? The ASM_MASM compiler identification is MSVC CMake Warning (dev) at C:/Program Files/CMake/share/cmake-3.1/Modules/CMakeFindBinUtils.cmake:33 (if): Policy CMP0054 is no

[CMake] Programmatically-generated dependencies

Hello all, I am mainly asking having glib-compile-resources in mind. This little program translates files into C source code to be used with the gresource system. It works in the following way: You have a file.xml describing the resources: some_file.txt To generate the source you use `glib