Could not resolve reference 'Realm' for target 'Toffee.iOS' (UIKit for Mac)

Fixed:

                     Reference 'Library' already was resolved to '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Obj/Library-D92432DECFDFE00C048CE3108A8358F331DC0DEA/Debug/Island.Darwin.iOS/Device/arm64/Library.fx' for target 'Toffee-iOS'.
                     Reference 'Library' was resolved to '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Obj/Library-D92432DECFDFE00C048CE3108A8358F331DC0DEA/Debug/Island.Darwin.iOS/Device/arm64/Library.fx' for target 'Toffee-iOS' (Device-arm64).
E:                   Could not resolve reference 'Library' for target 'Toffee-iOS' (Simulator-arm64).

now to step two, why it doesnā€™t build the Library for Simā€¦

Also fixed. Was caused by the differing project type, Toffee vs Island, that the Simulator=True (and other settings) didnā€™t migrate).

New build started now w/ both fixes

Thanks very much

Would 20210130-153207-elements-develop have the fixes ?

Yes.

1 Like

That build didnā€™t seem to fix anything. If you click on the commit it lists no changes. Should your changes be listed ? I pulled the latest from the ebuild repo and built that. Copying the bin folder into my element folder, fixes the issue.

I have another project which doesnt build, can you see anything from the log ?

Untitled-3.zip (72.7 KB)

My apologies; I had to run out right after committing the fix, and it seems the push for my merge didnā€™t go thru :(. A new build is started now that does have the fix.

Not offhand. let me know if this one persists with the new build, and Iā€™ll have a look tomorrow (or later today), if it does.

Thanks. Tomorrow is fine, it is the weekend after all.

MultiTargets.zip (5.3 MB)

Im wondering if what Iā€™ve done is a problem.

I added a second library called BaseLibrary. BaseLibrary is referenced by Library but also the two exes.

In the exe I have remote references but in Library itā€™s a project reference.

If the remote reference Library.element is the elements file, what does it do when it finds

    <ProjectReference Include="BaseLibrary">
      <Project>{B7CC504C-03B1-4DD2-9869-532E83E45BB4}</Project>
      <ProjectFile>..\BaseLibrary\BaseLibrary.elements</ProjectFile>
      <Private>True</Private>
    </ProjectReference>

I would not be surprised if thereā€™s a problems with mixing local and Remote Project References to the same project, within a solution. But if thatā€™s the case, can we explore that with a simpler test case that does not also involve multi-target?

That said, looking at your project, BaseLibrary was missing form the .sln, so it failed on that. if I add it, I get:

E: Remote project 'github.com/Mosh/MultiTargets/BaseLibrary/BaseLibrary.elements:*' referenced from 'NotV1App' is already part of the solution as a different file.

which is what I recalled shoudkl happen (ie ā€œdont do thatā€).

The solution V1App/V1App.sln has BaseLibrary as a remote reference, which one did you open ?

The solution Im using to build the libraries just has a project reference to BaseLibrary.

Iā€™ll tidy up the solutions, and upload another zip.

MultiTargets.zip (5.3 MB)

So I have 2 solutions. Apps, which has everything as remote references and Libraries which has Library and BaseLibrary. Library has a ProjectReference to BaseLibrary.

I was just wonder if this was the issue.

When I build Apps I get 2 Project Reference BaseLibrary could not be resolved for Target.

Actually reading the error message would indicate it was the issue.

Interestingā€¦

 Missing project 'BaseLibrary' referenced from 'Library', but project path '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/EBuild/github.com.Mosh.MultiTargets/BaseLibrary/BaseLibrary.elements' is valid.
   Package project 'github.com/Mosh/MultiTargets/Library/Library.elements:*' referenced from 'NotV1App', at '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/EBuild/github.com.Mosh.MultiTargets/Library/Library.elements'.
   Package project 'github.com/Mosh/MultiTargets/BaseLibrary/BaseLibrary.elements:*' referenced from 'NotV1App', at '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/EBuild/github.com.Mosh.MultiTargets/BaseLibrary/BaseLibrary.elements'.
   Package project 'github.com/Mosh/MultiTargets/Library/Library.elements:*' referenced from 'V1App', at '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/EBuild/github.com.Mosh.MultiTargets/Library/Library.elements'.
   Package project 'github.com/Mosh/MultiTargets/BaseLibrary/BaseLibrary.elements:*' referenced from 'V1App', at '/Users/mh/Library/Application Support/RemObjects Software/EBuild/Packages/EBuild/github.com.Mosh.MultiTargets/BaseLibrary/BaseLibrary.elements'.
   Build order:
   - 1. Library
   - 2. NotV1App
   - 3. V1App

its finding BaseLibrary ok, but it doesnt get added to the build order. I wonder why. will debug.

Fixed; was a chicken/egg problem:

as it went thru the references, first if found Library, that references BaseLibrary as a PROJECT reference (which at this point we donā€™t know about yet, so its ā€œmissingā€ from the sln), but since it finds the project via filename, it added it (but projects not part of the solution like that donā€™t get built, by default*; only pre-existing output of it would be used to resolve it).

THEN it got to the BaseLibrary ref, found "hey, I already have this project in the solution, lets keep using that one), done. But ofc BaseLibrary was still disableed.

*) workaround: --build-missing-projects will force all project references that can be resolved to a project file to be built, even if they werenā€™t;'t in the .sln

1 Like

Thanks. I think itā€™s fixed now.

Im converting a more complex iOS example and thats building now.

1 Like