Is there a program to generate header files for C source files? I'm really fucking sick of writing header files. I'd like to just write .c files and have the .h files generated automatically when I type make from whatever source files I changed. These would be generated simply by copying struct definitions and function prototypes into the header (and disabling duplicate definitions by wrapping them in a disabled preproc).
This seems like it could be fairly simple. I'm building a library, so functions (and structs) that need to be in header files are generally annotated with visibility information (e.g. LIB_EXPORT). I could add another annotation (e.g. LIB_INTERNAL) which has hidden visibility but still goes into the header file. Or I could just copy all prototypes into the header file (nothing private, but no need to tag anything).
The top of the .c file could have includes separated in two sections, like this:
Includes under the GENERATING_HEADER block would copied to the top of the header file, and this preproc would always be false during compilation. This would force you to declare your include ordering properly.
The generator could also copy doxygen-style documentation comments into the header files. This would make the include files sufficient documentation of function parameters without requiring the original source.
I don't think this would negatively impact compile time much if at all. Only when public functions are added to .c files would the appropriate header change, just as if I were updating them manually. I'm unconcerned with other header file considerations such as function inlining, although an inline function could easily be included in a disabled preproc that copies it to the header; this means inlines could be easily toggled on and off without moving code around, allowing you to easily test various choices on function inlining. I also don't give two shits about sepples compatibility (although it seems to me that template definitions could benefit greatly from this).
I'm pretty sure I could pull this off in a few hundred lines of Python. I've written similar tools before, and I haven't found anything online that does this. What does /prog/ think? Will this work, or am I wasting valuable time that could be spent writing header files?
Name:
Anonymous2009-12-04 2:11
>>1
Just to elaborate a little, or to try to prove that it could work, here's an end to end example. In this case HEADER is the magic preproc that the generator understands, and it is always undefined during compilation (thus disabling those code blocks in the .c file, leaving them only in the header). The parser copies out any function prototypes it sees, and anything in HEADER blocks, to the equivalent header file. Here is bar.c:
#if HEADER
// includes that are required in the header file
#include <stdio>
#include "foo.h"
#else
// own header
#include "bar.h"
// includes that are only needed in the source file
#include "something.h"
#endif
#if HEADER
/**
* A bar
*/
typedef struct bar_s {
int a, b;
} bar_t;
#endif
/**
* Some function that is private to this source file
*/
int privatefunc() {
return 9000;
}
/**
* Foos a bar
*/
LIB_API void foo(bar_t* x) {
// some stuff
}
And here is the resulting bar.h:
#ifndef BAR_H
#define BAR_H
#include <stdio>
#include "foo.h"
typedef struct bar_s {
int a, b;
} bar_t;
LIB_API void foo(bar_t* x);
#endif
Note that the .c file is never modified in this process; the duplicate code blocks are disabled by virtue of the preproc HEADER not being defined.
Is this a good idea? [y/n]
Name:
Anonymous2009-12-04 2:11
Aw shit, I forgot to copy the documentation strings. Ah well, you get the idea.
Looks pretty enterprise, but the whole idea sounds like more trouble than it's worth. Or maybe it's that keeping hands-on track of header files seems worth the trouble.
Name:
Anonymous2009-12-04 3:03
Wow, that was easy. 99 lines of python. Simple stack for #if/#endif and braces. Properly extracts HEADER blocks and only LIB_API functions and their comments, etc. I'm pretty happy.
Obviously the parser isn't very intelligent; it only handles top-level #if HEADER blocks, and will get confused if you do bullshit like unbalanced braces in preprocs. Still, it's definitely sufficient for my purposes. I think I'm gonna rip out all the header files in my project now.
Also, I took a look at LZZ, which seems to be trying to achieve the same thing but in a terribly convoluted way. It actually rewrites your source files into separate source, header, template, etc files, and it does so by implementing a full C++ parser. That seems way overkill for what I actually want; I am especially not cool with it magically divining what functions go where, especially when it starts rewriting your class definition to pull out non-inlines and stuff... Definitely not what I want.
Name:
Anonymous2009-12-04 3:06
>>4
Yeah I had checked that one also. Again it seems to want to do too much. Maybe I'm underestimating my requirements, but it seems to do things like generate docstrings and such. Honestly it took me lest time to write my own tool than read the documentation on that one, so it's not like it's a difficult problem to solve.
>>8
Oh wow, how did I miss that thread. I have to say, FV and I think very similarly when it comes to trolling. Maybe one day I can work my way up to his standard and reach SATORI!
Name:
Anonymous2009-12-04 4:13
You could probably do it pretty easily (and handle weird cases) with parsing expression grammars. There's a pareg module for python here http://bitbucket.org/pmoore/ppeg/src/ ; Roberto Ierusalimschy, who implemented the Lua version that the Python version is derived from, gives a pretty interesting explanation of them here: http://vimeo.com/1485123 . In short, they're kind of like recursive regexes, which makes them pretty damn powerful.
Name:
Anonymous2009-12-04 4:33
try this
main.c
#define INCLUDING
#include "foo.c"
#undef INCLUDING
int main() {
foo_init();
return 0;
}
then foo.c which is it's own header.
/*
* foo module
*/
#include <stdio.h>
int foo_init(void)
#ifdef INCLUDING
;
#else
{
printf("foo_init()\n");
}
#endif
possibly this could be wrapped in some kind of macro for even more elegance.
>>11
This is an interesting solution, but your function declarations are all horribly broken up by the preprocessor calls. That's unacceptable. The goal is to minimize the extra work that needs to be done and maximize code readability; if you have to do so much ifdef-ing and put up with the resulting readability issues then you may as well just write the header file.
Since I'm writing fairly object-oriented C, only two #if HEADER blocks are needed: the required includes and the struct (or a forward declaration of it if it should be hidden). These are needed just so the generator doesn't need to rewrite the .c file (unlike lzz). Everything else looks nice (the LIB_API tags aren't actually required; you can switch between LIB_API, LIB_API + LIB_INTERNAL, or just grabbing all prototypes).
Name:
Anonymous2009-12-04 10:00
OP, just save everyone the heartache and become use literate progamming tools.
The op needs to stop being a nigger and write header files. People are just going to have to rewrite his stupid shit so it uses the SANE convention of headers or fire him for incompetence.
(1) Write clean, documented header files.
(2) Write shitty implementing code with no comments and every variable named as if it were some register.
Now you are enlightened.
Name:
Anonymous2009-12-04 13:13
>>20
Imagine if Intel had had actually used full names for their registers and mnemonics, then. move accumulator 0 sounds oddly tantalizing, but hard to speed-read.
Name:
Anonymous2009-12-04 14:02
>>21
The only thing it would be good for is transitioning BASIC programmers to Asm.
>>23
Think about it. This thread and that thread are the same thread.
Unless that thread was about BBCode. Then they would differ mildly.
Name:
Anonymous2009-12-04 21:02
>>17 People are just going to have to rewrite his stupid shit so it uses the SANE convention of headers or fire him for incompetence.
This is for a standalone project. The header files would obviously be pre-generated when made available as a source download or part of a -dev package. For all intents and purposes, it WOULD be using the convention of header files; it's an internal tool that would only be used when actually developing the library. I don't see why I can't use such a tool the make my life easier.
Besides, at any point I can just stop using the tool, and take over updating the header files manually. If I want to clean them permanently I can just run sunifdef -R -UHEADER src, and the code is instantly turned into normal C style. So what's the harm in using this tool?
>>21
Abbreviations were acceptable for Intel because they have (had?) an extremely small number of registers and instructions, and they are written many more times than they are used, so it makes sense to abbreviate them. Once you learn them, you are never confused about what an abbreviation refers to.