Building third party modules is theoretically the same as building the main Rack modules. This, then, is what should normally happen:
rm -rf themodule/ # remove the previous installation
git clone themodule.git # fetch the latest version of the module from github
cd themodule # move into the directory cloning the module
make # build the module
cd .. # move up one directory (back to ‘modules’) so we can build another module
You can also chain these commands together for one simple copy and paste thus:
rm -rf themodule/ && git clone themodule.git && cd themodule && make && cd ..
Having built the module you can then build another one or if you want to run Rack to see the new module in action then you need to:
cd .. # move up one directory to the main Rack directory
Then you can:
make run # run Rack
When building your module you may see errors and warnings. Warnings you can generally ignore but errors will make the build stop. Something will need to change to make it work. If you have made a change and want to try again then you need to clear out the failed results of the last attempt. To do this run:
make clean # remove the last build (failed or not)
There are all sorts of reasons but here are some common ones:
When you run the ‘git clone themodule.git’ command it will clone a repository into a new directory wherever you run it from. When you change into that directory and run ‘make’ you will get an error message. Modules use files from the main Rack distribution and they look for them in a specific place (two directories higher). Remove the directory with ‘rm -rf themodule/‘, go to Rack/modules and try again.
Some module developers work with the development source and others work with the latest stable release source. The module’s main repository page will often tell you which. Another place to check is their release page. Most are now using the recommended versioning system.
The latest version of the module may not be working. Check the issues page in the repository to see if anybody else has reported a problem. Consider reporting the problem yourself if you are confident that you are not the cause of it. You can always 'checkout' an earlier version of the module to look for a working version .
Developers work on different operating systems. There are slight differences in compilers and how ‘strict’ they are in each. This is a very common problem for Mac users. Fortunately, fixing these problems is generally fairly easy. Check the module repository’s issues page as there is probably already a discussion about it with fixes outlined. Check also the Build Monitors where you will find cut and paste build instructions that fix many of these Mac specific problems.
VCVRack is under development and the source code constantly changes. At any given time some modules that are intended to be compiled against the dev version will be working and others will not. That is the nature of the game.
A common one is that following the cloning of the repository the resulting directory must be renamed. The main repository page will usually give such information. Renaming a directory is done by moving it:
mv directoryname newdirectoryname
From the Build Monitors you cam copy and paste the command to build a particular module. Remember to run it from the Rack/module directory.
On the Scripts page you will find scripts to build all the 3rd Party modules at once.