Re: Copy Build Phase should keep modification Date
Re: Copy Build Phase should keep modification Date
- Subject: Re: Copy Build Phase should keep modification Date
- From: Bernie Maier <email@hidden>
- Date: Fri, 28 Apr 2017 22:57:17 +1100
Gerriet M. Denkmann:
Ok. I made a Run Script (running before Copy Bundle Resources). Seems to
work ok.
[...]
But: In Xcode’s Project navigator I have a group (not a folder reference)
which contains several files; let’s call it “Group of Files”.
How can I access the content of “Group of Files” in my Run Script ?
Currently I have the names hardcoded, which is not very nice - especially if
I add other files to “Group of Files” later on.
Fair point. I haven't bothered trying that. I usually have a source directory
that only contains the files (and subdirectories) I want to copy, or at worst
an easily filterable set of files. And a command like rsync easily deals with
syncing entire directory trees (with or without filtering).
I could use set up Xcode the "Input Files" and "Output Files" fields in the
run script build phase settings (these are accessible in the script via
environment variables), but I've rarely felt it worth the effort. I see
nothing preventing you from putting a directory name in there rather than a
file name. But I don't think you can refer to a group of files that you have
defined in Xcode's Project Navigator. I can see this would be a useful feature.
<sidetrack type="philosophical">
But for me it boils down to where do you want to encode knowledge about your
source and destination file / directory structure. Given all IDEs I've
encountered are very good at dealing with the subset of build tasks they are
designed for, and poor at anything outside those limited bounds, I take the
view that the IDE's own files do not need to encode all knowledge about the
build files. They just need to encode enough to manage what they need
themselves, then call out to scripts or whatever else to deal with the rest.
And it all goes under source control, so the integrity of the project as a
whole is maintained. But the IDE doesn't have to do everything.
In particular, I personally don't bother adding to Xcode every resource file
that is ultimately destined for the built bundle. I'll generally only add to
Xcode the files it actually needs to process in some way, or are readable /
displayable in Xcode. Sure, if you have a flat bunch of resources that go into
a flat bundle, it's easier to add them to Xcode and use the built-in copy
files build phase. But as soon as you want more structure, why bother doing it
in Xcode?
</sidetrack>
There sure is some scope for Xcode feature requests for Xcode extensibility. I
haven't looked at the extensions API, but I gather it's more geared to editor
extensions rather than file management and organisation. Hopefully I'm wrong.
- Bernie
_______________________________________________
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