I’m curious if anyone else has run into the situation where they want to use a chunk of 3rd party code as an external item in their own project and hit up against the pain that Xojo causes for this process?
In my specific case, there is a Xojo project that is publicly available on Git that provides some nifty functionality I’d like to include in my application. The recommended way to do so is to grab a copy of the project from Git and copy/paste the core classes into my own project. This works fine, but does a poor job of keeping my project up to date with changes to this external project. As soon as updates are available in the Git repo for this external project, I have to manually delete the old versions from my project, then copy / paste the newer versions of these items into my project again.
Can someone help me understand why this is?
Xojo supports external project items, but it seems that they have to be either XML or binary files… and if I try to drag items into my project that are of a different format (say, xojo_code format) then we wind up with a situation where BOTH my project and the external library claim ownership of the classes, which leads to all sorts of problems between the 2 projects.
In short: I’d really love to use external frameworks in my projects that provide a shared set of functionality, but it appears that Xojo makes this difficult. Am I missing something? Is there magic sauce out there to make my life easier?
Also, if someone knows of a feature request already for improving this situation, I’d be glad to sign on. I could not find one that exactly covers that I’m talking about here.
Hey @Norman Palardy: I assume that the interpretation of your brief reply is as follows: “I recommend that to make this run more smoothly you transition the file format of the external library to use the version control flavor of xojo files rather than any other file format.”
Or are you actually suggesting I use SVN vs Git here? Cause that’s both a holy war and irrelevant to the topic.
Just for the sake of argument, let’s say that I can’t control the file format of the external library, and it is currently using .xojo_code files. Any tips?
Actually, now that I think about it, there is one way you can do it in Git. (There is probably an easier way to accomplish this, but since I don’t know what it is…)
Drag the classes into your project, save, then close. Delete the newly created files in your project folder then open the manifest in a text editor and manually change the paths to point to the files in the original project folder, including enclosing folders. When you next open the project, it will use the original files directly.
The downside is that any new classes added to the “external” project later will have to be added to your project manually.
What I’m saying is SVN and Git provide facilities for sub projects as their own repositories that are part of a larger one.
Take advantage of that.
Depending on what / how the original is set up you may be able to easily lift that code into your project with just a sub project or have to actually clone it then sync between the original check out of that code and what you lift into your project.
Personally I grab a copy of the code and manually include it so I"M in control of when I get new updated versions not the authors of the third party code
Sym links can also be used to redirect where the IDE looks for the code
I’d never try & do this with anything BUT version control format
@Kimball Larsen I have run into issues (lots of them) years back (REALBasic timeframe) with using “external” files that were common 3rd party centralized files. I just started copying the 3rd party files into each application. then I don’t have to worry about them being updated underneath me and breaking my code. Xojo likes it better. And I can make sure that the various tools are kept at a known stable (for my app) version.
@Kem Tekinay GIT and SVN have the submodule options. You can put the 3rd party tools as a submodule (each one as its own submodule). I have had limited success with suing submodules (both with SVN and GIT). my success or lack there of is probably my fault.
Personally I like the “I incorporate the code on MY timescale when I’m ready” approach which might mean I do a copy nonce in a while
That way I dont have code magically changing out from underneath me by simply updating a Git or SVN repository from a third party
[quote=170568:@Norman Palardy]Personally I like the “I incorporate the code on MY timescale when I’m ready” approach which might mean I do a copy nonce in a while
That way I dont have code magically changing out from underneath me by simply updating a Git or SVN repository from a third party[/quote]
[quote=170568:@Norman Palardy]Personally I like the “I incorporate the code on MY timescale when I’m ready” approach which might mean I do a copy nonce in a while
That way I dont have code magically changing out from underneath me by simply updating a Git or SVN repository from a third party[/quote]
As has been pointed out, Git does a great job of supporting submodules. These submodules are not updated to the latest when you do a pull on the main project. They are updated and versioned separately, so when I’m ready to update the external library, I want to just do a git pull on the submodule and I’m done. Instead, I have to do a git pull on the submodule, then open the module’s project in Xojo and go find the bits I need to copy, and then copy/paste them into my existing project, being careful to delete the versions that I had before so I don’t wind up with the IDE trying to make duplicates of things etc. This is a fiddly and error-prone process that does not scale well at all for projects that want to use lots of external libraries for things.
And now I must press pause on this conversation while I go watch my Blues slaughter the Canadiens.