PCM header information usage?

Hi,

just curious - will the release of ROOT-6 already use the PCM header information, or will this come later?

As far as I understand, ROOT-6/Cling currently still uses the actual header files - but to do that, it must be able to find the headers when a library is loaded. So currently, I pass the final/install location of the headers to rootcling with “-I”, but that means the header location gets hard-coded into the the dictionaries, which make the result non-relocatable. So you can’t pack all your libs into a package for distribution on a cluster and things like that where absolute paths are a problem. I guess this will go away again with the PCM files, as long as they’re next to the libs?

Cheers and thanks,

Oliver

Hi,

Yes, we expect PCMs to be part of ROOT 6.0.

We currently use quite an intricate / smart way of finding back your headers: any -I provided to ROOT (TInterpreter::AddIncludePath()) will do, as well as any ‘:’ separated path in ROOT_INCLUDE_PATH. The latter might vanish once we have PCMs. So you should be able to provide just the stem plus -I’s to rootcling, such that ROOT can find your headers at runtime through a combination of these stems and updated -I’s.

Cheers, Axel.

Great, thanks!

Hi,

I just tried with ROOT-6.00.00, but it still seems to be looking for the actual header files
(when I don’t use something like “rootcling … -I installed_header_dir”). I do have a
.pcm next to .rootmap and the .so in my LD_LIBRARY_PATH, but how do I make
ROOT use it? Or is something wrong with my pcm file (it’s quite small)?

I use

to generate rootmap and pcm.

Cheers,

Oliver

Hi,

Your files are fine. Real PCMs did not make it into 6.00. The files store similar information for now, in a different format. Until we get PCMs we need to #include the headers, and for now we need to find the original headers back as passed to rootcling / genreflex. This is expected to improve by 6.02 in September.

Cheers, Axel

Thanks for the update, Axel!

I’ll just use ROOT_INCLUDE_PATH and a few other tricks until 6.02, then. :slight_smile:

Hi,

just curious what the status is - I saw some more magic to include headers in the dictionary source code in 6.02, but the PCMs are still not used, right? So for now, everything stays the same, and as long as Cling can find the headers all is good?

Cheers,

Oliver

Hi,

Correct. For experiments’ frameworks we also provide a means of extending ROOT’s PCH.

Cheers, Axel.

Hi,

sorry for reviving this old thread again, but I’m (again) curious on an up-to-date status.

For our software framework infrastructure, it would be much easier to embed all header information in PCMs instead of having to keep the headers around at runtime (since all our users build the framework from source and regularly modify the headers during development, so header-library mismatch is extremely common).

At the moment, I only know of the inlineInputHeaders functionality (which embeds a single header). Is full “real” PCM support within reach? Could a PCH be an intermediate solution (for our case)?

Cheers,
Oliver

Hello,

I also feel it’s necessary to use pre-compiled PCH files instead of parse header files at runtime. It seems that we currently have allDict.cxx.pch which stores the AST information of some system module headers, but for other modules, there are only PCMs(a root file?) that could not provide full definitions to interpreter for loading enough symbols. Is that right?

I’m wondering why don’t we just save AST structure of module headers to the corresponding PCM file, also by that we could speed up the module loading process, I think :slight_smile:

Cheers,
Haoyan

Hi,

With ROOT and cling being updated to current llvm and ROOT being able to be built with PCMs we are now getting closer to PCM support for dictionaries. Nonetheless I expect this to take until the end of the year. The problem is not storing the AST but combining the overlaps from different PCMs; this has been solved by clang’s PCM implementation so there is no reason to reinvent this (with likely lower quality).

$ $ROOTSYS/build/unix/makepch.sh my.pch extraheaders-for-PCH
$ ROOT_PCH=my.pch root 

should generate a PCH for ROOT’s headers (it includes them automatically) and extraheaders-for-PCH. The second line makes it known to ROOT to use that PCH instead of its own.

Cheers, Axel.

Hi Axel,

thanks a lot for the update!

I fully agree. It’s no problem to wait a bit more. ROOT 6 is already working well, the problem of requiring headers at runtime only collides with our development model, since all our developers are working “within” the code of our framework (and not all are experienced C++ developers - so I will not recommend ROOT 6 as main platform to them yet). Waiting until the end of year / beginning of next year for the main userbase is no problem.

I might look into PCH creation in the meantime, thanks for the pointers to the correct script to use!
I believe for our purpose, a modified version of etc/dictpch/makepch.sh might be sufficient (using the installed dictpch-files from a ROOT build and injecting then the extra-headers of our framework).

Cheers and thanks again!
Oliver

Dear all,

I saw the post but I am not able to resolve my problem. So I have ROOT 6.02/05 (tacos 10.10).
I compiled many libraries of WAT (c++ libs) and then I try to load them in root. I have the following errors:

Loading WAT : /Files/CWB_osx_clang_6/WAT/trunk/tools/install/lib/wavelet.so …
Error in TCling::RegisterModule: cannot find dictionary module wave_dict_rdict.pcm
Loading Frame : /Files/CWB_osx_clang_6/FRAMELIB/libframe-8.21 …
Loading STFT : /Files/CWB_osx_clang_6/WAT/trunk/tools/install/lib/STFT.so …
Error in TCling::RegisterModule: cannot find dictionary module STFT_dict_rdict.pcm
Loading gwat : /Files/CWB_osx_clang_6/WAT/trunk/tools/install/lib/gwat.so …

etc …

I loaded othe libraries without problem, why these ones get that?
What is in this case the solution, to add the add_path in the rootlogon?

Sorry to come back here.
Thank you for your help
Filipe

Hi,

When you create a dictionary (and link it into a shared library), a PCM file is created with it. Please put it side-by-side next to the library.

In general it’s better to start a new topic for a new issue (rather than adding to a fixed one); this makes our discussion easier to find and it increases the chances that you get a fast reply!

Cheers, Axel.