I am currently trying to swap static libraries in one of my projects which requires swapping find_package() commands for explicit links to static libraries. One of the problems I encountered is that even after deleting find_package() commands reloading the CMake Project the old variables are still present.
Is there a way to explicitly flush the CMake cache other than manually deleting all files from the temporary folder Clion creates for building the project?
Starting with CLion 1.5 144.3143 (2016-01-20), you can clear the cmake cache without loosing the CLion indexes and without restarting (meaning: very fast, also on huge projects):
Tool | CMake | "Reset cache and reload project".
If that for some reasons is not enough, or if you have an older CLion, you can do the more radical:
File | "Invalidate Caches / Restart"
and click on "Invalidate and restart".
EDITS
2016-01-20: add the faster method available with newer CLion.
There is some magic with this cache.
I got bad value for one variable once: by some reason cmake found some wrecked freetype includes inside mono.framework (another reason to dislike mono...) and tried to use them to compile my project. Obviously compilation failed.
I tried to remove CMakeCache.txt and rebuild project but incorrect path come back. Even after I removed mono.framework dir!
The solution was to remove incorrect line from the cache and restart the build. After that cmake got the correct path and build succeded.
UPD:
After I "reload cmake project" incorrect value came back. Deleting everything in $HOME/Library/Caches/clion11/cmake/generated/ dir (for OS X) seems to finally solve the issue.
Related
My goal is to use a script/CMake to create a "Debug" build configuration and a "Release" build configuration that can be switched between within Code Composer Studio's UI (using the "Build Configuration -> Set Active..." option).
Currently,
A script is ran that runs CMake with desired commands (toolchain, etc). A Code Composer Studio project is generated (as described in CMakeLists.txt)
CCS project is imported into CCS
The problem is this only generates a "Debug" build configuration. Is it possible to add a command to CMakeLists.txt, or to cmake command line, or even ccs command line that allows multiple build configurations to be generated?
The only difference between the two will basically be defining NDEBUG, and possibly changing optimization level.
I had this same question...then realized I am the one who originally asked this ~4 years ago! Anyways, I found a way to do this:
Using Code Composer, create the build configuration(s) as you want them to behave. When done, copy the .cproject file to a cproject.in "template". CMake will use this template to generate an identical .cproject for any future cmake builds. Make sure to replace any hardcoded values (ex: project name) with proper cmake variables.
For me, my CMakeLists.txt called configure_file(path/to/cproject.in ${CMAKE_SOURCE_DIR}/.cproject #ONLY).
Also be sure to delete your CMakeCache and CMakeFiles if they already exist...I believe those were preventing me from seeing the resulting change.
I'm having issues with Clion (1.0.1) and CMakeLists.txt.
I use GitHub for my projects, and I commit them from directly within the IDE. If I then checkout the project on a different computer, the IDE looks for CMakeLists.txt in the original PC's directory.
The specific error message reported by Clion is this:
Error: CmakeLists.txt not found in C:\Users\Chris\ClionProjects\SDLTestClion
However, this is a Linux machine, so there's obviously no C drive.
Here's what I've tried:
File > Invalidate Caches/Restart
Change Project Root (from the CMake Window; the obvious solution)
File > Settings > Build, Execution, Deployment > CMake
There are no settings or variables here that indicate the directory above.
I can't find anything else, so either I'm missing something or this is bugged in version 1.0.1 and I need to sift through project files to change the path that Clion looks for the CMakeLists.txt file.
Well, I found the issue. As far as I can tell, in version 1.0.1 there is no way to remedy the problem through the IDE.
Solution:
Go to projectDir/.idea
Open misc.xml
Edit the field PROJECT_DIR to point to the directory with the project's CMakeLists.txt.
I think this is a bug and this field should probably be updated when choosing a new project root. A temporary solution may be to add misc.xml to .gitignore but I haven't tested this and don't know if this will cause other problems or if the IDE will automatically regenerate the file.
Testing any changes to my Xcode project has become an exercise in patience whenever I build. After all the source files have compiled, I get the following message in the activity window at the top of Xcode:
"Running 3 of 3 Custom Shell Scripts"
I have not added any of my own custom shell scripts but I am using quite a few dependencies via Cocoapods and I am using 2 frameworks for the build environment, Crashlytics and Tapstream. Crashlytics requires you add a run script in the build phases, other than that I don't know where the other ones are coming from and they appear to be the bottleneck in my build time.
Can anyone enlighten me as to what is going on and how i possibly speed it up?
I can't enlighten you but I can tell you how I stopped mine from running. This also happened after installing Cocoapods. In my main project's Target, under Build Phases, I noticed two entries entitled Check Pods Manifest.lock and another called Copy Pods Resources.
Under both there was an unchecked option Run script only when installing. I checked both and at least for now my projects build and run fine without running the scripts.
This is kind of a crappy answer because I can't really give you any more information, and it might not even work for your case, so hopefully someone comes along and enlightens us.
POSSIBLE EXTERNAL BUNDLE ISSUES
So I just had a frustrating experience debugging an issue where a pod installed library's NSLocalized strings file weren't working. Turns out it was because I checked the option mentioned above. Pods-resources.sh, which had the lines to install the bundle, wasn't running in debug mode. It was only running when installing - of course! Something to watch out for.
More info in this question:
NSLocalizedStringFromTable not working in CocoaPod dependency
To fix the slow "Copy pods resources" problem I figured out a solution to only copy the resources if they haven't been copied before.
For this purpose we have to patch the *-resources.sh files that are created by cocoapods such that the copy procedure only happens if a generated file in the target directory doesn't exist (it is created upon first copy). As long as this target directory exists and includes this autogenerated file, the copy resources phase is skipped. This saves me about 30 seconds in my project (of course depends on your project size). To accomplish this do the following:
Create a patch file called 'copy_pod_resources_once.patch' in your project root dir with the following contents:
5a6,13
> NONCE_FILE="${TARGET_BUILD_DIR}/${UNLOCALIZED_RESOURCES_FOLDER_PATH}/copyresources-done.nonce"
> if [ -f "$NONCE_FILE" ]; then
> echo "already copied resources"
> exit 0
> else
> touch "$NONCE_FILE"
> fi
>
In the Podfile for your project add the following post install hook:
post_install do |installer_representation|
system('find "./Pods/Target Support Files" -name "*-resources.sh" | xargs -I{} patch -p0 {} -i ./copy_pod_resources_once.patch')
<other post install stuff>
end
For me, it was Crashlytics. There were some outstanding changes, as Crashlytics does auto-updating of its files. I reset/removed them and rebuilt and got past it.
So the general answer may be to check any third party components and make sure they're working properly.
As Ramsel has said in this answer,
https://stackoverflow.com/a/21318086/1752988
I also went to Build Phases and cleared out all the possible links to PODs, after trying most of the other solutions and the three build issues shown regarding Pods were cleared out.
But then one file which was not list under the XCode Project navigator was missing, but they were in the Downloaded Git Zip folder! Obviously, I copied it and put into the XCode project and try running it runs cleanly! :)
I had a similar issue in my project (however not using Cocoapods). It ended up being an issue with an application external to Xcode (Spritebuilder) somehow holding onto a resource within my Xcode project when it crashed. I forced the non-xcode application to close and now the issue is gone
Check your project folder name have any space.Because space creates problem in directory path like "SRCROOT".I removed spaces and project run fine.
I've found that this happens to me frequently. Exact cause unknown, but appears to be switching between git branches that have differences in what pods are being used. In my case simply touching the Pods-xxx-Resources.sh shell script file causes it to speed back up.
Probably not going to work for you, but cleaning the project fixed it for me (Product -> Clean)
I've now been trying to get MinGW-w64 to work on my system for several days, mainly because it has a more recent GCC version, but I either set things up wrong or there's some strange problem with MinGW-w64 itself.
I've now downloaded i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb, unpacked it to C:/Dev/mingw-ruben and added the path C:/Dev/mingw-ruben/bin to the $PATH environment variable.
What I'm trying to build is SFML 2 which comes with a CMake file. Running CMake will work just fine, the compiler gets recognized and passes all test. CMake also finds the ar.exe in the C:/Dev/mingw-ruben/binfolder. After generating the MinGW Makefile I switch to the windows command line and run mingw32-make install.
There's where the problem happens, I get the error:
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libopengl32.a: No such file or directory
Or for the network library
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libws2_32.a: No such file or directory
The error seems quite obvious and on check there really is no libopengl32.a or libws2_32.a in mingw-ruben/lib/, but the files is actually located in C:/Dev/mingw-ruben/i686-w64-mingw32/lib.
Now How can I tell ar/make/cmake to not only search in the mingw-ruben/lib directory but also in the mingw-ruben/i686-w64-mingw32/lib?
Would it be a good idea to copy all the content from the i686-w64-mingw32 subfolder to the mingw-ruben root folder?
As a side note: I can call mingw32-make install again and the procedure will continue but up on trying to link my application against SFML, I run into many unresolved symbol errors for the glXYZ functions from within SFML.
Further information: I'm on Windows 8 x64, but I think that doesn't really matter and yes I've tried MSYS but it doesn't resolve any of my issues.
Am I doing something wrong? Do I have to configure things specially?
January 2015 Edit
Now that SFML 2.2 has been released, this is no longer an issue and you have to link SFML's dependencies yourself when linking static.
January 2014 Edit
As of commit 165f2b1888 and f784fe4c07, which is included in the stable version SFML 2.1, MinGW-w64 compilers are supported.
However while discussing further with different parties it came to light, that the sfml_static_add_libraries marco a rather ugly hack was. In short it unpacked the static dependencies and included their obj files into the SFML library itself. This was most noticeable an issue, when trying to use your own version of GLEW, which failed since SFML was using its internal one already. The issue was brought to the forum and was pushed around for quite a bit, until Laurent finally gave in and went with the proper way of linking dependencies, which means you have to link them now on your own.
As of commit dbf01a775b, which is not included in the stable version of SFML 2.1, one has to link the SFML dependencies in the finally application, when linking statically against SFML.
Original
After some chat on the IRC we've figured it out.
It has nothing to do with MinGW but it's all SFML's fault. To reduce the dependencies list for SFML while linking statically the developer decided to manually extract the symbols from each library (opengl32, ws2_32, ...) which obviously isn't how one does things and violates some ODR rules. The actual error then occurs because the developer assumed that the library will be in the folder mingw/libbut with MinGW w64 it's located in a seperate directory mingw/version/lib and so ar.exe didn't find the library.
Solution
Removing the call to the sfml_static_add_libraries macro and then recompile. Afterwards you'll have to link all the dependencies for static linkages, like it should be.
I think it may be well a problem of the gcc distribution you downloaded.
A bit of light into the problem gives ruben's question here:
https://unix.stackexchange.com/questions/45277/executing-binary-file-file-not-found
that seems to me related to that (although it is about linux and not win)
I was having a similar problem (the name of the missing file was different) few months ago with gcc 4.7.0 linux->win crosscompiler. So until now I lived with the standard ubuntu mingw-w64 package and only yesterday I gave another try to i686-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar.xz and it works without issues in otherwise same environment where the previous version was failing with "..ar.exe: ... no such file". Sometimes I develop also in windows, then I use http://www.mingw.org/ that was for me much easier to setup in Win. It supports only 32bit target but for my project it is sufficient.
I'm trying to compile libzint (a barcode generator) for Windows using CMake and MinGW. The aim is to avoid Visual Studio dependencies. All run fine except that the generated .dll file contains too much exported symbols. I should have only ZBarcode_* functions but in fact pretty much anything that is declared as a variable/constant gets exported (and the resulting .dll file have no version information, I think this is strange.)
Here's how I did the job :
git clone from github repository in D:\Projects\Zint
installed cmake in C:\CMake
installed mingw in C:\MinGW
started cmake-gui, browsed to D:\Projects\Zint
clicked "Configure", choosed "MinGW Makefiles" in the list and "specify native compilers", next I specified the full path to c:\mingw\bin\mingw32-gcc.exe (to be sure...)
Clicked "Configure". It succeeded but it added some variables in red because dependencies where not met (PNG and QT but I don't want them and zint is fine without them)
clicked "Configure" again, everything turned white
clicked "Generate"
closed the cmake-gui
started a console prompt
overrode the path variable environment to C:\mingw\bin only
went to "D:\Projects\Zint" and ran "mingw32-make" then "mingw32-make install"
the libzint.dll and zint.exe were deployed to "C:\Program Files\zint-package\bin"
I used Dependency Walker to have a look at the exported functions and saw that in addition to few ZBarcode_* functions there were also around 400 other symbols and given the source code I saw that these symbols are in fact constants, arrays and other internals of libzint.
Do you know how to configure or tweak things to avoid all these exports ?
Many thanks for your help, regards.
Look in the headers for any macros that contain dllexport. If you find one or more, check that it's not malfunctioning.
Another possibility is that all classes are being exported, instead of just the few functions that are necessary.
If you have grep, do grep -nr dllexport *. This will recursively look in all files. For every hit, it will print the file name, line number, and contents of the line.