• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 21 subscribers
  • Views 2949 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.?

  • 0

    "So I have a shortcut with the name header.h that can point to header1.h, header2.h"

    Sounds like a maintenance nightmare!
    What happens if you point the shortcut at the wrong header?

    It's generally far better to keep this stuff within the project, where it's all controlled by the tools.

    Look at uVision's facilities for different project Targets.
    Use a #defined symbol, or a symbol defined by the project, to select the appropriate headers using #if, etc...

    If uVision's facilities are too simplistic for you (which is quite possilbe) look a some version of make, or build you own batch files...

  • 0 in reply to Andy Neil

    "Use a #defined symbol, or a symbol defined by the project, to select the appropriate headers using #if, etc..."

    And taking that one small bit further, if using #if's in each source file to select the appropriate header files is undesireable, don't forget that the #include itself can specify preprocessing tokens, thus allowing all the #if'ing to be localized.

  • 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.

  • 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...

  • 0

    Thanks for your helpful comments. Yes, I was thinking of shortcuts as being the same as UNIX aliases. I don't use Windows much.