Machine Problem 11Due Apr 19, on line
Part of
the homework for CS:2820, Spring 2021
|
The posted solution to MP10, given as a shell archive, contains a README file but no makefile.
Write a makefile for the posted solution to MP10. This file should support the following make commands:
The makefile should be named Makefile and it should be contain appropriate comments, appropriate use of whitespace, and appropriate use of indenting. Appropriate comments include both header comments and documentation of the internal structure of the makefile.
The makefile should, to the extent possible, clearly document dependencies between the different files of the project, and it should do this without over-length lines and using named groups of files where this makes things more readable.
Definition: A .class file obviously depends on the corresponding .java file, but it also depends on every .class file for classes used in that .java file. This finding and documenting these dependencies may require searching the text of the source files. There are only 13 source files, one per class, in the posted solution to MP10, so 13 grep shell commands should suffice to find all references to the these classes from other files.
Warning: Spaces and tabs are not genrally equivalent in Makefiles. Many versions of make require use of tabs as prefixes on all shell commands included in the file as part of make rules. This may be stupid, but it is part of our legacy.
This assignment does not involve any changes to any of the .java source files! The only file you will need to edit (as opposed to inspect) is Makefile.
You should submit just the file Makefile; we will test this in the context of the remainder of the pieces of the posted solution to MP10.
As usual, submit using the ~dwjones/submit utility.
A student asked: I can't figure out if this class is part of the model or part of the support files.
There are two things to consider. Does any part of this class depend on classes that are part of the model? If it depends on part of the model, it must itself be part of the model or part of a higher layer above the model.
And, if it is general purpose, equally applicable to many applications, it would make sense as a support class. For example, class MyScanner could be used as part of a compiler, or it could be used to scan text from a novel for some kind of linguistics application. There's nothing in that class that is specific to simulation. Class Simulator is specific to discrete-event simulation, but there's nothing there specific to epidemics or road networks or digital logic or any other subject that can be simulated.
A student asked: I'm having trouble with make html because one of the Javadoc comments causes trouble. The error message from Javadoc complains about this line:
* Simulator.schedule( now+later, (double t)-> whatToDo( then, stuff ) );
What's the problem here?
Code within Javadoc comments is all converted to HTML format, and the characters < and > have special meaning in HTML; they are used as special quotation marks around HTML tags such as <pre> (for pre-formatted text) or <p> (for start new paragraph). If you want a raw > or < in the Javadoc text, you need to write them as > and <.
This is really ugly, no doubt about that. It is a direct consequence of the decision by the designers of Javadoc to directly incorporate HTML into Javadoc comments instead of designing a Java-specific documentation markup language.
Note: You do not need to turn in any repaired .java source files! The only reason you might want to fix javadoc errors in those source files is to check that the part of your makefile that handles make html is correct. The only thing you are supposed to submit is your makefile.
A student asked: Some of the lines in my Makefile are over 80 characters even after I took the long lists of files out of the dependency sections of the Makefile and gave them defined names. Do I have to worry about this? My proposed solution is to break the long lists of names into PartA and PartB and then define the whole thing in terms of $(PartA) $(PartB)
Yes, long lines are as big a readability problem in makefiles as anywhere else, and your solution will work.
It would be better to find a logical division instead of just calling the two parts PartA and PartB. Perhaps some of the files are central to the layer in question and others are peripheral? I encountered the same issue in my solution and found a logical distinction on which to base things.
As a general rule, anything you can do to clarify the program structure will help those who come after you who inherit your code. Makefiles are just one more place where you can provide useful help to your successors on the project.