[Geany-devel] C/C++ Header filetypes (Re: Committed Project Build Commands to build-system branch)
elextr at xxxxx
Wed Nov 12 03:23:47 UTC 2008
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.
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.
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
C++ source C++ .cpp .cxx compile, link, run
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
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
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
2008/11/11 Nick Treleaven <nick.treleaven at btinternet.com>
> On Tue, 11 Nov 2008 14:26:39 +1100
> "Lex Trotman" <elextr at 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
> 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
> 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.
> >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
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
> - Show quoted text -
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel