Tue 96/12/03 Transfer to Toshiba of makefile development that I started on the home PC. This is built around djgpp, with occasional checks on the Sun to ensure that features unique to gnu make are not used, if possible, so that the make system can be used with Solaris and SunOs make as well. One thing will have to be different: it appears that the inability of command.com to handle multiple commands on a single line means we are stuck with a difference in the master makefile: codas3/makefile. The unix version will have commands like cd dbsource; make while the equivalent for any DOS version will be cd dbsource make cd $(BASE_DIR) Fortunately, it appears that this will require different versions of only the single makefile (codas3/makefile); the versions can be, e.g. makefile.unx and makefile.dj. For present development I will just let the "dj" version be the "makefile". Note on make versions: gnu does NOT support $$@; system V does; we will not use it here. Perl 5 note: utime does not appear to work; can't fix file time in formake.prl, presumably the same for d2u.prl. Switched to BPERL (perl 4.036 compiled with Watcom, using Rational Systems DOS4G) and everything is fine. -> u2d.prl, d2u.prl, formake.prl: it would be good to add a test for functioning utime, giving the option of aborting if it is not working. Otherwise all the modification times of the CODAS source could be wiped out inadvertently. makefile strategy: 1) Keep it simple and reasonably explicit; disable all the confusing builtin rules, so that all rules are visible in the CODAS makefile system itself. 2) Allow easy compilation of particular files. 3) Include some dependency info (e.g. particular objects required for a binary), but at least to begin, don't try to put in all the possible include file dependencies. We may gradually add the most important of these. For now, though, the user will have to manually keep track of some of these dependencies (and dependencies on libraries), and when in doubt, just rebuild the whole system. macro notes: $? prerequisite list--OF MORE RECENTLY CHANGED PREREQS $@ current target $< current prerequisite--ONLY IN SUFFIX RULES ($$@ current target on dependency lines; NOT GNU!) If there is more than one object file prerequisite for an executable, then the list must be given explicitly in the linker command line. Use of $? does not work in general; if only one of the source files has changed, for example, it will cause a link attempt using only that file, ignoring the other prerequisite files. Too bad there is no standard macro for the whole prerequisite list. So far: makefile makefile.dep formake.prl to fix tabs and ends of lines listobj.prl generates objects.lst for libs dbsource/makefile use_db/makefile ioserv/makefile ioserv/main/makefile grid/makefile Tue 96/12/17 vstat/makefile vector/makefile ocean/makefile but so far, only for the library, not binaries matlab/makefile again, no binary; but it may be time to dump matscan adcp/use_adcp/makefile adcp/adcpsect/makefile (Fixed a bug in listobj.prl and reran it in library directories.) Wed 96/12/18 I changed the main makefile so that "make clean" now cleans everything out, and "make" does a full build (but without cleaning or deleting executables or libraries; and only for the grid and adcpsect binaries). Test of djgpp vs TC adcpsect on the demo nav: 8 seconds versus 2 seconds. Why is djgpp executable a factor of 4 slower?? All this is with DOS box in Win95 on 100 MHz Pentium. Only difference in output is due to floating point formatting bug in TC. Turning on -O2 made the binaries a little smaller (I think--they are still very large), but the runtime is still 8 s. Running in the full DOS mode, the time is over 1 minute--evidently the result of lack of disk caching. The disk activity light was on almost continuously. Wed 97/01/01 Visual C++ is now installed. To support it, the makefiles must use macros for object and library extensions. Previous makefiles are modified accordingly. In the process, I greatly simplified the library makefiles (to three lines each) by having them include ../make/$(HOST)/library.mak. NOTE: a new directory has been added to the CODAS tree: make subdirectory for each host. vecplot/makefile util/makefile Note: chtime really belongs in adcp subdirectory; it uses data processing mask,(dpmask.h) which is in adcp/include. fixnbyte: obsolete? I think this was a one-shot for fixing a temporary problem caused by a bug. use_db.h: cleaned out some duplicate declarations. to_day, to_date: fixed include statements adcp/edit/makefile Tue 97/01/07 Next: adcp/cal. Copied over makefile from edit. Looked at difference between timslip and timslip_: appears to be additional output from timslip_, with no explanation; but it looks potentially useful. rgrep did not find any m, c, or doc file that contains "timslip_". Solution: ideally, the extra output would simply be optional, selected in the control file. Problem: control file uses only parameter list. Solution: switch to option processing. adcp/cal/makefile: done, without timslip_; the change discussed above is STILL NEEDED! Wed 97/02/19 Brought over util/to_date.c and dbsource/dbopsrch.c after modifying them on noio. Added standard input option to the former, fixed a bug in the latter wrt time searching when an input time is in hundredths but the block time is in seconds. adcp/nav/makefile: done; required a change to the CC rule in makefile.dep to handle refabs, for which all source files are in the cal directory. Thu 97/02/20 adcp/ping2mat/makefile: done; DELETED nav2mat, which seemed hopelessly obsolete. I found no other files which used or referred to it, and there is not even any record of what nav file format it was supposed to read. MODIFIED ping2mat slightly, changing "unlink" to "remove"; unlink is in unistd.h whereas remove is in stdio.h. Also removed the "timezone" setting, which was PC-specific but NOT compatible with DJGPP. Fri 97/02/21 deleted INSTANT_C and LETS_C from all dbhost.* fixed include list in util/to_date.c adcp/scanload/makefile: done NOTE: ping_ren and pingcopy are PC-specific and TurboC specific; they are not in the makefile. They use directory access routines; are there any ansi-standard equivalents? adcp/tran_bbp/makefile: done many warnings; still needs to be cleaned up. adcp/tran_nbp/makefile: done also many warnings I changed several file names to match the convention in tran_bbp, so the makefiles would be more similar. One difference is that nbp has the file nbptodb, which must have gotten absorbed into some other file in tran_bbp. Sat 97/02/22 adcp/cal/ renamed refabs.c to refabinc.c created new refabs.c and refabsbt.c that just include refabinc.c, with or without a definition of REFABSBT. This allowed me to remove the special rule from the makefile, so the compilation of refabsbt is now just like any other program. adcp/util/makefile done There might be a couple of warnings needing attention. profstat/makefile: done ctd/load/makefile: done ctd/util/makefile: done Note: the conv_ctd program is not likely to ever be needed again; the code should be preserved, but it might make sense to take it out of the usual makefile loop so that the executable does not clutter up the bin directory. Sun 97/02/23 ocean/cmd/makefile: Note: atof prototype is in stdlib.h of djgpp; this is included by common.h only for the TurboC version, which is what we are using as the model for the djgpp; but perhaps it should be in the ansi version also, at least. >>CHECK<< scanping: on first test, it did not recognize the end of the list of file names. I fixed it by changing to "while(fscanf( } == 1" instead of "... != EOF" loadping: same change. adcpsect: uses "get_time_range" to read time ranges until end of file; similar change, keep looping while it returns 1 instead of while it is not EOF. (Returns 1 if a time range is found, 0 if it is not but it is not the end of file, and EOF if it is the end of file. In the 0 case, the file pointer is reset so that another attempt to parse can be made if desired.) adcpsect: still very slow with DJGPP; looks like very inefficient disk buffering--no use of cache? Try changing to DIR_IN_MEMORY. That seems to have brought it from 9 seconds down to 7 seconds (versus 2 for TC) and stopped the obvious disk thrashing. Still puzzling as to why it is so slow. Could it all be thunking overhead for all the disk accesses? profstat: same get_time_range loop change as for adcpsect other cases of this are listed in gtr.lst; corresponding fscanf cases are in fseof.lst. cases of "fprintf(...%lf" are in fplf.lst. (GCC warnings) Tue 97/02/25 The following from fseof.lst were fixed: ./vecplot/vector.c:506: while (fscanf(fpvec, " %lf %lf", &(ll_d.lon), &(ll_d.lat)) != EOF) ./util/asc_dump.c:66: while( fscanf( fp_cnt, "%79s", buff ) != EOF ) /* buff holds block ./adcp/nav/nmea_gps.c:371: while (fscanf(fpcnt,"%s",in_file) != EOF) ./adcp/nav/nmea_gps.c:387: while (!(finished || fscanf(fpcnt,"%s",in_file) == EOF)) ./adcp/tran_bbp/loadtbbp.c:185: while (fscanf(fpcnt, " %s", filename) != EOF) ./adcp/tran_bbp/loadtbbp.c:242: while (fscanf(fpcnt, " %s", filename) != EOF) ./adcp/tran_nbp/loadtnbp.c:93: while (fscanf(fpcnt, " %s", filename) != EOF) ./adcp/tran_nbp/loadtnbp.c:156: while (fscanf(fpcnt, " %s", filename) != EOF) util/mc1.c: I also fixed lines 511, 829, where there was in int sprintf format for a long argument. NOTE: These lines actually have another bug in the use of db->block_hdr.dir_type, which appears to still be assumed to be 0-3; this bug will go away when I change things back so that this is true again, by using another variable as the flag for seconds versus hundredths of a second. Fri 97/02/28 Fixed all of the following get_time_range bugs. ./util/lst_prof.c:100: while (get_time_range(fp_cnt, &start, &end) != EOF) ./adcp/edit/flag.c:219: while (get_time_range(fpcnt, &start, &end) != EOF) ./adcp/edit/set_top.c:93: while (get_time_range(fp_cnt, &start, &end) != EOF) ./adcp/edit/fix_temp.c:249: while (get_time_range(fp_cnt, &(range.ru.time.start), &(range.ru.time.end)) != EOF) ./adcp/edit/fix_temp.c:281: while (get_time_range(fp_cnt, &start, &end) != EOF) ./adcp/edit/fix_hdg.c:71: while (get_time_range(fp_cnt, &start, &end) != EOF) ./adcp/edit/newflag.c:221: while (get_time_range(fpcnt, &start, &end) != EOF) ./adcp/util/lst_hdg.c:92: while (get_time_range(fp_cnt, &start, &end) != EOF) ./adcp/util/getnav.c:95: while (get_time_range(fp_cnt, &start, &end) != EOF) ./adcp/util/lst_temp.c:144: while (get_time_range(fp_cnt, &start, &end) != EOF) ./adcp/util/lst_alfa.c:93: while (get_time_range(fp_cnt, &start, &end) != EOF) ./adcp/util/lst_conf.c:97: while (get_time_range(fp_cnt, &start, &end) != EOF) ./adcp/nav/ubprint.c:265: while (get_time_range(fp_cnt, &start, &endtime) != EOF) ./adcp/nav/nmea_gps.c:496: if(get_time_range(fpcnt, &startT, &endT) == EOF) exit(-1); ./adcp/nav/lst_btrk.c:112: while (get_time_range(fp_cnt, &start, &end) != EOF) ./adcp/nav/nav2dir.c:87: while (get_time_range(fp_cnt, &start, &end) != EOF) Started on fixlf.prl, which reads plf1.lst and will use it to change the %lf to $f etc. in *printf. Sun 97/03/02 Finished a major run of cleaning up warnings by "gcc -Wall". Some types: use of printf("%lf"...) instead of "%f". Float arguments are always promoted to double, so the "l" is superflous. I checked: no problem in making this change on TC, Sun 4.x, Sun 5 with any option, gcc. time() etc work with "time_t", not long; this change may require some fiddling with the compiler-dependent include strategy. labels and variables not used. disagreement between format strings and argument types--many variations on this. Something that looked like a genuine bug due to misplaced parens in invalid_position(), posn.c. Various header inclusion problems. For example, some functions were moved out of use_db. I did not fix the "missing braces around initializer" warnings. I made a try at it, but found that it would require adding so many braces that it would clutter rather than clarify. I also did not plunge into the loadt?bp programs; they need a full cleanup. scale.c and unscale.c still have warnings; Ying and I had earlier failed to find a clean way to escape them, and concluded that they were entirely harmless. Misc. discoveries: bin/sh200 works fine for redirecting stderr from gcc to a file: make > make.log 2>&1 Then use c:\turboc\grep warning make.log > make.w to get a list of warnings. The djgpp find command does not work with exec, because it tries to run the program from the original directory, but DOS has cd'ed to the directory in which the file is. Therefore part of the file path is repeated, and the file is not found. bin/sh200 can't handle a long enough input line to delete a list of files found by "find", but cygwin bash does fine with rm `cat rm.lst` Also, in cygwin, the normal find ... exec {} \; line does work, but the find command is case-sensitive. Q and most if not all DOS programs store the file names as upper case, so one must search for '*.BAK', for example, not '*.bak'! In a DOS batch file, % on a command line must be doubled. Otherwise DOS deletes it, thinking it marks a nonexistent variable. The gcc warnings give the line number of the END of the statement, so they can't be used trivially to locate the line in which a problem is actually found for automatic processing by a line-oriented PERL script. (This makes sense; it is not really a gcc deficiency, although it would be nicer if the line number of the beginning of the statement were given.) zip files: codas30.zip was made just before all these changes, codas31.zip just after. Before making the latter, I deleted all the sun4 binaries (but not the scripts) and the object files. Thu 97/03/06 ctd/load/load_odf.c: Fixed the design shortcut that caused the normal end of the program to generate an error message. possible change needed for smoothr: at the end of the present optimize_positions, make a pass in which any missing positions would be interpolated from the fix file directly. That way we would at least have a good estimate of where the ship was, even if we don't have a water velocity estimate. Things to check: is adcpsect or anything else relying on bad positions? Filling in the positions would seem to make life better for the llgrid routine, although perhaps that was already fixed to jump over missing positions. Sun 97/03/09 I went through all the bin makefiles and moved main_cnt from the library list to the object list. I also fixed several places where there was no "programOBJECTS" macro. This should leave these makefiles in a sufficiently regular state that a simple perl program can use them to write makefiles that will work with turboc. make/ucd: Unix CD. A little Turbo C utility to change directories with Unix slashes in them. This means the main makefile can have forward slashes, as can (and must) the BASE_DIR macro in makefile.dep make/ucd/dospath: Another little utility that takes an argument (Unix style path) and prints it to stdout as a DOS style path. Changed the makefile scheme a bit; set up tc directories and host type, and made the tc libraries with the standard makefile. Modified listobj.prl to generate a tlib.rsp file along with the objects.lst. TC binary makefile: the prototype is in grid. All bin makefiles need to have $(CC) changed to $(CCLINK), and the latter must be defined appropriately in each makefile.dep. Normally it will be the same as CC, but for TC it is a djgpp program called arglist; and CHMOD is pressed into service to call a perl program, tlink.prl, which reads the output of arglist, writes a response file for tlink, and calls tlink. ...Temporary turboC path variable at top of tlink.prl--Is this the place to set it? How do we make sure tlink.prl can be found? Where do we put it? .... Mon 97/03/10 tlink.prl is now in codas3/. Everything seems to work. A full TC compilation was completed. The command is: redir -eo -o make.log e:/pd/djgpp/make where redir is a djgpp utility. With these options it redirects stderr and stdout to make.log. The ladcp make file was also fixed and tested with TC. It works, but just barely; because of the number of include directories, the tcc command line is very close to the 128 limit. NOTE: for TC, the INCLUDES macro must be on a single line! If we start to run into problems with the tcc line limit, the solution may be to go to an intermediate step: write out a turboc.cfg file with the options (such as includes) before calling tcc witht the remaining arguments. See page 40 in the TC 2.0 user's guide. Sun 97/04/06 Substantial changes completed (I hope): The method of indicating hundredths of a second was changed. Previously it was indicated by 10 added to the profile directory type. Now it is indicated internally by a value of 2 in the new block_hdr.dir_time_flag which took the place of USHORT unassigned[1] (and which had been initialized to zero, the value for seconds rather than hundredths. In the data definition file, the key word DIR_TIME_IN_HUNDREDTHS on a line of its own causes the use of hundredths. The default in the absence of this line, or the explicit keyword DIR_TIME_IN_SECONDS, cause the use of seconds. The rationale for using "2" as the block_hdr.dir_time_flag was that it is the power of 10 by which the time is divided to get seconds. That leaves the door open to using other powers of 10; however, note that all the code related to hundredths is just checking the flag for zero/non-zero, so using anything other than 100ths would require another major rewrite. The time search had become a bit messy and buggy. I simplified it and removed a bug (error in searching for a time in the last minute of a block immediately preceding the currently open block) by deleting db.block_time_span and making changes in lock_on_time() and search_for_profile_by_time(). Comments were also added to try to make the code less confusing. The bug that was fixed probably would have shown up only when using showdb on an ladcp database. util/hunflag/hunflag.c: a quick one-off utility for fixing ladcp databases loaded with the old hundredths specification method. Sat 97/04/26 Michele Lyons had found a problem with the TC adcpsect. I traced it to the fact that dbupdate (and updscan) can cause MAXSHORT to be written into access.last_good_bin. adcpsect then adds 1 to it before comparing it to the number of bins found. Adding 1 on a 2-byte system causes it to wrap to -32768, which is less than the number of bins found, and ends up accepted as the number of bins. This causes havoc. I put in a check for this in adcpsect, and then changed dbupdate and updscan so that they don't write MAXSHORT, but write conf1.num_bins, the original default, instead. note on MAKE: The present system is specific to GNU MAKE. It is undesirable to be restricted to this one variant, but I could not find a clean way with standard make to accomodate the general CODAS directory structure, and rather than reorganize it, I used GNU. Specifically, it it the "%" form of pattern matching in the c-to-object compilation rule that allows us to have object files and their source in directories other than the current one. Wed 97/04/30 getln_nc.c: changed to reject any line for which the first non-white character is other than +, -, ., or a digit.