Re: cf_parser.c->cf_parser.h

On 20 Aug 2001 09:02:54 +0200, Henrik Nordstrom wrote:
> cf_parser is one of the odd things
>
> a) It is not a standalone C file
>
> b) It is not a C header file as it includes code, and not only definitions.
>
> Having it named .c is as appropriate as having it named .h. Neither are
> entirely correct or wrong.

Sure.
 
> In most other cases where I have seen similar constructs, the included code
> is named .c to not confuse it with a header file.

Looking down the track - at the automake branch - this needs to be a .h
file. Why? Because automake starts with the sources, and builds up, as
opposed to handcrafted Makefiles which start with the program and the
object files and infer the sources. Thus automake will attempt to
compile cf_parser.o. It's possible to work around this several ways. One
- rename to .h, two, make cf_parser.o compilable as a standalone file
and generate a separate header file with the functions to be exported,
three make cf_parser.o compilable, but ensure that all the functions are
declared static. Renaming seems easiest to me.

I'm not proposing we merge in the automake branch now :} - but the
source changes that I did there were (I agree this one is borderline -
but as I said, renaming is a lot easier) sensible regardless of the
presence of automake.

I'm quite content to work up a different workaround into the automake
branch if one of the other approachs would be more readily considered
for HEAD, or just let this lie until automake 1.5 is released and I can
lobby for the entire automake branch to be merged. (Thats probably post
2.5 realistically).

However thats not my preference: I'd like to be able to have the
automake branch with no code changes in it at all other than the VERSION
macro. That would allow the patch from there to be dropped in to my
working dir for other squid branches. And obviously for anyone else who
wants to use it :].

Rob

> --
> Henrik
Received on Mon Aug 20 2001 - 01:56:47 MDT