#include in C51 retrieves wrong header file

You raise an interesting point. The code in question
includes drivers for a DAC circuit and an A/D circuit. The
project has 5 boards with micros, all of which have at least
one of these circuits.

In my shoes, would you write this code 5 times, or would you
try to re-use as much as would port? Would you keep 5
identical copies of a file and give each one a different
name? When it comes time for a modification to a released
unit, how would you know you've made the change to all the
right files?

============================================================
Gary Lynch            |     To send mail, change no$pam in
lynchg@no$pam.com     |     my domain name to stacoenergy

You raise an interesting point. The code in question
includes drivers for a DAC circuit and an A/D circuit. The
project has 5 boards with micros, all of which have at least
one of these circuits.

In my shoes, would you write this code 5 times, or would you
try to re-use as much as would port? Would you keep 5
identical copies of a file and give each one a different
name? When it comes time for a modification to a released
unit, how would you know you've made the change to all the
right files?

============================================================
Gary Lynch            |     To send mail, change no$pam in
lynchg@no$pam.com     |     my domain name to stacoenergy

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.

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.

Gary;
The uV3 IDE is constructed for target systems just as you described.
In a single project, you define targets for Board1..thru..Board5. All source files exist for all targets. However, you can then set options at the target, group or file level to include/exclude files for each target.
You still have one set of source code in one place simplifying bookkeeping.
Of course you can fine tune single files with the normal #ifdef directives.
Of course, if you are like Erik, you can make it more complex with batch files and make files.
Bradford

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.

I NEVER reuse a name. All project specific files start with 2 capital letters that identify the project. Files used across projects reside in a separate directory and do not have the preface to the filename.

Erik

.. continuation ...

There is NOTHING more dangerous than having identical files in several places. You update and miss one of them and then, a year later, you spend days debugging because you "knew" that the missed file was updated.

Erik