Community
Participate
Working Groups
When adding a dir (containing extensionless headers) for includes in a C++ project .. the headers are not recognized and do not play with the content assist and the indexer .. even forcefully using them in the code does not make the code compile (unrecognized resource) The extensionless headers were proposed as a C++ standard. Not entering an argument if this decision for a standard was right or wrong in the first place .. but now it is an established current practice, especially in some major OSS projects (KDE 4 perhaps come to mind using such practice) A method should be included to recognize this special case on adding such a directory in the includes to include the extensionless headers in the project.
Do you have suggestions on how we'd know they are header files versus executables, for example, or other things? For tools, extensionless headers are a really bad idea.
I know that using extensionless header is a pain in the head. But yet it is still an ongoing practice, bad or not. But how does CDT differentiate between .h header file for c and those for c++ or this distinction is not present at the moment? Is there a way that CDT can look at the syntax of *only* extensionless files at the time of adding an include dir? On the other hand if you have any suggestions for working with those without tweaking CDT, then I will also be happy :)
(In reply to comment #2) > I know that using extensionless header is a pain in the head. But yet it is > still an ongoing practice, bad or not. > > But how does CDT differentiate between .h header file for c and those for c++ > or this distinction is not present at the moment? This is done with the project nature that is set when you create a new C or C++ project. > Is there a way that CDT can look at the syntax of *only* extensionless files at > the time of adding an include dir? Well, we don't do any parsing when you add an include dir. When indexing we could consider all files without extensions in an include dir to be a header file. But I'm worried what happens if it is totally not a header file. > On the other hand if you have any suggestions for working with those without > tweaking CDT, then I will also be happy :) > We do allow you to enter files into the C/C++ -> File Types preference. That's where the STL files are listed so we know that they are header files.
(In reply to comment #3) > > But how does CDT differentiate between .h header file for c and those for c++ > > or this distinction is not present at the moment? > > This is done with the project nature that is set when you create a new C or C++ > project. Does this mean that CDT does not quite handle heterogeneous projects where you have a mixture of C and C++ code? > > > Is there a way that CDT can look at the syntax of *only* extensionless files > at the time of adding an include dir? > > Well, we don't do any parsing when you add an include dir. When indexing we > could consider all files without extensions in an include dir to be a header > file. But I'm worried what happens if it is totally not a header file. There are #include statements in the source code. Isn't it possible to determine that a particular file is getting #included? Perhaps after adding such a file can be treated as a binary until such determination is made?
(In reply to comment #4) > Does this mean that CDT does not quite handle heterogeneous projects where you > have a mixture of C and C++ code? C files work in C++ projects. C++ files probably work in C projects for that matter. The project type is mainly for understanding what language header files are. We also use it to figure out what linker to use for managed projects. > > > Is there a way that CDT can look at the syntax of *only* extensionless files > > at the time of adding an include dir? > > > > Well, we don't do any parsing when you add an include dir. When indexing we > > could consider all files without extensions in an include dir to be a header > > file. But I'm worried what happens if it is totally not a header file. > > There are #include statements in the source code. Isn't it possible to > determine that a particular file is getting #included? Perhaps after adding > such a file can be treated as a binary until such determination is made? Of course, we always parse files that are #included no mater what the extension is or whether it has one. I thought you were talking about the indexer option where you parse all headers in the include path. If that's not happening then that's a different bug all together. But as far as I know that's working if your include dirs are set up correctly so we can find them.
> Of course, we always parse files that are #included no mater what the extension > is or whether it has one. I thought you were talking about the indexer option > where you parse all headers in the include path. > > If that's not happening then that's a different bug all together. But as far as > I know that's working if your include dirs are set up correctly so we can find > them. > Please can you explain your above paragraph .. I don't get it. Pardon my poor English. This is the first time I use eclipse for C/C++ and the first time I log into eclipse's bugzilla and file a bug report and I would like to see it develop in this regard ahead of many leading competitors. But I still hold my opinion that this is a very-much needed feature, whether I need it or not; because many projects have coexisting c and c++ code .. and many projects use the practice of extensionless headers, and as I told you .. big FOSS ones like KDE.. and perhaps other projects follow this standard too .. you may never know. And in the future, KDE will have many C++/scripting language bindings like python .. ruby .. even php and C#. In the future many FOSS project may resort to mixing several languages in one project, and CDT falling back just to the 'type of project' won't help in the future. Anyway to return to my point: Your solution of file types has the same pitfall you are worried about .. how can I associate every single filename to be a header file .. this is insane when working with dozens of these files .. even making a * is even madder in this regard or whatever .. I also suppose my binary and text files in my project will be read as headers .. so your proposed hack is worse than the current situation at least!! I guess my suggestion that doing a quick parse for extensionless files before adding the includes will do the trick. For performance .. only check extensionless files and do not check say jpg, bmp, hee, haa etc etc. files .. which the user could add himself along with other of his customized fancy extensions to the project file-types in the preferences. But extensionless is/used to be a standard and we must at least put it in our minds. Here is another suggestion too .. if CDT finds extensionless files in the included dir .. a dialog presents to the user "CDT found the following extensionless files in the include dir" .. and a listbox is shown containing the files enabled with multiple select "Please choose the files that will be included as #includes in your project." The user chooses the files .. voila!! I also need your feedback on the parser and content assist thing and how it will interact with extensionless headers. I guess it won't hurt ;) Regards.
(In reply to comment #5) > (In reply to comment #4) > > Does this mean that CDT does not quite handle heterogeneous projects where you > > have a mixture of C and C++ code? > > C files work in C++ projects. C++ files probably work in C projects for that > matter. The project type is mainly for understanding what language header files > are. We also use it to figure out what linker to use for managed projects. Actually, it works in practice well enough, at least in our practice. However there are some cases when distinction could be helpful. One example is bug 239964. > > > Well, we don't do any parsing when you add an include dir. When indexing we > > > could consider all files without extensions in an include dir to be a header > > > file. But I'm worried what happens if it is totally not a header file. I think that it is typical to keep a separate folder for headers. And I don't think it is typical to keep or generate binaries there. Oh, well I guess this is not exactly accurate, I've seen all kinds of garbage in include folders especially in common environment. But you are not supposed to! Maybe the header folders picked by scanner discovery should be "header folders" by default and non-header files to be marked as such by a user? Or indexer can figure out that it deals with non-ASCII and ignore that file? A threshold on number of errors? Something. Option for a user to mark the folder as "header folder" so its his responsibility if binary file gets indexed. > > > > There are #include statements in the source code. Isn't it possible to > > determine that a particular file is getting #included? Perhaps after adding > > such a file can be treated as a binary until such determination is made? > > Of course, we always parse files that are #included no mater what the extension > is or whether it has one. I thought you were talking about the indexer option > where you parse all headers in the include path. The contents of such a file may be parsed by indexer, however, you cannot work with it as with regular headers while editing or viewing. First, when you put a cursor on #include <header> and navigate there with F3, you get it open with plain text editor. Fine (not really) since I can open it via Project Explorer with C++ editor and get syntax highlighting (which is great by itself by the way). But there is no content assist and other niceties available. > > If that's not happening then that's a different bug all together. But as far as > I know that's working if your include dirs are set up correctly so we can find > them. Indexing works with some minor hiccups which "Rebuild" of Index can cure.
(In reply to comment #0) > When adding a dir (containing extensionless headers) for includes in a C++ > project .. the headers are not recognized and do not play with the content > assist and the indexer .. even forcefully using them in the code does not make > the code compile (unrecognized resource) Headers that are not part of the project are never parsed, unless they get included by some source-file. Then the inclusion takes place independent of the file name. The CDT-parser obviously has no influence on whether your code compiles or not, so I am uncertain what your bug report really is about. > The extensionless headers were proposed as a C++ standard. Not entering an > argument if this decision for a standard was right or wrong in the first place > .. but now it is an established current practice, especially in some major OSS > projects (KDE 4 perhaps come to mind using such practice) > A method should be included to recognize this special case on adding such a > directory in the includes to include the extensionless headers in the project. If you open up a header in the editor, CDT will detect the standard headers without extension (it knows the list of std-headers: iostream, vector, etc.). I don't see where the standard ever suggested to use headers without extension for other files and so far I did not see a project with such a foolish approach. I had a quick look at kdebase-4.0.5 and my first impression was, that the headers in there do have extensions. Can you point me to the problematic files?
> Headers that are not part of the project are never parsed, unless they get > included by some source-file. Then the inclusion takes place independent of > the file name. The CDT-parser obviously has no influence on whether your code > compiles or not, so I am uncertain what your bug report really is about. True. Sorry for the bad wording of the problem. My poor English. The bug report is about them not being added to the project when I added the dir to the includes.. because eclipse only searches for .h files (or other as specified in the file-types preferences) and ignores other files including extensionless files My initial trial to use them in code is because the directory containing them was indeed included in the includes, however, I eventually noticed that it is empty and the files contained within were not included in the project.. and hence not used by the indexer and content assist. (In reply to comment #8) > I don't see where the standard ever suggested to use headers without extension > for other files and so far I did not see a project with such a foolish > approach. I had a quick look at kdebase-4.0.5 and my first impression was, that > the headers in there do have extensions. Can you point me to the problematic > files? > After facing the problem of extensionless headers, I researched this practice and a couple of sites said that it was a horrible suggestion by *whoever name of important C++ programmer here* .. this is the only information I have about the origin of this practice. I, for one, hate this practice as much as all of us do. But as of now, there is no doubt it is being used. think <string>, <iostream> etc. Anyway, in kde, there are certainly .h headers but if you observe the code you will notice that the practice over there is using #include <KJob> i.e. extensionless They do this by providing an includes/KDE directory which contains the extensionless headers which are in reality just dummy headers containing only one line: #include <../header.h> just to reference the header with the extension in the parent dir. They say extensionless is more 'aesthetically appealing' and more 'in vogue' ;) But yes KDE is all over this practice.
And for reference here is the kde practice This is a project's (called plasma) includes library http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/plasma/includes/ notice the upper cases used in filenames and the absence of extensions Now let us take a look at one of these extensionless files .. let's say the file named "Applet" http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/plasma/includes/Applet?view=markup it only contains the line #include "../../plasma/applet.h" No comment!!! I hope I can contact one of the kde devs to know what is their motivation to use this weird convention.
(In reply to comment #9) > The bug report is about them not being added to the project when I added the > dir to the includes.. because eclipse only searches for .h files (or other as > specified in the file-types preferences) and ignores other files including > extensionless files > My initial trial to use them in code is because the directory containing them > was indeed included in the includes, however, I eventually noticed that it is > empty and the files contained within were not included in the project.. and > hence not used by the indexer and content assist. The files with wrong or no extensions are not shown in the project explorer or in the CView. However, they are indexed and their content can be used for content assist as soon as the header is included by at least one source-file. > .... > no doubt it is being used. think <string>, <iostream> etc. these are the standard c++-headers, which will correctly be shown in the Project Explorer. > But yes KDE is all over this practice. Thanks for pointing me to the right spot. I played a bit with such a scenario and actually I found it to work reasonably well. When the header is included from a source I can not only use content assist, also when navigating to the declarations in the header it will open up the header in a CDT-editor providing me an outline view and other tooling. --> I think you are looking at a different problem. A common mistake is to configure the include path for the wrong language (can be different for c- and c++). If you cannot make it work, please create a minimal project and attach it to this bug.
Created attachment 108615 [details] empty includes Marcus: I fail to see how the scenario works in your case but it certainly is not working with me. Take a look at the screenshot attached .. this is the /KDE includes dir which contains extensionless headers (all these headers are only dummies .. references to .h headers in the parent directory) as you can see the dirs is empty as the headers did not get added to the project now I tried your suggestion: I entered #include <KUrl> instead of #include <kurl.h> in one of the projects and I followed it using ctrl+click on the declaration .. the extensionless file opened true in the editor .. even giving me an outline view This time (maybe because I followed the KUrl into its extensionless header, I don't know for sure) .. the project built successfully and the compiler did not complain of an unidentified include .. but still problem(s) persist. Still .. the extensionless header wasn't added to the project after checking the includes (still empty) .. and the content assist does not play well with it .. no code completion and no indexing there. So being able to build the project using your suggestion is only a workaround and not a complete solution. Bear in mind that your workaround (which maybe I have to repeat for every single include I do .. without code assist) won't also get included by the indexer and hence won't be integrated as the other code. It appears there might be two explanations explaining this behavior: 1) A problem with the indexer: Since there are like two references to one .h file (the real one and the dummy extensionless one) - the indexer gets confused and only indexes the .h one ignoring the other files (but why it specifically chose the .h one? I don't know) 2) The indexer behaves well with these scenarios but the real bug is in the project includes because it insists on not adding any headers except if they are .h files. I think no.2 is the more reasonable explanation.(as evidenced by the empty include dir in the screenshot attached, even after successful building) I am open to your suggestions. Regards,
(In reply to comment #11) > > no doubt it is being used. think <string>, <iostream> etc. > these are the standard c++-headers, which will correctly be shown in the > Project Explorer. hmm .. yes they are being correctly shown in the project explorer. So the project explorer has the ability to add extensionless headers after all and treat them (with the indexer and code assist) as normal headers that can play well with the rest of the code!! But why does it fail to add my *own* extensionless headers? Because they are non-standard? Don't you see this is discriminatory behavior on part of the project explorer ;) Which makes me wonder: where is the real bug now?
(In reply to comment #13) > hmm .. yes they are being correctly shown in the project explorer. > So the project explorer has the ability to add extensionless headers after all > and treat them (with the indexer and code assist) as normal headers that can > play well with the rest of the code!! > But why does it fail to add my *own* extensionless headers? > Because they are non-standard? Don't you see this is discriminatory behavior on > part of the project explorer ;) > Which makes me wonder: where is the real bug now? I try for the last time: Content assist does not care about whether the header is shown in the project explorer or not. The thing that matters is that the file gets included by some source file such that it can be found by the parser via the include search path. Files without extension can be configured to have the content type 'c++-header'. To do that you need to know the names of the files in advance. CDT predefines the content type for the standard c++-headers, you can certainly add the ones that are important to you: Preferences - General - Content Types.
(In reply to comment #14) > I try for the last time: Content assist does not care about whether the header > is shown in the project explorer or not. The thing that matters is that the > file gets included by some source file such that it can be found by the parser > via the include search path. > > Files without extension can be configured to have the content type > 'c++-header'. To do that you need to know the names of the files in advance. > CDT predefines the content type for the standard c++-headers, you can certainly > add the ones that are important to you: Preferences - General - Content Types. OK then I believe you .. but there is a caveat.. when typing #include < (and you open a < .. and you click Ctrl+Space for assist to give you autocomplete) the following are given as options kurl.h and qstring.h .. but no KUrl and no QString why is that? I assume because they are not recognized as headers in the project and are not included in the includes dir. Following the declaration will open it in a CDT-editor as you said, and it will build successfully now .. but still they won't list in this particular scenario. It seems in this particular case, the code completion looks for files included in the project includes and does not look at headers "referenced by source files in the project" as you claim. This might be the only bug in the whole issue after all!! > Files without extension can be configured to have the content type > 'c++-header'. To do that you need to know the names of the files in advance. > CDT predefines the content type for the standard c++-headers, you can certainly > add the ones that are important to you: Preferences - General - Content Types. > Ok then .. it seems that this is the only workaround to do this.. however it won't be applicable if I am to work on a major project like KDE which may contain tens or hundreds of headers which I have to enter manually on an individual basis in the Content Types Preferences. It will be absurd. :( Note: Admins may close this bug for now if they see the above caveat is trivial enough for a bug fix.
> when typing #include < (and you open a < .. and you click Ctrl+Space for assist > to give you autocomplete) > the following are given as options kurl.h and qstring.h .. but no KUrl and no > QString > why is that? I assume because they are not recognized as headers in the project > and are not included in the includes dir. > ... Yes, we are on the same page now. I see two issues for extension-less non-standard includes: * project explorer does not show such headers below the include-directory * content assist for include-directives does not propose such headers. --> changing summary
Umpteen years later, working on Qt support which has extension-less headers in droves. Need to address this. Moving to cdt-qt component so I don't lose it.
