[NEW] Cling

[ani07nov@…]

Cling is a new and interactive C++11 standard compliant interpreter built on the top of Clang and LLVM compiler infrastructure. Its advantages over the standard interpreters are that it has command line prompt and uses Just In Time (JIT) compiler for compilation. Many of the developers (e.g. Mono in their project called CSharpRepl) of such kind of software applications name them interactive compilers.

One of Cling's main goals is to provide contemporary, high-performance alternative of the current C++ interpreter in the ROOT project - CINT. Cling serves as a core component of the ROOT system for storing and analyzing the data of the Large Hadron Collider (LHC) experiments. The backward-compatibility with CINT is major priority during the development.

[ryandesign (Ryan Carsten Schmidt)]

Thanks. I see some problems with the portfile:

• You need to fill in the version field. If the project does not assign version numbers, you can invent one; the YYYYMMDD format is often used.
• If possible, fetch from a distfile (e.g. tarball, zipball) instead of from git. If not possible, fetch from a specific committish of the git repository, not from the head of the repository because that's not a repeatable build.
• The maintainers line needs to list your complete valid email address, preferably in our obfuscated host:user format.
• In the post-fetch block, use system's -W argument instead of using cd.
• Do not disable the checksum phase. If fetching from a distfile, provide valid checksums; if not fetching from a distfile, MacPorts doesn't use the checksum phase anyway.
• Use a MacPorts python (e.g. python27), not OS X's python; you may want to provide variants so the user can select which MacPorts python version to use.
• Don't add --prefix=${prefix} to configure.args; it's already in configure.pre_args for you.
• Implement livecheck, if possible.

Note that we also have a request to add a cling variant to the root port, which might be relevant.

[mkae (Marko Käning)]

Cc Me!

[cjones051073 (Chris Jones)]

Note that we also have a request to add a cling variant to the root port, which might be relevant.

On this point, we have some prototype root5 and root6 ports in the final stages of testing/review, that will provide ROOT5 and ROOT6 (the current beta2) side by side. ROOT6 will of course use cling as its interpreter.

I hope we can iron out any remaining issues and submit these very soon.

Chris

[ryandesign (Ryan Carsten Schmidt)]

So what is the relationship between the cling in this port and the cling used by root in #34171? I assume they are the same software. Does root use its own internal version of cling? If this cling port were committed, would we change root to use it, or would that not be desired?

[cjones051073 (Chris Jones)]

Hi,

Yes, its essentially the same thing. Root6 though builds its own internal cling version, and afaik there is currently no option to use an external cling build. Both cling and root6 are heavily in development now, root6 is still in beta, so its reasonable they want to control the version they use, for compatibility reasons. Its possible they might in the future an add an option to use an external cling, but also given its an integral core component of root6, they also might decide they wish to always have control of the version they use. Root has also always shown a tendency to prefer to use its own internal builds... Either way, its something for upstream to decide if they wish to allow or not, so until they do any root6 and cling ports will have to use they own cling builds (i beleive root6 names theirs such that it would clash, but this would have to be tested.)

Chris

[ani07nov@…]

Cling and ROOT 6 are two separate projects. It is true that there is presently no out-of-the-box solution to use an external build of Cling with ROOT 6, but that will be made possible some day at which point this port will also be useful to the ROOT project and not just Cling users.

I believe I have rectified most of the problems which you pointed out. I have created a new attachment for my new Portfile. Please let me know if I have to make any other changes.

[cjones051073 (Chris Jones)]

Replying to jonesc@…:

Hi,

Yes, its essentially the same thing. Root6 though builds its own internal cling version, and afaik there is currently no option to use an external cling build. Both cling and root6 are heavily in development now, root6 is still in beta, so its reasonable they want to control the version they use, for compatibility reasons. Its possible they might in the future an add an option to use an external cling, but also given its an integral core component of root6, they also might decide they wish to always have control of the version they use. Root has also always shown a tendency to prefer to use its own internal builds... Either way, its something for upstream to decide if they wish to allow or not, so until they do any root6 and cling ports will have to use they own cling builds (i beleive root6 names theirs such that it would clash, but this would have to be tested.)

Just to correct that last statement. I intended to say "would NOT clash".... Somewhere along the line the not went awol..

Chris

[mojca (Mojca Miklavec)]

Not that it has much to do with a standalone cling port, but a port for ROOT6 has been committed in r119871.

[Mathias.Laurin+macports.org@…]

Cc Me!

[ani07nov@…]

Initial portfile for Cling

[ani07nov@…]

Modified the portfile to use the newly adopted version system of Cling. Please let me know if additional changes are necessary.

[myint (Steven Myint)]

Cc Me!

[mojca (Mojca Miklavec)]

This is not a requirement, but I'm asking nonetheless: are you able to figure out if the files could be fetched zipped from repository and checked for checksums as opposed to fetching them via git?

This seems to work for me for example:

wget "http://root.cern.ch/gitweb?p=clang.git;a=snapshot;h=cling-patches-r202469;sf=tgz"

[mojca (Mojca Miklavec)]

The starting point is here: ​http://root.cern.ch/gitweb

The official website instructs using:

git clone http://root.cern.ch/git/llvm.git src
cd src
git checkout cling-patches
cd tools
git clone http://root.cern.ch/git/cling.git
git clone http://root.cern.ch/git/clang.git
cd clang
git checkout cling-patches

So until someone fixes the code for fetching from git (#16373), the following files could be helpful to reduce the amount of downloads:

• http://root.cern.ch/gitweb?p=llvm.git;a=snapshot;h=cling-patches-r202469;sf=tgz
• http://root.cern.ch/gitweb?p=cling.git;a=snapshot;h=v0.1;sf=tgz
• http://root.cern.ch/gitweb?p=clang.git;a=snapshot;h=cling-patches-r202469;sf=tgz

(using the same variables that you used in your attachment to select the tag and latest know good revision)

[mojca (Mojca Miklavec)]

It would be also nice to try to get the CMake-based installation to work.

There are typos in your Portfile. It should have been

fetch.type          git
git.url             http://root.cern.ch/git/llvm.git
git.branch          cling-patches-r${LastKnownGoodLLVMSVNRevision}

post-fetch {
   system -W ${worksrcpath}/tools "git clone http://root.cern.ch/git/clang.git && cd clang && git checkout cling-patches-r${LastKnownGoodLLVMSVNRevision}"
   system -W ${worksrcpath}/tools "git clone http://root.cern.ch/git/cling.git && cd cling && git checkout tags/v${version}"
}

or simply checkout the proper branch from the start.

I'm testing the build right now (we *really* need to fix #16373, it's so annoying to keep cloning over and over again).

[mojca (Mojca Miklavec)]

The build with a modified Portfile eventually succeeded, but there is one major flaw. The port ends up installing the following files among others:

x ./opt/local/bin/bugpoint
x ./opt/local/bin/c-index-test
x ./opt/local/bin/clang
x ./opt/local/bin/clang++
x ./opt/local/bin/clang-check
x ./opt/local/bin/clang-format
x ./opt/local/bin/clang-tblgen
x ./opt/local/bin/cling
x ./opt/local/bin/count
x ./opt/local/bin/FileCheck
x ./opt/local/bin/llc
x ./opt/local/bin/lli
x ./opt/local/bin/lli-child-target
x ./opt/local/bin/llvm-ar
x ./opt/local/bin/llvm-as
x ./opt/local/bin/llvm-bcanalyzer
x ./opt/local/bin/llvm-config
x ./opt/local/bin/llvm-cov
x ./opt/local/bin/llvm-diff
x ./opt/local/bin/llvm-dis
x ./opt/local/bin/llvm-dwarfdump
x ./opt/local/bin/llvm-extract
x ./opt/local/bin/llvm-link
x ./opt/local/bin/llvm-mc
x ./opt/local/bin/llvm-mcmarkup
x ./opt/local/bin/llvm-nm
x ./opt/local/bin/llvm-objdump
x ./opt/local/bin/llvm-profdata
x ./opt/local/bin/llvm-ranlib
x ./opt/local/bin/llvm-readobj
x ./opt/local/bin/llvm-rtdyld
x ./opt/local/bin/llvm-size
x ./opt/local/bin/llvm-stress
x ./opt/local/bin/llvm-symbolizer
x ./opt/local/bin/llvm-tblgen
x ./opt/local/bin/macho-dump
x ./opt/local/bin/not
x ./opt/local/bin/opt

I don't believe this is acceptable.

You might want to take a look at how and where the llvm-3.x/clang-3.x ports install their files (and possibly support port_select even though that's not really a priority). Or at least you need to change the prefix.

[mojca (Mojca Miklavec)]

See also #43917.