Hi Guys,
Having taken the luxury of an uninterupted day to think about it I think Nick and Enrico combined have defined the problem: I've combined responses to both below.
Nick: C++ headers are not a separate language from C++ source files, they are the same language. Same for C headers. There could be special files for some languages that require different build commands, but if they are the same language they should not have a separate filetype. This is a build command issue, not a filetype one.
Enrico: As Nick already said, this is a build command issue. With the current code, one solution could be to remove the limitation that headers files can't be compiled. Anyway, there should be really no need for separate header filetypes. And since you are currently about to rework the build system, just make the custom filetype build commands work with header files.
To summarise the problem in very few words, we have files that contain the same language but require different actions. The table below defines it for C/C++ (hope it comes through the email neatly)
Semantics Language Extension Actions
C header C .h compile no .o file
C source C .c compile, link, run
C++ header C++ .h & mark compile no .o file .hpp .hxx etc
C++ source C++ .cpp .cxx compile, link, run etc
In the current implementation Geany does not have any way of distinguishing the language in the file (used for highlighting and symbols) from the semantics (used for the actions/commands allowed on the file).
From the discussions to date the solutions seem to be:
1. My solution was to define new filetypes (which use the same language internally) so I got separate actions. I think its fair to say that your response is that this is way overkill for the purpose ;-) although I didn't think the actual implementation was that significant since it uses C and C++ language stuff for Scintilla and tagmanager.
2. Use the same commands for source and header. Since the compile commands are different between source and header, that means we have two compile commands at the same time which is a potential source of confusion & I think generally yucky.
3. Use custom commands, but we still have the two commands problem from the item above and this is something that Geany really should offer its users as standard, not requiring them to configure it.
4. Use project/user preference commands. Now unwanted commands are visible on all languages which is worse, and we have the same problem that it should be standard.
The other solution I have thought of so far is to actually implement separation of semantics and language, I havn't got an actual implementation but it probably isn't too difficult to have another field in GeanyFiletype to select from several sets of commands. With default behaviour it should be possible to keep filetypes.xxx backward compatible but they will expand (and do for build system anyway). This GeanyFiletype field would be set using the code in implementation 1. above. Using the correct commands would be part of the build system extension. This does remove some mucky hardcoding in switch statements in implementation 1. that makes headers behave the same as source for scintilla and tagmanager but I don't know what else it may add. I don't know if this should be visible to plug-ins, it could give them a way of manipulating commands and, although I can't immediately think of why, my instinct is to make it available, but that changes the API I think. Your call.
Any other suggestions welcome.
I have combined responses below to Nick and Enricos points not covered so far.
2008/11/11 Nick Treleaven nick.treleaven@btinternet.com
On Tue, 11 Nov 2008 14:26:39 +1100 "Lex Trotman" elextr@gmail.com wrote:
Having separate C++ header templates with the mark already in it would help users to remember to add it. BTW it would be good to have
I don't think we should encourage people to make C++ header files with a .h extension, they should use an extension unique to C++.
I entirely agree!! Unfortunately a couple of old compilers don't and there is lots of code out there using .h files. I blame Stroustrup, who only uses .h for headers throughout his book, even though he acknowledges .cpp .cxx etc.
BTW with custom file templates you can have as many templates as you like for the same filetype, so you could have header.hpp, source.cpp, etc template files.
Can those templates be delivered with Geany? For something fairly fundamental it shouldn't require every user to configure it.
In terms of using make object, the .h doesn't compile to a .o file so thats no good, and I have to admit I don't quite see how make could
I meant when you have a foo.h file and a foo.c file, you can use Make Object on the foo.h file.
I still don't understand how this compiles the .h only, sorry for being obtuse.
This would cause more code to maintain, and more checks for header filetypes as well as the source file filetypes.
Surprisingly little code, Geany is pretty well structured but there are some hacks needed where filetype checks are hard coded.
Regards, Nick
Hey,
The point of all this is that providing support for the C++ .h files is important, so correctly detecting them is important. So is compiling .h files independently, it is annoying having to pick through errors in the .cpp file (often caused by errors in the .h file) to find the .h errors and fix them first, usually it gets so
As Nick already said, this is a build command issue. With the current code, one solution could be to remove the limitation that headers files can't be compiled.
I assumed that this has to happen anyway.
I don't remember exactly why I added this but mainly because until this thread I was thinking compiling header files doesn't make any sense at all. Maybe there were other reasons, too. Anyway, there should be really no need for separate header filetypes. And since you are currently about to rework the build system, just make the custom filetype build commands work with header files.
As outlined above I need to know its a header file, thats the problem.
The marking -*-C++-*- exists on all GNU headers which means it should be present on most Linuxii, I don't know about windows though. Looking at other (non-system) library headers I've got available, most of the C++ .h files identify themselves and interestingly about 15% of the C .h files identify themselves as C. In terms of the delays in opening the file, it is only intended to look at line 1 which has already been examined for shebang so it is already available in memory, most of the overhead has already occurred. Having separate C+
Yup, this is why I said the check should work on the first line or the first both lines. Then it doesn't cause much more overhead than already existent.
We are in furious agreement here ;-)
- header templates with the mark already in it would help users to
remember to add it. BTW it would be good to have these separate .h .hpp templates irrespective of the end result of these discussions because creating headers using C or C++ templates and filenames means you need to delete the main you don't want, add the guards etc.and then change the file extension on save too.
Check the classbuilder plugin. It's not exactly the same but it creates C++ class files and the corresponding headers, including guards and all this stuff. Unfortunately, the used templates in the plugin are not (yet) configurable but this is an easy task, it just needs to be done. Alternatively, Nick already stated about custom file templates.
Sort of the thing but I was only suggesting a really simple minimal header template for both C and C++. Also now we have two places to create files from, the file new or toolbar or the tools->plugin menus. I don't see any documentation for classbuilder plugin either so I hadn't realised it might be useful.
- Show quoted text -
Regards, Enrico
Finally whilst testing I found what I think is a bug in C/C++ symbols in tagmanager, since it occurs on 0.15 will submit a normal bug report for it.
Cheers Lex