Well, let’s say your code references a Xojo class in the framework, e.g. dictionary.
Now let’s say you call a method there. The library code will include the signature of the method you call.
Let someone at Xojo fix a bug or add a feature and change the method to have a new parameter. The signature changed and the linker/compiler can’t match the library code any more to new framework code.
Now your library code doesn’t reference a few, but hundreds of these methods by signature. Same for properties, events, delegates, etc.
For the LLVM version, it may be okay for newer LLVM to include code made by older one in most cases. Unless older version used some feature, that the new version doesn’t recognize.
That is what I see constantly in C with static libraries, so we recompile them frequently, e.g. with every little Xcode update. So we know the trouble in C and it may come to Xojo.
It won’t be an terrible issue if xojo was to make it so that it’s fast to compile and no need to re-compile every app build / debug run. What would be serious requirement is it to be as sharable and easy as possible to maintain.
Reading through this thread, this is the first time I have heard of Xojo Libraries. I didn’t even notice it on the roadmap.
This is one of my biggest issues as well. I end up with so many external class files that need to be linked in multiple projects that I sometimes skip creating classes when I should (and would have in other languages).
Has there been any mention of Xojo Libraries before this thread? I’m sure no one has any specifics, but has there been any hints as to whether or not this is actually a solution to what @GarryPettet mentioned concerning external modules and classes?