Add Arguments to Unnamed Root Macro Without Screwing Everything Up

Newbie
1

Hey,

So there is this repository X, which I did not make and do not fully understand that I have to incorporate into my code so that it can perform one (1) single function. I tried to write my script that uses the classes they have, but ran into a lot of errors when running it about having redefined certain functions, etc, and I figure out that it’s some kind of issue with me not getting the repository’s shared library. Helpfully, they offered an example for how to run a user made script with a little root macro wrapper like:

{
    gROOT->ProcessLine(".L X.so");
    gROOT->ProcessLine(".L whateverScript.cc+");
    int hardCodedInput = 0;
    whateverScript(hardCodedInput);
}

This works great and after a long process of actually making code that works to do what I want I got everything to run nice and fine with it just doing:

root -q -l -n -b rootMacWrapper.C

Finally, though, I naively wanted to give this little thing some arguments so I could batch process it with permutations of inputs, etc. So after looking into it I altered it to something like:

scriptWrapper(int varInput){
    gROOT->ProcessLine(".L X.so");
    gROOT->ProcessLine(".L whateverScript.cc+");
    whateverScript(varInput);
}

but now I get "error: use of undeclared identifier ‘calc12122023JECRoch’. Because, oh no, now it’s treating it as valid C++ code, which it sure isn’t. So I go ahead and add an include for my script like:

#include "whateverScript.cc"
scriptWrapper(int varInput){
    gROOT->ProcessLine(".L X.so");
    gROOT->ProcessLine(".L whateverScript.cc+");
    whateverScript(varInput);
}

but suddenly all the errors I was getting around the shared library at the start are back, because, I’m guessing, in this context it doesn’t care about the gROOT->ProcessLine stuff. However, helpfully again the repository creators have included some instructions for making a standalone executable out of a macro, that include the alterations I’ve already done, removing the gROOT->ProcessLine stuff, and end with

g++ scriptWrapper.cc -o scriptWrapper.exe `root-config --cflags --glibs` X.so

This would be great, but when I run it I get:

X/many/directories/down/to/a/file/included/in/the/class/i/want/to/use/someHeader.h fatal error: CondFormats/CMSSW/Stuff/interface/someCMSSWHeader.h: No such file or directory

Which about exhausted my troubleshooting capabilities. So at this point I’m ready to just make a different wrapper file for every permutation of inputs I want, have the .sh I give to condor handle accessing the correct one in each job, and never think about this again, but I’m sure not at least getting a little insight into the issue will come to bite me someday. Correspondingly, any input on what’s going on would be dearly appreciated. Obviously I’m not expecting specifics since I’m giving general example code, but if anything can be gleamed from it that would be great, thanks.

ROOT Version: 6.12/07

2

have you tried adding void:

void scriptWrapper(int varInput){
...
}

?

3

Indeed I did. Sorry, I mistakenly didn’t include it in the example I gave and as far as I can tell I can’t edit my post (something specific to the “Newbie” forum?).
EDIT: Or, perhaps, specific to the OP.

4

Looks like some cling issue, I guess @vvassilev can help.

5

Regarding the issue with the shared library, it seems to me that it’s a path or linking problem. When you compile with g++, it might not be aware of all the dependencies that ROOT automatically handles. Checking the library paths and ensuring all dependencies are correctly included in the compilation command could help.

Also, the error from the standalone executable compilation suggests a missing header file or an incorrect include path. It’s crucial to ensure all the necessary CMSSW headers are accessible and correctly referenced in your code.

I know it’s tempting to create separate wrappers for each input permutation, but that might lead to a lot of redundant work. If you can solve the root of these compilation issues, it’ll save you time in the long run and give you a more robust solution.

6

You switch from an unnamed macro (i.e. essentially a series of input for the command line) to a named macro that is now parsed and compiled as a whole before any execution takes place.

We have macro R__LOAD_LIBRARY that can help in the transition:

R__LOAD_LIBRARY(X.so)
R__LOAD_LIBRARY(whateverScript.cc+)

#include "whateverScript.cc"

scriptWrapper(int varInput) {
    whateverScript(varInput);
}