Building ROOT against exiting cling and (patched) clangdev

I have been working on the conda packaging of cling, and the patched version of clang required by cling, and this has worked beautifully so far. The way we have done this is by creating a variant of the clang package including the patches. In doing so, we were able to prevent the vendoring of clang. Also, since conda includes its own C runtime and compiler, it is a distribution-independent build of cling.

There are some folks working on the conda packaging of ROOT itself, but they are vendoring clang and cling in the ROOT package, which does not play well with the rest of the packages.

Would if be possible to add an option to build ROOT against an existing build of cling?

I am not sure how the quotes in @Wile_E_Coyote’s reply relate to the original question.

That’s a good idea (we were discussing exactly this a month back). Our main issue is ROOT’s need of a static cling build, plus the fact that we need a couple of llvm / clang libs independently of cling. I.e. it needs a bit of work. But I guess Conda is a good motivation for us to do it.

Btw - if you have any connections to Conda folks, please support our request to get root-project as organization; for now they block it with the argument “it contains the word ‘root’ and that’s vetoed”…

@Axel Well, you could create a more general Physics-Packages or science-highenergy-physics project.

No matter how it is called, please make sure that there is NO “default” ROOT and that several different ROOT versions can coexist / be installed simultaneously.

Thanks @Axel. I would love to see ROOT depend on cling as a package! I don’t see a problem with the conda package including a static build… Do you think that it would be interesting to split it into a library and an executable for the REPL rather than exporting symbols in the executable?

I don’t have a means to influence this kind of policy w.r.t. the people administrating anaconda.org unfortunately.

Happy 2019, @Sylvain_Corlay!

That would be much easier, indeed (and it’s what we do for ROOT). But for I’m not sure the benefits are as high for cling - which is more of a demo application of the underlying functionality. The cost, OTOH, will be people saying “I start cling and it fails to find its library”…

Is this relevant in the conda context? More than for packaging / building, but for usage? I’m asking because I’d like to understand this better if it’s the case.

Cheers, Axel.

Do you think that it would be interesting to split it into a library and an executable for the REPL rather than exporting symbols in the executable?

That would be much easier, indeed (and it’s what we do for ROOT). But for I’m not sure the benefits are as high for cling - which is more of a demo application of the underlying functionality. The cost, OTOH, will be people saying “I start cling and it fails to find its library”

Well, we do depend on cling in xeus-cling, and that would be a more natural thing for us to do if you split into two cmake targets. I find it unlikely that the executable can’t find the shared object.

Similarly, I would be in favor of splitting the jupyter kernel out of the main cling repository, because it brings a dependency to the Python interpreter and the whole Jupyter stack.

How is that a repo thing and not a question of build configuration?

O, it’s very easy for binaries not to find their shared libs. If xeus-cling needs a cling library then that should be a conda entity, indeed. And it could be a static cling library, that then cling itself (the binary) depends on. IIRC that’s how the cling build system sets this up. So - what’s there to fix on cling’s side?

Similarly, I would be in favor of splitting the jupyter kernel out of the main cling repository, because it brings a dependency to the Python interpreter and the whole Jupyter stack.

How is that a repo thing and not a question of build configuration?

We could have two conda packages using the same source tarball, one building cling and the other one the kernels. Although the fact that both are in the same repository brings the expectation that it all comes bundled in one package.

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