[cling] Startup script support

[jiangyilism]

Changes or fixes:

Implement startup script support according to this post: https://root-forum.cern.ch/t/cling-startup-scripts-support/51358

Checklist:

• [X] tested changes locally
• [ ] updated the docs (if necessary)

[phsft-bot]

Can one of the admins verify this patch?

[jiangyilism]

cling startup scripts are different from rootlogon.C and rootrc . rootrc is a config file while .clingrc is a regular cling script. cling startup scripts are executed also in invocation of standalone cling binary (not from root interpreter).

Question:

1. Renaming .cling_profile and .clingrc with suffix .C ?
2. Rename .clingrc to something else so that .clingrc can be reserved for cling config file in the future (if any)? Making it a config file instead of a cling script aligns with rootrc but not with bashrc, zshrc.
3. Drop .clingrc for now and keep .cling_profile only ? If a cling script can easily tell if it is in interactive mode then keeping only 1 script makes sense. Otherwise it is better to keep both to align with bash and other interpreter inspired by bash design. By easily telling I mean a macro like CLING_INTERACTIVE or something simple that does not access gCling.

[vgvassilev]

@phsft-bot build!

@jiangyilism, thanks for you PR, can you add some tests for the new functionality under cling/test?

[phsft-bot]

Starting build on ROOT-debian10-i386/soversion, ROOT-performance-centos8-multicore/cxx17, ROOT-ubuntu18.04/nortcxxmod, ROOT-ubuntu2004/python3, mac1015/cxx17, mac11/cxx14, windows10/cxx14 How to customize builds

[jiangyilism]

Hi @vgvassilev, cling/test/StratupFile.C is added. However it only covers usage of .cling_profile.C.

To proceed further, I would like to clerify the above decisions first.

Let me summarize again here:

1. Should we .x execute the startup file(s) or execute it in shebang #! way? @eguiraud, @vgvassilev, @Axel-Naumann, what is the designed/documented difference between the 2? Will it effect project root (which I have not tried out myself. I am experimenting standalone cling only) As far as I read from the web, rootlogon.C and .rootrc are executed in shebang way. Their filename-functions rootlogon(), rootrc() are not executed.

   My proposal: Execute startup files in .x way

2. How should the startup files be named? .cling_profile, .cling_login, .cling_logon like bash and root?

   https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html

   Should we adopt file suffix .C ?

   My proposal: .cling_profile.C to align with rootlogon.C (to be honest I just want the editor syntax highlighting...)

3. Do we need .cling_profile and .clingrc as the original draft implementation? If inside the script we can tell if cling is in interactive mode by a macro like CLING_INTERACTIVE then only 1 file is needed.

   My proposal: keep .cling_profile.C as the only startup file. Forget about #define CLING_INTERACTIVE 1 for now.

   I mentioned this support just because bash and other shells/interpreters have it. But unless someone wants this feature right now, I prefer not to implement it and reserve CLING_INTERACTIVE and .clingrc/.clingrc.C for future design.

[jiangyilism]

@Axel-Naumann , @vgvassilev Could you provide some feedback?

[vgvassilev]

@jiangyilism, thanks for your patch. I am a bit worried about the fact that upon startup cling will execute "random" code. Can you elaborate a little more about your usecase?

I suspect python does something similar, can we model the feature following their approach?

[jiangyilism]

My use case is to #include <...> some standard headers I often use. e.g. filesystem and thread. I will also put namespace fs = std::filesystem; in my startup file. cling already implicitly includes some standard headers so I think letting users to customize it makes sense.

About "execute random code", is there risk if the executed code/script is in user's home directory or XDG_CONFIG_HOME ?

[vgvassilev]

My use case is to #include <...> some standard headers I often use. e.g. filesystem and thread. I will also put namespace fs = std::filesystem; in my startup file. cling already implicitly includes some standard headers so I think letting users to customize it makes sense.

Thanks for explaining. It all makes sense.

About "execute random code", is there risk if the executed code/script is in user's home directory or XDG_CONFIG_HOME ?

Well, I guess bash and python suffer from the same issue. As long as we are consistent to their practices it should be no issue.

[vgvassilev]

cling startup scripts are different from rootlogon.C and rootrc . rootrc is a config file while .clingrc is a regular cling script. cling startup scripts are executed also in invocation of standalone cling binary (not from root interpreter).

Question:

1. Renaming `.cling_profile` and `.clingrc` with suffix `.C` ?

2. Rename  `.clingrc` to something else so that `.clingrc` can be reserved for cling config file in the future (if any)?
   Making it a config file instead of a cling script aligns with rootrc but not with bashrc, zshrc.

3. Drop `.clingrc`  for now and keep `.cling_profile` only ?  If a cling script can easily tell if it is in interactive mode then keeping only 1 script makes sense. Otherwise it is better to keep both to align with bash and other interpreter inspired by bash design. By easily telling I mean a macro like `CLING_INTERACTIVE` or something simple that does not access `gCling`.

How about a ~/.cling.d folder where we glob all files and execute?

[jiangyilism]

How about a ~/.cling.d folder where we glob all files and execute?

Sounds good to me too.

I will enumerate .C files in .cling.d/ (if dir exists) with llvm::vfs::directory_iterator like CompilerInstance.cpp. So the enumeration does not guarantee specific orderings.

Search order of .cling.d/ is still

1. ${CLING_HOME} envvar
2. ${XDG_CONFIG_HOME}/cling/
3. ${HOME}/.config/cling/
4. ${HOME}/

Does that look good to you?

[Axel-Naumann]

Apologies for not reacting - this sounds terrific! Could you update the PR?

[jiangyilism]

So the enumeration does not guarantee specific orderings.

Updated. However the behavior is slightly different: the startup files are sorted after enumeration so the execution order is deterministic.

[Axel-Naumann]

@phsft-bot build

[phsft-bot]

Starting build on ROOT-debian10-i386/soversion, ROOT-performance-centos8-multicore/cxx17, ROOT-ubuntu18.04/nortcxxmod, ROOT-ubuntu2004/python3, mac12/noimt, mac11/cxx14, windows10/cxx14 How to customize builds

[phsft-bot]

Build failed on mac11/cxx14. Running on macphsft23.dyndns.cern.ch:/Users/sftnight/build/workspace/root-pullrequests-build See console output.

Failing tests:

• projectroot.roottest.python.distrdf.dask.roottest_python_distrdf_dask_test_all
• projectroot.roottest.python.distrdf.spark.roottest_python_distrdf_spark_test_all

[vgvassilev]

@jiangyilism I was wondering what's the status of this PR?

[jiangyilism]

@jiangyilism I was wondering what's the status of this PR?

There is no pending issue as far as I know. The mac11/cxx14 test fail above is due to (flaky?) timeout so it seems irrelevant to this PR.

[vgvassilev]

@Axel-Naumann, should we merge this then?

[github-actions[bot]]

Test Results

       11 files         11 suites   2d 5h 55m 22s :stopwatch:   2 469 tests   2 460 :heavy_check_mark: 0 :zzz:   9 :x: 25 472 runs  25 461 :heavy_check_mark: 0 :zzz: 11 :x:

For more details on these failures, see this check.

Results for commit f816fae9.

[Axel-Naumann]

Thanks for your very nice contribution!