So, I understand that CLion currently only fully supports CMake projects. I don't care if I can't compile or run anything with CLion, as I don't currently do that with Eclipse anyway. I am just looking for editor support, with nice click-to-follow, autocomplete, etc.
What I am wondering is whether or not indexing can still work for non-CMake projects. I can create my project just fine, and indexing completes just fine, but after that is done it can't find my include files. It creates a default CMakeLists.txt file, in which the appropriate sources and include_directories have been added. It doesn't seem to make a difference though, as after indexing completes I still can't click-to-follow #include lines, and any references to things in other files don't work correctly.
Is there something else I can do to make indexing work so I can use CLion as an editor, or is this a pipe dream until Makefile support is someday added?
After some research, I found out your best chances are:
Once it's created, edit CMakeLists.txt (for example, see How to
find libraries). One example:
set(Library "../Library")
include_directories(${Library})
set(SOURCES main.cpp)
add_executable(project_name ${SOURCES})
Note ../ goes to the up folder and in the main.cpp you can use #include "header_to_add.h" (header_to_add.h must be in ../Library folder.
Edit the source code of you .cpp, .h or whatever to add the full path of the library you want to #include taking into account the scope starts in the directory where the file is.
For example: #include "../Library/header_to_add.h" (note the "../" goes one level up from the current folder".
(Maybe not possible or hard) Modify the makefile to prepare CMake to get the necessary inputs (for example, see this).
I recommend the first one mainly because it maintains the structure outside the source files.
Edit: Also it's possible to prepare CMake to use makefile (Source).
Related
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 have a situation where I am using two libraries which have duplicate header file names. For example timer.h exists in both libraries. I think the normal solution to this would be to explicitly specify the directory in the include like #include <dir1/timer.h> or #include <dir2/timer.h> so that the compiler has a clue as to which I am specifying. However, my problem is that one of the libraries I am using is not in a sub directory of my project. It exists somewhere else at a higher level. That is...
Root
Library1
Projects
ProjectFolder
Library2
This was done so that multiple projects could reference Library1. It seemed like a good idea at the time. However, now that I have the name conflict of Library2 it creates issues. One other important detail is that I often use two different workstations. The absolute location of Library1 on these workstations is not the same, nor is the relative location (with respect to the project folder) the same between the two. What I have been doing to this point is adding both absolute locations to the search path of the preprocessor.
Anyway, I'd appreciate any guidance you might offer.
You are on the right track with "dir1/timer.h" and "dir2/timer.h". But rather than think of it as dir think of it as "project1/timer.h". Now in your makefile you will need to have the location of project1 added to your include search path if it's not in a common location.
You shouldn't have relative paths in either your code (no ../file.h). They should be relative to the base directory of their project (e.g. #include <sys/socket.h> or #include <linux/sched.h>). Then it's up to your makefile to find them (those two examples are in the standard search path so they will work). For your case you can -I<path to project directory> and then #include "other_project/library.h".
I'd prefer including a copy of a specific version of the external library with my project and updating to a newer version as needed (but not actually changing the external library from the project). If you just refer to the current (changing) version that everybody uses, then your project may change behavior without even having its code changed. A release of your project would also have to refer to whatever version of the library you were using at that point in time to be complete.
If you did it that way, the relative paths are always the same (say, "../ExternalLib") if you want to use that approach. Or you can do as dave suggests.
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.
I'm trying to use standard system header files in my C++ XCode project:
#include <openssl/bio.h>
#include <openssl/ssl.h>
#include <openssl/err.h>
The build fails and it complains:
"Openssl/bio.h: No such file or directory"
I added /usr/include to the "Header Search Paths" in Project settings, but that doesn't fix it.
I can fix it by adding the whole path like:
#include </usr/include/openssl/bio.h>
-- but the project is full of similar includes and I don't want to change all of them this way. Also, I feel I shouldn't have to do this.
Another way to fix it would be as another thread mentioned, which is to add /usr/include to User Header Search Paths. But if I do that, then I'd have to change all the angle brackets <> to quotes "", which again seems like a hack. I mean, these are standard system header files so I feel it should be something simple, not requiring these kinds of hacks.
Any ideas?
Thanks!
Xcode uses the currently selected SDK as a base path, which it prefixes on to system includes. So if your SDK is /Developer/SDKs/MacOSX10.6.sdk then it will look under /Developer/SDKs/MacOSX10.6.sdk/usr/include by default for system includes.
There are various possible workarounds - I would probably just put a symbolic link in /Developer/SDKs/MacOSX10.6.sdk/usr/include pointing at /usr/include/openssl but you can probably think of others now that you know the underlying problem.
It might depend on the fact that HFS(+) is case insensitive. The error message talks about "Openssl/bio.h" with capital "O", but you're specifying "openssl/bio.h" in the include and the path with /usr/include works.
I suspect that there's some "Openssl" (capital "O") directory in your include path, that gets used when looking for "openssl/bio.h". This wouldn't happen if HFS(+) were case sensitive from the very beginning (I know it's possible to have is case sensitive, but it's actually a PITA to use...)
I've been able to avoid having to specify paths on includes by simply making sure to select Create groups for any added folders for the Folders option in the Add Files to Project dialog which pops up when you're adding the files.
With the other option, Create folder reference for any added folders, I have to manually point it to the file via the full path (and the folder icons show up blue instead of the normal beige). Interestingly, even in this case, AutoComplete sees the file, but Xcode complains it can't find it.
Background: Keil C51 on a PC, currently moving to GCC (CrossPack-AVR) on an iMac.
Since I write firmware for micro's I have a lot of 'driver' source files etc. that I need to include with my programs, e.g. a LCD driver, i.e. reusing code. These code snippets (.c and .h files) live sub folders in a /snippets/ folder, i.e. /snippets/lcd/. My /snippets/ used to be in a folder that also had a /projects/ folder for, well, projects or applications. I had considered putting them in a library but I use various architectures so it would not always work.
The Question: How can one set that up in GCC without having to specify absolute paths to the snippets in, for example, the various #include paths etc. so that the source file, of the included snippet, gets re-compiled along with the project that uses/includes it? Thus, if I improve on a snippet, it benefits all projects that is compiled/re-compiled subsequently?
I looked around on google but must be using the wrong search term.
Thanks!
I think make files will do the trick.