Other format for "Warning: Unused Class Rule"?

Cling
1

Hi,

quick question: I’ve seen some warnings in our linkdef files about unused class rules. Those are great, however the warning is usually just

Warning: Unused class rule: ClassName

which makes it a bit hard to parse in our build system. Is there a way foreseen to make this warning gcc compatible with gcc? Something like

path/to/Linkdef.h:N:M: warning: Unused class rule: ClassName

Maybe via rootcling command line argument? This would be very helpful, especially with multi-core builds it becomes very hard to find the offending Linkdef.h otherwise.

Cheers,

Martin

2

Hi Martin,

very good proposal.

Cheers,
D

3

Hi,

to be sure to address this use case correctly for BelleII, could you post an example invocation of rootcling/genreflex coming from BasfII?

Cheers,
D

4

Sure thing, the command is (slightly abbreviated for include paths and defines)

rootcling -f build/Linux_x86_64/opt/framework_dataobjects_include_Dict.cc \
    -std=c++17 -O3 [...lots of -I...]  \
    -noIncludePaths  \
    -rmf "build/Linux_x86_64/opt/framework_dataobjects_include_Dict.rootmap" \
    -rml libframework.so \
    -D_PACKAGE_=\"framework\" [...some more defines...] \
    include/framework/dataobjects/RelationElement.h \
    [...more files in the same directory...] \
    framework/dataobjects/include/linkdef.h

so we would be fine with the name of the linkdef file to be reported exactly as given to rootcling, no need for any path manipulation. Also, for simplicity line number and column number can be 0 if they are not available.

5

Hi,

would for this particular case this warning be adequate?

framework/dataobjects/include/linkdef.h: warning: Unused class rule: ClassName

(N and M can be tricky, at least in first approximation).

Cheers,
D

6

Personally I would prefer if N and M are just given as 0:0 if they are not known. Just to be compatible with any tool parsing GCC errors

framework/dataobjects/include/linkdef.h:0:0: warning: Unused class rule: ClassName
7

Hi,

is this because you do not want to modify the warning parser of your ci?

D

8

Partly yes :smiley:

But also I just think it’s beneficial to keep to a format which is used by gcc+clang anyway. Not only would we not have to modify our parser but nobody else would have to either.

But we can live with both solutions. Or with just a line number and no column. As long as the filename is included as shown above we will manage :slight_smile:

9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.