JUCE Updating Process could be improved


#1

This is not a big issue, but it is a bit annoying.

Every few weeks I am grateful that you guys push out updates to JUCE and that the Projucer automatically alerts me to a new version. However, the Projucer fails to automatically update JUCE literally every time. It will typically give me some error message about not being able to overwrite the JUCE folder.

I own about 5 computers, some Mac and others PC, and I have literally never been able to successfully update JUCE through this automated process on any of them. Not once. I always find myself going back to the JUCE web site and clicking the link to download for the free plan (even though I am a paying subscriber).

Perhaps its just me who experiences this problem. But it seems strange to me that it happens to me on so many different computers.


#2

I think most of us use github to download the latest commits.

Rail


#3

Fair enough. I’ve never been a big fan of GitHub. I’m a bitbucket man.


#4

using command-line git is the same process, regardless of if the remote repo’s location is on bitbucket or github, or some other cloud storage.

$ git clone <repo URL>
$ git checkout develop
$ cd ./extras/ProJucer/Builds/MacOSX/
$ open ./Projucer.xcodeproj

then just click “run” to build it…

Most people don’t bother with the websites for interacting with the repos, they just use the command-line, the IDE, or a 3rd party tool like SourceTree to pull/push/commit/checkout.


#5

Thanks matkat.

I’m largely self-taught as a programmer, and have always found it hard to figure out things like this. Much like the process of teaching myself how to be a good sound engineer, I find that solutions like this probably easy to find and use (if you know that they exist, which I did not). But you never know just how much you don’t know.

I wonder if perhaps the reason why this is, is because those of us who get really good at programming or sound engineering have little incentive to make it easy for all the newbies who might compete with us for jobs. Just a theory…


#6

I got where I am, knowledge-wise, by annoying the sh*t out of the people in ##c+±general on Freenode IRC and now C++Help on Discord lol And eventually, being able to understand what was being discussed in CppCon and ADC videos on youtube.

I agree, there’s partly the problem of “I worked super hard to figure this stuff out myself, why would I give it away for free” mentality that’s prominent with self-taught folks, but there’s also the part of “this c++ stuff isn’t easy”! If it were, it would be taught alongside math, english, and social studies in elementary school.

It’s never really stated anywhere that we should use git to get set up with JUCE, until you start working or collaborating with other programmers, and then it’s like, “do you know how to use git?”. If you answer ‘no’, you get a pretty quick explanation of how to use it, and then when you go snoop around on the JUCE forum and see where all the bug fixes get reported, you’ll immediately “get” all of the “fixed with commit a4d5e23s” posts and wish you had learned about git source management before you even learned how to program a single line of code. At least, that’s what my experience was. The ability to roll back is such a life-saver sometimes.

I wouldn’t beat yourself up about not realizing that you should have been cloning the repo from Github and just pulling/recompiling ProJucer whenever there is a new update. I’ve been working on a ‘Programming for Musicians’ youtube series, to kind of pave the way for TheAudioProgrammer’s videos, and the very first video is literally How to take a blank machine, install an IDE (xcode or visual studio), clone the JUCE repo via command line, Build Projucer, make a GUI project in Projucer, and finally, build it in the IDE.

OS X:


Windows:

#7

For Git and GitHub, Dan Shiffman’s YouTube channel is a great intro: https://www.youtube.com/playlist?list=PLRqwX-V7Uu6ZF9C0YMKuns9sLDzK6zoiV


#8

Also, using git from the command line can become very user unfriendly, especially when you are typing in long commands as if they were magic spells without knowing exactly what the arguments represent.

My suggestion to not feel unnecessarily overwhelmed with that git complexity is to keep a git GUI client handy for the everyday work.

After all, the basic concepts of git are moderately simple to grasp and several GUI clients do an excellent job at presenting them, plus for me it’s much easier to have a visual representation of all the commits and branch.

You can get back to the command line only when absolutely needed, or when you feel comfortable enough that the GUI clients impede your work rather than easing it.

As for which one to use, I’ve been an happy Sourcetree user for years and have recently started to appreciate also Fork.


#9

Yeah, sourcetree is great. I use xcode’s built-in source control for the most part, but source tree’s interface is pretty dope for getting a bigger picture of the branches


#10

Yeah I use sourcetree as my bitbucket client. It sometimes has unintelligible errors while committing but it is usually quite a good tool.


#11

About git, I recommend this (free!) book : https://git-scm.com/book/en/v2