[gcc r13-3169] Specialize paths to version.h in _vxworks-versions.h

[gcc r13-3169] Specialize paths to version.h in _vxworks-versions.h

[Olivier Hainque]

https://gcc.gnu.org/g:21e51a55e9714d14a6df0e8e83ae005eb19f0f02

commit r13-3169-g21e51a55e9714d14a6df0e8e83ae005eb19f0f02
Author: Olivier Hainque <hainque@adacore.com>
Date:   Fri Oct 7 10:12:26 2022 +0000

    Specialize paths to version.h in _vxworks-versions.h
    
    The _vxworks-versions.h runtime file helps us control
    the compilation of some library components depending on
    the OS version extracted out of a system header.
    
    The system header name is "version.h", and gcc has a
    "version.h" file of its own.
    
    gcc's version.h is now generated and the current
    instance instead of the OS one, resulting in build failures
    from
    
      #if !defined(_WRS_VXWORKS_MAJOR)
      #error "_WRS_VXWORKS_MAJOR undefined"
      #endif
    
    This change introduces a twist in the way
    _vxworks-versions.h #includes version.h, using a relative
    path with components that will match in the OS include
    dirs only.
    
    The actual relative path is conditioned on _VSB_CONFIG_FILE
    to accommodate a change in the include dirs organisation between
    VxWorks 6 and 7.
    
    2022-10-07  Olivier Hainque  <hainque@adacore.com>
    
    gcc/
            * config/vxworks/_vxworks-versions.h: Use OS specific
            paths in #include of version.h.

Diff:
---
 gcc/config/vxworks/_vxworks-versions.h | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/gcc/config/vxworks/_vxworks-versions.h b/gcc/config/vxworks/_vxworks-versions.h
index 15e8bfeb4a6..994dda90643 100644
--- a/gcc/config/vxworks/_vxworks-versions.h
+++ b/gcc/config/vxworks/_vxworks-versions.h
@@ -23,15 +23,24 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #define _VXWORKS_VERSIONS_H  1
 
 /* All we need is access to the bare _WRS_VXWORKS_MAJOR/MINOR macros,
-   exposed by version.h or already provided somehow (e.g. with a self
-   spec for some reason).  When resorting to system headers, cheat a
-   bit to make sure we don't drag additional header files, which can
-   easily cause #include ordering nightmares.  */
+   exposed by version.h or already provided somehow (e.g. with a self spec
+   for some reason).  When resorting to system headers, use typical os
+   paths to prevent possible confusion with a gcc version of version.h
+   visible during the build and temporarily #undef _WRS_KERNEL to prevent
+   indirect inclusion of internal header files, which can easily cause
+   #include ordering nightmares.  */
 
 #if !defined(_WRS_VXWORKS_MAJOR)
+
+#if defined(_VSB_CONFIG_FILE)
+#define _VXWORKS_VERSION_H <../public/version.h>
+#else
+#define _VXWORKS_VERSION_H <../h/version.h>
+#endif
+
 #pragma push_macro("_WRS_KERNEL")
 #undef _WRS_KERNEL
-#include <version.h>
+#include _VXWORKS_VERSION_H
 #pragma pop_macro("_WRS_KERNEL")
 #endif