rfg@ics.uci.edu (Ron Guilmette) (12/20/89)
In article <89Dec18.204529est.27294@snow.white.toronto.edu> ghfeil@white.toronto.edu (Georg Feil) writes: >I am in the process of installing protoize/unprotoize. This apparently >requires gcc 1.36 to be rebuilt with a fairly hefty set of patches. The vast majority of the patches are simply the addition of new files. This should not interfere with anything. There are however a significant number of patches to the "base" GCC files, and that does indeed cause many problems. The two fundamental problems are (a) the patches may not apply cleanly if you have a hacked-up version of GCC, and (b) the patches may not apply cleanly on the (always just around the corner) next version of GCC. I'm going to make this problem much less severe. Basically, the patches for the existing GCC files were in two groups. One group to support the new -fgen-prototypes option. The second group was to add full support for the (secret and mostly unimplemented) -fsyntax-only option. Supporting -fsyntax-only allowed a significant speed-up in the protoization process, but other that that, was unnecessary. In order to reduce patching problems, I'm deleting the -fsyntax-only patches from the next release of protoize/unprotoize. This will make it much less likely that you get any patching problems, since the remaining patches for GCC files will be quite minimal. >What effect do these changes have on g++? G++ uses many of the gcc 1.36 >source files. Seems to me that if I apply the protoize patches and then >attempt to rebuild g++, something will go wrong. Is this true? In general, if you have a hefty hunk of GCC patches, and if you try to use them with G++, be prepared to spend a lot of time fiddling. Believe me. I know. Anyway, that's beside the point. THERE IS NO RATIONAL REASON to implement -fgen-prototypes within G++. Since G++ *requires* that everything be in prototype format already, this is a big waste of time. I suggest that you should build a plain vanilla G++, and a separate version of GCC with support for -fgen-prototypes. >I also wonder if there are plans to make protoize/unprotoize (or at least >the relevant compiler patches) a permanent part of future versions of gcc. Yes. There are such plans, but don't hold your breath. Rms has lots of other things to do also. In the meantime, protoize/unprotoize users should be aware that I've been doing some rather intense hacking on a new version which I hope to make available by the first of next year. (That's not far off you know!) I'm very proud of the changes that I've made so far, and I believe that people will be stunned and amazed to see how far protoize/unprotoize have come. The new version will be incredibly more bullet-proof. Unlike previous versions, it will NEVER be confused by comments or preprocessing directives, (but macro CALLS in the wrong places may still cause files to be unconvertable). Also, all known bugs (and many undiscovered ones) have been fixed, and several new options have been added. Protoize will offer the choice of inserting new declarations (for things that were implicitly declared) *either* locally (in nearest blocks) or globally (near the top of the file). Both tools now support conversion of functions which return pointers to functions, and even functions which return pointers to functions which themselves return pointers to functions (ad nauseum). Original files will be saved with a .save suffix (rather than being deleted) and conversion is done in-core so that if a file is found to be unconvertable (quite rare), the original will be left intact. Even if you are root, no attempt will be made to convert files beneath /usr/include (unless the -f "force" flag is used). Also added was a -n option (i.e. no-convert) that is similar to the -n option for make. When used, no conversion will take place, but a list of files that *would* be converted (if the conversion were performed) is written to stdout. This may be helpful if you are converting a large system that uses include files from other directories (and possibly belonging to other users) that should not be changed. Using -n allows you to know (ahead of time) which files will be changed. Finally, I plan to do something for the sake of those systems where FILE is #define'd (rather than being a typedef as it should be). Basically, this just involves getting the .P files edited so that "struct _iobuf" gets un-macro-expanded back to "FILE". >(Of course, once GNU C takes over the world, we won't need protoize anymore :-) Not true at all. You may not need "unprotoize" anymore, but you will need "protoize" for a long time because of the millions of lines of old K&R code that still exist out there. In case there is any doubt in anybody's mind, you can be sure that I have a sincere hope that *everybody* on the entire planet will use the next version of protoize to convert EVERY SINGLE LINE of existing C code to ANSI C. That's why I have gone to such trouble to build it and then to try to make it "production quality". I hope that its existance will remove the excuses, even for those people with million line systems written in K&R C. Of course after every line is converted to ANSI, *then* we will have to start getting it all munged around to be C++ also. (And that was my real goal in the first place). // rfg