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ā¦
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.
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.
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ā).
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.
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