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

Targets with same name but different type end up together in IR directory #46

Open
kjcjohnson opened this issue Sep 1, 2023 · 2 comments · May be fixed by #78
Open

Targets with same name but different type end up together in IR directory #46

kjcjohnson opened this issue Sep 1, 2023 · 2 comments · May be fixed by #78
Assignees
Labels
bug Something isn't working

Comments

@kjcjohnson
Copy link

If an archive has two targets with the same name, but of different types, the IR output is apparently being combined into just one directory in the .xcarchive. For example:

  • One project named "KeithTestApp" with a target "KeithTestApp" that produces KeithTestApp.app
  • One project named "KeithApplication" with a target "KeithTestApp" that produces KeithTestApp.framework

Outputs for both end up in IR/KeithTestApp.app. Example project set up like so:

image

$ gen-ir --version                                      
v0.4.2
$ xcodebuild -workspace KeithTestApp.xcworkspace -scheme KeithTestApp -destination generic/platform=iOS -configuration Debug -archivePath KeithTestApp.xcarchive DEBUG_INFORMATION_FORMAT=dwarf-with-dsym ENABLE_BITCODE=NO archive | tee KeithTestApp.log.txt
$ gen-ir KeithTestApp.log.txt KeithTestApp.xcarchive --project-path KeithTestApp.xcworkspace
$ tree KeithTestApp.xcarchive/IR
KeithTestApp.xcarchive/IR
└── KeithTestApp.app
    ├── ContentView.bc
    ├── KeithTestAppApp.bc
    ├── KeithTestApp_vers.bc
    └── TestFile.bc

1 directory, 4 files

Note how TestFile.bc is ending up in the KeithTestApp.app directory, when it should be in a KeithTestApp.framework directory!

Veracode does report that bitcode for the framework is missing when uploading our real app that has this quirk, so it is blocking us from being able to switch to gen-ir.

@NinjaLikesCheez
Copy link
Collaborator

Interesting - this will take a little more digging that the previous issue... I believe we can try to just use the 'path' attribute of the various file references instead of the name of the target - but not all targets have a path etc, so will need to come up with a more holistic approach.

Thanks for the report!

@NinjaLikesCheez NinjaLikesCheez self-assigned this Sep 4, 2023
@NinjaLikesCheez NinjaLikesCheez added the bug Something isn't working label Sep 4, 2023
@bmxav bmxav assigned bmxav and unassigned NinjaLikesCheez Sep 12, 2024
@bmxav bmxav linked a pull request Sep 19, 2024 that will close this issue
@bmxav
Copy link
Contributor

bmxav commented Sep 19, 2024

@kjcjohnson Sorry for the delay in tracking this one down, I know 0.5.0 had a partial fix for this issue. PR is open here #78 if you'd like to give it a shot.

Before:

$ tree DuplicateTarget.xcarchive/IR
DuplicateTarget.xcarchive/IR
├── DuplicateTarget.app
│   ├── ContentView.bc
│   ├── DuplicateTargetAppApp.bc
│   ├── DuplicateTarget_vers.bc
│   └── GeneratedAssetSymbols.bc
└── DuplicateTarget.framework
    ├── ContentView.bc
    ├── DuplicateTargetAppApp.bc
    ├── DuplicateTarget_vers.bc
    └── GeneratedAssetSymbols.bc

3 directories, 8 files

After:

$ tree DuplicateTarget.xcarchive/IR
DuplicateTarget.xcarchive/IR
├── DuplicateTarget.app
│   ├── ContentView.bc
│   ├── DuplicateTargetAppApp.bc
│   └── GeneratedAssetSymbols.bc
└── DuplicateTarget.framework
    └── DuplicateTarget_vers.bc

3 directories, 4 files

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants