[CMake] MSYS Generator with Visual Studio compilers

[Ben Robinson]

Hello,

Due to the relative slowness of mingw32-make.exe (MinGW) compared to
make.exe (MSYS) I set out to convert a working MinGW generator project over
to MSYS.  The project uses Visual Studio CXX and Intel Fortran.  Is this
even possible?

My approach was to treat the toolchain like a cross compile, since MSYS
assumes GCC and GFortran.  I printed the relevant toolchain variables from
the working MinGW build, and set them in the MSYS build before the project
statement.  The statements are:

set(CMAKE_SYSTEM_NAME "Windows")
set(CMAKE_C_COMPILER "C:/Program Files (x86)/Microsoft Visual Studio
12.0/VC/bin/amd64/cl.exe")
set(CMAKE_C_COMPILER_ID "MSVC")
set(CMAKE_CXX_COMPILER "C:/Program Files (x86)/Microsoft Visual Studio
12.0/VC/bin/amd64/cl.exe")
set(CMAKE_CXX_COMPILER_ID "MSVC")
set(CMAKE_Fortran_COMPILER "C:/Program Files (x86)/Intel/Composer XE
2015/bin/intel64/ifort.exe")
set(CMAKE_Fortran_COMPILER_ID "Intel")
set(CMAKE_AR "C:/Program Files (x86)/Microsoft Visual Studio
12.0/VC/bin/amd64/lib.exe" CACHE FILEPATH "Archiver")

However, when I perform the initial cmake specifying the MSYS Makefiles
generator I get the following error:

-- The CXX compiler identification is MSVC 18.0.31101.0
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/amd64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/amd64/cl.exe -- broken
CMake Error at c:/Program Files
(x86)/CMake/share/cmake-3.0/Modules/CMakeTestCXXCompiler.cmake:54 (message):
  The C++ compiler "C:/Program Files (x86)/Microsoft Visual Studio
  12.0/VC/bin/amd64/cl.exe" is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: F:/P4V/brobins_sim_DEV/build_msys/Release/CMakeFiles/CMakeTmp

  Run Build Command:"c:/opt/gnuwin32/bin/make.exe"
  "cmTryCompileExec3536241854/fast"

  c:/opt/gnuwin32/bin/make.exe -f
  CMakeFiles/cmTryCompileExec3536241854.dir/build.make
  CMakeFiles/cmTryCompileExec3536241854.dir/build

  make.exe[1]: Entering directory
  `F:/P4V/brobins_sim_DEV/build_msys/Release/CMakeFiles/CMakeTmp'

  "/c/Program Files (x86)/CMake/bin/cmake.exe" -E cmake_progress_report
  /F/P4V/brobins_sim_DEV/build_msys/Release/CMakeFiles/CMakeTmp/CMakeFiles 1

  The system cannot find the path specified.

  make.exe[1]: ***
  [CMakeFiles/cmTryCompileExec3536241854.dir/testCXXCompiler.cxx.obj] Error
  1

  make.exe[1]: Leaving directory
  `F:/P4V/brobins_sim_DEV/build_msys/Release/CMakeFiles/CMakeTmp'

  make.exe: *** [cmTryCompileExec3536241854/fast] Error 2

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:30 (project)

-- Configuring incomplete, errors occurred!
See also
"F:/P4V/brobins_sim_DEV/build_msys/Release/CMakeFiles/CMakeOutput.log".
See also
"F:/P4V/brobins_sim_DEV/build_msys/Release/CMakeFiles/CMakeError.log".

Any ideas what I should attempt next?

Thank you!

Ben
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] No rule to build mod file

[Brad King]

On 12/10/2014 7:49 AM, Alain Miniussi wrote:
> Is this something expected ?

Parallel builds of Fortran 90 sources with modules are expected
to work with the Makefile generator, and known to work on several
non-trivial projects.  Please post or link a complete example
tarball with sources that reproduces the problem.

Thanks,
-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Including another CMakeLists project

[Micha Hergarden]

If the projects are truly independent, you may also want to look at the
external_project command.

Regards,
Micha

On 12/10/2014 03:42 PM, Petr Bena wrote:
> I have 3 projects, all using cmake. When I run cmake on each of them
> and separately build them, it's all fine.
>
> When I use include() on these 2 cmake files in 1 of them, so that I
> could run only 1 cmake and then build them all using 1 make, it fails.
>
> I believe that these 3 cmakes are colliding with each other, is there
> a way to run it isolated?




signature.asc
Description: OpenPGP digital signature
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] 64 bit build of wxWidgets-2.8.12 is not found

[Robert Pollak]

Hello,

I am using:
- Windows 7 Professional 64 Bit
- Visual Studio 2010 Professional
- CMake 3.0.1

and I have installed wxMSW-2.8.12-Setup.exe to L:\wxWidgets-2.8.12-vc10\
and created 32 bit and 64 bit shared library builds there (see footnote [1]).

Now I want to use the 64-bit wxWidgets libraries in a CMake-based project.
For that, I have started with a minimal CMakeLists.txt in an empty folder:
> cmake_minimum_required(VERSION 3.0.1)
> 
> find_package(wxWidgets REQUIRED core base)

and created a 64 bit configuration cmake-win64-libs-vc10.conf next to it:
> set(wxWidgets_ROOT_DIR "L:/wxWidgets-2.8.12-vc10" CACHE PATH "wxWidgets base 
> directory" FORCE)
> set(wxWidgets_LIB_DIR "L:/wxWidgets-2.8.12-vc10/lib/vc_amd64_dll" CACHE PATH 
> "wxWidgets libraries directory" FORCE)
> set(wxWidgets_CONFIGURATION msw CACHE PATH "wxWidgets configuration" FORCE)

When I now call my configure-win64-vc10.bat there:
> setlocal
> rmdir /S /Q build
> mkdir build
> cd build
> set WXWIN=L:\wxWidgets-2.8.12-vc10
> cmake -C ..\cmake-win64-libs-vc10.conf ^
>   -G "Visual Studio 10 Win64" ^
>   ..
> cd ..
> endlocal

, I get the error
> CMake Error at C:/Program Files 
> (x86)/CMake/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 
> (message):
>   Could NOT find wxWidgets (missing: wxWidgets_FOUND)
> Call Stack (most recent call first):
>   C:/Program Files 
> (x86)/CMake/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:343 
> (_FPHSA_FAILURE_MESSAGE)
>   C:/Program Files 
> (x86)/CMake/share/cmake-3.0/Modules/FindwxWidgets.cmake:869 
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>   CMakeLists.txt:4 (find_package)

However, a corresponding 32-bit configuration works!
The only differences of my 32-bit and 64-bit configurations are
* the wxWidgets_LIB_DIR: vc_amd64_dll vs. vc_dll (both directories are existing 
and filled with the corresponding dlls)
* the CMake generator: "Visual Studio 10 Win64" vs. "Visual Studio 10"

This looks to me like a bug of FindwxWidgets.cmake.
Can anyone confirm? How can I debug this?


Best regards,
Robert



[1] with
> call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" 
> x86
> set WXWIN=D:\libraries\wxWidgets-2.8.12-vc10
> cd \wxWidgets-2.8.12-vc10\build\msw
> nmake /f makefile.vc BUILD=debug   SHARED=1
> nmake /f makefile.vc BUILD=release SHARED=1
resp.
> call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" 
> x86_amd64
> set WXWIN=D:\libraries\wxWidgets-2.8.12-vc10
> cd \wxWidgets-2.8.12-vc10\build\msw
> nmake /f makefile.vc TARGET_CPU=AMD64 BUILD=debug   SHARED=1
> nmake /f makefile.vc TARGET_CPU=AMD64 BUILD=release SHARED=1
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Including another CMakeLists project

[Parag Chandra]

I think you may want to try the add_subdirectory() command instead of
include(), if you truly have multiple projects that are being built by
CMake. The name suggests that it would only work with a hierarchical
directory structure, but that is not the case - you can specify absolute
paths if necessary.

On the other hand, if you need to use include() to add shared logic across
build scripts (but not actual entire projects), then it¹s helpful to think
of include() as analogous to the #include directive. I¹ve found that I
needed to condition guard the included file, something like this:

if (NOT (DEFINED Foo_cmake))
set (Foo_cmake TRUE)
# Add shared logic below, then end with:
endif ()

Hope this helps.


Parag Chandra
Software Engineer, Mobile Team
Mobile: +1.919.824.1410

 

Ionic Security Inc.
1170 Peachtree St. NE STE 2285, Atlanta, GA 30309











On 12/10/14, 9:42 AM, "Petr Bena"  wrote:

>I have 3 projects, all using cmake. When I run cmake on each of them
>and separately build them, it's all fine.
>
>When I use include() on these 2 cmake files in 1 of them, so that I
>could run only 1 cmake and then build them all using 1 make, it fails.
>
>I believe that these 3 cmakes are colliding with each other, is there
>a way to run it isolated?
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at:
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Including another CMakeLists project

[Petr Bena]

Yup, that works.

Thanks

On Wed, Dec 10, 2014 at 3:48 PM, Parag Chandra  wrote:
> I think you may want to try the add_subdirectory() command instead of
> include(), if you truly have multiple projects that are being built by
> CMake. The name suggests that it would only work with a hierarchical
> directory structure, but that is not the case - you can specify absolute
> paths if necessary.
>
> On the other hand, if you need to use include() to add shared logic across
> build scripts (but not actual entire projects), then it¹s helpful to think
> of include() as analogous to the #include directive. I¹ve found that I
> needed to condition guard the included file, something like this:
>
> if (NOT (DEFINED Foo_cmake))
> set (Foo_cmake TRUE)
> # Add shared logic below, then end with:
> endif ()
>
> Hope this helps.
>
>
> Parag Chandra
> Software Engineer, Mobile Team
> Mobile: +1.919.824.1410
>
>  
>
> Ionic Security Inc.
> 1170 Peachtree St. NE STE 2285, Atlanta, GA 30309
>
>
>
>
>
>
>
>
>
>
>
> On 12/10/14, 9:42 AM, "Petr Bena"  wrote:
>
>>I have 3 projects, all using cmake. When I run cmake on each of them
>>and separately build them, it's all fine.
>>
>>When I use include() on these 2 cmake files in 1 of them, so that I
>>could run only 1 cmake and then build them all using 1 make, it fails.
>>
>>I believe that these 3 cmakes are colliding with each other, is there
>>a way to run it isolated?
>>--
>>
>>Powered by www.kitware.com
>>
>>Please keep messages on-topic and check the CMake FAQ at:
>>http://www.cmake.org/Wiki/CMake_FAQ
>>
>>Kitware offers various services to support the CMake community. For more
>>information on each offering, please visit:
>>
>>CMake Support: http://cmake.org/cmake/help/support.html
>>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>>Visit other Kitware open-source projects at
>>http://www.kitware.com/opensource/opensource.html
>>
>>Follow this link to subscribe/unsubscribe:
>>http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Including another CMakeLists project

[Robert Maynard]

I would try using add_subdirectory() instead of include()

On Wed, Dec 10, 2014 at 9:42 AM, Petr Bena  wrote:
> I have 3 projects, all using cmake. When I run cmake on each of them
> and separately build them, it's all fine.
>
> When I use include() on these 2 cmake files in 1 of them, so that I
> could run only 1 cmake and then build them all using 1 make, it fails.
>
> I believe that these 3 cmakes are colliding with each other, is there
> a way to run it isolated?
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Including another CMakeLists project

[Petr Bena]

I have 3 projects, all using cmake. When I run cmake on each of them
and separately build them, it's all fine.

When I use include() on these 2 cmake files in 1 of them, so that I
could run only 1 cmake and then build them all using 1 make, it fails.

I believe that these 3 cmakes are colliding with each other, is there
a way to run it isolated?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake Vs 2012 Express 64bit

[Parag Chandra]

Not sure, but I believe that is a limitation of the Express edition
itself; not a problem with CMake per se. You may want to try the
just-released VS 2013 Community Edition instead. If you insist on using
2012 Express, perhaps this link may be of help:

http://www.kobashicomputing.com/64-bit-c-development-under-visual-studio-20
12-express



Parag Chandra
Software Engineer, Mobile Team
Mobile: +1.919.824.1410

 

Ionic Security Inc.
1170 Peachtree St. NE STE 2285, Atlanta, GA 30309











On 12/10/14, 9:03 AM, "Micha Renner"  wrote:

>Hi all,
>
>is there a way that CMake create solution files for 64-bit targets?
>(Visual Studio 2012  Express)
>
>Greetings
>Michael
>
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at:
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake

-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Target 'copy-construction'/'fork'

[Domagoj Saric]

Hi,

Given a target named Foo, is there a simple/builtin way to create a copy of that 
target named Bar so that it retains all the properties of Foo but can be 
independently changed from that point onward i.e. is there a way for CMake 
targets to follow the semantics of standard C++ objects with copy-constructors..?
This would be useful for creating targets which are essentially the same but 
differ only in a few properties (e.g. creating /MD and /MT versions of a MSVC 
DLL)...



--
Domagoj Saric
Software Architect
www.LittleEndian.com
--

Powered by www.kitware.com

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

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

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

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

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

[CMake] CMake Vs 2012 Express 64bit

[Micha Renner]

Hi all,

is there a way that CMake create solution files for 64-bit targets?
(Visual Studio 2012  Express)

Greetings
Michael


-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] No rule to build mod file

[Alain Miniussi]

Hi,

I am experiencing a problem related with dependencies on fortran mod 
files. Basically, the "make -j" it's failing with:
make[2]: *** No rule to make target `dsfdm3d/inc/modacqui.mod', needed 
by `dsfdm3d/src/CMakeFiles/dsfdm_sp-exe.dir/main.f90.o'. Stop.



mod file are generated as a side effect of source file compilation, so a 
file A.f90 using a mod B.mod must be compiled after the file producing 
the module (say B.f90).


cmake seems to be able to convert those constraints in terms of build 
order (that is, B.f90 will be compiled before A.f90) and insert a 
dependency from A.f90 to B.mod. But sinces there are no specific rule to 
build B.mod, a full parallel build will fail on the dependencies.
That is, before building anything, make will detect that A.f90 depends 
on a non existing file (yet) and fail to see that the compilation of 
B.f90 would have produced the file.


 For some reason, the problem seems to appears only if I build an 
executable (from A.f90) and have many files suc a B.f90 used to build a 
library.
 When building with a simple 'make' everything is okay (I guess because 
the build order is good), the problem only appears with "make -j".


I have the problem with cmake  3.1.0-rc1 and 2.8.12.2

the CMakeLists.txt looks like:

add_library(somelib OBJECT
 [some 52 source files>.f90
  )

set_target_properties(somelib PROPERTIES Fortran_MODULE_DIRECTORY 
"${CMAKE_CURRENT_BINARY_DIR}/../inc")

set_target_properties(somelib PROPERTIES COMPILE_FLAGS "")

add_executable(exe main.f90 $)
set_target_properties(exe PROPERTIES COMPILE_FLAGS "")


add_dependencies(exe somelib)

Is this something expected ?

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

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

[J Decker]

>
>
> b: in msvc, you cannot debug by right-click on the target -> debug ->
> start new instance.
>
> I can and do all the time.


> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Sergei Nikulov]

2014-12-10 13:29 GMT+03:00 Sergei Nikulov :

>
>
> 2014-12-10 2:38 GMT+03:00 Walter Gray :
>
>>  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
>> INTERFACE_LINK_LIBRARIES property recursively to find all such shared
>> library, however I'm running into a small problem.  I really like using
>> file globbing in higher level source directories to add all appropriate
>> sub-directories, but this means that sometimes a dependency will not be
>> fully defined yet. This is normally fine since these things are usually
>> resolved at *generation* time, but since I'm doing a manual traversal of
>> the list of link libraries at config time that's not really acceptable.  I
>> realize I could just not do the globbing and just make sure the directories
>> were setup in the correct order, but I really don't like making the
>> add_subdirectory calls order dependent.
>>
>
Sorry for  empty email.

Instead of globbing you can set single place for all project binary output

set(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/dist)

Or whatever other place instead of top project folder.


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

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

[Tim Blechmann]

> > 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 DESTINATION lib )
> > endif( WIN32 )
> 
> on unixy platforms, shared libraries can be resolved using rpaths. on
> windows this is not the case: if you link a dll into an executable the
> executable will not run, unless the dll can be resolved at startup time.
> the is typically done by placing he dll next to the exe.
> 
> the install step is a possible workaround, but in my experience this
> implies that you have to run the install script in order to debug the
> binary, which is pretty inconvenient.
> 
> No more inconvenient than building any other target... from the command
> line cmake --build . <--target install / instead of blank>;

a: typically you don't want to build the complete project, but only the
binary you want to debug (install requires all). depending on the size
of your project, this can be a big issue.

b: in msvc, you cannot debug by right-click on the target -> debug ->
start new instance.

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Sergei Nikulov]

2014-12-10 2:38 GMT+03:00 Walter Gray :

>  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
> INTERFACE_LINK_LIBRARIES property recursively to find all such shared
> library, however I'm running into a small problem.  I really like using
> file globbing in higher level source directories to add all appropriate
> sub-directories, but this means that sometimes a dependency will not be
> fully defined yet. This is normally fine since these things are usually
> resolved at *generation* time, but since I'm doing a manual traversal of
> the list of link libraries at config time that's not really acceptable.  I
> realize I could just not do the globbing and just make sure the directories
> were setup in the correct order, but I really don't like making the
> add_subdirectory calls order dependent.
>
> One solution I've come up with is to add the targets I want to do this to
> to a global list, then iterate over that list as the last step in my
> top-level cmake lists file, but that has the issue that I can no longer use
> add_custom_command on those targets at that point.  I'm wondering 3 things:
>
> 1)What is the reasoning behind not allowing add_custom_command on targets
> not defined in the current directory? Especially now that SOURCE can be
> modified, the restriction seems very arbitrary.
>
> 2)How stupid would it be to reserve the command using something like
> add_custom_command(TARGET ${target} POST_BUILD COMMAND
> $)
>  then use set_property(TARGET ${target} APPEND PROPERTY
> COPY_SHARED_LIBS_COMMAND to add more copy steps to the command?
>
> 3) Am I completely missing something and there's already a totally well
> supported way of making sure that an executable's shared library
> dependencies end up in the correct directory?  I couldn't find a really
> satisfactory answer on stack overflow or the archives.
>
> 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
>



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

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

[J Decker]

On Wed, Dec 10, 2014 at 2:14 AM, Tim Blechmann  wrote:

> > 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 DESTINATION lib )
> > endif( WIN32 )
>
> on unixy platforms, shared libraries can be resolved using rpaths. on
> windows this is not the case: if you link a dll into an executable the
> executable will not run, unless the dll can be resolved at startup time.
> the is typically done by placing he dll next to the exe.
>
> the install step is a possible workaround, but in my experience this
> implies that you have to run the install script in order to debug the
> binary, which is pretty inconvenient.
>
> No more inconvenient than building any other target... from the command
line cmake --build . <--target install / instead of blank>; or 'make
install' instead of 'make'
click and build in a gui environment; again not a big issue... and can just
select that as the default target anyway... again just a modification to
workflow.  If it was a base library everything will be rebuilt
appropriately and nothing more or less.. just one extra copy step that's
pretty quick... and even that only copies what it needs to.
So I don't know why you would attribute that as a negative 'pretty
inconvenient' when it's really just a thing that just is... nature of the
beast

although now that you mention it; it would be nice to define install as the
default 'all' project.  Or do something really rude that would make every
target depend on install such that building a sub-executable would still
trigger the install script phase.
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Tim Blechmann]

> 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 DESTINATION lib )
> endif( WIN32 )

on unixy platforms, shared libraries can be resolved using rpaths. on
windows this is not the case: if you link a dll into an executable the
executable will not run, unless the dll can be resolved at startup time.
the is typically done by placing he dll next to the exe.

the install step is a possible workaround, but in my experience this
implies that you have to run the install script in order to debug the
binary, which is pretty inconvenient.


> On Tue, Dec 9, 2014 at 3:38 PM, 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 the code that
> scans an executable's INTERFACE_LINK_LIBRARIES property recursively
> to find all such shared library, however I'm running into a small
> problem.  I really like using file globbing in higher level source
> directories to add all appropriate sub-directories, but this means
> that sometimes a dependency will not be fully defined yet. This is
> normally fine since these things are usually resolved at
> *generation* time, but since I'm doing a manual traversal of the
> list of link libraries at config time that's not really acceptable. 
> I realize I could just not do the globbing and just make sure the
> directories were setup in the correct order, but I really don't like
> making the add_subdirectory calls order dependent.
> 
> One solution I've come up with is to add the targets I want to do
> this to to a global list, then iterate over that list as the last
> step in my top-level cmake lists file, but that has the issue that I
> can no longer use add_custom_command on those targets at that
> point.  I'm wondering 3 things:
> 
> 1)What is the reasoning behind not allowing add_custom_command on
> targets not defined in the current directory? Especially now that
> SOURCE can be modified, the restriction seems very arbitrary.
> 
> 2)How stupid would it be to reserve the command using something like
>add_custom_command(TARGET ${target} POST_BUILD COMMAND
> $)
>  then use set_property(TARGET ${target} APPEND PROPERTY
> COPY_SHARED_LIBS_COMMAND to add more copy steps to the command?
> 
> 3) Am I completely missing something and there's already a totally
> well supported way of making sure that an executable's shared
> library dependencies end up in the correct directory?  I couldn't
> find a really satisfactory answer on stack overflow or the archives.
> 
> 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
> 
> 
> 
> 


-- 

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