1. CEGUI team
  2. CEGUI
  3. CEGUI
  4. Issues
Issue #1146 new

build failure against default branch

Christopher Beck
created an issue

Operating System: Ubuntu (64-bit) OS version/build: 16.04

When testing on travis, I get the following build failure:

[ 30%] Building CXX object cegui/src/RendererModules/OpenGL/CMakeFiles/CEGUIOpenGLRenderer-9999.dir/GLXPBTextureTarget.cpp.o

In file included from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/Sizef.h:35:0,

                 from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/../../Renderer.h:35,

                 from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/RendererBase.h:32,

                 from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/RenderTarget.h:30,

                 from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/TextureTarget.h:30,

                 from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/GLXPBTextureTarget.h:32,

                 from /home/travis/build/cbeck88/cegui-mirror-two/cegui/src/RendererModules/OpenGL/GLXPBTextureTarget.cpp:27:

/home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/AspectMode.h:44:5: error: expected identifier before numeric constant



/home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/AspectMode.h:44:5: error: expected } before numeric constant

/home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/AspectMode.h:44:5: error: expected unqualified-id before numeric constant

/home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/AspectMode.h:62:1: error: expected declaration before } token

 } // End of  CEGUI namespace section


make[2]: *** [cegui/src/RendererModules/OpenGL/CMakeFiles/CEGUIOpenGLRenderer-9999.dir/GLXPBTextureTarget.cpp.o] Error 1

make[1]: *** [cegui/src/RendererModules/OpenGL/CMakeFiles/CEGUIOpenGLRenderer-9999.dir/all] Error 2

make[1]: *** Waiting for unfinished jobs....

I think this is a problem in the cmake lists: GLXPBTEXTURETARGET is supposed to be an OS X only target IIRC, so idk why it's building on a linux box.

Reproduction steps:

  - mkdir build
  - cd build
  - make -j2

Also worth noting: this is with a pretty ancient gcc,

-- The CXX compiler identification is GNU 4.8.4

If that's not supported on default branch it's pretty understandable. It is the default version for ubuntu 14.04. I'll check if it fails on more recent gcc.

Comments (43)

  1. Lukas Meindl

    Can we do something like

    #if None == 0L 
    #undefine None

    and at the end of this one cpp define it to 0L again?

    I guess we would have to do this for a number of files though. Do we know where`the header is leaked in?

  2. Lukas Meindl

    Yaron Cohen-Tal that is absolutely acceptable, imo. They do not need to combine those two in one implementation. They can just be sane and make a facet, or manager, or whatever the heck they want for it to encapsulate CEGUI and hide it away from the rest. That is sane and can be expected from a Linux developer ;)

    I also want to mention that libraries in fact often clash with each other if included into one cpp, this is not rare and others btw also got problems with x11. The thing we must prevent is only that it clashes internally or on very very likely usage. What do you think?

  3. Yaron Cohen-Tal

    I would like to add that when such compile errors happen they aren't trivial to figure out. See, even an expert programmer like Christopher Beck didn't immediately know how to solve this (in case he tried..). As a matter of fact, if paul hadn't mentioned it, and if I hadn't had some experience with Xlib and None myself, it wouldn't have been trivial for me to solve it either. So, I think, to prevent possible frustration from other programmers, it's best to rename the enum value to prevent a possible clash.

  4. Christopher Beck reporter

    Yeah this stuff is a huge PITA. I remember I had a lot of trouble porting a program to windows once because there is some windows header that defines "ERROR" all-caps as a macro and I was using that myself as a macro T_T

    Maybe we can establish a convention that all CEGUI enumerators should be in spanish or esperanto or something. Hopefully "Non" and "Nada" are not OS X macros or something... :D

  5. Yaron Cohen-Tal

    Either way, our macOS users should prolly b fine, which is of course the most important.

    Personally I'd b very glad to watch a gladiator tournament between the ppl that #defined ERROR, IGNORE, None, True, False, Dennis Ritchie (which imo has done everything he could when creating C so that such clashes often happen, and the situtation in C today isn't better; As far as I'm concurned the C designers r the most responsible for all that mess), 5 tigers and 12 lions and a tarasque.

  6. Lukas Meindl

    Yea, I wonder if making macros namespace-able would have solved this. But then again, we would have all those specialists that wouldn't put them in namespaces, right?

  7. Yaron Cohen-Tal

    U don't need macros at all. Enough to use an enum in a namespace, or enum class, or a constexpr function in a namespace. Macros r evil. I just can't comprehend how it took so long to those super-elemantary elements to make their way into C++ (and will prolly never make it into C).

  8. Lukas Meindl

    I agree that for defining variables it is retarded in headers. I agree that Macros in general are evil but I disagree they are never needed. Look at CEGUI's macro usage, and maybe you can prove me wrong and find a better way than how we do the things - I actually would be glad about that - but the only way I see that that would be possible is with a lot of code duplication. What I do see is that by setting up methods smarter we could save us at least some of them. If you wanna do it, imo do it.

    I m meanwhile renaming all None's and then we see what else will burn.

  9. Yaron Cohen-Tal

    I'm not saying I have a better alternative for every macro usage, and by no means I meant to criticize cegui's macro usage. I do say, however, that in most (and perhaps all) cases when macro usage is the best alternative, this implies a flaw in the underlying programming language's design, which should have given a better alternative.

  10. Lukas Meindl

    I agree but they wanted to keep C backwards compatibility. Unfortunately for us, these days. And I dont think this problem can be solved without making a new programming language ):

  11. Christopher Beck reporter

    Yeah, I tested now. I get different failures now, now in GL.h. I think it's mentioned by Yaron

    Also I get some warning about "subscript outside of array bounds" which sounds bad


    Array warning:

    /home/travis/build/cbeck88/cegui-mirror-two/cegui/src/InputAggregator.cpp: In member function virtual void CEGUI::InputAggregator::initialise(bool):
    /home/travis/build/cbeck88/cegui-mirror-two/cegui/src/InputAggregator.cpp:523:73: warning: array subscript is above array bounds [-Warray-bounds]
         d_keyValuesMappings[static_cast<unsigned char>(Key::Scan::Backspace)] = SemanticValue::DeletePreviousCharacter;

    GL.h failure: (Might be that the only issue is the None enum, hard to say)

    In file included from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/RendererBase.h:37:0,
                     from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/RenderTarget.h:30,
                     from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/TextureTarget.h:30,
                     from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/GLXPBTextureTarget.h:32,
                     from /home/travis/build/cbeck88/cegui-mirror-two/cegui/src/RendererModules/OpenGL/GLXPBTextureTarget.cpp:27:
    /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/GL.h:88:9: error: expected identifier before numeric constant
             None, /*!< Not initalized yet */
    /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/GL.h:88:9: error: expected ‘}’ before numeric constant
    /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/GL.h:88:9: error: expected unqualified-id before numeric constant
    /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/GL.h: In function CEGUI::OpenGLInfo& CEGUI::getSingleton():
    /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/GL.h:93:48: error: s_instance was not declared in this scope
         static OpenGLInfo& getSingleton() { return s_instance; }
    In file included from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/RendererBase.h:37:0,
                     from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/RenderTarget.h:30,
                     from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/TextureTarget.h:30,
                     from /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/GLXPBTextureTarget.h:32,
                     from /home/travis/build/cbeck88/cegui-mirror-two/cegui/src/RendererModules/OpenGL/GLXPBTextureTarget.cpp:27:
    /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/GL.h: At global scope:
    /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/GL.h:108:5: error: Type does not name a type
         Type type() const { return d_type; }
    /home/travis/build/cbeck88/cegui-mirror-two/cegui/include/CEGUI/RendererModules/OpenGL/GL.h:114:33: error: non-member function bool CEGUI::isUsingDesktopOpengl() cannot have cv-qualifier
         bool isUsingDesktopOpengl() const { return type() == Type::TypeDesktop; }

    If we wait a hundred years, then we'll know if the array bounds warning is gcc 4.8 only or if it also reproduces on gcc 5

  12. Lukas Meindl

    I must have done the one change late at night, let's all laugh about it, I did

    bool d_keysPressed[sizeof(Key::Scan)];

    instead of

    bool d_keysPressed[std::numeric_limits<unsigned char>::max()];

    :D (Key::Scan is an unsigned char)

  13. Christopher Beck reporter

    Yeah, I could try turning off the bindings to see if it goes to completion then. First error now is

    In file included from /home/travis/build/cbeck88/cegui-mirror-two/cegui/src/ScriptModules/Python/bindings/output/CEGUI/WidgetComponentIterator.pypp.cpp:4:0:
    /home/travis/build/cbeck88/cegui-mirror-two/cegui/src/ScriptModules/Python/bindings/generators/include/python_CEGUI.h:57:12: error: ‘Vector2f’ does not name a type
         static Vector2f stringToVector2(const String& str)
    /home/travis/build/cbeck88/cegui-mirror-two/cegui/src/ScriptModules/Python/bindings/generators/include/python_CEGUI.h:146:41: error: ‘Vector2f’ does not name a type
         static String vector2ToString(const Vector2f& val)
  14. Lukas Meindl

    The only one who knows how to regenerate the python bindings in their current setup is Martin Preisler btw.

    He says there is magic involved.

    Maybe if somebody got a plan, we can change our setup to a simpler generator but I think martin already has investigated this not so long ago.

  15. Log in to comment