sweetpad-dev / sweetpad

Develop Swift/iOS projects using VSCode
https://marketplace.visualstudio.com/items?itemName=sweetpad.sweetpad
MIT License
132 stars 5 forks source link

configurable destination #23

Open aelam opened 1 week ago

aelam commented 1 week ago

Right now the default build is using the generic simulator the problem is the build will build both x86_64 and arm64 for simulator, if I don't make a mistake. this will make the compile doubled if we only want to debug

xcodebuild -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 -destination 'id=${sweetpad.selected-target}' I just noticed that your code has the 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 optional

I guess it can solve this issue automatically https://github.com/sweetpad-dev/sweetpad/issues/16 the real device could be applied with this rule

aelam commented 1 week ago

@hyzyla Thanks for your great work! and I'm interested in the development. may I join you?

hyzyla commented 1 week ago

Yes, of course! I've assigned this issue to you to have visibility that you will be working on that issue

hyzyla commented 1 week ago

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.

aelam commented 1 week ago

~~before I start, I got some setup issue of the project. ~~ Do you have tutorial to run this project

setup is done here.

aelam commented 1 week ago

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

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

hyzyla commented 1 week ago

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:

  1. Install dependencies npm install
  2. Run extension by pressing F5
hyzyla commented 1 week ago

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

  1. sweetpad.build.destination — an option in .vscode/settings.json. Raw destination, passed to xcodebuild's -destination paramter.
  2. "destination" — an option in .vscode/tasks.json. See #tasks and XcodeBuildTaskProvider for reference.
  3. in other cases:
    • if destination is selected, then use platform=iOS Simulator,id=${options.id}
    • if destination is unknown, then fallback to generic/platform=iOS Simulator
aelam commented 1 week ago

In my opinion, The first item may not be necessary. the 2 and 3 are good