//These 2 lines are in "usb_hal_pic16f1.h", and are not being seen now...
//#define BDT_BASE_ADDR 0x2000
//#define BDT_BASE_ADDR_TAG @ BDT_BASE_ADDR
volatile BDT_ENTRY BDT[BDT_NUM_ENTRIES] BDT_BASE_ADDR_TAG;Somewhere, a header file #ifndef is preventing the file being included, because elsewhere the header file has already been included. From experience this can take days to track down.That doesn't make sense to me. Properly implemented include guards should prevent each header file from getting included more than once per compilation unit (in this case usb_device.c). Therefore, if a header was included already, then its contents should be visible by the compilation unit.
Note: There is an ideal rule that states a header file should not itself include other headers.This is not true. There is nothing wrong with including other headers inside headers, as long as each and every header file has an include guard properly implemented.
I don’t know where the “header should not include another headers” rule comes from, but this is bullshit.Because usually little thought is put into the structure of header files, and you end up with the situation where the whole project will be rebuilt any time a header is modified.
Because usually little thought is put into the structure of header files, and you end up with the situation where the whole project will be rebuilt any time a header is modified.I see it as a natural consequence of what C and C++ preprocessors are. Remember that the “header files” are abstractions of human brain. For the compiler and build tools they are effectively a part of the final source files that are built. Those tools do not know that some definition from a header is not really used in that particular source file. It may be remedied, but it’s usually too much work for anyone to bother. Still, even with those workarounds, the headers still should include everything that is needed by them.
I see it as a natural consequence of what C and C++ preprocessors are. Remember that the “header files” are abstractions of human brain. For the compiler and build tools they are effectively a part of the final source files that are built. Those tools do not know that some definition from a header is not really used in that particular source file. It may be remedied, but it’s usually too much work for anyone to bother. Still, even with those workarounds, the headers still should include everything that is needed by them.Most issues can be avoided by simple refactoring, eg. moving type declarations into separate files, and not including function declaration headers into other headers. Another typical error is getting the declarations you really want via long include chains, instead of only including the file you actually need.