Lkates

Lorne Kates' User Page.

Me

I'm a 4/5/6/7th semester BSD student. I transferred in after completing CTY. Since the programs are similar yet different, I'm taking courses from all over the cirriculum.

In my spare time (what little there is), I pursue a myrid of hobbies in a very Jack-of-all-Trades manner. I read, write, play the guitar, and cook. My first short story was published earlier this year in the anthology Mythspring

I also run a yard haunt in Newmarket. Pictures from 2004, and some from 2005, are posted on the haunt's site.

My email: lkates@learn.senecac.on.ca

IRC handle: halcyon1234

BTP600

BTP600 course material goes here. I wouldn't mind doing the Wikipedia Design Pattern stub.

Code Reading Exercise

Looking at MAKE and ???

1. Which file(s) did you have to examine?

make First I looked at loadargc, since argc reminds me of the C/C++ standard command line variables that you use in main. However, that turned out to be a load balancing program. Next I looked at Main.h, since main seems like a good start, and headers tend to define stuff. But there wasn’t anything useful there. So I opened Main.c, and voila! Code that has to do with command line switches.

1. What are your first reactions to these files when you examine them?

make I don’t think I can put them down, in accordance to Seneca’s Acceptable Use Policy. But the sheer amount of code and underscores and structs were a bit overwhelming.

1. How is the code for working with command-line switches organized at the method, class and project levels? (e.g. is is all in one class? broken across multiple classes? spread across many methods? etc)

make There are a couple methods defined right near the beginning:

static void decode_switches PARAMS ((int argc, char **argv, int env));
static void decode_env_switches PARAMS ((char *envar, unsigned int len));

Almost immediately afterwards, there's the structure for an acceptable command line switch

/* The structure that describes an accepted command switch. */

struct command_switch

 {
   int c;			/* The switch character.  */

   enum			/* Type of the value.  */
     {

flag, /* Turn int flag on. */ flag_off, /* Turn int flag off. */ string, /* One string per switch. */ positive_int, /* A positive integer. */ floating, /* A floating-point number (double). */ ignore /* Ignored. */

     } type;

   char *value_ptr;	/* Pointer to the value-holding variable.  */

   unsigned int env:1;		/* Can come from MAKEFLAGS.  */
   unsigned int toenv:1;	/* Should be put in MAKEFLAGS.  */
   unsigned int no_makefile:1;	/* Don't propagate when remaking makefiles.  */

   char *noarg_value;	/* Pointer to value used if no argument is given.  */
   char *default_value;/* Pointer to default value.  */

   char *long_name;		/* Long option name.  */
 };

Main.c then goes on to define a usage output, that is used to define, in English, how to use all the different flags. Presumably, this is used when the /h switch is used

/* The usage output. We write it this way to make life easier for the

  translators, especially those trying to translate to right-to-left
  languages like Hebrew.  */

static const char *const usage[] = ...

   N_("\
 -h, --help                  Print this message and exit.\n"),

...

Afterwards, there is a table of the command switches, along with a bunch of flags and numbers I don't understand.

/* The table of command switches. */

static const struct command_switch switches[] =

   { 'b', ignore, 0, 0, 0, 0, 0, 0, 0 },
   { 'B', flag, (char *) &always_make_flag, 1, 1, 0, 0, 0, "always-make" },

...

It also defines "long names" for short switches, like when you use --help rather than /h

/* Secondary long names for options. */

static struct option long_option_aliases[] =

 {
   { "quiet",		no_argument,		0, 's' },
   { "stop",		no_argument,		0, 'S' },
   { "new-file",	required_argument,	0, 'W' },
   { "assume-new",	required_argument,	0, 'W' },
   { "assume-old",	required_argument,	0, 'o' },
   { "max-load",	optional_argument,	0, 'l' },
   { "dry-run",	no_argument,		0, 'n' },
   { "recon",		no_argument,		0, 'n' },
   { "makefile",	required_argument,	0, 'f' },
 };

Main.h also defines a structure called "file", which has error handling in it for empty filenames:

static struct file * enter_command_line_file (name)

    char *name;

{

 if (name[0] == '\0')
   fatal (NILF, _("empty string invalid as file name"));

Shortly after, main goes into its main() function. It starts to do a bunch of crazy stuff with backslash conversion and allocating temp space for variables and stuff. After its done that, it goes ahead and re-interprets the command line switches, in case Make itself has added any:

 /* Decode switches again, in case the variables were set by the makefile.  */
 decode_env_switches ("MAKEFLAGS", 9);

1. if 0

 decode_env_switches ("MFLAGS", 6);

1. endif

It then goes into a bunch of "goal files", which are, as far as I can tell, files that have to be made. If none are specified, but are expected, it dies:

  if (!goals)
     {
       if (read_makefiles == 0)
         fatal (NILF, _("No targets specified and no makefile found"));

       fatal (NILF, _("No targets"));
     }

1. How are invalid or non-existent Filenames dealt with?

In general, a fatal flag is put up, and the program dies. This seems to be mostly done when the command line switches are processed. If a file was expected (ie: a Make file, or a file specified after a switch argument), then the errors are found when the switch is processed, or the file is looked at. This is different from what I was expecting. I was expecting it to do mandatory file checking right off the bat (start of main function, perhaps), and dying before it did any other work.

Other Wiki Courses

lkates:dps909