Thread: [Ctags] Filtering via #define macros
Brought to you by:
dhiebert
From: Barnhart, K. <Kev...@ec...> - 2002-08-05 20:08:12
|
Hi All, I'm new to ctags, so pardon a newbie question. A VERY handy feature for me would be able to process preprocessor directives. The code that I work on is what we call "switched" code. We use a single code base for many different model versions. So, when I download the code from our VC tree I get a lot of code that is useless to the model that I am working with. Basically, we switch on a model number (i.e. #define m8000) and inside one of the header files, this switches on a bunch of other #defines that are used in that model. This determines the actual code that the compiler uses for the model I am working on. SO, I'd like to know if ctags has any feature that will take a defined macro (ie I give it m8000) and it parses all #define's, #ifdef's, #if's and only looks at the code that is specific to my model. This is especially useful, since a function might be declared 4 or 5 times in the same file, but only once for the model I'm working on. Would I have to define a different parser, or could I add to the current C parser? Please send me a reply to this, as I'm not apart of the list. Thanks, Kevin |
From: Darren H. <dhi...@us...> - 2002-08-07 03:10:52
|
On Mon, 5 Aug 2002, Barnhart, Kevin wrote: > A VERY handy feature for me would be able to process preprocessor > directives. The code that I work on is what we call "switched" code. We > use a single code base for many different model versions. So, when I > download the code from our VC tree I get a lot of code that is useless to > the model that I am working with. Basically, we switch on a model number > (i.e. #define m8000) and inside one of the header files, this switches on a > bunch of other #defines that are used in that model. This determines the > actual code that the compiler uses for the model I am working on. SO, I'd > like to know if ctags has any feature that will take a defined macro (ie I > give it m8000) and it parses all #define's, #ifdef's, #if's and only looks > at the code that is specific to my model. This is especially useful, since > a function might be declared 4 or 5 times in the same file, but only once > for the model I'm working on. Would I have to define a different parser, or > could I add to the current C parser? This has actually been requested several times (which probably means that it should go into the FAQ). The problem is that to support this, I would have to add support for full expression parsing and evaluation, which I am very reluctant to do for such limited benefit. Example: #if PROG_VERSION > 4 && SOME_LABEL == 2 ... #endif You can probably see where this is going. Now you may say "but I only need support for "#ifdef LABEL". Yes, I know from experience that as soon as I add support for this, I will receive complaints that it does not support "#ifdef LABEL == 0", and the slippery slope will have begun. I do not really want to turn ctags into a full preprocessor. Even then, you may find that it doesn't always solve your problem. Example: #ifdef ONE void foo (int a) { /* implementation 1 */ } #else void foo (int a) { /* implementation 2 */ } #endif Since ctags generates regex patterns (by default) to locate the function definition, the regex patterns for both instances are identical and the unique sort of the tag file will result in only one (since there is no value of having the same pattern twice). You editor cannot possibly know which match you want, and will always go to the first one. If you have any ideas that I have not thought of, feel free to suggest them. -- Darren Hiebert <dhi...@us...> http://DarrenHiebert.com |
From: Neil B. <ne...@fn...> - 2002-08-07 07:26:54
|
Around about 07/08/2002 04:11, Darren Hiebert typed ... > You can probably see where this is going. Now you may say "but I > only need support for "#ifdef LABEL". Yes, I know from experience > that as soon as I add support for this, I will receive complaints > that it does not support "#ifdef LABEL == 0", and the slippery slope > will have begun. I do not really want to turn ctags into a full > preprocessor. Then how about a 'simple' "use [this] cpp program" as an option? All of the cpp's I've seen spew a single output file with all pre-proc tokens and unwanted code elided. The only token left in is the "#line" which you'd have to use to skip all files bar the one you originally wanted to process, and then keep track of the 'current' line accordingly. The only problem is - you'd lose the ability to tag #defines, etc., as these would have disappeared. (thinking aloud) I suppose you could, in parallel to reading the cpp output, actually still *process* the original source, but omit any source lines for which the equivalent cpp output line is empty (meaning that cpp has determined iot wasn't wanted). That might seem a bit hacky, but I can see it working. -- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit |