• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 21 subscribers
  • Views 2951 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

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

using shortcuts to name header files

Paul Linsay

I tried to use a shortcut(alias) to point to a C header file but uVision2 couldn't resolve the shortcut when opening the project. So I have a shortcut with the name header.h that can point to header1.h, header2.h, and so on, but Uv2 can't figure out where header.h is pointing. Is there a solution to this beyond the obvious of multiple #includes, etc.?

Parents
  • 0

    but Uv2 can't figure out where header.h is pointing

    Of course it can't! Your plan is based on the incorrect assumption that desktop shortcuts actually work like symbolic links would, in Unix. Well, they don't.

    Shortcuts are just a special type of file recognized by Explorer. They're not implemented at file-sytem level, so tools other than Explorer can't generally make heads or tails of them.

    Is there a solution to this beyond the obvious of multiple #includes, etc.?

    I don't think there is. And I don't think that's a bad state of things, either. Organized #includes are exactly what you should do to tackle this. The source code is exactly where such things should be kept.

Reply
  • 0

    but Uv2 can't figure out where header.h is pointing

    Of course it can't! Your plan is based on the incorrect assumption that desktop shortcuts actually work like symbolic links would, in Unix. Well, they don't.

    Shortcuts are just a special type of file recognized by Explorer. They're not implemented at file-sytem level, so tools other than Explorer can't generally make heads or tails of them.

    Is there a solution to this beyond the obvious of multiple #includes, etc.?

    I don't think there is. And I don't think that's a bad state of things, either. Organized #includes are exactly what you should do to tackle this. The source code is exactly where such things should be kept.

Children
  • 0 in reply to HansBernhard Broeker

    "The source code is exactly where such things should be kept."

    I think that the Project can be a perfectly acceptable alternative, provided it is subject to the same control procedures as the source code.

    Unfortunately, many tools (including, IMO, uVision) do not make it easy to maintain and document such stuff.
    uVision is better than some - at least the Project files are plain ASCII text.

  • 0 in reply to Andy Neil 

    #if defined HEADER_TO_USE

#if HEADER_TO_USE == 2
#include "header_2.h"
#elif HEADER_TO_USE == 3
#include "header_3.h"
#else
#error "Invalid value for HEADER_TO_USE
#endif

#else
#error "HEADER_TO_USE is not defined"
#endif

    You Could define HEADER_TO_USE in a "configuration" header file, included before all others, on the command line, or via the Project options (eg, using different Targets).

    Note the use of #else clauses to catch missing or invalid definitions;

    Note also that it's best to avoid values 0 and 1 - as these are often used as defaults when a symbol is defined (especially on the command line) without assigning a specific value...