• State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 22 subscribers
  • Views 1613 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

#include in C51 retrieves wrong header file

Gary Lynch

I am designing a project using the Keil C51 V7.50 and
uVision 3 IDE V3.10a on a Silicon Labs C8051F046 MCU. My
project contains source file foo.c, which contains a
directive:

    #include "foo.h"

where foo.h contains standard header info and is located in
the same directory as foo.c.

When I run C51 from the command line, this module compiles
as I expect, but when I compile within uVision 3, it goes
out and finds another foo.h, located in another directory on
the same drive, which is not set up for this project, and
the compile fails.

I can find nothing in the documentation to explain this. I
have checked all the tabs in the "options" dialog box. When
I copy my correct foo.h into the alien directory, uVision 3
will compile it correctly, but I am not content to function
this way.

Any clues why this is happening?
============================================================
Gary Lynch            |     To send mail, change no$pam in
lynchg@no$pam.com     |     my domain name to stacoenergy

Parents
  • 0 in reply to Gary Lynch

    Seriously, you mean?

    Of course I'll sometimes reuse a file name. (Directories exist to allow hierarchical, compound file names.)

    In particular, I have a file with my favorite conventions for typedefs and such U8, U16, TRUE, etc), which has to be adapted to any particular compiler and processor. But this file always has the same name in different projects.

    In a situation as described, I'd normally strive for a single .h which defines the interface for controlling a DAC, and then different .c's in different projects that implement the common interface according to the specific hardware.

    I usually name the .c's according to the device they control. For example, I might have "Flash.h" for a flash driver, and "FlashAmd.c" and "FlashIntel.c" for the AMD-style command interfaces and the Intel-style command set. One target would link with one .c, and another with the other.

    If a particular project can only be built with one option, then I might wind up with the project name distinguishing the files; something like "Dac.h" with "EVB900A\Dac.c" and "EVB750\Dac.c". (This is where you start to have to be careful when copying files around, or setting up project directories, as you originally pointed out.)

    If the implementation stays out of the interface -- that is, no macros -- then you can usually have a common .h. The version control system usually has a way to make sure the same file shows up in different project trees.

    If you are using macros for some of your "functions", then you've got a multiple version or conditional compilation problem, and might wind up with multiple .h files to avoid the latter. One alternative is to factor out the macros into another file, and #include that file into the common.h. These would essentially be "implementation" .h's, rather than "interface" .h's as is usually the case, so they belong with the .c's. For inline functions (macros, in C), I absorbed the convention of naming the implementation files to be included .i instead of .h.

Reply
  • 0 in reply to Gary Lynch

    Seriously, you mean?

    Of course I'll sometimes reuse a file name. (Directories exist to allow hierarchical, compound file names.)

    In particular, I have a file with my favorite conventions for typedefs and such U8, U16, TRUE, etc), which has to be adapted to any particular compiler and processor. But this file always has the same name in different projects.

    In a situation as described, I'd normally strive for a single .h which defines the interface for controlling a DAC, and then different .c's in different projects that implement the common interface according to the specific hardware.

    I usually name the .c's according to the device they control. For example, I might have "Flash.h" for a flash driver, and "FlashAmd.c" and "FlashIntel.c" for the AMD-style command interfaces and the Intel-style command set. One target would link with one .c, and another with the other.

    If a particular project can only be built with one option, then I might wind up with the project name distinguishing the files; something like "Dac.h" with "EVB900A\Dac.c" and "EVB750\Dac.c". (This is where you start to have to be careful when copying files around, or setting up project directories, as you originally pointed out.)

    If the implementation stays out of the interface -- that is, no macros -- then you can usually have a common .h. The version control system usually has a way to make sure the same file shows up in different project trees.

    If you are using macros for some of your "functions", then you've got a multiple version or conditional compilation problem, and might wind up with multiple .h files to avoid the latter. One alternative is to factor out the macros into another file, and #include that file into the common.h. These would essentially be "implementation" .h's, rather than "interface" .h's as is usually the case, so they belong with the .c's. For inline functions (macros, in C), I absorbed the convention of naming the implementation files to be included .i instead of .h.

Children
No data