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??
Related
I'm a newbie to both IntelliJ and Aurelia. I did my last web project almost a decade ago, and I find myself a bit lost between all those new libraries. That said, my question is probably of rather trivial nature:
I've downloaded the Aurelia skeleton project [1], imported the sources into a new node js project in IntelliJ and started index.html. Voila. Browser opens, shows the site.
Then I changed something (added a new route to src/app.js).
I hit the run button to show index.html again: No changes. Hm?
I rebuild the project in IntelliJ, and retried. Still my changes aren't shown.
I run gulp watch on the command line, open the browser, and my changes are shown.
So, I'm asking two things: What needs to be done to really refresh the build within IntelliJ?
And secondly, when did it become a sport to create inter-depending Javascript libraries with blurry names? Just kidding... (though I'm not laughing)
[1] https://github.com/aurelia/skeleton-navigation/blob/master/skeleton-esnext/src/child-router.js
I found it out myself. You need to put 'gulp build' to the pre-launch list of the run configuration. This is because the sources get transpiled and copied to the dist directory, from where the server is actually running.
Just building the sources from IntelliJ isn't enough.
Project rebuild start automatically after any files was changed in project directory. You do not need to build it from IDE-- only save your changes and wait a few seconds to refresh.
Of cause it will work only when you run project build with watch statement like gulp watch (e.g. run gulp watch and your project will rebuild automatically).
But if there were some errors in code -- gulp process will stop and you must restart it again. I recommend you change IDE's settings to disable automatically saving to files and use <CTRL+S> buttons to save data manually.
When I create a new project in XCode 6.0.1, I got this error message: The file "exclude" doesn't exist
It seems to only impact the versioning of the files i.e. the generated stub files are not committed into github after the project is created.
What can cause this problem?
For me the issue was caused because I had previously created a project with the same name, and Xcode still had record of that.
To clear it out,
go to Window -> Organizer in the menu bar
Remove all of the repositories highlighted in red
To add your repository (if it's not being tracked for some reason),
Click the + (still in Window -> Organizer from the steps above)
Enter the path of your file
Make sure to change to Git from Subversion (if Xcode has Subversion set as default - it did for me.
I usually get this error if I initialize an Xcode project with a git repository, delete it and try to recreate it with the same name (casing doens't appear to make it sufficiently 'different'). Turns out, "Well I'll just start over" can leave some issues as well.
Hope this helps.
I had this issue as well, and I tracked it down to the .git-template folder included with Thoughtbot's dotfiles. Basically, Xcode expects its template folder to have info/exclude, and Thoughtbot's dotfiles don't. Creating that directory and file fixed the problem, as so (in the Terminal):
cd ~/.git_template
mkdir info
cd info
touch exclude
If you're getting this issue without Thoughtbot's dotfiles, you could probably look at ~/.gitconfig and use whatever templatedir is getting set as instead of ~/.git_template in the first command.
About a week ago I installed golang successfully on my computer and got it's terminal commands to process. So by that, I know go is on my computer.
I have been looking for a good IDE and found https://code.google.com/p/liteide/ LiteIDE which was made specifically for Go.
I read that if you already had go installed on your computer then you could use LiteIDE to start building your code right away. I must have read something wrong some where because I cannot get my projects to build at all. I think it there may be a missing/incorrect path and or something is just setup incorrectly.
This is the error I get in the console:
Current environment change id "win64-user"
C:/go/bin/go.exe env [c:\go]
set GOARCH=amd64
set GOBIN=
set GOCHAR=6
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=
set GORACE=
set GOROOT=c:\go
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set TERM=dumb
set CC=gcc
set GOGCCFLAGS=-g -O2 -m64 -mthreads
set CXX=g++
set CGO_ENABLED=1
Command exited with code 0.
First_Lite_Go_Proj [C:/go/src/First Litel Go Proj]
Error: process failed to start.
I checked the C:/go directory to make everything there is correct and it was. Also I'm using 64bit windows 7 and double checked that as well.
Any ideas? Mine are: Missing/Incorrect Paths, Can't access a certain directory due to restrictions.
While I have not tested this in Windows 7, on Windows 10, these were the steps that I took to make LiteIDE work
Installed Go to C:\Go
Added C:\Go\bin to PATH and made sure go was working from Command Line
This was the most important step for me. Defined GOPATH in an environment variable. In my case, it was C:\Users\vivek\Documents\Source\Go. I also made sure that there were three folders src, pkg and bin were created in GOPATH. At this point go env was showing me correct values for GOPATH and GOROOT. go get, go build and go install was working as well at this step.
Downloaded and unzipped LiteIDE to C:\liteide. Started LiteIDE and it worked out of the box for me. Make sure that GOPATH is seen correctly by LiteIDE by going to View > Manage GOPATH
Hope this helps. Good luck.
It's not a good idea to keep your projects in the GOROOT path, which per default (when installed using the MSI installer) is C:\Go. Always keep it separated from there. It also helps to avoid issues with updates.
Since Go projects are made up of packages which are organized in directory structures it is important to follow a few rules and keep the working space for your Go projects separated and clean.
In my opinion its best practice to create ONE working directory as the root for ALL your Go projects somewhere in your user space and stick to it.
One way to do this is to create a directory like "work" and set the environment variable GOPATH to it (e.g. C:\Users\Peter\Documents\work). Make sure to relog or restart your computer after your changes.
Upon certain operations Go will automatically create the directories bin, pkg and src below your GOPATH.
src contains your created or downloaded Go source files,
pkg contains your installed package objects, and
bin contains your installed executable files.
bin or pkg will automatically be created when you use the go install command to install a binary executable or a package. It's important to understand that these are files that are not part of the Go installation.
src, if it does not yet exist, will automatically be created the first time you issue a go get command or in case of LiteIDE, the first time you create a new Go1 Command Project or Go1 Package Project. Watch the "Location:" field on the dialog box, it should include your path defined in GOPATH followed by \src (e.g. C:\Users\Peter\Documents\work\src).
In the name field enter the path you want to use for your project. If you plan to track the development of your project on Github (or other repo) it's common practice to include the path to the Git repo in your source path (e.g. github.com/petergloor/hello-go).
Of course you can use any other structure to organize your projects as long you make sure they fall below the src directory in your GOPATH.
For more information about Go workspaces read https://golang.org/doc/code.html#Workspaces.
A final note about the GOROOT environment variable. Dont explicitly set this if you install Go in C:\Go. It's enough to include C:\Go\bin in your path and to set GOPATH. GOROOT is only needed in case Go is installed at another location.
I also had this problem first, but after completing the installation process, I succeeded.
Step 1:
Run (Ctrl+R) -> run target, request build first.
BuildAndRun(Ctrl+F7) -> build and run target
FileRun(Alt+F6) -> go run
step 2:
Check Config via this URL:
https://www.goinggo.net/2013/06/installing-go-gocode-gdb-and-liteide.html
Try setting up the GOROOT to the directory where go was installed. It worked for me.
Do you have 'Install' keyword in your project name? Try remove it.
You have to setup LiteIDE variables correctly (if there are not by default).
Please, check two options:
Go to Settings → "Manage GOPATH"
Options → LiteEnv (there are
environment definitions files). Just double click on someone and
setup Go environment variables.
I'm not sure how this works, but it worked in my case. I got this idea from this video on Youtube-Chris Hawkes
Open LiteIDE.
Click File---New.
Select "Go1 Command Project".
Browse the desired path.
Select the desired folder.
Name the folder and click Ok.
Now, you will be able to see a "main.go" file opened in the IDE.
Write whatever code you want to run in this file with correct syntax, it will run.
The only problem with this is, whenever I create another ".go" source code file in the same folder, the same error is shown. So, you might have to edit this file every time, you try to write new code.
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).
You come at a certain point in the development of every app that what you see in the simulator does not match what you think should happen. Mostly these are human errors -- or at least they are in most of my cases ;-) -- but sometimes Xcode has just 'lost track', or so it seems. I've learnt that the Clean (Shift+Cmd+K) and Clean Build Folder… (Option+Shift+Command+K) menu options can show the difference between your error or Xcode's.
My question though is:
What does the Clean command do or not do, which leaves a reason for Clean Build Folder… to exist? When should I pick one over the other, why not just always clean the whole folder?
If you select Clean from the Product menu, XCode will delete the files inside every folder in the Build folder, if you select Clean Build Folder it will delete the entire Build folder.
After Clean command:
After Clean Build Folder command:
I think you should select Clean Build Folder when you want to build a binary that you want to release to the AppStore, when you messed up with your project or when your app doesn't work for an "unknown" reason, otherwise use Clean.
I hope I've answered your question :D
Clean… cleans the folders for the current selected target.
Clean Build Folder… cleans the folders for all the targets.
As of Xcode 10, 'Clean' has effectively disappeared. Apple says here:
"The new build system uses the "clean build folder" behavior. The legacy "clean" behavior is not supported".
If you select "Clean", Xcode will delete files inside every folder(e.g., Products, Intermediates) in the Build folder, for the current target. Files for other targets remain.
If you select "Clean Build Folder", Xcode will delete the entire Build Folder, so nothing left.
In most cases "Clean" will work for "unknown" reasons, but you still have to "Clean the Build Folder" because Xcode won't delete files in the include folder inside Products folder.
Some files at ~/Library/Developer/Xcode/DerivedData/xxx-ABCD, where xxx is the name of your project or workspace, have been deleted after you Clean or Clean Build Folder.... Obviously, Clean Build Folder... will delete more files than Clean will do. However, I think deletion of the folder that I mentioned before is needed in some case, such as your Xcode cannot work properly.
By the way, something has changed for Xcode 8, Build folder is kept all the same after Clean Build Folder...