Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Special Interest Groups
  3. C++ Gurus
  4. #ifdef...#endif statements breaking other sub projects
Forum Update on Monday, May 27th 2025

#ifdef...#endif statements breaking other sub projects

Scheduled Pinned Locked Moved Solved C++ Gurus
3 Posts 2 Posters 1.1k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • G Offline
    G Offline
    graniteDev
    wrote on last edited by graniteDev
    #1

    I have a "packages" subproject that various other projects rely on to determine which packages they have access too.

    "packages" has an "enum Packages" which has various values that control which packages are available. I do this with #ifdef _sysID_ ...#endif satements around the groups of enum values under the enum definition. The projects ID is controlled by a DEFINES += _sysID_ statement inside a systemID.pri file that "packages" checks at compile time. This way all of our main projects can use the "packages" sub-project for package control, and can each set their own system ID which is check at compile time.

    I thought I was all sorts of clever with this, as "packages" compiled just fine, and in the project I tested it with, correctly detected the system ID to compile the correct enum values. The issue I'm running into is that, while I can compile "packages" just fine, the other components in the main project that are looking for the enum values are producing errors at compile time when I try to compile the whole project.

    The errors are "such-and-such is not a member of "packages"". Now, I have the ordered flag set, so I know the "packages" sub-project is compiling first. I've even tested this manually by building it, and then manually building part of the main project that relies on it, and I still get the same errors.

    Why are the other components of the project unaware of the enum values when "projects" has already compiled and has those values available?

    VRoninV 1 Reply Last reply
    0
    • G graniteDev

      I have a "packages" subproject that various other projects rely on to determine which packages they have access too.

      "packages" has an "enum Packages" which has various values that control which packages are available. I do this with #ifdef _sysID_ ...#endif satements around the groups of enum values under the enum definition. The projects ID is controlled by a DEFINES += _sysID_ statement inside a systemID.pri file that "packages" checks at compile time. This way all of our main projects can use the "packages" sub-project for package control, and can each set their own system ID which is check at compile time.

      I thought I was all sorts of clever with this, as "packages" compiled just fine, and in the project I tested it with, correctly detected the system ID to compile the correct enum values. The issue I'm running into is that, while I can compile "packages" just fine, the other components in the main project that are looking for the enum values are producing errors at compile time when I try to compile the whole project.

      The errors are "such-and-such is not a member of "packages"". Now, I have the ordered flag set, so I know the "packages" sub-project is compiling first. I've even tested this manually by building it, and then manually building part of the main project that relies on it, and I still get the same errors.

      Why are the other components of the project unaware of the enum values when "projects" has already compiled and has those values available?

      VRoninV Offline
      VRoninV Offline
      VRonin
      wrote on last edited by VRonin
      #2

      Because of

      Controlled by a DEFINES += sysID statement inside a systemID.pri

      Since the sub-projects don't have access to this define they have no way of knowing.

      Enums are just copy-paste of values. They are not compiled into a binary form once you build the "packages" project.

      "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
      ~Napoleon Bonaparte

      On a crusade to banish setIndexWidget() from the holy land of Qt

      1 Reply Last reply
      3
      • G Offline
        G Offline
        graniteDev
        wrote on last edited by
        #3

        I was concerned something like that would be the problem. Ok, a different approach is needed then. Thank you.

        1 Reply Last reply
        0

        • Login

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • Users
        • Groups
        • Search
        • Get Qt Extensions
        • Unsolved