CINT Dictionary Fix, master branch (2019.06.06.)

Fixed a mistake that crept in during the last big update (!475 (merged)) of this code.

This was preventing incremental builds from re-generating dictionaries correctly when header files, from which CINT dictionaries are generated, got modified.

This was discovered in athena!23831 (merged), and was a bit discussed in ATLINFR-1644.

I tried to now very explicitly test, using akraszna/CMakeDictionaryTests, that this update would make the builds return to their expected behaviour. (I didn't do such rigorous tests with the previous update...)

Any reason why we cannot add these tests into atlasexternals directly?

AE Build FAILURE
Build logfiles are available at Jenkins [AE-MERGE-REQUEST-CC7 #13]

Jenkins please retry a build.

@aundrus, could you look at this MR? I can only imagine that the SLC6 -> CentOS 7 change has something to do with this failure. But unfortunately I can't even navigate to Jenkins with the link that was put into the merge request.

Hi @akraszna, only one project build failed: AnalysisBaseExternals https://atlas-sit-ci.cern.ch/job/AE-gcc-build-CC7/Executor_Label=aibuild20-043,PROJECT=AnalysisBaseExternals/2/console

15:08:07 [ 82%] Built target Netx
15:08:07 CMakeFiles/NetxNG.dir/src/TNetXNGFile.cxx.o: In function `TNetXNGFile::Flush()':
15:08:07 /usr/include/xrootd/XrdCl/XrdClXRootDResponses.hh:261: undefined reference to `XrdCl::Status::ToString[abi:cxx11]() const'
15:08:07 CMakeFiles/NetxNG.dir/src/TNetXNGFile.cxx.o: In function `TNetXNGFile::ReadBuffer(char*, long long, int)':
15:08:07 /usr/include/xrootd/XrdCl/XrdClXRootDResponses.hh:261: undefined reference to `XrdCl::Status::ToString[abi:cxx11]() const'
....
15:08:07 /build2/atlasexternals/master/AnalysisBaseExternals/src/ROOT/net/netxng/src/TNetXNGSystem.cxx:342: undefined reference to `XrdCl::URL::URL(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
15:08:07 collect2: error: ld returned 1 exit status
15:08:07 make[5]: *** [lib/libNetxNG.so] Error 1

It is just undefined reference... But I notice it uses /usr/include/xrootd. Should it use xrootd from CVMFS?

Alex

Argh... I'll have to think a bit of how to solve this...

The problem is that AnalysisBaseExternals tries to be smart about what it's building. If it sees one of its externals already available on the host system, it doesn't try to re-compile that. This is to allow analysers to easily build the analysis release on top of their locally installed ROOT/Boost/etc. versions.

Now, in SLC6 the system had Python 2.6 installed. Since the analysis releases required Python 2.7, everything was always built. Since XRootD/ROOT/etc. all depend on Python. So even if the build machine had XRootD installed under /usr, AnalysisBaseExternals still built XRootD on its own.

But now on CentOS 7 the system provides Python 2.7 itself. So AnalysisBaseExternals doesn't try to build Python by default. And at this point, if it finds XRootD under /usr, it also doesn't try to build that. It did try to build ROOT though, telling it to use XRootD from /usr. But clearly that XRootD installation was not built in C++17 mode, and so we get a linking error.

What makes it much worse is that I forgot that I actually had problems building XRootD on CentOS 7 with GCC 8. There's something very weird happening in the AnalysisBaseExternals build that I didn't manage to figure out so far. (I can build XRootD by itself successfully with GCC 8. But when I build it as part of AnalysisBaseExternals, the compiler issues a warning on one of the source files, which, because of the -Werror flag that XRootD uses, causes a build failure.) I've known about this for a long time now, but until now it was not near the top of my ToDo list...

This particular merge request I'll just push in. But I'll have to think a bit how we should fix the CentOS 7 + GCC 8 build of AnalysisBaseExternals...

Cheers, Attila

merged

mentioned in commit b093ca27

mentioned in merge request !485 (merged)