Exclude component header from project.h

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
PaSw_2578827
Level 4
Level 4
25 replies posted 10 replies posted 10 questions asked

I have a header file in my component that defines some functions, this header only needs to be included in one file withing my component but it's automatically getting pulled into the project.h file and therefore included in everything. It's mostly generating a bunch of warnings but also probably needlessly bloating the actual code size with static function that aren't needed. Is there a way to explicitly exclude it from the project.h file?

0 Likes
1 Solution

Absolutely, that's just the standard header guards that I put in every header file. Their scope is only within the same C file though, you will still end up with a definition in every single object file, the compiler doesn't care about that but if there is a function defined in the header (not inline) then the linker will complain about multiple definitions. I was able to resolve it using a similar technique though:

Within the C file that called it:

#define USE_FILE

#include "header_file.h"

#undef USE_FILE

Then within my "header_file.h"

#ifdef USE_FILE

<header_file>
#endif

Since no other C file has USE_FILE defined the contents of the header don't get compiled. It still would be nice to be able to explicitly mark a header file as being excluded from project.h though.

Thanks for your reply once again!

View solution in original post

0 Likes
8 Replies
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

PaSw,

I'm probably not understanding your issue completely.  However, I'll give it a try.

Are you using the following conditional compile statements in your header file?

#if !defined(HEADER_H)     // Check to see if this has already been defined. If not, execute the statements below.

#define HEADER_H          // Define it.  Therefore further times this header is referenced will not reload.

... header file stuff

#endif  // HEADER_H          // Complete the #if statement.

HEADER_H should be substituted with the name of your header file.

This is used to exclude this header file during the precompile phase once it is brought in the first time.

Hopefully I'm not too far off the mark.

Len

Len
"Engineering is an Art. The Art of Compromise."

Absolutely, that's just the standard header guards that I put in every header file. Their scope is only within the same C file though, you will still end up with a definition in every single object file, the compiler doesn't care about that but if there is a function defined in the header (not inline) then the linker will complain about multiple definitions. I was able to resolve it using a similar technique though:

Within the C file that called it:

#define USE_FILE

#include "header_file.h"

#undef USE_FILE

Then within my "header_file.h"

#ifdef USE_FILE

<header_file>
#endif

Since no other C file has USE_FILE defined the contents of the header don't get compiled. It still would be nice to be able to explicitly mark a header file as being excluded from project.h though.

Thanks for your reply once again!

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

As you are already using USE_FILE trick it will be fine,

but if I remember correct, the global "static" was file scope.

So I think that defining a static variable in a header is not a good idea.

Since you can use #define USE_FILE before #include "header_file.h"

can't you just define the static variable inside that c source file and avoid

defining it in a header?

moto

0 Likes

Since you can use #define USE_FILE before #include "header_file.h"

can't you just define the static variable inside that c source file and avoid

defining it in a header?

I certainly could, but the header file is essentially a small library of code from somewhere else so I'd rather not change it in anyway. It just makes it easier to keep track of where it came from and easier to replace should there ever be a future update.

MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Hi,

I'm afraid that this may not be any help for you,

but I'd like to learn the situation you are facing...

Let's assume that you have a component_x which you created, right?

Then component_x.c includes component_x.h,

therefore component_x.h is always included in the project.h.

And in the component_x.h you have those "used once" functions?

As I'm not familiar with making a component in PSoC Creator, I may(must) be wrong,

but in such case can't we have 2 headers for the component_x.c such as

component_x.h and component_x_private.h

and let only the component_x.c include component_x_private.h

so that project.h include non private definition only?

moto

0 Likes

That is the exact question I'm asking, is there a way to make a headerfile private such that it won't be included in project.h?

project.h is an automatically generated header file that PSoC Creator makes by grabbing every header file in every component. To date I have not been able to find a way to tell it to ignore a specific header file.

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Dear PaSw-san,

Thank you!

Now I really understand the problem.

And I was thinking that it could be done, but it seems to be difficult now.

I skimmed the "Component Author Guide" but could not find a description

about a switch/parameter to disable/enable a header from being included.

So right now, the only method I can think of is the same one you mentioned,

having some defined value before the #include "project.h"

and let the header take care of the condition.

Sorry for taking your time.

But at least I could learn.

Best Regards,

26-Mar-2020

Motoo Tanaka

0 Likes
MotooTanaka
Level 9
Level 9
Distributor - Marubun (Japan)
First comment on blog Beta tester First comment on KBA

Dear PaSw-san,

After resigning in my previous response, I've been thinking about this whole night.

If the following statement meant that you don't want to separate the header

we could just place the entire content of the header in the beginning of the c source.

==============

I certainly could, but the header file is essentially a small library of code from somewhere else so I'd rather not change it in anyway. It just makes it easier to keep track of where it came from and easier to replace should there ever be a future update.

==========

The following have been my thoughts...

At first I thought that there are two kind of parts in the component_x.h,

they are header_public_part and header_private_part.

So it should look like

<<< case 1 >>>

component_x.h

=========

#ifndef _COMPONENT_X_H_

#define _COMPONENT_X_H_

     header_public_part

     #ifdef USE_FILE

          header_private_part

     #endif /* USE_FILE */

#endif /* _COMPONENT_X_H_ */

=========

component_x.c

==========

#include "project.h"

#include "component_x.h"

component_x_body_part

==========

So I suggested to move static part into the component_x.c

<<< case 2 >>>

component_x.h

=========

#ifndef _COMPONENT_X_H_

#define _COMPONENT_X_H_

     header_public_part

#endif /* _COMPONENT_X_H_ */

=========

component_x.c

==========

#include "project.h"

header_private_part

component_x_body_part

==========

There you did not like having header_public_part and header_private_part

in the different places, as it makes keeping track of the library difficult.

Then how about placing whole header except the guarding macros?

So that the original library stays as a whole.

<<< case 3 >>>

component_x.h

=========

#ifndef _COMPONENT_X_H_

#define _COMPONENT_X_H_

     // nothing remains here, but the empty "component_x.h"

#endif /* _COMPONENT_X_H_ */

=========

component_x.c

==========

#include "project.h"

header_public_part

header_private_part

component_x_body_part

==========

With doing case 3, the maintenance of library should not be different.

Only the difference is where the library chunk is placed.

And there is no need of using USE_FILE trick anymore.

Best Regards,

27-Mar-2020 (4:58 JST)

Motoo Tanaka

0 Likes