Reminder: Look at <file:/home/jake/CSC/index.html> for updates or corrections!
Goal: Dealing with dependencies using a release tool.
First, create a local copy of the exercise files.
tar xf ~jake/CSC/exercise10.tar
This will create CMT directories for seven packages, named A through G. Each of those will have separate versionsDrop down to version 1-0 of G and check the dependencies:
cmt show uses
You’ll see that G depends on version v1-0 of all of A through F (and B still depends on A, as in exercise9). Check the G.h and G.cxx files to see why that’s true. Then ask CMT to build everything needed:
cmt broadcast make
Note that cmt does seven build operations: It builds version v1-0 of the A through G packages, but not any of the other versions, because they’re not needed (yet). Run the program:
It should display a line from each of the seven libraries. Success!
Now we’re going to simulate the various issues that can arise as you try to “release” consistent sets of code. First, note that you’ve got a working combination here. The “requirements” file for G lists a set of versions that works.
Unfortunately, there’s a problem with v1-0 of the D package; it’s printing the wrong thing, and you’ve detected that during your testing. The owner of the package has provided a “v1-1” version that has this fixed. Make the necessary changes to your G requirements file, rebuild, and see if you’ve really fixed it. (You are not to change the .h or .cxx files in this exercise; pretend they’re too complicated to figure out right now)
You’ve now got a working “v1” of G and the libraries it uses, which you could bundle up and distribute.
Unfortunately, as the system gets bigger and bigger, having G depend on everything becomes impractical. So we need to iteratively evolve this system so that G just depends on F, which does some of the work and relies on E, etc.
Look at the version v2-0 G.cxx, F.cxx, etc files to see a way that this could be done (there are other, more robust ways to do it, but this will serve for now). The programmers have provided those, but they’ve not updated the dependencies in the various requirements files. Your next task will be to update those so that you can build this:
(edit v2-0/cmt/requirements files as needed)
cmt broadcast make
You may need to do the “make” several times. If things get too messed up, you can say
cmt broadcast make clean
to clean things up. When you get it to build properly, you should be able to say
cmt show uses
to run the program and show the usage tree respectively.
Note two things about your solution:
1) Since the dependencies in the code changed, the requirements files in each package had to change too. It makes sense for the people who are working on the code to also maintain the requirements file!
2) The G package now depends on only F, not anything else. (If you have anything else in the G/v2-0/cmt/requirements file, you should remove them and try again)
Unfortunately, the D package didn’t get enough unit testing, so v2-0 of it has the same spelling problem that v1-0 had. Next, you’re to fix that by using the new v2-1 version of D. (Again, don’t change the code itself)
Which requirements file do you need to change to fix this?
Make the change, and confirm that the program really does produce the right output. Use the CMT “show uses” command to look at the new dependencies.