new clang warning about undefined-var-template

[KrisThielemans]

/home/travis/build/UCL/STIR/src/include/stir/RegisteredParsingObject.h:129:51: warning: instantiation of variable 'stir::QuadraticPrior<float>::registered_name' required here, but no definition is available [-Wundefined-var-template]

Possible solution seems to imply we need to define registered_name for every type, not with a template.

[KrisThielemans]

I'll give a more complete example here (but look at any Travis OSX log)

In file included from /Users/travis/build/UCL/STIR/src/include/stir/KOSMAPOSL/KOSMAPOSLReconstruction.h:40:
In file included from /Users/travis/build/UCL/STIR/src/include/stir/RegisteredParsingObject.h:142:
/Users/travis/build/UCL/STIR/src/include/stir/RegisteredParsingObject.inl:34:21: warning: instantiation of variable 'stir::OSMAPOSLReconstruction<stir::DiscretisedDensity<3, float> >::registered_name' required here, but no definition is available [-Wundefined-var-template]
  { return Derived::registered_name; }
                    ^
/Users/travis/build/UCL/STIR/src/include/stir/RegisteredParsingObject.h:86:7: note: in instantiation of member function 'stir::RegisteredParsingObject<stir::OSMAPOSLReconstruction<stir::DiscretisedDensity<3, float> >, stir::Reconstruction<stir::DiscretisedDensity<3, float> >, stir::IterativeReconstruction<stir::DiscretisedDensity<3, float> > >::get_registered_name' requested here
class RegisteredParsingObject : public Parent
      ^
/Users/travis/build/UCL/STIR/src/include/stir/OSMAPOSL/OSMAPOSLReconstruction.h:101:31: note: forward declaration of template entity is here
    static const char * const registered_name;

These would be nice to get rid of, as it means it's almost impossible to see what else is going wrong.

Suggested solutions seem to all say you need to include something like

template <> extern const char * const OSMAPOSLReconstruction<DiscretisedDensity<3,float> >::registered_name;

in the .h files, i.e. you can tell the compiler explicitly which variables are going to be instantiated in a .cxx somewhere. Also related is this nice post on the benefits of declaration of an explicit instantiation . Related discussion here dealii/dealii#3705.

It makes sense, as you make it part of the API (i.e. .h) which instantiations are going to be available.

On the other hand it also means that we need to put in our .h files which templates we're going to instantiate, which seems a fair amount of work.

I therefore suggest to disable the warning, but create an other issue to add declarations of explicit instantiations, deferring that to 5.0 or so.

[KrisThielemans]

@rijobro do you know what the clang option would be. Maybe even do a PR? We have job failures because of log file size exceeded, see e.g. https://travis-ci.org/github/UCL/STIR/jobs/678274643

[rijobro]

Does that mean that everywhere we have ::registered_name, we need to add your suggestion Sounds like a lot of work...

I therefore suggest to disable the warning

This sounds like a lot less work!

Maybe even do a PR?

For which one, the easy one or the hard one? The easy one is just adding -Wno-undefined-var-template for OSX Travis builds, right?

[KrisThielemans]

a PR for the easy option!

As opposed to doing it for Travis, I'd put it in our CMakeLists.txt.

if (CMAKE_CXX_COMPILER_ID MATCHES "Clang")
  # using regular Clang, IBM Clang or AppleClang
  # see https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_ID.html
   ...
endif()

could you put it on the new release_4 branch? I've got the feeling that we'll need to do a few small PRs on that first before jumping to 5 with master