I have a target that uses classes from a static library (.a file).
I have the static library in XCode and it is required for the target and is in the "Linked Libraries" section.
In the code I use a class from the static library like:
#include "class_from_static.h"
But XCode complains that the file "class_from_static.h" is not found. Shouldn't it find it?
I have verified that the static library does indeed contain this class.
What is the issue?
Static libraries aren't like frameworks; they only contain code, not headers. You need to add the folder containing class_from_static.h to your user header search paths, or just add the header file directly to the project. If you double-click the setting you can drag and drop a folder into the list.
As well as telling the linker where to find the static library, you must tell the compiler where to find the header files. Adding the header files to the project also adds them to the compiler's search path.
Try it also with the parent folder. For example, assuming class_from_static.h is in the directory named Static (which should also be the name of the static library), you might try:
#include <Static/class_from_static.h>
Also, remember to add, to your project's "Header Search Paths" under "Build Settings," the path to the directory (relative to your project root) that contains the Static directory above (which might also be called Static). E.g., Vendor/Static, which would contain another directory called Static:
ProjectDir
|- Vendor
`- Static
`- Static
`- class_from_static.h
This is how SSToolkit is structured.
Related
I'm following a tutorial on CMake and I have problems understanding the necessity of using the 'include_directories' command at one point.
Let me explain the project first:
In my working directory I have:
- a main.cpp function, a CMakeLists.txt(the main one), a configuration file, a 'MathFunction' directory and a 'build' directory
In the MathFunction directory I have:
- a CMakeLists.txt file that will be invoked by the main one
- A file 'mysqrt.cxx' that contains the implementation of a function which will be used in 'main.cpp' application
- A 'MathFunctions.h' header file that contains the prototype of that function
In the CMakeLists from 'MathFunction' directory I'm creating a library using code from 'mysqrt.cxx' like this:
add_library(MathFunctions mysqrt.cxx)
This snippet is a part of my main CMake code:
# add the MathFunctions library?
#
if (USE_MYMATH)
include_directories ("${PROJECT_SOURCE_DIR}/MathFunctions") # WHY DO WE NEED THIS
add_subdirectory (MathFunctions)
set (EXTRA_LIBS ${EXTRA_LIBS} MathFunctions)
endif (USE_MYMATH)
add_executable(Tutorial tutorial.cxx)
target_link_libraries (Tutorial MathFunctions)
Now I do not understand why I need too add that 'include_directories' command in order to use the library? Shouldn't it be enough that the last command 'target_link_libraries' links the already created executable and libraries togheter so there would be no need to also include_directories?
Thank you for reading and I'm sorry if I have not explained it very well but I hope you will understand what I mean :D
Command include_directories sets directories for header files (.h) to be searched. Linking (target_link_libraries) with a library basically specifies only a library file (.so, .dll or other type). As you see, these are different things.
When linking executable with a library target, CMake propagates (more precisely, "consumes") some properties of that library target to the executable. Among these properties there is INTERFACE_INCLUDE_DIRECTORIES property, which adds include directories to the executable.
So, when a library target has INTERFACE_INCLUDE_DIRECTORIES property correctly being set, you don't need to explicitly specify include directories for executable:
MathFunctions/CMakeLists.txt:
add_library(MathFunctions mysqrt.cxx)
# Among other things, this call sets INTERFACE_INCLUDE_DIRECTORIES property.
target_include_directories(MathFunctions PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
CMakeLsits.txt:
add_executable(Tutorial tutorial.cxx)
# This also propagates include directories from the library to executable
target_link_libraries (Tutorial MathFunctions)
Note, that using simple
# This *doesn't* set INTERFACE_INCLUDE_DIRECTORIES property.
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
in MathFunctions/CMakeLists.txt doesn't imply propagating include directories to the linked executable.
I have a CMake project that looks like this:
project/
CMakeLists.txt
subprojectA/
CMakeLists.txt
include/
headerA.hpp
src/
libraryA.cpp
subprojectB/
CMakeLists.txt
src/
mainB.cpp
The "library" subproject, A, is compiled as a static library, becoming libsubprojectA.a. The "main" project, B, is compiled as a binary and depends on the library. mainB.cpp includes a reference to headerA.hpp.
Here is subprojectA/CMakeLists.txt:
project(SubProjectA)
include_directories(include)
add_library(subprojectA STATIC src/libraryA.cpp)
set(${PROJECT_NAME}_INCLUDE_DIRS
${PROJECT_SOURCE_DIR}/include
CACHE INTERNAL "${PROJECT_NAME}: Include Directories" FORCE)
And here is subprojectB/CMakeLists.txt:
project(SubProjectB)
include_directories(${SubProjectA_INCLUDE_DIRS})
add_executable(mainBinary src/mainB.cpp)
target_link_libraries(mainBinary subprojectA)
The main Project CMakeLists.txt looks like:
project(Project)
add_subdirectory(subprojectB)
add_subdirectory(subprojectA)
Note that subprojectB, the main project, is listed before subprojectA.
Here's the problem. When I first run "cmake" on this project, ${SubProjectA_INCLUDE_DIRS} is not set within SubProjectB.
What I think is happening is that the CMakeLists for SubProjectB loads first, when ${SubProjectA_INCLUDE_DIRS} has not yet been set. It sets its own include path to an empty string as a result. However, even though libsubprojectA.a gets built successfully before mainBinary, the include path was already set empty beforehand. As a result, I get this error when trying to make mainBinary:
subprojectB/src/mainB.cpp:1:23: fatal error: headerA.hpp: No such file or directory
#include "headerA.hpp"
^
It's a workaround to put subprojectA before subprojectB in the main Project CMakeLists in the declarative world of CMake. What I really want is to know the proper way to indicate to CMake that the include_directories(${SubProjectA_INCLUDE_DIRS}) line depends on the definitions that exist inside SubProjectA's CMakeLists. Is there a better way to do this?
If you want to express that include directory subprojectA/include is an interface of the library subprojectA, attach this property to the target with target_include_directories command:
subprojectA/CMakeLists.txt:
project(SubProjectA)
add_library(subprojectA STATIC src/libraryA.cpp)
# PUBLIC adds both:
# 1) include directories for compile library and
# 2) include directories for library's interface
target_include_directories(subprojectA PUBLIC include)
So any executable(or other library) which linked with subprojectA will have this include directory automatically:
subprojectB/CMakeLists.txt:
project(SubProjectB)
add_executable(mainBinary src/mainB.cpp)
target_link_libraries(mainBinary subprojectA)
Of course, for use last command properly you need to process directory with library before one with executable:
CMakeLists.txt:
project(Project)
add_subdirectory(subprojectA)
add_subdirectory(subprojectB)
I'm attempting to write a Ruby script that will delete certain files from the Xcode project. I can find the files based on the absolute path and remove them from the project using the remove_from_project method of PBXFileReference. However this leaves source files (e.g. .m or .swift files) in the "Compile Sources" build phase of whatever target(s) it is a member of, but without a name.
I know I need to also remove the file from the target(s) but there seems to be no easy link between a PBXFileReference and a target (PBXNativeTarget).
From what I can make out I need to iterate through each of the project's targets, then iterate through the files or files_references of that target's source_build_phase looking for the PBXFileReference I already have.
Is this correct or am I missing some obvious link such e.g. file_ref.target_memberships?
if (object.is_a?(Xcodeproj::Project::Object::PBXFileReference))
if (!object.real_path.exist?)
object.remove_from_project
end
end
project.save(project_path)
Not sure when this was introduced, but as of xcodeproj version 1.15.0, you can can get the build files associated with a file reference with:
file_ref.build_files
From the documentation:
Method: Xcodeproj::Project::Object::PBXFileReference#build_files
#build_files ⇒ Array<PBXBuildFile>
Returns the build files associated with the current file reference.
Returns:
(Array<PBXBuildFile>) — the build files associated with the current file reference.
Seems like this should do the trick:
file_ref.build_files.each { |file| file.remove_from_project }
I have a project where there's only a handful of logical groupings for generating static libraries. However for convenience I want to have the library's source code to be managed with more granular folders.
Currently the only way I know to do this in CMake without having a library for each folder is to just list files as you would normally in with their relative paths:
add_library(SystemAbstraction STATIC "Some/Path/File.cpp")
However I can see this getting unwieldy as the project grows in size with all the different paths.
I tried to see if I could have a CMakeLists.txt in each folder and just use a variable in the base CMakeLists.txt when adding library dependencies. But it seems that add_subdirectory doesn't also import variables?
For expanding the scope of a variable inside a subdirectory, use the PARENT_SCOPE option of set. For example, you can test that if you have
# CMakeLists.txt
set(SRCS main.c)
add_subdirectory(foo)
message(${SRCS})
in the root directory and
# foo/CMakeLists.txt
set(SRCS ${SRCS} foo.c PARENT_SCOPE)
in a subdirectory then it will print main.c foo.c, i.e., the variable is correctly imported into the base CMakeLists.txt.
An option would be to use the object library feature of CMake. You still can but doesn't need to organise your CMake script into subdirectories:
add_library(lib1 OBJECT <srcs>)
add_library(lib2 OBJECT <srcs>)
...
add_library(mainlib $<TARGET_OBJECTS:lib1> $<TARGET_OBJECTS:lib2>)
You can set different compile flags for each object library:
target_include_directories(lib1 PRIVATE incl-dir-for-lib1)
target_compile_definitions(lib2 PRIVATE def-for-lib2)
You still need to set link libraries on your main library:
target_link_libraries(mainlib PRIVATE deps-of-lib1 deps-of-lib2)
Related documentation: Object Libraries
I'm having a problem getting XCode to deal with a particular file structure that I am using or that I wish to use.
I have a set of files in the following form...
Library
Headers
Library
Package1
Header1.h
Header2.h
HeaderN.h
Package2
Header1.h
Header2.h
HeaderN.h
PackageN
Header1.h
Header2.h
HeaderN.h
Source
Package1
Source1.m
Source2.m
SourceN.m
Package2
Source1.m
Source2.m
SourceN.m
Package3
Source1.m
Source2.m
SourceN.m
The include model I want for code outside of this library is...
#import "Library/Package/Header.h"
I want to point XCode at Library/Headers but not at the internal folders. When I add this tree to the project XCode seems to make implicit include paths to every node in the tree.
Client code within the project but outside this tree can do this...
#import "Header.h"
instead of...
#import "Library/Package/Header.h"
I can't seem to find a way to dissallow the non-qualified form.
Any help would be appreciated.
Thanks,
-Roman
You're running up against Xcode's behaviour that it builds a flat-headermap. You can disable this by adding the build setting:
HEADERMAP_INCLUDES_FLAT_ENTRIES_FOR_TARGET_BEING_BUILT=NO
to your project settings.
If you include the headers in files in the project then XCode will always find them without path qualification, as you've discovered. The best solution is to remove the headers from the project and specify "Library/Headers" as a header search path in your project settings. The headers won't show in your project, but they also won't be implicitly found by XCode while compiling, either; client code will have to specify the full path off of "Library/Headers" to get to the header file they want.