Github corrupting max externals?
So after some weird funny business with my github repository I've figured out that .mxo files are getting messed up when being put up in github.
They seem to show up as folders, and if someone downloads the files from github, they don't run right, giving an error like this:
descriptors~: unable to load object bundle executable
2014-09-26 02:44:55.446 Max[3288:707] Cannot find executable for CFBundle 0x12fc80d0 (not loaded)
Here is my repo if you want to see what I mean (look at the first 4 items listed):
https://github.com/rconstanzo/the-party-van
Now, I can just find a way to distribute the patch without having the externals live in the same folder with it, but is there a workaround to this?
A couple of the externals I'm using are custom/specific and not part of a general external distribution I can point to, so it would be messy for someone to have to download the repository AND some externals, and then put them together themselves (defeating the convenience of using a github in the first place).
I'm not in a position to look at your repo right now but .mxo "files" ARE in fact folders that contain files and other folders. The actual library lives further down, if I recall directly it's inside a MacOS folder that lives inside the Contents folder. So make sure you pushed all the files underneath.
Also, I have seen a case where, depending on the build configuration, where the actual library wasn't living where expected and only an alias to the library was in the location.
Just two things worth checking
Yeah, I had something like that happen before, where uploading an .app via dropbox would break symbolic links, but didn't know this would/could happen with github/externals too.
I didn't personally build the externals, and they've been working before, so they should just be self contained.
Yeah that makes sense. I just like the convenience of having the github being a mirror of my 'live' folder, which includes local versions of app specific externals.
I will definitely do a zip/dmg with all the needed files for the next party van version update. I learned how to use github more since making the first (and only) TPV release, and have been trying to iron out bugs and stuff before doing another release.
For another repo I did do the dmg/source combo thing:
https://github.com/rconstanzo/dfscore-performer/releases
I will add the gitattributes thing as well to be safe, and for the next (v1.1) release make a nice tidy source/app distinction.
I've been wanting to go to a maxproject format too, but now with github, and doing a compiled app, I don't know if I want/need to do that anymore.
So going to do some variation of that, but at the moment I can't figure out where the .gitattributes file is supposed to go. I tried putting it in the root level (as in NOT inside the .git) but that didn't seem to work.
I could be doing the procedure wrong, but I deleted the local externals, created/added the .gitattributes file in the root folder, placed fresh versions of the .mxo files in the root folder, and then pushed it back to github (using SourceTree).
The .mxo files work for me, but someone else downloading the repo has the same error listed in the original post.
Hmm weird. The MacOS folder (and the executable) is in my local version, it's just not getting pushed to the github.
I seem to recall that GIT had a method for excluding certain subdirectories from the push/pull protocol. It's been ages since I had to do this, but something you might want to look at.
I have to admit that I found GitHub less than ideal when editing Max patches, but that has more to do with the rather arbitrary way Max orders components of its JSON data structures on save. Has this gotten any better?
To exclude files or folders from the repo you can list them in the .gitignore file(s). take a look at the git reference for the wildcard syntax.
if a file/folder is already added to a repo before the .gitignore is created the will remain part of the repo unless you explicitly remove them.
Yeah I wanted to add a gitignore, but just structured stuff so that nothing lives in the git that doesn't need to be there.
Is there a reason why my MacOS folders wouldn't be getting pushed to github?
Oh I see. I thought that was a general comment on git structuring. I shall test pushing that.
@Peter Do you know this message:
;max sortpatcherdictonsave 1
?
Put that in an init file, and your diffs will get better.
I've wondered about using that message but never got around to testing it to make sure that it was 100% reliable. Seems to me that it would have made sense for a sorted safe to be the default unless the way patchers are normally saved leads to some load optimization.
So do you just loadbang that in a top level patcher every time?
Does it need to be in each individual abstraction?
What I've done is to make a file here: .../Max x/Cycling '74/init/sort-on-save.txt
with:
max sortpatcherdictonsave 1;
as its contents.
Then I forget all about it.
I think that the default ordering of objects in the patch file is first-touched to last-touched. I suspect that is how they exist in memory, so sorting them on save would incur a slight penalty. I doubt there would be any effect on load optimization. Personally, I think this should be the default setting, or settable by a preference. But, I guess the number of people who use version control on Max patches is pretty small.
@Mzed: Yes, I know the message and have used it.
No, it's not really proven to be a big help. Not in two-people-editing-at-the-same-time situations (which, otoh, GIT handles reasonably well with procedural code).
Does anyone know of any improvements to GitHub/Max Project technique since 2014, or for the upcoming Max 8? Thanks