I seem to have some files in my Xcode project that I can't erase. I've tried right-clicking->deleting, dragging out, Build->Clean, anything I can possibly think of.
Any ideas how to get rid of these renegade files?
I'm sure in an older version of Xcode you could dig around (AT YOUR OWN GREAT PERIL!) inside the .xcodeproj file (show package contents and look in there) and somewhere was an xml file which held everything like that. However, I have just had a quick look and didn't see anything that looked likely. Try grepping the files in there for your rogue filenames and see if anything shows up.
If you don't get anywhere in that route you might be able to trick it by creating those files (or at least files with those names) again, then re-importing / re-deleting them.
Related
Is there any way to download gradle-kotlin-dsl-6.6.1.jar source file by idea or manually with a link?
I wanted to read the source code of the functions in this dependency, I couldn't find the source code also.
I reasoned that, since the plugin is working for me, the code must've been downloaded. What I've found is that (in Android Studio under Linux), if I ctrl-click on a keyword in (anything, I think, but in this case) a build.kts file it takes me to the definition.
Doing this, I can then hover my cursor on the tab name and it shows me where the file is. Mine is way down under /.gradle, but the point is it does tell me where.
So, while I haven't found the jar file itself, I'm thinking that each of the files found like this are part of it. Does that help enough, or at least a bit?
I'm working on a project in Pycharm, and lately I've noticed an odd thing: empty files are being created that mirror the names of already existing files, but prefixed with exclamation points and numbers. They're not even necessarily files I'm actively doing anything with in the project.
For example, as I'm on a Mac, each of my directories has a .DS_Store file, and now, a couple of the directories also have something like .!19564!.DS_Store. Or where I had deployment_file.zip I now also have .!18274!deployment_file.zip. I've never been able to pinpoint the exact moment one of these files is created (as they don't occur all the time and I haven't been watching for them), so I couldn't say what is causing it.
It doesn't seem like anything I should be concerned about; it's just an unknown I would like to know. Does anybody have any idea what this is?
I've created a project and built out a several model classes. I've decided that I'd like to recycle them as a separate framework. In doing so, I want to change my class prefix of those files. The issue is, of course, that I now have to batch rename my files and my classes. I could use the refactor tool, but I have tens of classes, so it would be tedious. Is there a good way to automate the process? For reference, I'm using Xcode 5.
For anyone looking for an answer, I think I have a solution, although it's something I'd like to see built in to Xcode. I've filed a radar.(#15261680)
I had three things to worry about here:
The class names themselves. The class prefixes didn't match the framework that I wanted to put them in.
The file names. Even if I did a careful global search and replace and changed the class prefixes, the file names would be wrong.
The Xcode project references. Xcode keeps a list of your files, and I had to be sure that Xcode would know where to find my files, in the event that I renamed them.
What I did:
I did a global search and replace. Instead of clicking "Replace All", I used the "Review" pane, so I was able to exclude about ten or so cases that I wanted to keep with the original prefix.
I found a utility to do a batch rename. Now my files and classes all match nicely.
Uh oh! Xcode doesn't know where my files are, now. To fix this, I opened the .pbxproj file and did another careful search and replace. (I made sure to quit Xcode first, so my changes wouldn't be overwritten automatically.)
This was a bit of an involved process, and I was hoping that there was a tool or Xcode feature to help me do this, but alas, not yet.
All the .h and .m files are in the folder for a particular app I'm working on, but the xcodeproj file is missing, even though I worked on it less than a week ago. Looking in the Finder doesn't bring it up (though it brings up lots of OTHER xcodeproj files).
I've looked for answers to this question but I'm not understanding what I've found so I can't tell whether it helps.
I'm sure it's something completely obvious, especially as I'm very new to source control and git. Can anybody help me out?
It is possible that you are looking in the wrong folder for the xcodeproj, or that it is not currently on your system and you have to retrieve it from the repository.
Perhaps you are viewing a folder that's one level down from where the xcodeproj file is. Move up the filesystem hierarchy and see if you find the file. If you're not concerned where the file is on your system and you just want to open it in Xcode, use Xcode's File > Open Recent menu item.
If those attempts fail, you may have to check out the missing file:
How do I pull a missing file back into my branch?
I looked here, and went where Macmade said to go. I then deleted everything above #import in the two FILEBASENAME files at File Templates/Cocoa/Objective-C class.xctemplate/NSObject. However, I'm creating new classes in Xcode, derived from NSObject, and I'm getting all the same stuff as before. How can I be rid of it?
(I'm open to the possibility that I shouldn't be getting rid of it, but I don't believe it's useful in the least. Is it?)
The “junk” is comments, and comments make no difference to the preprocessor, compiler, linker, or user, so there's no harm in getting rid of it.
Like everything else in the file, it comes from the file template you created the file from. You'll need to make copies of the file templates you use and remove the comments from your copies; then, there will be no comments in any files you create in Xcode from the new templates.
I suggest removing the import(s), too, while you're at it. Your prefix header should take care of that; importing system headers anywhere else should be nothing but further noise.