I'm working on a very huge project, it contains lots of modules and they shared some basic header files.
The project is managed by CMake.
Today I found that if I make a tiny change on some comments in a basic header file, it would cause all of modules recompilation since they all include this basic header file.
Is it possible to make CMake ignore the comment changes?
Related
I'm having a problem getting the 'System Header Search Paths' in build settings to work in Xcode and allow me to use #import <Core/CoreBlocks.h> rather than a local copy and #import "CoreBlocks.h"
First I need to "frame" the problem.
I have built a framework that I use across many if not all my projects. This is Core.framework . Inside the framework is the requisite "Headers" directory and within that 40 other headers, all of which are included in the 41'st header Core.h
I drop the Core.framework into another project and the other project headers or source files then import:
#import <Core/Core.h>
and get all the functionality of the 40 modules in the framework. Works fine.
BUT, what I need is a simple way to run the 40 modules of Core.framework outside the framework construct, as a separate build or project, with just the source and breakpoints, so I can debug and enhance it.
I try to define the framework's source directory as a search path for the other project:
yet the compiler complains about the inability to find the headers in the source code:
is all I get for all of the imports even though they all reside in the lower Core directory below that path:
~/Development/Projects/Core/Core/Core/NSRange+Core.h
And that's where I'm at a loss. What am I doing wrong?
Found out why... Xcode for some reason can't use the *nix home directory notation in a pathname.
In other words while:
~/Development/Projects/Core/Core
does not work, the expanded equivalent:
/Users/BC/Development/Projects/Core/Core
does work in the Xcode system header search paths, yet it is not obvious as to why...
I have an external project that unzips a bunch of header files to ${EXTERNAL_INSTALL_PATH}/extproj.
The problem is that I have no way of telling my various executable to build extproj beforehand unless I do add_dependencies(myapp extproj).
I have a lot of executables though, so that's a lot of add_dependencies!
Is there a way to just do something like:
add_dependencies(header_file.h extproj) such that any app that #include <header_file.h> automatically knows to build extproj?
I'm in the process of converting a rather huge project to a Windows 10 Store app. I've gotten it to compile and now can't get past several APPX1101 errors - "Payload contains two or more files with the same destination path". The files are .xml files part of the project, e.g. "baseDir\Assets\foo\timers.xml" and "baseDir\Assets\bar\timers.xml". Different files and different paths.
The solution and projects are created by CMake (3.72). The cmake files have been modified to support creating a Windows 10 store app platform config.
It appears that the directory tree has been flattened and files are overlapping. But how or why eludes me. Every UWP project I've seen contains an "Assets" folder under the main project but this one does not. I see files such as Logo.png and SplashScreen.png in folder named "Resource Files". The files causing the errors are under the folder named "Assets" which existed before this was a UWP project.
Primarily:
How can I fix this error? Did I misconfigure CMake?
Additionally:
How to avoid directory flattening?
There are a few hundred data files taking up a few hundred megabytes used by the program. Will I need to add each of them to the solution to be packaged?
Updates:
I've gleaned more info but not enough to fully satisfy the question. The directory flattening in the output occurs due to how the files are added to the project via CMake and how the original Windows product was packaged. The XML files are added to the project with a full path in the .vcxproj. The .vcxproj.filters also use a full path to the file and a filter like "Data\foo". The desktop Windows version didn't need to care since it knew where to find it's data relative to the executable and was packaged by an external tool.
I've manually added an "Assets" filter and modified the .vcxproj and .vcxproj.filters files. The .vcxproj file needed a property added to the file's include. This uses relative paths and gets rid of the APPX1101 duplicate error.
.vcxproj
<XML Include="..\Base\Assets\foo\Data\timers.xml">
<Link>Assets\foo\Data\timers.xml</Link>
</XML>
.vcxproj.filters
<XML Include="..\Base\Assets\foo\Data\timers.xml">
<Filter>Assets\foo</Filter>
</XML>
Update 2
From what I can tell, it's not possible to get CMake to add a <Link> to XML and other .vcxproj Include types. I went through the latest CMake source code (3.8rc). The <XML Include> is added to the .vcxproj in cmVisualStudio10TargetGenerator::WriteExtraSource() in cmVisualStudio10TargetGenerator.cxx. Other types have the option to set the flag to add the <Link> but XML and other data types do not have code to set the flag.
The only options I can see are modifying CMake source or reworking the project to add data files using relative paths that match the same <Filter> for the matching Include in the vcxproj.filters file. This is only a problem with CMake. Visual Studio 2015/2017 have no problem adding assets above your tree. The MS UWP examples on GitHub do it to share common data between sample projects.
It's been a while and I'm posting this as an answer in case someone else runs into this problem. I'm not marking it accepted because I find the workaround rather weak. My knowledge of CMake is limited and my understanding of Universal Windows apps even less.
The primary issue is that by design, CMake does not build a relocatable solution. i.e. you can't xcopy a Windows solution to another tree and expect it to work as you would would with one generated from within the Visual Studio IDE.
The second issue is that this was a huge pre-existing project already targeting multiple platforms. And by huge, I mean it ships on a dual layer blu-ray disc. The location of asset files was fixed and was above the location of the CMake build folder. This caused files to be stripped of their path when added to the layout whenever their location was not under the expected assets folder.
There is no way in the current CMake (3.8) to add a <link> tag to the include in the project file. And CMake creates the include tag with the full path to the file not a relative one by design.
The workaround I came up with was to add a step to the batch file that invokes CMake to edit the .vcproj and vcproj.filters files to change the fixed asset paths relative ones and then added another step to create a symbolic link/junction (SysInternals.com) under the build folder to the location where the assets were. The assets now appear as being under the expected asset folder are now added correctly to the layout.
As I said, not ideal but it works. The real solution would be to re-organize all the data but this is not something that can happen for this project when a vast amount of data is generated from different script, tools, sources and contributors.
I'm trying to figure out how SFML's CMake configuration shows the <SFML/*> include directory in a project folder.
My test project has include_directories(${CMAKE_CURRENT_SOURCE_DIR}/include) but the include folder does not appear in the project structure like SFML's
The folder will show up if you have added any source files from within that directory (or a subdirectory below it) to any target in the project. Since you are talking about headers, you can simply add the header files as sources to an existing target. CMake will just ignore them as far as the building of that target is concerned, but it will then add those headers to the project's list of files. I've also seen people add a static library target with nothing but headers listed just so those headers show up in the project view. A bit hacky in my opinion, but it gets the job done.
I have written a CMake module that contains a couple of useful macros that I would like to use across a number of other CMake projects. However, I'm not sure where to put the module.
I would like to be able to do this inside each project that uses the macro:
include(MyModule)
However, I'm not sure if there is an easy and cross-platform way of achieving this. In fact, I can't even get it to work on Unix. I put the module (MyModule.cmake) in the following locations:
/usr/lib/cmake/
/usr/lib/cmake/Modules
/usr/local/lib/cmake
/usr/local/lib/cmake/Modules
...and the project with the include() was unable to load the module.
What is the correct location for this module? Is there a better approach?
I should also point out that the macros are not related to "finding" a third-party library and therefore have nothing to do with find_package().
Put the module in a directory of your choice, and then add that directory to CMAKE_MODULE_PATH using list(APPEND).
You can even host that module somewhere and then download it via file(DOWNLOAD). If you download it to the same directory as the current CMake script being processed, you just include(MyModule.cmake) and don't need to modify CMAKE_MODULE_PATH.
You could download the file to a common location on disk and then add a check using if(EXISTS "${module_location_on_disk}") to skip the download if it's already downloaded. Of course, more logic will be required if your module changes, or you want to have a common location and multiple versions of the module, but that's out of those scope of your question.