Im trying to run a cmake file, however i keep getting an error in which cmake is trying to find a source file, however I have already deleted this source file since i do not need it, but no matter which directory i make the new cmake file, it keeps throwing an error trying to find this deleted file even though its not used at all.
I have deleted the old project, and removed the old cmake files however i still get this error.
Related
I have come to this problem several times: Something on my system has changed so cmake got confused and cannot parse the project anymore.
When I just setup everything from scratch it works.
What I tried to solve the problem was following:
delete cmake cache
delete everything in the build folder
delete the cmakelist.txt.user
run cmake again -> problem still there
The only way I could solve it was to make a new build folder and set up the project from scratch, because some settings were still somewhere saved for the old build folder.
So where are those corrupted settings stored? and how can I reset them without having to change the folder??
I have been using ROS Kinetic for a while, and today when I went to make a new catkin workspace following the ROS tutorials page (http://wiki.ros.org/catkin/Tutorials/create_a_workspace) I get a CMake Error stating that PROJECT_NAME is set to Project, which is invalid. I have never run into this issue with any of my other work spaces I have created.
I do not want to mess with toplevel.cmake out of fear of screwing up my other work spaces.
Any ideas why this is happening?
CMake Error at /opt/ros/kinetic/share/catkin/cmake/catkin_package.cmake:91 (message):
catkin_package() PROJECT_NAME is set to 'Project', which is not a valid
project name. You must call project() before calling catkin_package().
Thank you.
I was able to reproduce the above error you are getting. For that what I did is opened my CMakeLists.txt and commented the second line which defines the package Name, i.e., project(package_name). After that, I tried to build my package via catkin_make, but got below error(see the error inside yellow box):
Then, I tried to build the same package after uncommenting the above line. This time I was able to build my package(test, in my case) successfully, without any error.
CMakeLists.txt file contains project() as well as catkin_package() and the former function should be called before catkin_package() inside the file. So, project(package_name) is either missing from your CMakeLists.txt file or is commented.
If it is missing, then manually add it. If it is there, but commented then uncomment it.
Read more about the correct format of CMakeLists.txt file from here.
ironically, you'll be running : sudo apt-get install ros-<distro_name>-catkin to reinstall catkin because even if u clear your entire workspace the problem will persist due to some symbolic link or something broken in the package which will always result in the same error, upon reinstalling catkin it worked for me, knowing that I had the exact same issue.
Had to come answer this because I think I did the same thing OP did. Here's what happened: There are supposed to be TWO CMakeLists.txt in your project folder. One lives at ProjectName/src and should be read-only and should actually be a link to your /opt/ros/your-ros-distro/share/catkin/cmake/toplevel.cmake folder.
If you do like I did, and I'm assuming like OP did, and edit that file, and then use your superuser to overwrite that file, then you are (1) breaking all of your catkin projects, because ALL of the catkin projects link to this one file, AND you're misconfiguring this project because the CMakeLists.txt file you're supposed to modify actually exists a folder deeper, at ProjectName/src/ProjectName/. THIS is where you're supposed to put the CMakeLists.txt file that names your project, where your package.xml file is supposed to go, etc.
If you use superuser to force-overwrite the read-only CMakeLists.txt file then you're going to have a bad day. Fortunately you can fix that file by fixing the toplevel.cmake folder, which you can do by reinstalling the catkin package: sudo apt-get install --reinstall ros-indigo-catkin
And, to put this in terms of OP's question specifically - the project() needs to get named at the inner file, the ProjectName/src/ProjectName/CMakeLists.txt, because again the root file is read-only and should never be modified.
I've got a project that debugging was working just fine about an hour ago, and now after the latest rebuild I can't get it to load the symbol files, so I cannot hit my breakpoints.
I've tried everything suggested here on Fixing “The breakpoint will not currently be hit. No symbols have been loaded for this document.” and cannot get it to load my PDB. There are a ton of questions on .PDB files not loading here on SO and I've spent the last hour going through as many of them as I can and trying everything suggested, but to no avail.
I've tried Build>Rebuild Solution, Build>Clean+ Build>Build Solution, Build>Clean + Build>Rebuild Solution, manually deleting all files from the BIN output folder + Build Solution and/or Rebuild Solution. The same thing happens in each case; the compiler creates a brand spanking new .DLL and .PDB file, yet the .PDB refuses to load at runtime.
I've even tried Debug>Windows>Modules>[Right-Click on offending symbol library]>Load Symbols and I manually browsed to the correct .PDB file, but when I hit Open it just tells me "A matching symbol file was not found in this folder".
Using Debug>Windows>Modules>[Right click...]>Load Symbol Information gives me:
C:\Windows\ssoederPDMupgrade.pdb: Cannot find or open the PDB file.
C:\VS_TestFolder\EPDMAddIns\ssoederPDMupgrade\bin\Debug\ssoederPDMupgrade.pdb:
PDB does not match image.
C:\VS_TestFolder\EPDMAddIns\ssoederPDMupgrade\obj\Debug\ssoederPDMupgrade.pdb:
PDB does not match image. C:\Windows\ssoederPDMupgrade.pdb: Cannot
find or open the PDB file.
C:\Windows\symbols\dll\ssoederPDMupgrade.pdb: Cannot find or open the
PDB file. C:\Windows\dll\ssoederPDMupgrade.pdb: Cannot find or open
the PDB file.
C:\Users\ssoeder\AppData\Local\Temp\SymbolCache\ssoederPDMupgrade.pdb\afe14027e9c6490883d12f2f139cb5911\ssoederPDMupgrade.pdb:
Cannot find or open the PDB file.
C:\Users\ssoeder\AppData\Local\Temp\SymbolCache\MicrosoftPublicSymbols\ssoederPDMupgrade.pdb\afe14027e9c6490883d12f2f139cb5911\ssoederPDMupgrade.pdb:
Cannot find or open the PDB file.
C:\VS_TestFolder\EPDMAddIns\ssoederPDMupgrade\obj\Debug\ssoederPDMupgrade.pdb:
PDB does not match image. SYMSRV:
C:\Users\ssoeder\AppData\Local\Temp\SymbolCache\ssoederPDMupgrade.pdb\AFE14027E9C6490883D12F2F139CB5911\ssoederPDMupgrade.pdb
not found
SYMSRV:
http://msdl.microsoft.com/download/symbols/ssoederPDMupgrade.pdb/AFE14027E9C6490883D12F2F139CB5911/ssoederPDMupgrade.pdb
not found
http://msdl.microsoft.com/download/symbols: Symbols not found on
symbol server.
Not much of an answer but...
I think something became corrupt in VS Express 2013. I have no idea how or why - and I may be totally wrong here, but the simple matter is what got my breakpoints working was installing VS Community 2015.
After installing VS Community 2015 (VSC 2015) the symbol file loads without problem, and all breakpoints are hit. This also got everything working in my existing VS Express 2013 (VSC 2013) installation, so I can work in either one now without problem.
Event timeline:
I've been working in VSE 2013 on this same project for a month or two now. Writing a class library, debugging using Debug>Attach to process.
I made some changes yesterday to code within a single class module (no other changes) and used Build>Rebuild Solution to clean and re-generate the current configuration (DEBUG) output files.
Event horizon: I went to debug using Attach to process as usual, and my break point appeared hollow with the message it would not be hit because no symbols had been loaded.
I spent quite a bit of time trying to work this out before posting here (see my original question for details on what was tried).
Received suggestion from #HansPassant regarding use of Symchk from command line. Tried to follow instructions linked to and was unable to get it working - command line didn't recognize Symchk or Symchk.exe as valid commands/processes/etc.
I downloaded WDK 8.1 update and installed.
Opened VSE 2013, received an error message regarding a driver failing to load, application froze before loading up. Actually, after trying multiple times I found it would sometimes get to the welcome screen - but remained unresponsive even then.
Went on M$ VS site to download latest copy of VSE 2013 installation files to do a repair-install, and I noticed there was a newer version: VSC 2015.
Downloaded and installed VSC 2015.
Opened project, started debugging by using Debug>Attach to process and it worked - all symbols loaded and my breakpoints worked. NOTE: I changed nothing with the project * - just opened it and ran.
* unless some changes are made by the IDE unbeknownst to me just by opening the project.
This seemed to repair whatever driver was corrupted in the VS2013 install as well, as I went back to VSE 2013 and it opened without error AND I was able to open the same project and do Attach to process and all symbols loaded and breakpoints are working again.
I had the same problem with VS2013 Ultimate. I did a clean and build of the assembly several times, and I deleted all temporary files from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files.
I also verified that in "Debug -> Options and Settings -> Symbols", there were no modules excluded... in the end, I found a reference that was different from that deployed into the GAC.
I'm glad you got it to work CBRF23! I had this problem when trying to compile a DirectX effect file in DevC++. The easiest way I found of downloading pdbs is to first download WinDBG here:
http://go.microsoft.com/fwlink/p/?LinkId=536682
Then as an example, say you want to download d3dx9d.pdb. copy d3dx9d.dll from C:\windows\system32 and paste another copy into your (debugger) windbg symchk.exe folder, then connect to your internet server, go to the windows start menu, Run: [then type] cmd [press enter], next go to the windbg debugger folder by going to the Command Prompt (MS-DOS Window)
(if it's in the C:\windbg_6p12p0002p633\debugger_x86 folder for example, then type):
cd windbg_6p12p0002p633[enter]
cd debugger_x86
[and finally type the following but change the double asterisk** to one asterisk *:]
symchk /if d3dx9d.dll srv**c:\symbols*\mainserver\symbols*https://msdl.microsoft.com/download/symbols
Please note again, that there is only supposed to be one asterisk after srv (the post would interpret an asterisk as italic or bold), not two then it will open symchk.exe and download the pdb symbol file associated with the inputted dll into the created C:\symbols\ folder automatically!
Did you try these steps?
1- delete the .SUO file
2- make a CLEAN BUILD.
3- make a BUILD PROJECT
I have switched my XCode version from 3.2.6 to 5.1.1, I have been asked to change the project settings and porting to a new format and resolved many compilation errors as well.
Now there is no compilation errors i could able to build my project successfully.
When I tries to sign the project using codesign v2 (mac 10.9.5) i could see the following error
"Abc.app unsealed contents are present in the bundle root"
To Resolve I have gone through the below link and tried to create a bundle structure as mentioned in it, but i'm missing something basically I don't know what it is.
Codesign: What are unsealed contents?
My folder Structure would be similar to below, if anyone has seen discrepancy kindly mention what i need to correct.
/src/Abc/
Abc.xcodeproj
build\
doc\
English.proj
Info.plist
Installer.pmdoc
InstallScripts\
Japanese.lproj\
Libraries\
Abc_Prefix.pch
Abc.pmproj
Package\
Resource\
*.png, *.icns, *.jpg, setting.plist
Source\
Uninstall\
zh_TW.lproj\
In my experience, this error message means I've left some files in the same folder level as the Contents folder.
Everything must be inside the Contents folder.
Try moving whatever files are on the same level as the Contents folder to somewhere inside the Contents folder.
If CMake is re-executed after the source directory is moved, an error like this is given:
CMake Error: The current CMakeCache.txt directory /new-path/CMakeCache.txt is different than the directory /old-path where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt
What is the best approach to deal with this? It seems that deleting the cache works. Why might I want to edit CMakeCache.txt, rather than just delete it?
I think your best bet is indeed to delete the cache and re-create it. In fact, I tend to go further and remove the entire build tree if I need to move the source, but this is probably overkill.
The CMakeCache.txt file can be edited via the CMake GUI or by hand if you're sure what you're doing, but I find it's not usually worth the effort compared to re-running cmake from scratch. I guess if running CMake takes a significant amount of time (e.g. if you use ExternalProject_Add which could involve downloading and building a third-party resource), it may be preferable to modify the CMakeCache.txt.
This article provides a bit more detail about the CMakeCache.txt file and editing it. In particular it says:
The main reason for editing the cache would be to give CMake the location of a native library such as JPEG, or to stop it from using a native library and use a version of the library in your source tree.
CMake will not alter an existing entry in the cache file itself. If your CMakeLists.txt files change significantly, you will need to remove the relevant entries from the cache file. If you have not already hand-edited the cache file, you could just delete it before re-running CMake.
I applied below two command and worked for me.
flutter clean
flutter pub get
flutter clean + flutter pub get is the easiest solution
I ran into same error while running a CGAL code (which I had already compiled sometime ago) . All I did was create a new directory and copy the ".cpp" file there and run " CGAL_create_CMakelists " and then run cmake command.It worked this way. I don't exactly know but I think the error comes when you run the code which was already compiled and has its build files already in the folder(due to previous compiling).