fyne package does not work with main package not in the current directory

[toaster]

Checklist

• I have searched the issue tracker for open issues that relate to the same problem, before opening a new one.
• This issue only relates to a single bug. I will open new issues for any other problems.

Describe the bug

When using fyne package -os ios for bundling an iOS app, it does not work when the command is not run in the main package folder, i.e., this does not work:

fyne package --os ios --appID … ./cmd/my_app

But this does:

cd cmd/my_app
fyne package --os ios --appID …

The failing command looks like this:

> fyne package --os iossimulator --appID net.pruetz.tikita --name Tikita ./cmd/tikita
go build -tags ios -ldflags=-w -o=/var/folders/sx/0z23ptj14clbhss6vj4hncvc0000gn/T/fyne-work-1743836396/arm64 github.com/toaster/tikita failed: exit status 1
# fyne.io/fyne/v2/internal/driver/mobile/app
darwin_ios.m:275:35: warning: 'userInterfaceStyle' is only available on iOS 12.0 or newer [-Wunguarded-availability-new]
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator17.4.sdk/System/Library/Frameworks/UIKit.framework/Headers/UITraitCollection.h:39:54: note: 'userInterfaceStyle' has been marked as being introduced in iOS 12.0 here, but the deployment target is iOS 7.0.0
darwin_ios.m:275:35: note: enclose 'userInterfaceStyle' in an @available check to silence this warning
darwin_ios.m:275:57: warning: 'UIUserInterfaceStyleDark' is only available on iOS 12.0 or newer [-Wunguarded-availability-new]
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator17.4.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIInterface.h:32:28: note: 'UIUserInterfaceStyle' has been marked as being introduced in iOS 12.0 here, but the deployment target is iOS 7.0.0
darwin_ios.m:275:57: note: enclose 'UIUserInterfaceStyleDark' in an @available check to silence this warning
# fyne.io/fyne/v2/app
app_mobile_ios.m:15:12: warning: returning 'NS_RETURNS_INNER_POINTER const char *' from a function with result type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
# github.com/toaster/tikita
runtime.main_main·f: function main is undeclared in the main package

I looked at the help of the fyne command and also tried to use the --src arg which takes a bit longer (i.e., does more things) before failing. Note that the working directory was replaced by ….

> fyne package --os iossimulator --appID net.pruetz.tikita --name Tikita --src ./cmd/tikita
/* com.apple.actool.errors */
…/tikita/cmd/tikita/Images.xcassets: error: The output directory "…/tikita/Tikita.app" does not exist.
/* com.apple.actool.notices */
…/tikita/cmd/tikita/Images.xcassets: warning: Failed to read file attributes for "…/tikita/cmd/tikita/Images.xcassets"
    Failure Reason: No such file or directory
/* com.apple.actool.compilation-results */

: exit status 1

How to reproduce

1. Set up build environment including XCode.
2. Set up “Hello world” app.
3. Try to package according to https://docs.fyne.io/started/mobile but with the main package in a different directory.

Screenshots

No response

Example code

// This problem is not specific to the app code.

Fyne version

2.4.5

Go compiler version

1.22.1

Operating system and version

macOS 14.4.1

Additional Information

No response

[toaster]

When running the variant with the --src parameter for an actual IOS build, it showed me this message:

> fyne package --os ios --appID net.pruetz.tikita --name Tikita --src ./cmd/tikita 
parameter -sourceDir is currently not supported for mobile builds. Change directory to the main package and try again

This explains a lot and probably this message should be shown for iossimulator, too.
To me, it seems that the main package directory was never intended to simply be the last parameter (like for go commands) but to be specified via --sourceDir.

[andydotxyz]

Thanks for this. I think that we have maybe different folk working on this with different intentions. We should pick a direction and fix it up the right way.
Given that we are moving to fyne-io/tools for cmd/fyne in 2.5 maybe we transfer this issue over there to get it sorted going forward?