Quick update on SOOT, a Perl-ROOT wrapper

ROOT
1

This is mostly just a heads-up that I haven’t vanished entirely after announcing the wrapper.

I’ve kept working on SOOT in spare moments. Specifically, it’s now installable* from CPAN with a single command, even if there is no ROOT on the target system:

should go ahead, install the Alien::ROOT module (which detects ROOT or installs its own), then install SOOT itself. Sprinkle "sudo"s as appropriate.

For the command line tool (shell-alike), you would want to do:

There is a fairly long list of changes at http://cpansearch.perl.org/src/SMUELLER/SOOT-0.09/Changes and the distribution comes with quite a number of examples (partly working, partly not). http://search.cpan.org/dist/SOOT

As an experiment, I managed to get SOOT built as part of the ROOT build process, but in order to do so, I had to hack the install procedure of ROOT a little bit. “configure” and “make” stages provide hooks, “install” doesn’t and I had to add hooks for that to get anywhere. The reason is that SOOT uses the typical Perl-specific build tools and it’s hard to change that without duplicating a lot or sacrificing the CPAN installation. My hacks to make SOOT build inside ROOT is nowhere near production-grade. In general terms, would you accept patches to make the install target extendable like the other build stages?

While in the long run, I’d still like to see SOOT included in ROOT, the ease of installation from CPAN and the more frequent releases are a simpler short-term solution, particularly since the automatic detection and installation of ROOT seems to be working fairly well.

  • Linux/gcc only
2

Hi,

if you keep SOOT in CPAN that is fine for us. We could extend our configure such that when doing --enable-soot we could make an attempt to install it from CPAN if not already installed. Anyway, we are open to adding hooks in the install target if that suits you.

Cheers, Fons.

PS: why SOOT? Not that I think of a Perl-ROOT interface when talking about SOOT. :wink:

3

Hi Fons,

thank you for your kind reply.

Making --enable-soot use CPAN.pm to install the extension is something that never occurred to me. I’ll have to think about it for a bit, but I have a hunch it might be combining the difficulties of both setups: You need a configured CPAN client and you need to have some kind of install-time hook in ROOT. I’ll give it some thought.

What I really need from a ROOT installation is that it’s built with explicit linking. I failed to find out why without it, my wrapper simply doesn’t work at all. Now, for Alien::ROOT, I had to work around the fact that it usually only discovers its ROOT installation at run-time, so I had to learn about rpath for breaking ld.so dependency cycles. Maybe, given this new setup, the problem just goes away. I sure hope so.

Various reasons: There are many attempts at providing perl-root wrappers out there, most of them using “static” wrapping, which turned out to be their doom in the long run. I wanted to prevent confusions such as “A: I’m using Perl-ROOT” – “B: Oh, that’s long gone!” – “A: But no, the other Perl-ROOT”.

Furthermore, I have to admit, I’m not a big fan of the name of ROOT. Capitals or not, it’s not particularly search engine friendly. Try searching for “perl soot” and “perl root” and see what comes up. PyROOT solves this in a similar way, but PeROOT, PROOT, etc all sound as silly as SOOT.

But really, in the end, it’s just a pun in various ways. The implementation is pretty hacky and thus the reference to soot is appropriate. Perl also has string increment, so you can do:

perl -E '$name = "R"; say ++$name'

(Unfortunately, that’s not going to cut it for the whole name, since ROOT++ would be ROOU.) :wink:

4

Hi,

ok, to get things into ROOT, propose the install hook you need. But most importantly try to get rid of the explicit linking requirement as we generally build without that option, and having to build with it to use the perl module will be a pain. Try using the rootmap files to determine what libs need loading before the perl module gets loaded.

Cheers, Fons.

5

Hi Fons,

thanks for your reply.

I will propose the hooks when I get the time to sort things out in a way that doesn’t make me look any more silly than absolutely necessary. But we have a collaboration meeting coming up that takes precedence by a long shot. :slight_smile:

Losing the explicitlink option would be great, but that will be hard because I don’t know where to start looking for the actual problem. In see no particular reason why I need it at all. I think I’m going through CINT when loading things, which should be using the rootmaps already. But alas, I get linker problems when building SOOT against a ROOT without explicit linking. Apparently, RubyROOT has the same problem. Maybe I need to tweak the actual linker options at SOOT build/link time or something. I’m obviously not an expert.

Without wanting to beat a dead horse, I also fail to see a good rationale against including explicit linking information in shared libs. You wrote earlier that it meant slower edit/compile/link cycles for developers, which is of course a valid concern, but unlike the average user or sysadmin, developers are likely quite capable to remember passing an extra option to configure.

I’ll try to keep working on SOOT and its inclusion, but it’s a significant bit of work done entirely in my spare time, on top of the software I maintain already on CPAN and in the perl core, so progress is naturally slow. The code’s on github. I’d be happy to collaborate with others.

Best regards,
Steffen