Classes in Swift files inside folder references not seen by Xcode 10's compiler
Asked Answered
S

1

5

We have a project with nearly 1K Swift files. It just works well if everything is inside groups, but when trying to add some folder references to directories that contain Swift files, the compiler just can't see any thing defined inside these files (classes, for example). It works well for bundle and data files, but not for source code.

I also tried changing existing groups to folders using different methods (dragging, using the menu and manually browsing, etc.) and XCode stops seeing the entities declared inside these Swift folders' files. When I switch the same folder back to a group (delete -> remove reference -> add files to project...), it works again.

Please note that I opened the File Inspector, and already ensured that the target for the reference folder was checked. Also tried to uncheck it and checked again, just in case there is just-another-XCode-bug when adding files. Nothing worked.

Another experiment that I've done was consisted of moving a folder to the root directory, so the folder was not inside a group. Didn't work either.

After each try, I always cleaned the project's build folder, just in case.

Please note that the following questions did not provide anything useful tip for fixing this:

And of course, this another one does not make sense to me since I want folders, not groups, because I find them much easier to use and specially, to maintain, given the large amount of Swift files of this particular project: Adding Folder to Xcode Project is not Properly added

Sentimentalize answered 24/9, 2018 at 17:8 Comment(0)
R
8

It works well for bundle and data files, but not for source code.

Yup, well, that's because those are completely different kinds of thing, and need to be treated in completely different ways.

You can't put code inside a folder reference (blue). That would simply mean "copy this code file into the body of the app", which would be silly. That's the kind of thing you would do with bundle and data files.

If the problem is to organize your code file references within the project window, you can use:

  • a group (yellow with a red mark in the lower corner)
  • or, a folder-linked group (yellow plain and simple)

In the latter case, the code file itself will also be placed in the corresponding folder on disk inside the project window, so this is also a mode of organization on disk.

NOTE But note that you must always let Xcode itself organize the contents of the project folder! You must work entirely within the Project inspector in the project window. Stay out of the Finder. Otherwise, you'll break your project.

Refractory answered 24/9, 2018 at 17:17 Comment(10)
We are using only folder-linked groups always, but something that bothers us specially is if one developer removes a file and does not "move to trash", then the file remains and it is difficult to track. So I hoped to have a mechanism as in many other IDEs to just add a folder that automatically reflects the file system content, without having to take care of unused files, as with folder-linked groups.Sentimentalize
I guess what I'd suggest is that you just not worry about it. You'll build up a collection of unreferenced files inside the project folder, but these do not add to size of the git repo and, since no further changes in them will be made, they will not clutter subsequent commits. However, if that's not a sufficient approach, perhaps you should ask a question specifically about your git situation. This question is basically an x-y question: you're having a git cooperation issue, but instead of asking about that, you asked about folder references instead.Refractory
Of course you could correct the dev's mistake by doing what I said not to do, i.e. reach right into the project folder and trash the file. This can do no harm if there are no longer any references to it in the project. But this is so risky that I'd say it's better just to ignore it.Refractory
I added source code as a folder with Group References and it shows up yellow. How can those source files be accessed by the existing controllers? Using import mysubproject where mysubproject is the name of the folder placed inside Sources does not workEustashe
@javadba They don't have to be accessed. If they are part of the app target, they are part of the app target. Are they?Refractory
@Refractory I do not even know where or see the targets. That is curious. I am feeling my way around the xcode gui. Will likely post a separate question to allow me to post screenshotsEustashe
I see what you mean now: in the "Add files to <myProject>" I did have the myProject checked in the "Add to targets" list. But I get "module not found" on the directoryEustashe
Because the directory is not a module. The files are part of the target, and the group is irrelevant.Refractory
At the risk of being annoying : how can those newly added source files be "found" in the existing sources? The relationship between group, target, module etc is a whole new concept. I will try to find some material to enlighten. V frustrating to spend 95% of time on xcode and 5% on coding in swift.Eustashe
Oh! It's because a yellow group has no meaning at all, except as a way of helping you organize the Project Navigator to make it easier for you to see your files. As far as the compile and build process is concerned, the yellow group folders are basically not there at all. To see this, go to the target's Build Phases and look at the Compile section; you will see all your swift files as a big flat list. That is how the compiler and build process sees them. They are all just part of one big target, with no divisions.Refractory

© 2022 - 2024 — McMap. All rights reserved.