[CMake] target_include_directories(): SYSTEM option does not seem to work on recent versions of CMake, when targeting Xcode.
Hi,
We are moving our codebase from native project file to CMake based
management. The process is going well, but we need the Boost dependency to
be configured as a system library (to avoid spamming the build log with
Boost related warnings).
It is our understanding that giving a SYSTEM argument to
target_include_directories function should do just that. Yet it does not
seem to work as expected. We created a minimal example that reproduces the
problem:
cmake_minimum_required(VERSION 3.0)
find_package(Boost 1.49 COMPONENTS)
project(system_dependencies)
add_executable(${PROJECT_NAME} main.cpp)
target_include_directories(${PROJECT_NAME} SYSTEM PUBLIC ${Boost_INCLUDE_DIRS})
The compiler invocation issued by Xcode contains this Boost header search
path:
*-I/Users/.../SDK/boost/include*
It is not using "-isystem" flag, whereas it is available.
Did we misuse the command ? Or should we report this as a bug ?
Thank you for reading,
The environment:
CMake v3.3.0 (previously tested with v3.0.0 for the same results)
OS X 10.9.5
Xcode 5.1.1
There is a Stack overflow question opened for this problem:
http://stackoverflow.com/q/31722426/1027706
--
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] target_include_directories(): SYSTEM option does not seem to work on recent versions of CMake, when targeting Xcode.
On 08/06/2015 10:41 AM, A D wrote: It is not using "-isystem" flag, whereas it is available. Did we misuse the command ? Or should we report this as a bug ? Thank you for reading, I am not too familiar with XCode myself but Modules/Platform/Darwin.cmake contains # Xcode does not support -isystem yet. if(XCODE) set(CMAKE_INCLUDE_SYSTEM_FLAG_C) set(CMAKE_INCLUDE_SYSTEM_FLAG_CXX) endif() suggesting that even though the compiler might support -isystem, Xcode itself does (or did) not. I can't tell if that is something that may or may not have changed with current Xcode releases. If you have reason to believe it is supported now (e.g. because you are able to create and Xcode project without cmake that has explicit system includes) you may want to open an issue. 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
[CMake] ZERO_CHECK hangs for a MS Visual Studio 2010 project on Windows7
Hello, I have a piece of C++ and Fortran software that I'm porting to the CMake build system. On my TeamCity continuous integration server I observe a weird behaviour: whenever I modify a CMakeLists.txt in a way that might mean ZERO_CHECK has something to update, building the ZERO_CHECK hangs until it gets killed off by the CI server job scheduler some 6 hours later. The project in question is definitely not big enough to make 6h of ZERO_CHECK sound reasonable. Besides, when I restart the build job after it gets killed, the second build works ok: it completes ZERO_CHECK promptly, and carries on with its regular job of compiling, linking etc.etc. Log sample: [13:23:52][Step 4/4] [13:23:52][Step 4/4] Microsoft (R) Visual Studio Version 10.0.40219.1. [13:23:52][Step 4/4] Copyright (C) Microsoft Corp. All rights reserved. [13:23:52][Step 4/4] 1>-- Build started: Project: ZERO_CHECK, Configuration: RelWithDebInfo x64 -- [13:23:56][Step 4/4] 1>Build started 31.07.2015 13:23:54. (it looks the same way even when I enable detailed logging in MSBuild) This behavior seems to be 100% reproducible, and doing any trivial `echo "#FOO!" >> CMakeLists.txt` dummy commit is enough to trigger it. The same behavior seems to happen both when I run the build directly from devenv.com and via IncrediBuild distributed build thingy. Has any of you seen a ZERO_CHECK build that hangs in VisualStudio 2010? Any ideas about how and why it might happen? Is there any way to see some verbose logs of what was it that the ZERO_CHECK build wanted to accomplish when it hanged? I tried looking around with procmon, but I'm not very proficient with this tool, and didn't see anything obvious. Hoping to hear from you soon, -- Tadeusz Andrzej Kadlubowski -- 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] ninja under windows
> -Original Message- > From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Gonzalo > Garramuño > Sent: Monday, August 03, 2015 17:23 > To: cmake@cmake.org > Subject: [CMake] ninja under windows > > I compiled Ninja on cygwin from git. That now works fine it seems. > I am trying to compile for msvc. However, when cmake runs, I get: > I wouldn't even go there... I would recommend: * Do not build anything requiring native Windows build tools from Cygwin - for example, don't call Visual C++ compiler from Cygwin. * Consider not build anything requiring native Windows build tools from MSYS/MSYS2, like Visual C++ compiler, since MSYS/MSYS2 is a fork of Cygwin. (Unless MSYS/MSYS2 maintainers patch Cygwin to resolve the problems, which you'd better research before going there.) It sounds drastic but I can tell you from experience that eventually you'll run into problems and you may be on your own. The big reason I have run into is that Cygwin's handling of stdin/out/err pipes differs from how most Windows programs (i.e. programs based on Visual C++ runtime, or based on .NET Framework) handle the pipes. They do this for POSIX compatibility reasons, I'd guess. And the Cygwin maintainers in the past have shown limited interest in being compatible with non-Cygwin programs. The end result is you end up with things like a basic/simple .NET Framework 4.0 program not working right if called from Cygwin, for example. If you want to forge ahead, I can offer two suggestions that seem to mitigate the problems - today anyway: * Set CYGWIN environment variable to contain pipe_byte. This is very important but I forget the specifics why, other than non-Cygwin programs break if this isn't set. (Search the Cygwin mailing lists for my posts on the issue). * Make a custom build of Cygwin and then set CYGWIN environment variable to contain pipe_nooverlap (a flag I added). This is also very important because if you don't, .NET Framework 4.0 apps and potentially other programs called from Cygwin will break. I submitted a patch to Cygwin maintainers but they rejected it, so you'll have to build Cygwin yourself (and rebuild it every time the maintainers release new Cygwin version). The link to the patch is here: https://cygwin.com/ml/cygwin-patches/2013-q4/msg00020/pipepatch Setting these flags maybe breaks some POSIX compatibility but in practice, I have had zero problems with common Cygwin programs (bash, coreutils). Since proper interaction with non-Cygwin programs now requires you to make a custom build of Cygwin - a big hassle - I suggest don't even go there, and keep Cygwin (and its MSYS/MSYS2) derivatives out of your build system if you require calling native Windows apps (e.g. Visual C++). There are other unrelated considerations if you want a 100% solid build environment, like you should research the (non-)reliability of forking under Cygwin/MSYS/MSYS2. I have to commend the Cygwin developers for making it work in the first place, since Windows provides no forking API. But in the end, to get POSIX working on the Win32 API, I think they are relying on a lot of undocumented Win32 stuff that works in practice but subject to breakage when new versions of Windows come out, etc. > > Is compiling under the microsoft compiler not an option for ninja files ( I can > compile with NMake Makefiles just fine in the same project ). It is and we do it, here is how: 1. Don't build Ninja under Cygwin. IIRC the procedure would be (a) install Python for Windows, (b) go to a Visual C++ command prompt to set up VC++ environment, (c) call Ninja bootstrapper script. 2. Run CMake from a Visual C++ command prompt when you want to use the Ninja generator because Ninja generator will just look for whatever "cl.exe" is in the PATH. At no point does Cygwin enter into the equation. Best regards, James Johnston -- 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] on cmake supporting one arch per project (from CMake IR)
> -Original Message- > From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Greg Marr > Sent: Wednesday, August 05, 2015 18:42 > To: Raymond Wan; Scott Aron Bloom > Cc: cmake@cmake.org > Subject: Re: [CMake] on cmake supporting one arch per project (from > CMake IR) > > > Gilles Khouzam from Microsoft has created an experimental fork, current as > of 3.2.1, that adds this support. > https://github.com/Microsoft/CMake/tree/feature/MSMultiPlatform > > Adding experimental MultiPlatform support to CMake for Windows and VS > 2012 and above. > > By setting the CMAKE_VS_EFFECTIVE_PLATFORMS variable, the user is able > to specify that multiple platforms should be produced for the same project. > > The supported platforms are Win32, ARM and x64 (not applicable to > Windows Phone) and should be specified as a delimited string > Win32;ARM;x64 for example. I read this and also glanced through the patch (look for commit ID 065bdceb0fbe5253b229faa843fce6b1c271f047 in his repo). It feels a little goofy and too VS-centric to me. How should existing end-user code like this be handled? if(MSVC90 AND NOT CMAKE_CL_64) # set 32-bit VC2008 flags set(CMAKE_CXX_FLAGS ) # snip elseif(MSVC90 AND CMAKE_CL_64) # set some 64-bit VC2008 flags set(CMAKE_CXX_FLAGS ) # snip endif() Well, it seems like you would need platform-specific CXX_FLAGS variables, in addition to the configuration-specific CXX_FLAGS variables already offered. So you'd need a lot new CMake variables for the compiler, linker, etc. Ideally you'd want to figure out how to do this without completely breaking every piece of user code that previously ever touched those variables. While you're at it, you'd want platform-specific variables containing platform-specific paths to each compiler. (e.g. path to 32-bit cl.exe, path to 64-bit cl.exe.) Of course, that opens the door to mixing VC++ and non-VC++ compilers in the same CMake project... Also, the meaning of variables like "MSVC90" or even "CMAKE_CL_64" change: previously CMAKE_CL_64 meant "building for 64-bit" whereas maybe now it means "you may or may not be building for 64-bit" ??? What is CMAKE_CL_64 supposed to do if CMAKE_VS_EFFECTIVE_PLATFORMS is set to Win32;x64? Also, you're still limited to VS generator in his patch, as evidenced by "VS" in "CMAKE_VS_EFFECTIVE_PLATFORMS". I guess that's all fine & well as far as Microsoft's concerned. What if I want to build multi-platforms with the Ninja generator? GNU Make generator? Multi-platforms on Linux? Mac? (Personally I dislike the VS generator / MSBuild on Windows for big builds because the parallelization in MSBuild and cl.exe isn't coordinated, leading to significant over/under-subscription problems that can be avoided with any other generator on Windows.) I'm not making this up, if CMake supported multi-platform building, I would be needing/wanting to specify multiple platforms for the project I'm working on right now: (1) VC++ 32-bit, (2) VC++ 64-bit, (3) GCC cross-compiler, (4) C++ Builder. Some targets would be built for multiple platforms; others would be built for only one of those four platforms. I have annoying requirements that multi-platform could help with like: the cross-compiler requires a custom build step/tool that is built using Visual Studio. Very flexible multi-platform can/should be "easy" for the makefile generators to handle. And the VS generator can handle #1 and #2 fine enough but what if I want it to generate a CMake project containing the GCC/BCC32 targets, for example? How the heck does that work? And what if I want multiple VC++ versions in my platform list - say, VC2008 and VS2013? (After all, I could point to differing versions of cl.exe with my platform-specific COMPILER variables). Again that's something that multi-platform makefile generators can/should handle "easily" but what if the VS generator is asked to generate for VC2008 and VC2013 platforms? Right now the VS generators have it easy - they only have one cl.exe version to contend with (and it's guaranteed to be a cl.exe to begin with). I guess you could have the Ninja/makefile generators happily generate true multi-platform stuff while have the VS generator just croak, but then what if I want to use the VS IDE for my VC++ targets? It would be awesome if CMake could support multi-platform - it could really simplify things for me (as now I am working on a superbuild that iterates through all the above platforms) - but I'd rather see it in a form that is baked into the core of CMake, rather than something VS-specific hacked onto the VS generator that I feel won't interact well with anything non-VS. Best regards, James Johnston -- 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/hel
Re: [CMake] Managed C++ / C# Projects: Location of assembly DLL
> -Original Message- > From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert > Dailey > Sent: Wednesday, August 05, 2015 19:02 > To: CMake > Subject: [CMake] Managed C++ / C# Projects: Location of assembly DLL > > I am including external MS projects via CMake for my C# projects. The > Managed C++ projects I generate via CMake directly. However, sharing > assembly references between the two is difficult. > > Sometimes I need my imported C# projects to know where to find the > managed C++ DLL assembly it built. This is in the CMake binary directory, > which might be different on each machine, so I can't exactly setup a relative > path to this file in the C# project references section. > > Likewise with dependencies on C# output from Managed C++. It's a little > easier to tell CMake where to find the output DLL file for a C# project (since > the output location is relative inside the source dir). > > How do you guys recommend solving these dependency issues? Is there a > way I can add an assembly reference to a Managed C++ project via path > through CMake? I also need to use C#. Until CMake has first-class C# support, I hacked together a primitive "csproj" file generator in about a day and a half (excluding the wrong approach I initially took). I also had problems with "how do you deal with references" and "how do you get the C# project to do an out-of-source build?" (I don't want the C# projects touching my source tree, it's not the CMake way.) So initially I investigated calling csc.exe directly as a custom build step but that approach will have two problems: * No IntelliSense support for C# in the IDE because a C++ project is emitted. * More importantly, system references are difficult to resolve. To see what I mean, built a Hello World C# app in Visual Studio and look at the MSBuild invocation to csc.exe. Note they don't specify "/reference:System.Core.dll" on the command line. Instead we end up with a full path to something like "/reference:C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll" - which is a different path from what is used at runtime (GAC path "C:\WINDOWS\assembly\GAC..."). If you Google there are good reasons to link with the reference assembly and not the one installed on your system. Well it turns out that MSBuild has a complicated set of rules for resolving references, they are not well documented, and they are found in your Microsoft.Common.targets file (search for AssemblySearchPaths to see the list of 9 locations it checks). These rules are different and lengthier than the ones used by csc.exe if an absolute path is not provided. So here's my suggestion: 1. Generate a csproj file on-the-fly from a template and put it into your binary dir, given a list of source files, target name, references, etc. That solves the out-of-source build problem. Make a reusable CMake function(s) for adding C# targets which handles the steps here. 2. Use either include_external_msproject if using a VS generator, or create a custom command/target to directly invoke MSBuild if using a non-VS generator. 3. For references, if you will be using include_external_msproject (as opposed to custom target), and the reference is not an imported target, you will want to generate a project reference. Else, generate a regular reference directly to the file for the configuration. 4. You can use file(GENERATE) to make configuration-specific files that list the references for each configuration. These can then be 'ed into the main csproj file. This lets you use generator expressions if you need to when determining the path for your reference. 5. If generating a project reference to a C++ project, you can use $/../ref.vc(x)proj to get to the project file. If the project reference is to another C# project you can use the undocumented EXTERNAL_MSPROJECT target property. If it's a non-project reference then you have to provide a which can be done with $ for C++ references and a custom property you'll have to maintain for C# project references. 6. Don't forget to call CMake add_dependencies() as well. Best regards, James Johnston -- 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] Modules FindXXX.cmake for toolchains under windows
Hi, I have some experience with cmake toolchain files, and wanted to try it under windows. Everything works fine (find_library, path etc) except find_package. I added a custom FindCTRULIB.cmake file in my folder D:/devkitPro/devkitArm and this folder is listed in my CMAKE_FIND_ROOT_PATH, printing its value gives this : d:/devkitPro/devkitARM;d:/devkitPro I also tried to put it in D:/devkitPro/devkitArm/cmake and D:/devkitPro/devkitArm/share/cmake but it doesn't work. Did I misunderstand the find_package documentation ? I know that I could use CMAKE_MODULE_PATH, but I think this one should only be used by the projects, not for scripts that are shipped with other libraries. Thanks, Lectem -- 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] ninja under windows
I've been using cygwin buildbot for some time, doing pure windows builds. The trick is to have the cygwin buildslave unset a few environment variables (like cygwin's PATH and TEMP and temp), then run a windows batch file to do everything involving compilers, e.g. running windows cmake. There is a tiny bit of magic involved in cleansing the environment enough for the windows tools to be happy, but not much. But I agree: for cmake and things like ninja that run compilers, use pure windows versions, even if you kick them off originally from a cygwin shell script. - 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 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
