Carthage: Generate xcfilelists for copy-frameworks for Xcode 10

Created on 7 Jun 2018 · 16Comments · Source: Carthage/Carthage

Xcode 10 has a new xcfilelist file type that can be used to specify the input and output files for _Run Script_ build phases. We should generate these files so that no one needs to manually specify all those files for copy-frameworks.

enhancement help wanted

Source

mdiep

👍38 ❤20 🎉1

Most helpful comment

Why are you opposed to reading the project file?

Because it's undocumented and not supported by Apple. I think it's fine to build tools on top of Carthage that do this. But inside Carthage, we don't want to build on undocumented/unsupported things.

mdiep on 22 Jun 2018

👍5

All 16 comments

YESSS

dzenbot on 8 Jun 2018

That will be such welcome change!

KyleLeneau on 10 Jun 2018

👍2

How would you generate the files? For example, how would you know what subset of frameworks are used by each target?

bwhiteley on 21 Jun 2018

I think we'd generate a list of all frameworks for each platform. Maybe we could also detect which frameworks are for testing. It wouldn't work for everyone, but it would probably work for many people.

mdiep on 22 Jun 2018

We use a tool that wraps carthage copy-frameworks and builds the input and output lists from the Frameworks listed in the target's Linked Frameworks and Libraries. Do you foresee a problem with that approach? Maybe we should build that into Carthage directly.

bwhiteley on 22 Jun 2018

If we can get that information without reading the project file, then it'd be a good fit. (i.e. if you can get the info through xcodebuild) We don't want to read or write Xcode project files.

mdiep on 22 Jun 2018

Technically, you can get it from otool:

$ otool -L Carthage/Build/iOS/<redacted>.framework/redacted
Carthage/Build/iOS/<redacted>.framework/redacted:
    @rpath/redacted8.framework/redacted8 (compatibility version 1.0.0, current version 2909.0.0)
    @rpath/redacted1.framework/redacted1 (compatibility version 1.0.0, current version 2816.0.0)
    @rpath/redacted2.framework/redacted2 (compatibility version 1.0.0, current version 2863.0.0)
    @rpath/CoreStore.framework/CoreStore (compatibility version 1.0.0, current version 1.0.0)
    @rpath/Tyro.framework/Tyro (compatibility version 1.0.0, current version 1.0.0)
    @rpath/Swiftz.framework/Swiftz (compatibility version 1.0.0, current version 1.0.0)
    @rpath/redacted3.framework/redacted3 (compatibility version 1.0.0, current version 2909.0.0)
    @rpath/redacted4.framework/redacted4 (compatibility version 1.0.0, current version 2814.0.0)
    @rpath/Alamofire.framework/Alamofire (compatibility version 1.0.0, current version 1.0.0)
    /System/Library/Frameworks/Foundation.framework/Foundation (compatibility version 300.0.0, current version 1450.14.0)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
    /usr/lib/libSystem.dylib (compatibility version 1.0.0, current version 1252.0.0)
    /System/Library/Frameworks/CoreData.framework/CoreData (compatibility version 1.0.0, current version 849.2.0)
    /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation (compatibility version 150.0.0, current version 1450.14.0)
    /System/Library/Frameworks/CoreMotion.framework/CoreMotion (compatibility version 1.0.0, current version 2237.0.22)
    /System/Library/Frameworks/HealthKit.framework/HealthKit (compatibility version 1.0.0, current version 1.0.0)
    @rpath/libswiftCore.dylib (compatibility version 1.0.0, current version 900.0.74)
    @rpath/libswiftCoreData.dylib (compatibility version 1.0.0, current version 900.0.74)
    @rpath/libswiftCoreFoundation.dylib (compatibility version 1.0.0, current version 900.0.74)
    @rpath/libswiftCoreGraphics.dylib (compatibility version 1.0.0, current version 900.0.74)
    @rpath/libswiftCoreImage.dylib (compatibility version 1.0.0, current version 900.0.74)
    @rpath/libswiftDarwin.dylib (compatibility version 1.0.0, current version 900.0.74)
    @rpath/libswiftDispatch.dylib (compatibility version 1.0.0, current version 900.0.74)
    @rpath/libswiftFoundation.dylib (compatibility version 1.0.0, current version 900.0.74)
    @rpath/libswiftMetal.dylib (compatibility version 1.0.0, current version 900.0.74)
    @rpath/libswiftObjectiveC.dylib (compatibility version 1.0.0, current version 900.0.74)
    @rpath/libswiftQuartzCore.dylib (compatibility version 1.0.0, current version 900.0.74)
    @rpath/libswiftUIKit.dylib (compatibility version 1.0.0, current version 900.0.74)

tmspzz on 22 Jun 2018

😕1

We use this library to read the project file: https://github.com/xcode-project-manager/xcodeproj

I understand not wanting to write to the project file. Why are you opposed to reading the project file?

bwhiteley on 22 Jun 2018

Why are you opposed to reading the project file?

Because it's undocumented and not supported by Apple. I think it's fine to build tools on top of Carthage that do this. But inside Carthage, we don't want to build on undocumented/unsupported things.

mdiep on 22 Jun 2018

👍5

I guess it's a work for Carting https://github.com/artemnovichkov/Carting. It scans Carthage folder and linked frameworks, gets framework names and updates the script. I'm going to update Carting with xcfilelists.

artemnovichkov on 19 Sep 2018

❤2

Carthage "copy-frameworks" build script doesn't work with Xcode 10 new build system, so I guess it must be fixed first before implementing support for generating xcfilelists: #2598

virl on 1 Oct 2018

copy-frameworks _does_ work in Xcode 10 with the new build system. @virl's project is misconfigured.

mdiep on 1 Oct 2018

@mdiep Thanks, you're right.

virl on 1 Oct 2018

Hello!
Looks like that I'm working on the same question https://github.com/Carthage/Carthage/issues/2605.
From what I understood during digging into this question: it is really easier to stay with environment variables (like SCRIPT_INPUT_FILE_#) rather than a file. File should be written somewhere on the disk before being used (even in the /tmp/). Using env variables simplifies process since we don't need to have a file but rather exporting required variables in runtime. It simplifies code a lot.

@mdiep looks like that we really want to open .xcodeproj to read linked frameworks. Otherwise we may end up copying frameworks to target A(Main App) that belong to target B (UnitTests) in case of simply copying all the frameworks.
I'm also interested in using existing tools over third-party to read linked frameworks (Xcode CLI?) but failed to find one.

What do you think?

dimazen on 5 Oct 2018

https://github.com/Carthage/Carthage/issues/2477#issuecomment-399447095

mdiep on 5 Oct 2018

Also, another caveat, if we do this, is that there should be some way to specify which dependencies to include on each platform. For example, let us say I'm building an a iOS and watchOS app that depends on Dependency A. Dependency A supports iOS and watchOS, but for the purpose of my project I just need Dependency A on my iOS app. The xcfilelist should only include the dependency on the iOS side but not the watchOS side. Ideally, there should be a way to handle this.