Re: Headers in folder references
Re: Headers in folder references
- Subject: Re: Headers in folder references
- From: Rick Mann <email@hidden>
- Date: Tue, 31 Jul 2012 03:00:36 -0700
On Jul 31, 2012, at 1:02 , Andreas Grosam <email@hidden> wrote:
>
> On 30.07.2012, at 22:25, Rick Mann wrote:
>
>>
>> On Jul 30, 2012, at 3:18 , Andreas Grosam <email@hidden> wrote:
>>
>>> You better should not dislike it :) In fact, this is the method to get your header path issues solved. Otherwise, your headers seem to appear in a flat namespace - calls for trouble in a more complex project.
>>
>> I don't like having to set header search paths for files already IN the project. This means there are two independent parts of the UI that can get out of sync. If I move a file in the project, I have to remember what impact that might have on the header paths I've set in the build settings.
>
> Setting a header search path manually is not that cumbersome as you might think. The search paths settings are NOT independent, instead *your* build settings will have *precedence* to the paths set by Xcode. What you gain is "structure", better readability of your code and conflict free import of headers (example below).
>
> In a more complex (iOS) application, you should give your code a meaningful structure anyway, that is you should logically divide your sources into folders and subfolders. My personal preference is to group "features", that is, I put (almost) everything into one subfolder that constitutes for example the feature "User". This includes views, controllers, resources, and possibly models (CoreData managed object classes) - instead of putting controllers to a "Controllers" folder, resources into a "Resources" folder and so on - or even putting everything into the "Classes" folder as it is the default.
>
> There are many ways to structure your code, for several reasons: helper classes, base classes, libraries, etc.
> You should just utilize the structure and reflect that in your code - *and* in your import directives as well! The reason is obvious once you compare a big project with say more than 300 files where almost all sources are put into one folder and one that logically subdivided it into a reasonable folder hierarchy.
Unfortunately, that doesn't work when the headers you're using are generated by a tool that doesn't do the same thing.
And by independent, I mean that if I change the file hierarchy in the project, I have to remember to change the header search paths.
Whether or not to search a particular folder (or group) in the Xcode file hierarchy should be a property of that folder. That way, if I move it, or rename it, or whatever, search paths go with it.
But because the current search path setting is buried down inside the build settings (and could be on the project, or the target), it's MUCH harder to make sure it's kept consistent.
What we have right now is at least two ways to set search paths. One is by adding a folder as a group, the other is by modifying the build settings.
--
Rick
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden