Open aelam opened 1 week ago
@hyzyla Thanks for your great work! and I'm interested in the development. may I join you?
Yes, of course! I've assigned this issue to you to have visibility that you will be working on that issue
Regarding the issue, I think you are heading in the right direction. When we know the target device/simulator, I think, it's better to set the destination to a specific ID, instead of building for deneric device. Function src/build/commands.ts::buildApp
already have parameter destinationId
, but currently it's only used for "test" command. You can try to find all placeses where buildApp(..., options: {..., destinationId: null, ... })
and replace with proper destinationId
Unfortunately, this doesn't solve the issue mentioned in sweetpad-dev/sweetpad#16 because there are no separate x86_64 simulators; all simulators on M1 chips are ARM-based. We can only build the app for the x86_64 architecture, and when we run it on an ARM simulator, Rosetta will handle the process and start translating it to the ARM instruction set.
~~before I start, I got some setup issue of the project. ~~
Do you have tutorial to run this project
setup is done here.
Unfortunately, this doesn't solve the issue mentioned in https://github.com/sweetpad-dev/sweetpad/issues/16 because there are no separate x86_64 simulators; all simulators on M1 chips are ARM-based. We can only build the app for the x86_64 architecture, and when we run it on an ARM simulator, Rosetta will handle the process and start translating it to the ARM instruction set.
I think this would be the rosetta simulator
-destination 'platform=iOS Simulator,arch=x86_64, name=iPhone 15'
-destination 'platform=iOS Simulator,arch=x86_64, id=xxxx'
I tried
xcodebuild -project HELLO.xcodeproj -scheme 'HELLO' -configuration Debug -destination 'platform=iOS Simulator,name=iPhone 15' -derivedDataPath -arch x86_64 build -verbose
this may affect the watch. I can't tell the actual issue right now.
so far, I'm thinking of exposing the configuration of destination
, otherwise using the current implementation as the default value. it might be flexible to handle the most cases engineers could face
Do you have tutorial to run this project Currently I don't have any tutorial. I've just few seconds ago pushed .vscode/launch.json and .vscode/tasks.json that helps to run extension:
npm install
F5
so far, I'm thinking of exposing the configuration of destination, otherwise using the current implementation as the default value. it might be flexible to handle the most cases engineers could face
We can implement all 3 options
sweetpad.build.destination
— an option in .vscode/settings.json
. Raw destination, passed to xcodebuild's -destination
paramter..vscode/tasks.json
. See #tasks and XcodeBuildTaskProvider for reference.platform=iOS Simulator,id=${options.id}
generic/platform=iOS Simulator
In my opinion, The first item may not be necessary. the 2 and 3 are good
Right now the default build is using the
generic simulator
the problem is thebuild
will build bothx86_64
andarm64
for simulator, if I don't make a mistake. this will make the compile doubled if we only want to debugxcodebuild -project HELLO.xcodeproj -scheme 'HELLO' -configuration Debug -destination 'platform=iOS Simulator,name=iPhone 15' -derivedDataPath build -verbose
like here it will find the first matching simulator and build for the active simulator
or it might be better -destinationI just noticed that your code has the'id=${sweetpad.selected-target}'
destinationId
, but it has to be a fixed value. if there is a saved$selectedSimulator
, then the variable can be used in build the arch is determined with it too , #18 this could be optionalI guess it can solve this issue automatically https://github.com/sweetpad-dev/sweetpad/issues/16 the real device could be applied with this rule