Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate xcfilelists for copy-frameworks for Xcode 10 #2477

Open
mdiep opened this Issue Jun 7, 2018 · 16 comments

Comments

Projects
None yet
9 participants
@mdiep
Copy link
Member

mdiep commented Jun 7, 2018

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.

@dzenbot

This comment has been minimized.

Copy link

dzenbot commented Jun 8, 2018

YESSS

@KyleLeneau

This comment has been minimized.

Copy link

KyleLeneau commented Jun 10, 2018

That will be such welcome change!

@bwhiteley

This comment has been minimized.

Copy link
Contributor

bwhiteley commented Jun 21, 2018

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

@mdiep

This comment has been minimized.

Copy link
Member Author

mdiep commented Jun 21, 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.

@bwhiteley

This comment has been minimized.

Copy link
Contributor

bwhiteley commented Jun 22, 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.

@mdiep

This comment has been minimized.

Copy link
Member Author

mdiep commented Jun 22, 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.

@blender

This comment has been minimized.

Copy link
Member

blender commented Jun 22, 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)
@bwhiteley

This comment has been minimized.

Copy link
Contributor

bwhiteley commented Jun 22, 2018

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?

@mdiep

This comment has been minimized.

Copy link
Member Author

mdiep commented Jun 22, 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.

@artemnovichkov

This comment has been minimized.

Copy link
Contributor

artemnovichkov commented Sep 19, 2018

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.

@virl

This comment has been minimized.

Copy link

virl commented Oct 1, 2018

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

@mdiep

This comment has been minimized.

Copy link
Member Author

mdiep commented Oct 1, 2018

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

@virl

This comment has been minimized.

Copy link

virl commented Oct 1, 2018

@mdiep Thanks, you're right.

@dimazen

This comment has been minimized.

Copy link
Contributor

dimazen commented Oct 5, 2018

Hello!
Looks like that I'm working on the same question #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?

@mdiep

This comment has been minimized.

Copy link
Member Author

mdiep commented Oct 5, 2018

@hyerra

This comment has been minimized.

Copy link

hyerra commented Oct 13, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.