Could not resolve reference for iOS simulator

Elements Fire
1

Hi,
I created a multi target static library. I want to add that as a reference to an ios Toffee app. When building for the simulator I get this

             Reference 'libMoshine.Api.Location' already was resolved to '/Users/JohnMoshakis/Library/Application Support/RemObjects Software/EBuild/Obj/Moshine.Api.Location-10910FCD2301720A4FE1D2083C5DB05CA27CC22C/Debug/Toffee.iOS/Device/libMoshine.Api.Location.fx' for target 'Toffee-iOS'.
             Reference 'libMoshine.Api.Location' was resolved to '/Users/JohnMoshakis/Library/Application Support/RemObjects Software/EBuild/Obj/Moshine.Api.Location-10910FCD2301720A4FE1D2083C5DB05CA27CC22C/Debug/Toffee.iOS/Device/libMoshine.Api.Location.fx' for target 'Toffee-iOS' (Device).

E: Could not resolve reference ‘libMoshine.Api.Location’ for target ‘Toffee-iOS’ (Simulator).

This is the contents for the bin directory.

Screen Shot 2020-12-22 at 1.29.54 AM
Screen Shot 2020-12-22 at 1.29.54 AM725×298 50.8 KB

Shouldn’t there be a x86-64 folder for the simulator ? I also cant see any of adding to the architectures.

Cheers,
John

2

Hmm. Topffe doesnt really generate per-arch files (in Bin)? it does in /obj, but the final files ar emerged/.fat binaries. (Island keeps them separate). Can I see an (ideally small) testcase that shows this?

3

StaticExample.zip (2.0 MB)

I think I worked it out. If I select IOS Device + Watch OS Device as the target, it builds. If I then select a simulator and do another build I get

Cache does not contain resolved reference ‘libMoshine.Api.Location’ for target ‘Toffee-iOS’ (Simulator).

4

Hmm. That sounds like a cache issue yeah. Ok have a look tomorrow. I assume. A rebuild takes care of it?

5

Hmm. (after adjusting the provisioning profile & id), I can switch back and forth between device and sim, just hit Cmd-B, and it builds fine for either :frowning:

6

Oh wait, got it. after I clean and delete ./Bin, I now can repo it.

this seems to be a non-fatal error. essentially it just invalidates there cache after an attempted restore because the file insert there, and then reruns the Resolve uncached:

            -> Task RemObjects.EBuild.Elements.ElementsResolveReferences started for SimpleApp.
               -> Target Toffee-iOS started.
D:                Using cached data for ResolveReferences.
                  -> Task RemObjects.EBuild.Elements.ElementsValidateCachedToffeeReferencesForTarget started for SimpleApp, Toffee-iOS.
E:                   Cache does not contain resolved reference 'libMoshine.Api.Location' for target 'Toffee-iOS' (Simulator).
                  <- Task RemObjects.EBuild.Elements.ElementsValidateCachedToffeeReferencesForTarget failed for SimpleApp, Toffee-iOS, took 0.0012s (0.001s).
                  -> Task RemObjects.EBuild.Elements.ElementsResolveToffeeReferencesForTarget started for SimpleApp, Toffee-iOS.
                     Project 'Moshine.Api.Location' referenced from 'SimpleApp' is not enabled, reusing cached output.
D:                   Project Reference 'Moshine.Api.Location' will resolve using target 'Toffee.iOS'.
                     Project Reference 'Moshine.Api.Location' was resolved to '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Obj/Moshine.Api.Location-7B4646F22B641E6DA6E635E3C34A47097EE30703/Debug/Toffee.iOS/Simulator/libMoshine.Api.Location.fx' via target 'Toffee.iOS' (but is already referenced).

it’s also just a one-time thing after I deleted Bin; after I build both destinations once, it doesnt come back…

I suppose this should not show as an error; will fix!

7

Build for 20201222-202127-elements-develop started on bajor

8

I think its fixed for when the project is in the solution but when it is a remote reference I get

Could not resolve reference ‘libMoshine.Api.Location’ for target ‘Toffee-iOS’ (Simulator).

StaticExample.zip (2.0 MB)

1 Like
9

Ah, that would make sense, as it doesn’t rebuilt the project using the new build destination, if it’s not in the solution, and unchanged. I’ll need to think about how to best address this… :(. Probably tie the cache to the build destination, or always force all build destinations for the remote reference…

10

Hi, I just wanted to make sure this is on a list to fix somewhere ?

11

Thanks, logged as bugs://85368

12

Was still on my list, but logged, JIC.

13

Hmm, its actually been slightly worse: Since Fire passes the build destination (Sim vs Device) to the build per project, and Fire doesn’t know abut the Remote Reference as being a project itself, that ref is only ever being build for Device — even on rebuild.

I propose as solution for EBuild to simply always always force Simulator=True and Device=True to remote projects (and also Mac=True, if (one of) the projects that reference it has Mac Catalyst enabled.

That way we incur some extra built time there first time around, Burt we’re set for good, when switching.

14

Another problem is that your remote project doesn’t define the SubMode for Toffee. Technically, Toffee uses SubMode to set iOS vs macOS vs …, not the SDK; SDK is only used to narrow down to a specific version. The code that synced Sum vs Device up assumed that SubMode was was (I’m working around that now, but technically that project of tours is still “invalid” as it is.

  <PropertyGroup Condition=" '$(Target)' == 'Toffee.iOS' ">
    <Mode>Toffee</Mode>
    <SDK>iOS</SDK>
    <SupportMacCatalyst>True</SupportMacCatalyst>
    <DefaultUses>Foundation;RemObjects.Elements.Linq</DefaultUses>
  </PropertyGroup>

should have

    <SubMode>iOS</SubMode>

That would fix that at least rebuild will build all.

15

Build for 20201231-121849-elements-develop [water] started on bajor has this fixed (both to match the targets by just the SDK if needed, and to always build Device & Sim (& Mac) for the remote refs).

1 Like
16

Thanks this is fixed.

1 Like
17

Happy to hear!

18

bugs://85368 got closed with status fixed.