I have git repos for various shared classes and modules, all of which started life in a project and I then used Make External, saved them as xml_code in a directory outside of the project, under management of a different git repo. Those classes/modules are then used by various projects.
I am wondering why? The XML code format is much more difficult (IMHO) to diff on and resolve conflicts with multiple developers than the xojo_code format. I didn’t realize you could do this, but if you drag a xojo_code file from Finder (I’m on OS X) holding the Cmd+Opt buttons, it will add it to your project but simply reference the file, the same as an external file.
So, why would I ever use Make External? I can have a xojo_code file, shared amongst many projects, in it’s own repo just as an external xml_code file.
For a single file that might work
But for any code item (say a module) that contains others you’ll find pain & suffering
I’d also double check that changes to the item ARE in fact reproduced in the project where you added it this way
I’m definitely not seeing that happen here and each project has its own copy
its why there’s a feature request for the text format to enable using that format as an external item
<https://xojo.com/issue/3624>
[quote=90617:@Norman Palardy]its why there’s a feature request for the text format to enable using that format as an external item
<https://xojo.com/issue/3624>[/quote]
That case has been on the top of my Top Cases for a while now but reading in various places in the forums, it seems that it’ll never be done due to the mass amounts of changes necessary to core parts of Xojo.
I guess I should learn to look past all the XML jumbo when looking at project diffs, merging code from various developers, etc…
well there are some things you can do depending on what VCS you use
for svn an external works - its basically a repository that gets checked in/out as path of another repository
so your common code can be in there and shared between projects
git has something similar
vault has a way to do this
most vcs do
but this IS definitely something done outside the IDE using the VCS and is quite invisible to the IDE itself
Oh, managing the code is not a problem (git). I just find it hard to merge conflicts, look at history and see exactly what changed during a given commit, etc… I’m use to seeing Xojo source code, not XML w/Xojo source code somewhere mixed in there
OK, I understand what you’re saying now. I think I’ll convert one of our projects around and see how it works out. I’d love to get away from the XML format.
I’ve never used the XML format, but is there some reason why it is needed? Even though you can’t diff on it, I understand the need for the binary format. But does the XML version bring something to the table that the text format does not? Just curious.
@Norman Palardy - I’ve finally gotten around to doing this and it is not working out as well as I had hoped. I created a project called edi-unit-test in which I have a Module Edi and in that module, I have several classes EdiFile, EdiSegment, …
This all works fine. I consider this my “master” project. I can add things to code, add tests, etc…
Now I create a new project edi-import. I add edi-unit-test as a git sub-module. So my structure is now:
edi-import/edi-import.xojo_project
edi-import/various-files
edi-import/edi-unit-test/
edi-import/edi-unit-test/Edi.xojo_code
edi-import/edi-unit-test/Edi/EdiFile.xojo_code
edi-import/edi-unit-test/Edi/EdiSegment.xojo_code
edi-import/edi-unit-test/Edi/various other classes
So, that works out fine. The problem comes in when I drag from edi-import/edi-unit-test/Edi.xojo_code, my Edi module containing all the Edi classes. All I get in my edi-import project is an empty module. No classes are contained within it. So, I then tried dragging file edi-import/edi-unit-test/Edi.xojo_code and the directory edi-import/edi-unit-test/Edi/ into my edi-import project. This now exposes all of the classes and the module, but the classes come over contained in a directory, not contained in the module.
So… This means that when I add a new class such as EdiElement to my master project, edi-unit-test, it will not appear in all of my apps using it as a git submodule. I must then go to all my apps and add in the new class manually.
Don’t move things on disk
The project manifests have no clue you’ve done this
So you’ll be asked to relocate things when you reload any project that used the code
Same for trying to drag directories in from the OS into your project
The overall project manifest is the only place that the “containment” is stored or known
I do not use git so I’m not familiar with how it handles “sub projects”
Sharing items across projects using VCP format is trickier than binary or XML - no question.
The problem is mostly keeping the project manifests pointed at the same items and in sync.
Its grunt work because the IDE literally has no idea (or means) to represent an “external text format project item”
Just adding an item to you edu-import project doesn’t automatically make it part of any other projects manifest
And altering the configuration of the edi-import code base doesn’t update the other manifest
And thats the source of the issue
The only way to sea with it is as you have found, add it manually in the project then alter things on disk so the one you added is pointed to the git subproject
Quite honestly I would not try this set up in something that is going to evolve a lot with adding new classes etc as you will spend a lot of time updating projects that consume the code since they do NOT automatically import any new items added to the other project.
I did not move anything on disk, although I did drag from the OS to the project tree. That is how I added those items to the project. Is there a different way I should add items to my project from the submodule project?
Correct, but you can use the idea of a SCM submodule to share code amongst multiple projects. Those submodule’s will not be “external.” They will be shared by the SCM mechanism though.
Drag & drop from the finder / explorer into your project won’t preserve the logical hierarchy (as you’ve discovered) as the on disk hierarchy is NOT the logical hierarchy in the project
That organization is only stored in the manifest (the VCP project file)
You could actually have files all in one dir yet in the project appear nested inside modules etc
To get started I would initially copy from one project into the other
Save the project you just pasted into.
Now in the project you just pasted in to you have a copy
And what you want to do is on disk (not in the project manifest) make it so the new project that you just pasted into refers to the original files you copied from
If you were NOT using version control you could use aliases, symlinks etc BUT those don’t work well with version control systems
Any changes in the original files would be reflected in the copies (since they are just aliases pointing to the actual original files)
But you can see that in the original project if you add a class there’s no automatic “import” to the project you pasted into
You’d have to repeat the process for that new class.
So what you need to do (I have no idea how to do this in Git) is treat those copies as their own subproject that is composed of the files from the original project you copied from (not sure how to set that up in Git)
In SVN I can set up an “external” for a portion of a project & use that in another project and I’m good to go
SVN maintains all this for me once I initially set it up but again if I add to the original project I need to get the entry in the manifest for the project I had pasted things into.
That part SVN doesn’t help with at all.
Partly. The part I do not yet understand is how to get from a git submodule to having the code in my project. It may be different in SVN (I’ve never used sub modules in SVN). But, the way git works is:
$ cd my-project
$ git submodule add git://url my-sub-module
$ ls -R
my-project.xojo_project
my-project-class.xojo_code
my-sub-module/EDI.xojo_code
my-sub-module/EDI/EdiFile.xojo_code
...
So… Now that it is on disk, under the main project directory, I am not sure how to get it into my project and preserve its logical hierarchy.
add it to your project FIRST by copy paste - that preserves the logical structure
save
now have git overwrite it on disk
doing it by adding the submodule on disk BEFORE adding it to the project & saving means when you do add it to your project your overwrite what git puts there
And note that you will have to repeat this ANY time you change the structure of your submodule (add classes , modules, folders, etc)
Its why I said I would NOT do this for anything that is going to evolve a LOT
