I am generating Xcode project with CMake. In Xcode it compiles, executes, and debugs fine. But it shows only the cpp files in the Source Files group. Is there any way to add another Header Files group ? My project is compiling fine on Linux, and in Linux I am using KDevelop, there everything works just fine, and I don't want to break that. I don't want to put headers in ADD_EXECUTABLE.
Is there any macro in CMake that creates such files group only for a specific IDE ? Then I would create a group for headers, another group for ui files, another groups for resources etc.
You can easily differentiate between project types in CMake. However, you must include the headers in the add_executable statement for them to be present in the project. I'm not really sure why you wouldn't want to add the headers in the add_executable statement, it shouldn't have any effect on compilation (the whole point of CMake is to be operational across multiple compilers!). However, you could easily do:
if (defined XCODE_VERSION)
add_executable(<ExeName> ${SOURCES} ${HEADERS});
else()
add_executable(<ExeName> ${SOURCES});
endif()
Thus only affecting XCode projects. If you want to arrange the sources (headers, etc), in different groups within the IDE, the generic CMake command for doing that is source_group. So, you could do:
source_group("Source Files" FILES ${SOURCES});
source_group("Header Files" FILES ${HEADERS});
Related
I do not understand how Xcode knows which headers should be included into which target? For example if I add a new File to my Xcode Project it adds the .m File to the compile sources of the selected targets but what about the .h files? How does my target know which header files should be used?
Only .m files and resource files are part of the targets, not .h. Headers only need to be copied for a framework target, and only because they are part of the framework release (they allow users to know how to use the framework). Apps don't need the headers because they're compiled stand alone entities. The headers (and the pch file) are used during compilation but aren't required at runtime.
You want files to be members of your target when they:
Form part of the executable (e.g. implementation (.m) files or libraries), or
Are included as files in the application bundle (e.g. images).
Just to give an example via screenshot, the way we control headers in Xcode for libraries is in build phase something like this:
You may further read out this Apple Documentation for setting the visibility of header files in Xcode.
I have two targets in the same xcode project, as bundle plugins, and I want the executable files within the binary to have the same name for both targets.
Is there a way I can either:
A) Define the executable file for each binary without affecting the .bundle name (or first target overwrites the second target as they're building).
B) Build both files in their own folder.
They are in the same project, so the build end-results are automatically placed in the same folder. One overwrites the other, as the .bundle name always ends up the same (because I want the same executable name). They share a lot of code, so they are in the same project, to build everything again at once, to make sure everything always has the latest code across all versions.
Would anybody know a way of doing this? I tried various options in the build settings. Or would anybody maybe have any "build phase" workaround ideas? Please don't ignore that the executable name needs to be the same for all binaries.
Thanks in advance!
I created a project for each slightly different built, with flags in the build settings for each target making each target distinct (with use of macros in the actual code).
Regarding in ensuring code is always the up-to-date, partially shared, code for each build/project, they share the source code by adding it to the project, without selecting the "copy to project folder" option. Annoying workaround, but it'll do until I work something better out...
Why don't you use targets with different names? Or a script after build, that copies the target to a different name?
This should copy each target to a unique name after build, without each build overwriting the other. (If things are linear)
I have a cmake configuration that works great for my project on Windows and Linux. We're tinkering with MacOS right now and we're at the point where Xcode spits out the libraries built one directory off from what we define. Instead of it being dropped in ~/bin it is dropped in ~/bin/Debug, for example. As best I can tell Xcode is taking upon itself to add this folder to the path and I don't want that.
How can I disable Xcode from doing this from within my cmake configuration?
You'll need to specify the target properties ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>, LIBRARY_OUTPUT_DIRECTORY_<CONFIG>, and/or RUNTIME_OUTPUT_DIRECTORY_<CONFIG> for each config type and each target you want to affect.
To affect all targets, you can set variables named as these with CMAKE_ prepended. Any relevant target added after these have been set will be affected.
So, for example you could either do:
add_library(MyLib ${Sources})
set_target_properties(MyLib PROPERTIES
ARCHIVE_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR}
ARCHIVE_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR})
or you could do:
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_DEBUG ${CMAKE_BINARY_DIR})
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY_RELEASE ${CMAKE_BINARY_DIR})
add_library(MyLib ${Sources})
Having said that, I normally find it's best to let multi-configuration generators like XCode and MSVC just add the config-specific directories. Unless you plan to also change the default names of exes and libs, these multi-config IDEs will overwrite one config's outputs with another's. So, it's hard to tell whether you're looking at a Debug or Release exe for example.
For single-config generators, I think it's common to have separate build trees per configuration to keep the distinction clear.
Basically, I wouldn't fight against the generator. CMake automates so much of the build process that I never find this slight difference between generators to be a problem. You rarely have to consider whether the output path contains a config dir or not.
I'm developing a large project using Qt 4.6, CMake 2.8 and Visual Studio 2008 for the Windows platform.
As far the build system goes, it's all standard stuff: I'm using CMake's QT4_WRAP_CPP macro to generate moc files from header files, which are then linked into the final executable in the add_executable command. Everything is working as expected.
The only restriction with this setup is that I can't define widgets or helper using Q_OBJECT in .cpp files. This would be very convenient for small, context-specific helpers classes that should appear right next to where they're used.
I tried to pass the whole list of source files (both .h and .cpp) to QT4_WRAP_CPP, instead of just the header files, but that doesn't work (linking fails because some moc-related symbols are undefined).
I think the problem is that, for a given pair of files foo.h and foo.cpp, the QT4_WRAP_CPP macro will generate the same moc file (moc_foo.cxx) in the same directory, and obviously that means the first file will be overwritten by the second one, and as a result symbols will be missing at link-time.
Is there a way to fix or work around that problem? For instance, I tried to add a specific rule for foo.cpp of the form
QT4_GENERATE_MOC(directory/foo.cpp directory/foo.moc)
and then add
#include "foo.moc"
at the end of foo.cpp. I think this ought to work, but alas Visual Studio only allows one build rule per file, and .cpp files already have a build rule (compilation to object file), so this approach doesn't work, at least with Visual Studio.
Another idea that I had was to create a new macro, say QT4_WRAP_CPP_WITH_PREFIX, based on QT4_WRAP_CPP (which is defined in share/cmake-2.8/Modules/Qt4Macros.cmake), that would take an additional prefix argument and would add this prefix to the generated moc files. That way, I would call QT4_WRAP_CPP_WITH_PREFIX twice, once for .h files and once for .cpp files, with different prefixes. What I just dislike about this approach is that I'd be messing with the internals of CMake's Qt support, instead of using the public API.
Any better idea?
Recent versions of CMake have "automoc" which worked like a charm for me:
http://blogs.kde.org/2011/11/01/cool-new-stuff-cmake-286-automoc
Simply add in the CMakeLists.txt:
set(CMAKE_AUTOMOC TRUE)
and then in the cpp (e.g. example.cpp) file:
#include "example.moc"
(the *.moc must match the cpp file's name).
Referring to the documentation "Using the MOC" (http://doc.qt.nokia.com/4.1/moc.html), you'd only need to import "foo.moc" at the end of your implementation file. As you can not tweak the build rules correspondingly, try to export a .pro file and apply the build rule as suggested by the nokia document.
If I add sources and headers in my .pro file that arn't in the same directory, the resulting xcode project groups the files by it's default Sources, Headers, etc. but then puts the files in a subdir of those folders indicating the subdirectory where the files are. This make non-flat projects look exceedingly ugly when generated for xcode (notice all the Qt examples are flat).
How do I prevent it from doing that? Or am I stuck with either an ugly xcode layout, or a flat project?
You can create your own configuration features for qmake by adding a new CONFIG argument variable in a .prf file.
Check out this Qt wiki.
Also it looks like you can use different variable names to generate different group names in xcode.
I'm going to figure out both these methods and generate a nice report.