wxOVERRIDE flag in wxWidgets

[CPPAWhile]

Hi,

I only recently started using wxWidgets. I am using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1-16.04.5). I check my flags for build using wx-config --cxxflags and wx-config --libs.

The above approach works fine for me to compile with g++ -c and/or to link.

The minor problem I have is the keyword wxOVERRIDE. There is some include or build option (probably an include). Just wondering where it is. What include file has it - I'm sure that gcc 5.4.0 is C11-compliant. There's just some compile flag or perhaps a directory I need. I would like to use that flag. Currently, I just take it out when I build so things build.

I'm just using a simple command-line to build some small programs. I'll check the makefiles of the samples, and the include dirs - maybe I'll think of something.

No emergency.

I tried the flag -std=c++11 but that did not help.
I wonder if I have a compiler version which is troublesome?
I wonder do I need to send a flag that wxWidgets recognizes for the level of tool I'm using - like 3 or something?
I don't find a definition of wxOVERRIDE when I do a find in files in any of the directories - hMM?

I'm going to look - I think it's in a defs.h file perhaps?

My thread got messed up:

I now realize what it is. For certain compilers (those that support pre-compilation), the file wx/wxprec.h is included in the samples. That file in turn references wx/defs.h, as does wx/wx.h. The sample designer should have put a separate reference to the file defs.h (which has the wxOVERRIDE defined).

No biggie: I can just include it separately.

There are two directory sets on my computer that have wx/wxprec.h, wx/defs.h. The one that I didn't want was being scanned first and the compiler skipped the 2nd which has the wxOVERRIDE definition.
So I removed the -I home references in my compilation and just added the flag myself.For some reason, there are two sets of directories which have the file wx/wxprec.h - one set in /usr, one set in /home. I can't find an order of these files in the compile which allows me to scan the /home ones first which HAS the wxOVERRIDE definition, and also allows a good link (without unreferenced errors). I'm not sure why there are two sets. My wx-config suggests using /usr includes. But I can't. There's no definition of wxOVERRIDE, and probably other important differences.

I just did the built without the -I to the /home and then added my own definition of wxOVERRIDE override and it built, linked, and ran fine. I might have put another installation perhaps of binaries on first before installing the source? I don't know, something like that using apt install.

[CPPAWhile]

I now realize what it is. For certain compilers (those that support pre-compilation), the file wx/wxprec.h is included in the samples. That file in turn references wx/defs.h, as does wx/wx.h. The sample designer should have put a separate reference to the file defs.h (which has the wxOVERRIDE defined).

No biggie: I can just include it separately.

[Peter87]

wxOVERRIDE expands to the override keyword if the compiler supports it.
https://www.wxwidgets.org/develop/coding-guidelines/#use_override
http://en.cppreference.com/w/cpp/language/override

If your program requires C++11 or later there isn't much reason to use this macro. Just use the override keyword directly.

[CPPAWhile]

For some reason, there are two sets of directories which have the file wx/wxprec.h - one set in /usr, one set in /home. I can't find an order of these files in the compile which allows me to scan the /home ones first which HAS the wxOVERRIDE definition, and also allows a good link (without unreferenced errors). I'm not sure why there are two sets. My wx-config suggests using /usr includes. But I can't. There's no definition of wxOVERRIDE, and probably other important differences.

[CPPAWhile]

Sorry, my thread has become confusing as I deleted one post accidentally.

I see what you're saying that I can just use override directly.

But in an edit of my original post of the thread, I explain that I was having compilation difficulties when I tried to use wxWidget's own defs.h file in /usr subtree since it did NOT have a definition of wxOVERRIDE. I just wanted to understand that a little better. So I decided to just put my own definition in for now, or as you say, I can hard-code it later.

It's been a long day, at least my program runs, thanks for the info on what you think I should do. The samples use that macro - perhaps the samples were developed a good while ago???

At least I got my short compile script so I don't have the huge makefile until I think I need it. Of course, it might be dangerous by I favor a minimalist approach so I can see what's needed more clearly (hoping I don't crash at runtime). So far so goo.

[CPPAWhile]

A summary of my thread should be given here:

My run of wx-config suggested two usr directories to -I include when I run g++ or gcc, whatever. But the wx/defs.h does NOT have ANY definition of wxOVERRIDE. Hence the suggestions of wx-config are sort of wrong for lack of a better word. But sooner or later, perhaps I'll know why. But if I include both usr and home's version of defs.h, even if I switch the order so it uses home I have other problems. So I just dropped the -I home references, but I feel this is a slight kludge. I just didn't expect this but it might be ok.

[Peter87]

It sounds almost like you have two versions of wxWidget on your computer. An older one in /usr that you have installed from the package manager, and a newer one in your home directory that you have downloaded yourself. If this is the case you probably should get rid of the older version and instead use the newer one.

The samples use that macro - perhaps the samples were developed a good while ago???

wxOVERRIDE is a relatively new thing. They only started to use it after C++11 was out. The purpose is to be able to take advantage of override on compilers that support it without breaking backward compatibility, because wxWidgets supports older versions of C++ and they probably want the samples to do the same.

[CPPAWhile]

Thanks, when I boot that machine up today, I'll have to figure out which version I built when I downloaded source and compiled (I pray it's the newer one). It probably IS not only newer, but the beta version of wxWidgets. The one in /usr (as you say) is almost surely the older one, because it's obvious that I probably installed the one I built from source in home (which is a place I would normally install something built from scratch).

Then I'll have the right headers (home-based) by the end of today (ie. the ones with HAVE_OVERRIDE/wxOVERRIDE in them). And hopefully, I'll be able to get wx-config to suggest the right headers. I'll have to dig into that tool and see how it works. Right now it gives me the /usr stuff.

I like having that flag in there though as I will be building this app in a variety of environments.

[CPPAWhile]

I believe I now know what happened. After I ran ./configure and make. I just didn't do a make install.

[CPPAWhile]

Everything is fine now. Here's a little summary for anyone who had this problem:

If you package-install wxWidgets 3.0 and then build wxWidgets 3.1, BUT accidentally forgot to run make install, or better sudo make install (you have to prefix with sudo or make install will fail out on some lib stuff), then do the following:

1. Run sudo make install in the directory where ./configure and the Makefile are.

2. Run wx-config --cxxflags to get your new include stuff for g++.
3. Run wx-config --libs to get your new link stuff for g++.

There will be slight changes to your previous build - mostly a lot of 3.0 become 3.1 and some 2u greps become 3u greps. And maybe an extra html lib, perhaps one or two added or subtracted directories. Basically, the build will be very similar and not take long to change your make.

4. Run sudo ldconfig - This is important so that the runtime you build will find the shared libraries. I tried to use LD_LIBRARY_PATH but it didn't work.

You can see if any shared libraries mentioned in a failed run are on the machine just by cd'ing to root and running find -name sharedlib.so.x (x is version number). sharedlib is the lib the executable wants. I'm not sure why LD_LIBRARY_PATH setting didn't work. ldconfig seems like the tool of choice here. I'll have to understand these tools better.

But all is building and running now, and I can even use the wx/wxprec.h include which ultimately calls wx/defs.h and has the wxOVERRIDE flag.

Voila - c'est fini for now.

Thank you for the help and comments!

Update: I now realize that ldconfig just sets LD_LIBRARY_PATH - I had simply mis-typed the path, or possibly (according to the end of the make install script comments), there is something else that ldconfig does. I need to understand this.