and when I build I get
Project ‘libToffee-macOS’ built successfully.
E: Fatal Error: “Toffee-OS X” is not valid XmlElement name
D: | at RemObjects.Elements.RTL.XmlElement.SetLocalName (System.String aValue) [0x0005e] in :0
D: | at RemObjects.Elements.RTL.XmlElement.set_LocalName (System.String value) [0x0000e] in :0
D: | at RemObjects.Elements.RTL.XmlElement.AddElement (System.String aName, RemObjects.Elements.RTL.XmlNamespace aNamespace, System.String aValue) [0x0002b] in :0
D: | at RemObjects.EBuild.EBuildProject.ToXml () [0x001c2] in <4e073e7a31c0412799a88eefe7638fb8>:0
D: | at RemObjects.EBuild.EBuildProject.SaveResolvedProject (System.String aFilename) [0x0000e] in <4e073e7a31c0412799a88eefe7638fb8>:0
D: | at RemObjects.EBuild.BuildSolution+<>c__DisplayClass1.b__0 (RemObjects.EBuild.EBuildProject p, System.Nullable`1[T] i, System.Boolean lIsParallel) [0x0039c] in <4e073e7a31c0412799a88eefe7638fb8>:0
Side note, I recommend referencing libToffee.elements instead of libToffee-macOS.elements, as I’m moving libTopffee towards the single multi-target project, and will eventually drop the single-target ones…
As a side Q, what’s the goal with linking this as a remote project ref from our repo, when the local binary we ship is usually zip top date and we dont changes this much? or are you using local fork?
BTW, this was one of like 387 regressions/side effects of the simple change I made to handle <Mode>Island vs <Import Toffee.targets. Its been worth if, because its much cleaner now, but you would not believe how long that innocent change has kept me busy last week (including almost failing the build, coz Fire failed with the same error — but then I figured, “f**k that, I’ll just fix Fire.elements locally and not worry about shipping that regression this week” and fixed its post
For my own projects I have all references as remote. The 2 things I dont are things that ones that ship in the Zip and shared projects. I did wonder what the experience would be like if everything was a remote reference. Its nice being able to have the source locally and be able to debug. Its also easier to push a fix to the remote repo and everything is updated when I build.
For the shared projects I have multiple of the same repo in several folders and I forget to sync everything.
Does this look ok ? LastConsoleApplication 3.zip (640.2 KB)
It seems to still be referencing the old version, even though
Package project ‘github.com/remobjects/libToffee/Source/libToffee-macOS.elements:*’ referenced from ‘LastConsoleApplication’, at ‘/Users/JohnMoshakis/Library/Application Support/RemObjects Software/EBuild/Packages/EBuild/github.com.remobjects.libToffee/Source/libToffee-macOS.elements’.
LD takes set of names to link AND a set of folders. separate. it looks for the library by name, in all the folders. So it still links the libToffee.a we deploy because it finds in the folder that is passed because libElements is in it. Only fix is to delete that copy of libToffee.a manually.
Happens to me all the time as well, with libElements.a itself ;), when I work in Fire and need a custom local libElements build…
I didnt know about multi target projects. I saw what you did with libToffee so Im converting my shared projects to be multi target libraries. That way I can have a remote reference in every project and one repo on my computer instead of one repo per project using the shared library.
Yeah, they are very lightly documented for now, because the IDE support really isn’t there yet (Fire/Water can handle them, but don’t let you create new targets or configure the individual targets yet; VS doesn’t handle them at all yet).
It’s on my list to change that, and the rect refactoring for Fire/Water and VS to all sue the same shared “Common project System” is a first step in that direction, so hopefully I’ll find time to do the actual UI work sometime soon, now.
Cool. let me know of you have any Qs not answers by the docs topic above yet, or have any other suggestions or feedback (aside from “let me do this in the IDE”, which, yeah ;).
Actually, looks like this is already supported, at least in EBuild; you can have the same kind of Condition tag on an ItemGroup as on a PropertyGroup. Not sure what the IDE will make of that though, there’s a chance it’ll f’ them up on saves it doesnt know about the Condition, and it does try to merge items into three specific ghroiups, for references, folders and the rest. SO I’ll look at improving that as part of the above issue.
It builds with that change. When do you plan adding proper Fire support for this and remote project references ?
These days I also have the elements file open in a text editor because I’ve made heavy use of remoteproject references and now this.
Remote Project References, work, except for adding them, right? As in, the IDE preservers them ok?
As for target groups: I’m just about done with the code changes to let the IDEs preserve them; in fact I;'m thinking of auto-cleaning projects to use them, when saved from the IDE; here’s what RTL2 would looks afterwards: (this is post .2525)
As for exposing all the capabilities of administering targets in the IDE ‚ it’s on my list, and the new Common project System refactoring added recently was a big step towards enabling it, but its a good chunk of work and I cant say yet when I’ll get around to that…