travis: enable checking the real gcc on OSX

[papadop]

Just to document some issues I found while attempting to have the cmake build in travis.... 1) On MacOS, the gnu build is the same as the clang build. Because, right now travis installs only the clang compiler which is named g++. To get really gnu/g++, from the docs one has to specify a g++-version, but I have not been able to make this work. 2) The check of wiki examples is not really working. Some tests fail without being noticed by travis (the return code is 0), It is not even clear why the test is failing. It's a link error but the proper lib are correctly passed to the compiler. 3) I think these wiki tests are somehow done in the wrong way, It would be much easier to add the tests to the blitz repo and to include them in the wiki page. In this way, these tests can be done by users (not only on travis) and the whole build system can be leveraged.

[slayoo]

Thanks a lot for fighting with it!!!

Re 1: AFAIK, this is not a Travis issue - OSX simply presents its clang as g++ to its users

Re 2: IIUC, this is what you refer to: https://travis-ci.org/blitzpp/blitz/jobs/527970013#L3673 If so, I hope this will help: https://github.com/blitzpp/blitz/pull/121

Re 3: In principle, I agree, yet (i) I don't know a way of including such content in github wiki (see https://github.com/github/markup/issues/346); (ii) what is tested here are not the blitz features but rather if the program output presented in the wiki page is consistent with the current behaviour of the library.

[slayoo]

@papadop any ideas why linking fails with the wiki examples? Nowith changes with --enable-shared and with --prefix=/usr: https://travis-ci.org/blitzpp/blitz/jobs/528152660

[papadop]

Re: Re 1: Well yes and no. The issue is that the report lets us believe that it works on MacOS with gcc, whereas this is untested. travis site states that it is possible to select the official gnu compiler by using g++-version but I have not been able to do that (I did not spent much energy on this, I had other troubles). My thinking is that either we disable the g++ MacOs travis build (which will spare some resources) or we make it work....

[papadop]

No that puzzled me too. I would try the -L approach instead of LD_LIBRARY_PATH .... Seeing your tests, I do not think it is a share/static problem as the cmake build by default creates a shared library.

[citibeth]

Blitz++ is very NOT OS-specific: it depends almost entirely on the compiler, not on system libraries, etc. My guess is that GCC on (Intel) Linux is almost indistinguishable from GCC on (Intel) macOS. I'm happy to forgo testing GCC on macOS.

[papadop]

I agree. But the proper solution is to disable the travis configuration MacOs/gcc.

Just a small note: I noticed the problem, because I renamed the clang config file llvm/bzconfig.h instead of gnu/bzconfig.h. clang and gcc are not the same compiler and differ in their C++ implementation levels... Given that blitz is quite old and relies on "old" C++ features, mixing the bzconfig files for clang and gcc is not a big problem today, but if we start to use newer things such as parameter packs, I'm not sure we will not discover some differences between the compilers. So I prefer to distinguish gnu and llvm for the config file name. Another note: It would be nice to "collect" somewhere the various bzconfig.h so that we can start cleaning up the C++ feature macros that are available in every compiler... Third and last note: Start a list of the actually used compilers. Are the compilers such as compaq, fujitsu or apple/ibm/xlc still in use ? Here also, a cleanup would be nice. A glimpse on actually used compiler can be found through cmake: https://cmake.org/cmake/help/v3.0/variable/CMAKE_LANG_COMPILER_ID.html

[citibeth]

On Mon, May 6, 2019 at 10:46 AM Theodore Papadopoulo < notifications@github.com> wrote:

I agree. But the proper solution is to disable the travis configuration MacOs/gcc.

Just a small note: I noticed the problem, because I renamed the clang config file llvm/bzconfig.h instead of gnu/bzconfig.h. clang and gcc are not the same compiler and differ in their C++ implementation levels... Given that blitz is quite old and relies on "old" C++ features, mixing the bzconfig files for clang and gcc is not a big problem today, but if we start to use newer things such as parameter packs, I'm not sure we will not discover some differences between the compilers. So I prefer to distinguish gnu and llvm for the config file name.

The whole bzconfig approach to making things work with different compilers is completely outdated, and doesn't play well with most things these days. It was outdated when Blitz++ was first built as well; but not AS outdated then. Autotools paved the way, way back then, to avoid this kind of stuff. If we can get rid of it, that would be great.

Another note: It would be nice to "collect" somewhere the various bzconfig.h so that we can start cleaning up the C++ feature macros that are available in every compiler...

Third and last note: Start a list of the actually used compilers. Are the compilers such as compaq, fujitsu or apple/ibm/xlc still in use ? Here also, a cleanup would be nice. A glimpse on actually used compiler can be found through cmake: https://cmake.org/cmake/help/v3.0/variable/CMAKE_LANG_COMPILER_ID.html

Let's just support the MOST used compilers (eg: Clang, GCC, Intel, MSVC). If people want to use other compilers, they can speak up; and until then, they can use the Autotools build.

-- Elizabeth

[slayoo]

I've renamed the issue to make it a bit clearer what is the focus. The wiki-examples script problem is being addressed here: #121

[papadop]

The CMake build supports already all the various compilers that are common to the list in the web page above and in the autotools list. But this is just theory unless someone tries effectively those builds...