Add complete list of copy types to PBXCopyFilesBuildPhase.

These commits do 2 things compared to the original code:
1.  complete the mapping of build-setting names to Xcode destination spec code
2.  change the RE used to separate the build setting name from any trailing path elements to a non-greedy match so that build-setting variables can be used in the trailing part of the destination.

No. 1 enables specification of any of the destinations available in the Xcode 5.2 UI. The current code supports only "Products Directory" and "Absolute Path". With proper understanding of Xcode build setting variables and the Xcode generator, any destination can be specified as an "Absolute Path" so this change does not enable any new functionality. It just makes it easier and generates a more user friendly project file.

No. 2 enables the above mapping to extract and match $(VAR1) from destination specifications like $(VAR1)/$(VAR2) as well as $(VAR1)/relative/path. Once matched the GUI Destination field will be set appropriately. The previous greedy match, would only extract VAR1 from a spec like $(VAR1)/relative/path. As a result the Destination shown in the GUI for these 2 cases would have different values while the gyp file would suggest they should be the same.

The updated patch adds the RE fix and also fixes an error in the list added by the first patch which was mapping EXECUTABLES_FOLDER_PATH to destination code 6. Xcode uses EXECUTABLE_FOLDER_PATH as the destination for code 6.

It also changes handling of the "XPC Services" destination so gyp files can simply use XPCSERVICES_FOLDER_PATH just like any other destination.

Will this break anything?

I have run the mac and ios tests and got identical results before and after the change.

There is no possibility for the first change to break any working gyp projects as they could only use BUILT_PRODUCTS_DIR and that is still first in the map.

The second change could not change the build result of any working project but a project using e.g. $(BUILT_PRODUCTS_DIR)/$(EXECUTABLES_FOLDER_PATH) will see the Destination in the UI change from an "Absolute Path" of $(BUILT_PRODUCTS_DIR)/$(EXECUTABLES_FOLDER_PATH) to "Products Directory" with a subfolder of $(EXECUTABLES_FOLDER_PATH). The final destination is the same in both cases.

[Ken Russell (switch to Gerrit), 2014-08-11 17:42:06]

Brad, Brett: would either of you be prepared to review this change? Thanks.

[brettw, 2014-08-11 21:03:22]

I don't know what any of this stuff is, removing myself.

[Ken Russell (switch to Gerrit), 2014-08-13 06:22:34]

Mark, Robert: any chance either of you would be prepared to review this?

[Mark Mentovai, 2014-08-13 17:56:43]

This needs tests.

I’m not positive that Xcode can deal with variables to expand in the dstPath
property. It didn’t used to be able to, but this may have changed. You say that
this is what you’re targeting with your non-greedy RE change, so you should
definitely add a test for that.

https://codereview.chromium.org/391223002/diff/20001/pylib/gyp/xcodeproj_file.py
File pylib/gyp/xcodeproj_file.py (right):

https://codereview.chromium.org/391223002/diff/20001/pylib/gyp/xcodeproj_file...
pylib/gyp/xcodeproj_file.py:1955: 'BUILT_PRODUCTS_DIR':               16,  #
Products Directory
Can you sort this list a little bit better?

https://codereview.chromium.org/391223002/diff/20001/pylib/gyp/xcodeproj_file...
pylib/gyp/xcodeproj_file.py:1960: 'EXECUTABLE_FOLDER_PATH':            6,  #
Executables.
No period at the end of this comment.

https://codereview.chromium.org/391223002/diff/20001/pylib/gyp/xcodeproj_file...
pylib/gyp/xcodeproj_file.py:1994: separator = '/'
I think that separator is '/' if match group 2 is not empty, and '' if it is.
It’s subtly different from using match group 3.

[msc, 2014-08-27 00:32:56]

On 2014/08/13 17:56:43, Mark Mentovai wrote:
> This needs tests.
Absolutely agree. I have made a start but still have a lot to learn about the
gyp tests.

> 
> I’m not positive that Xcode can deal with variables to expand in the dstPath
> property. It didn’t used to be able to, but this may have changed. You say
that
> this is what you’re targeting with your non-greedy RE change, so you should
> definitely add a test for that.
It definitely works in Xcode 5.1. I have not used any earlier versions so can't
speak to those.

> 
>
https://codereview.chromium.org/391223002/diff/20001/pylib/gyp/xcodeproj_file.py
> File pylib/gyp/xcodeproj_file.py (right):
Is this suggesting a change or seeking confirmation that this is the file to
review?

> 
>
https://codereview.chromium.org/391223002/diff/20001/pylib/gyp/xcodeproj_file...
> pylib/gyp/xcodeproj_file.py:1955: 'BUILT_PRODUCTS_DIR':               16,  #
> Products Directory
> Can you sort this list a little bit better?
What ordering would you suggest? It currently follows the ordering in the Xcode
UI.

> 
>
https://codereview.chromium.org/391223002/diff/20001/pylib/gyp/xcodeproj_file...
> pylib/gyp/xcodeproj_file.py:1960: 'EXECUTABLE_FOLDER_PATH':            6,  #
> Executables.
> No period at the end of this comment.
Fixed.

> 
>
https://codereview.chromium.org/391223002/diff/20001/pylib/gyp/xcodeproj_file...
> pylib/gyp/xcodeproj_file.py:1994: separator = '/'
> I think that separator is '/' if match group 2 is not empty, and '' if it is.
> It's subtly different from using match group 3.
I set the separator to '' if match group 3 (relative_path) is empty. If I am
reading the RE
correctly, I can't see any way for match group 2 to be empty and match group 3
to be non-empty.
Match group 2 is either '/' or '/<match group 3>'. So match group 2 can be
non-empty and
match group 3 empty but not the other way around. I think the match group 2
empty case
is handled.