- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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