> On Dec 14, 2014, at 2:34 PM, H Miersch <[email protected]> wrote > apparently xcode has decided to try to drive me nuts.
Didn't have to decide; it's default functionality. By the way, and I'm trying to be better than my usual impulse to sarcasm, could you please, please use your shift key? You have to use it for code anyway, so the trouble is nothing you aren't used to, and you are discussing symbols for which all-lower is a misspelling. It's hard to read. > in my current project i have a subclass of nsview (button1). i needed a > similar class (button2) so i duplicated the files for button1 and started > deleting the parts i didn't need. thing is, i accidentally edited the wrong > header file (button1). so i threw it away and duplicated the button2 header > file back to button1, then edited the header file for button2. so far so good. This is an odd approach to class refactoring, and you might spare a moment to consider whether a version-control system could have saved you so much trouble. Are you able to adopt tools and an OS that aren't one or two major versions back? Not everybody has that luxury, but more bugs have been fixed than introduced since 2012, and most people have trouble giving useful advice on things they haven't used recently. But these are beside your literal questions, so let's take your problems as they are, as you describe them. As usual, I have no clue about your exact problem. I can only go through What I'd Do Next. > now the problem is that when i try to build, xcode gives me a file not found > error on the header file for button1. i've tried everything i can think of ... First thing: Select the problem .m file and Product > Preprocess, or use the assistant of the same name, or the Related Items menu command (that's in the drop-down at the very left end of the jump bar). This will give you the preprocessor's idea of what's in the file and where it's looking for #includes. (You aren't putting your header name in angle brackets, right?) Next. Select the files in question in the Project navigator, and examine the File inspector (first tab in the collapsible area on the right). This is what the project thinks the file is. Where does the inspector say the file is? Is there such a file? (You say so, but this is a checklist.) Is it the one you intend? If there is more than one file of that name in the project's directory tree, whether in the Project navigator or not, are they (near) duplicates, and can you reduce them to just one, in the proper directory? Can you take the unused ones out of the tree? Can you bury them in zip archives? The File inspector will say that it is using an absolute path, or one relative to something. Any surprises? You may not expect "relative to group." It's the one exception to the rule that the project list has nothing to do with the file system — a group has a home directory, and its members may be located relative to it. Figure out whether the group directories and the relative paths make sense. The inspector doesn't say the header is an actual part of a target, does it? Unless you're publishing a library or framework (or something more exotic), it shouldn't be. The build system caches names and locations of headers in "header maps" (.hmap), somewhere in the derived-products library directory. These sometimes get out of sync. Everything does. Close your project, keeping Xcode open. Open the Projects organizer (sh-cmd-2 in Xcode 5?), find your project, and click the button that trashes the derived-products directory. Reopen the project and see if the problem persists. Ironically, Mac development tools suffer side effects from the file system being case-insensitive by default, while everything else in the toolchain is case-sensitive. Those effects can be subtle. Audit your code and file names to see whether your assumptions about when case matters are correct. Look in the Reports navigator and select the last build that failed. Expand the build log to find the broken compilation, and click the hamburger button that appears at the right end of the line. This is the actual clang command and results. Paste that into an empty text file — it's unreadable as is. Audit the file paths, including the .m file, and the search paths for headers. Is your header on those paths (it probably is)? Ahead of any other file with the same name, ignoring case? A lot of people have died of naming one of their own headers Strings.h. And now someone will jump in with an on-point solution I hadn't thought of. I'm making private bets on who they'll be. — F _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
