From your comment I think the following approach would work:
- setup a 'base' workspace that includes all the packages that are needed for the functioning of your complete application, but that are not part of the exercises (ie: your students don't need to / are not expected to change anything in those packages)
- build that workspace on a single machine (while making sure that the machines the students use are 'similar enough', ie: have a compatible runtime system), and install it to the install space of the catkin workspace
- create a tarball of the install space
copy that tarball to all the other machines, extract it there, making sure the install space ends up in the same relative location. So if it was in /home/some_user/ros/catkin_ws/install, it should be in /home/some_user/ros/catkin_ws/install on the student machines.
Note that the install space doesn't need to be in your home directory at all, it can be placed anywhere (fi: /opt/base_ws or /usr/local/base_ws (or something similar)). The location can be configured using catkin config --install-space ... But you have to make sure to put the workspace in the same location on the students' machines.
Only thing left now is to create a new workspace (the 'exercise' or 'student' workspace), that extends the base workspace on all the student machines, and to place just the exercise package(s) in it. Whenever students build that workspace, only the packages in the overlayed workspace will be built, not those in the 'base' workspace.
Personally, I would use a VCS to distribute the exercise package(s), create a .rosinstall file (pointing to the (git) repositories containing the packages) and have students use wstool merge <url to rosinstall file> to setup their own workspaces.
Edit: if you would be willing to spend the effort, and / or need to scale this up, you could even think about creating debian packages or RPMs for your base packages, and distribute those in some way. But that could be quite some work (depending on any other infrastructure you might already have).
Note that you can also create a .deb from your install space using fpm. It wouldn't be a really proper debian package, but it would perhaps be easier to distribute than an unversioned tarball.
I don't think devel spaces are supposed to be relocatable, or shareable. install spaces however should be shareable, provided you put them in the same relative location on the other machines.
Do your students need access to the source code of your pre-compiled nodes?
They only need to "fill" a portion of code in one node. I could share a workspace with some pre-installed packages and provide a install() directive on the CMake for the "exercise" package. They should be able to install & compile only the "exercise" package, source install space and have fun right?
I would only use an install space for your 'base' packages (ie: those you want to precompile and distribute). I would make students create their own workspace, that extends your base workspace. That would keep things nicely separated. See my answer for some more detail.