lex and gcc

Exercise 10.2.1: Automatically generate a lexical analyzer which outputs the uncommented and commented included header filenames from a stream of C/C++ source code. Requirements: a) Your program must read from standard input and file input, but always write to standard output. b) Your program must support only two command-line options (-u and -c) and combinations of them (e.g., -uc and -cu). c) When run with no command-line options, your program must print both uncommented and commented included header filenames (and nothing else) using the format used in the sample output given below. d) When run with the -u command-line option, your program must print only the uncommented included header filenames (and nothing else) using the format used in the sample output given below. e) When run with the -c command-line option, your program must print only the commented included header filenames (and nothing else) using the format used in the sample output given below. f) When run with the -u and -c command-line options or the -uc or -cu command-line options, your program must print both the uncommented and commented included header filenames (and nothing else) using the format used in the sample output given below. g) If an invalid option <option> is given, the program must print ./showheaders: Illegal option: <option> and a usage message to stderr and halt with a exit status 1 as shown below. 1 $ ./showheaders ?t 2 ./showheaders: Illegal option ?t 3 Usage : showheaders [?cu] [file(s) . . . ] 4 $ echo $? 5 1 h) If an invalid file <file> is given, the program must print ./showheaders: Invalid file: <file> and a usage message to stderr and and halt with exit status 2. 1 $ ./showheaders somefile 2 ./showheaders: Invalid file : somefile 3 Usage : showheaders [?cu] [file(s) . . . ] 4 $ echo $? 5 2 i) You may assume that the input stream will never contain more than fifty (uncommented or commented) included header filenames. j) You may assume that if you encounter an opening /* comment token that the closing */ comment token will always be on the same line. More generally, you may assume that the input stream will be syntactically valid C/C++ source code. k) Note that comments may contain both text and an include file: 1 /* This i s my comment about # in clude < s t di o . h> */ 2 3 // This i s my comment about # in clude < s t di o . h> l) Your solution must contain only a flex specification file and a Makefile (i.e., no other source files). m) Use macros and substitutions (e.g., digit [0-9]), where possible and appropriate, to simply the pattern-matching rules in your flex specifi- cation file. n) Develop a Makefile which builds your lexical analyzer. Your Makefile must include target directives for every derived file produced during the compilation process (i.e., each program, each object file, and any other intermediate files produced during code generation and compilation). Make sure that each directive also lists all files on which the derived file depends in its dependency list. Also, your Makefile must be written so carries out only the commands necessary to bring any produced file up-to-date. Your Makefile must do just enough, but no extra, work to bring showheaders (the final executable for your lexical analyzer) up-to-date every time make is invoked. In addition, it must have an all directive and a clean directive to remove all generated files. Use variables where appropriate in your Makefile to improve its readability. Your Makefile must bring everything up-to-date, using only lex and gcc, without any warnings or errors, when make is invoked.