About different versions of the same header files

[parag_paul]

HI all,
Suppose I have a huge code base, And I have a very common header file.
Now there are mulitple places where this header file is kept.

This header file cannot be factored as it has different function
prototypes in different places.
Now can there be a safeguard at compile time to maintain the #defines
in the different headers files to be same .

ie suppose I add a new type in one of the header files and then want
that compile fails in the other directories which has the header file
with the same name, unless all the #defines are same in all.

 

[Ian Collins]

HI all,
Suppose I have a huge code base, And I have a very common header file.
Now there are mulitple places where this header file is kept.

Why? Just keep one copy.

The rest is more of a source code management problem than a C one. If
you have to support multiple versions, use a decent SCM tool.

 

[parag_paul]

We are using perforce.
I thought of making all of them as links.
But Whatever damage has been done cannot be taken back that easily
( will take a lot of hard work )

So , going forward, can there be checks to stop this kind of
tomfoolery
-Parag

 

[Ian Collins]

Please retain enough of the message you are replying to for you message
to make sense.

We are using perforce.
I thought of making all of them as links.
But Whatever damage has been done cannot be taken back that easily
( will take a lot of hard work )

So , going forward, can there be checks to stop this kind of
tomfoolery

As I said, don't copy the file, share one instance.

 

[keith]

HI all,
Suppose I have a huge code base, And I have a very common header file.
Now there are mulitple places where this header file is kept.

This header file cannot be factored as it has different function
prototypes in different places.
Now can there be a safeguard at compile time to maintain the #defines
in the different headers files to be same .

If it requires different contents in the header in different places,
it's not the same header, and should therefore have a different name
in each place. Put the stuff which is always common in one header in
one place, and have each specific header include that. Or use loads
of #ifdef statements, but that can become a mess very quickly.

 

[CBFalconer]

Suppose I have a huge code base, And I have a very common header
file. Now there are mulitple places where this header file is kept.

This header file cannot be factored as it has different function
prototypes in different places. Now can there be a safeguard at
compile time to maintain the #defines in the different headers
files to be same .

ie suppose I add a new type in one of the header files and then
want that compile fails in the other directories which has the
header file with the same name, unless all the #defines are same
in all.

Don't do that. The only purpose of header files is to allow use of
the C file in other compilations, i.e. to specify the interface.
You should have only one copy of such a header, and it should not
change (barring early development). If it needs to appear in
multiple locations consider using links, rather than file copies.
(U/Linux).

 

[Keith Thompson]

Don't do that. The only purpose of header files is to allow use of
the C file in other compilations, i.e. to specify the interface.

Not all headers are associated with C files; some just have macro

You should have only one copy of such a header, and it should not
change (barring early development). If it needs to appear in
multiple locations consider using links, rather than file copies.
(U/Linux).

I don't see why it would *need* to be in multiple locations. It
should be possible to have one copy in one place, and refer to it from
anywhere within the project.

But the OP's problem is that he's dealing with a huge code base that's
*already* a mess; it's a little late for "Don't do that".

If there are chunks of the header that need (for now) to be different,
and other parts that are still consistent, it probably makes sense to
split the header into two parts, one that's identical across all
copies (or, better, stored in only one place), and another that
reflects the current inconsistencies. This will require updating a
lot of '#include' directives, but it should be possible to automate
that. Over time, try to migrate declarations from the multiple
inconsistent headers into the single shared header, updating client
code as needed. This can be done incrementally, and *eventually* you
should be able to get rid of the multiple inconsistent headers.

 

[Richard]

Don't do that. The only purpose of header files is to allow use of
the C file in other compilations, i.e. to specify the interface.
You should have only one copy of such a header, and it should not
change (barring early development). If it needs to appear in
multiple locations consider using links, rather than file copies.
(U/Linux).

Completely and utterly false.

Headers are used for defines and macros too.

They also change very frequently during development as APIs change and
constants are altered or added/removed.

To mention "links" is off topic and completely platform specific and
nothing even to do with C compilers.

 

[Thad Smith]

Suppose I have a huge code base, And I have a very common header file.
Now there are mulitple places where this header file is kept.

This header file cannot be factored as it has different function
prototypes in different places.
Now can there be a safeguard at compile time to maintain the #defines
in the different headers files to be same .

I concur with the other responders that there shouldn't be multiple
copies. If you need it in different places for ease of compilation, I
suggest having your build procedure copy the master to your working
directory. That way you will always be up to date.

If you do have separate versions you can have the compiler check for
inconsistencies in macro definitions by including them all in a single
module. A diagnostic is required if a macro is redefined with a
different definition. There are logistic problems with doing that,
though (header guards, typedefs, etc.).

 

[parag_paul]

If you do have separate versions you can have the compiler check for
inconsistencies in macro definitions by including them all in a single
module. A diagnostic is required if a macro is redefined with a
different definition. There are logistic problems with doing that,
though (header guards, typedefs, etc.).

That is exactly what I am pointing towards. Diagnostic. Is there a
smart way to do so.,
Actually,
there are diff. #def in all of them, which have gone out of sync due
to non uniform code
checkins.
Now it is too late to go back from here. But is there any way, that a
header file inclusion will be
caught at compile and we will not go ahead with the build procedure.
I had seen somebody putting counts to the enums, but these are
#defines, and there is no way they can be counted
other than extra C coding to open this file and do so . Or platform
dependent greps etc,

 

[Thad Smith]

That is exactly what I am pointing towards. Diagnostic. Is there a
smart way to do so.,
Actually,
there are diff. #def in all of them, which have gone out of sync due
to non uniform code
checkins.

If you want to check for consistencies of macro definitions it would be
straight-forward to write a simple program (or script) to read all files
from a list and compare multiple definitions of any macros. Run the
utility as part of your build process.