New Port - root-devel giving a snapshot of the ROOT6 development.

[cjones051073 (Chris Jones)]

Hi,

Attached is the port file (and two patch files) for a proposed new port root-devel. It should I guess live in the science section, along side the root port.

It provides access to a snapshot of the ROOT 6 development cycle. This is a major development over ROOT 5 and most notably replaces the CINT interpreter with cling, a new one based on llvm/clang. This is a big change so it is likely we will want to maintain ROOT5 and ROOT6 versions for some time, even once ROOT6 is first released.

No actual releases are made yet, so this port grabs an a particular (fixed) svn revision from the ROOT svn server. Other than the changes needed to do this the port is essentially the same as the root port, and provides most of the same variants. I have though removed the various gcc and clang variants, as it simply does not compile with these compilers. I have only got it working with clang and llvm-gcc4.2 in OSX10.8 Xcode 4.5.2. I don't have access to any other OSX versions, so have no idea if it will compile on them or not ...

This port conflicts with the root port (and thus if committed the root port should be updated at the same time to conflict with this one). Allowing them to be installable side by side might be possible, but quite a bit of effort and I am not sure if it would be worth it.

One thing I wasn't completely sure on was how to update the livecheck section, so please take a look at that part.

cheers Chris

[cjones051073 (Chris Jones)]

Sorry. There will be a short delay before I attach the files, as I sort out a last minute issue...

[cjones051073 (Chris Jones)]

Just for the record, the delay in attaching the files was I managed to trip myself over ticket #32575 again, by having python 3.2 selected as my default python version. As this devel ROOT version internally builds llvm as part of the cling interpreter it suffers from the same LLVM bug (yes, thats what I would call it) as LLVM itself which assumes python is from the 2.X series and doesn't bother check.... Solution is the same as for LLVM, upstream needs to acknowledge python 3 exists and either support it, or check and bail out gracefully ...

Chris

[cdeil (Christoph Deil)]

Do you plan to make this port track ROOT SVN trunk or ROOT 6 stable once it's released? I think that should decide if the name of this port should be root-devel or root6.

[cdeil (Christoph Deil)]

For me the SVN checkout only works if I use https, with http I get an error:

$ /usr/bin/svn --non-interactive --trust-server-cert export http://root.cern.ch/svn/root/trunk@48346
svn: OPTIONS of 'http://root.cern.ch/svn/root/trunk': Could not read status line: connection was closed by server (http://root.cern.ch)
$ /usr/bin/svn --non-interactive --trust-server-cert export https://root.cern.ch/svn/root/trunk@48346
svn: Destination directory exists; please remove the directory or use --force to overwrite
svn: 'trunk' already exists

[cdeil (Christoph Deil)]

Does Python work for you? Can you try and see if this crashes?

python -c 'import ROOT; ROOT.TBrowser()'

I'll try your Portfile now on OS X 10.7 and 10.8.

[cjones051073 (Chris Jones)]

Good question. I agree it would be useful to agree on the naming scheme now...

My thinking was this port would stay with the SVN versions (updating as and when) and until the first ROOT6 'stable' release is made. Even then, my feeling is plenty of users will want to stay with ROOT5, so at that point root-devel would switch from SVN revision builds, to stable release builds, but the 'root' port would stay with the ROOT5 release series.

Then, at some totally undefined point in the future we would move ROOT6 to the stable 'root' port, when it is felt to be ready. At this point a root5 port could be created, for those that wish to stay with it. root-devel would then either stop updating, or move to ROOT7 or whatever...

The alternative I guess would be to move the current root port to root5 now, and submit this as root6. They could then develop independently as needed.

I am easy either way with the above alternatives. I can see pros and cons to both...

[cjones051073 (Chris Jones)]

Replying to Deil.Christoph@…:

Does Python work for you? Can you try and see if this crashes?

python -c 'import ROOT; ROOT.TBrowser()'

I'll try your Portfile now on OS X 10.7 and 10.8.

yes, but maybe you tripping over ticket #37673 ?

[cjones051073 (Chris Jones)]

Replying to Deil.Christoph@…:

For me the SVN checkout only works if I use https, with http I get an error:

$ /usr/bin/svn --non-interactive --trust-server-cert export http://root.cern.ch/svn/root/trunk@48346
svn: OPTIONS of 'http://root.cern.ch/svn/root/trunk': Could not read status line: connection was closed by server (http://root.cern.ch)
$ /usr/bin/svn --non-interactive --trust-server-cert export https://root.cern.ch/svn/root/trunk@48346
svn: Destination directory exists; please remove the directory or use --force to overwrite
svn: 'trunk' already exists

Works fine for me ...

Chris-Jones-Macbook-Pro ~/Projects >  /usr/bin/svn --non-interactive --trust-server-cert export http://root.cern.ch/svn/root/trunk@48346
A    trunk
A    trunk/cmake
A    trunk/cmake/scripts
<snip>

maybe some transient error for you ?

https works fine for me though, so I have no problem updating the port to use that if preferred ?

Chris

[cjones051073 (Chris Jones)]

Replying to jonesc@…:

Replying to Deil.Christoph@…:

Does Python work for you? Can you try and see if this crashes?

python -c 'import ROOT; ROOT.TBrowser()'

I'll try your Portfile now on OS X 10.7 and 10.8.

yes, but maybe you tripping over ticket #37673 ?

just to be clear, by 'yes' above I mean yes it works fine for me ...

[cdeil (Christoph Deil)]

The SVN problem with http is not transient for me. I think changing to https should work for everyone.

I did try ROOT SVN trunk couple of times in the past month. My ticket for Python and ROOT 6 is still open, so I was assuming it just doesn't work yet: ​https://savannah.cern.ch/bugs/?99145 Let's see ....

[cjones051073 (Chris Jones)]

Replying to Deil.Christoph@…:

The SVN problem with http is not transient for me. I think changing to https should work for everyone.

Fair enough, lets make it https.

I did try ROOT SVN trunk couple of times in the past month. My ticket for Python and ROOT 6 is still open, so I was assuming it just doesn't work yet: ​https://savannah.cern.ch/bugs/?99145 Let's see ....

Sorry, I just realised I ran the test with root, not root-devel... with root-devel I also get a failure

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ROOT.py", line 411, in __getattr1
    self.__finalSetup()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ROOT.py", line 516, in __finalSetup
    not ( self.keeppolling or _root.gROOT.IsBatch() ):
RuntimeError: could not resolve TROOT::IsBatch()

the root-devel/root6 port is going to be a 'devel' port, work in progress, alpha release port, for some time to come. Something will always not work... I thought of creating it just to allow people to start testing if they want to. A few people have asked me now as maintainer of the root port if cling support was coming, and this seemed the best way to supply that. So I think a failure like this is not a reason not to have such a port. Yes, we will probably need to update it regularly to pick up fixes, but thats fine I think...

Chris

[cjones051073 (Chris Jones)]

I've updated the Portfile to use https instead of http.

[cdeil (Christoph Deil)]

I get the same error with the python27 variant on Mac OS X 10.8:

>>> ROOT.TBrowser()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ROOT.py", line 411, in __getattr1
    self.__finalSetup()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/ROOT.py", line 516, in __finalSetup
    not ( self.keeppolling or _root.gROOT.IsBatch() ):
RuntimeError: could not resolve TROOT::IsBatch()

[cjones051073 (Chris Jones)]

Fair enough, at least that is consistent ;)

As I said, I don't view this as a reason not to release the port. It is an 'alpha' level port and the main reason to have it is to try and increase user exposure to it, to help the ROOT team with more bug reports.... As long as user realise what it is and use t 'root' port for a more stable version...

Chris

[mojca (Mojca Miklavec)]

Cc Me!

[cdeil (Christoph Deil)]

+1 for this port! I didn't mean we should wait for problems with ROOT 6 to be solved. It seems the ROOT 6 release is coming before mid-March ( ​http://root.cern.ch/drupal/content/root-user-workshop-11-14-march-saas-fee ) so it's good to get testing with Macports started now.

[cdeil (Christoph Deil)]

This port works on Mac OS X 10.7 as well.

[cjones051073 (Chris Jones)]

Replying to Deil.Christoph@…:

This port works on Mac OS X 10.7 as well.

Good to hear. Just for interest, what compiler are you using on 10.7 ?

Chris

[cjones051073 (Chris Jones)]

What do people think on the naming scheme ? I am starting to come around to the idea of renaming the current root port root5, and calling this one root6. Primarily because I am sure even once root 6 is released as stable, many users will want to stick with root5....

[mojca (Mojca Miklavec)]

I completely agree that existence of version 5 will be needed for quite a while after the release of version 6 (if nothing else to satisfy the dependencies of Geant4), so using the name root6 would definitely make sense. Whether the new port is called root-devel, root6 or root6-devel might not be so relevant since it won't exist for long.

I believe that once the first release of version 6 gets out there will hardly be any need for fetching the latest SVN version any more? But I still find it very important to make the first port before the release since the team will have time to get rid of Mac(Ports)-specific bugs and consequently there will be less patches needed for the official release.

Renaming root to root5 would probably be a logical consequence of adding root6. But it might also make sense to look into ways of enabling parallel installation of both. (Or at least keeping root5 where it is and trying to make root6 independent by using /opt/local/share/root6 instead of /opt/local/share/root etc.)

[mojca (Mojca Miklavec)]

One more question: wouldn't it make sense to try to switch to CMake-based installation?

[cjones051073 (Chris Jones)]

maybe... I am not that familiar with cmake and it would anyway be a big rewrite of the port file. I don't have time for that now, but if someone else wants to, be my guest...

[mojca (Mojca Miklavec)]

I'm willing to help, only ... would you be willing to help me complete the Portfile if I start with something CMake-based that works and then you help me add the zillion of options?

I'm aware that it means a big change, but switching to Root 6 is a big change on its own. So it feels like the perfect timing to do that, also because Geant4, CLHEP, Gate and other similar/related projects all switched to CMake.

[cjones051073 (Chris Jones)]

I believe that once the first release of version 6 gets out there will hardly be any need for fetching the latest SVN version any more? But I still find it very important to make the first port before the release since the team will have time to get rid of Mac(Ports)-specific bugs and consequently there will be less patches needed for the official release.

Yes, once there are official releases of root6, it will no longer be needed to download from svn directly, but use the tar balls. Until then, updating the svn revision as and when wanted is quite easy.

Renaming root to root5 would probably be a logical consequence of adding root6. But it might also make sense to look into ways of enabling parallel installation of both. (Or at least keeping root5 where it is and trying to make root6 independent by using /opt/local/share/root6 instead of /opt/local/share/root etc.)

I agree that would be nice, but as with moving to cmake it involves a lot more work on the port file than it took to put this one together ( which really was just a matter of changing the fetch method and removing a few non-working Variants). I don't have the time to look into this now, but if someone else wants to again, like with cmake, be my guest. I'll help where I can. If you want to be a co maintainer of a root6 port, even better...

Chris

[g5pw (Aljaž Srebrnič)]

I think we should have a port named root-devel which is in sync with the svn repository of root, and whenever they release root 6, we just copy that, change name to root6, change fetch method and rename root to root6. So, for a brief transition period we'll have 4 root ports (all conflicting):

• root (obsolete stub port pointing to root5)
• root5
• root6
• root-devel

What do you think?

[g5pw (Aljaž Srebrnič)]

Cc Me!

[cjones051073 (Chris Jones)]

Maybe. Keeping root-devel 'in sync with svn' will be tough in general, as there are updates most days... The best we could hope for is to update every now and then, whenever there is something commit someone wishes to test. That is why I was think to only follow svn for a short while, in the run up to the first root6 release, and then switch to the releases. So only have 2 versions at any one time.

[mojca (Mojca Miklavec)]

Off-topic, but: "oh, great". I have found ​https://github.com/bbannier/ROOT. This might not be the official repository (I found it under ​http://root.cern.ch/phpBB3/viewtopic.php?f=3&t=5570&start=30), but I cannot stand SVN doing a fresh checkout every time I change a few characters in the Portfile. I'll upload the CMake-based attempts of the port using GitHub if you don't mind.

[cjones051073 (Chris Jones)]

For your private tests use git OK, but for the released portfile we should use the official ROOT SVN repository, not a private git clone "updated from time to time"

Chris

[mojca (Mojca Miklavec)]

Just curious: which fortran compiler is known to work? I tried with the default one without any special settings (g95; not using your port) and it fails with

cd /Users/me/.macports/opt/local/var/macports/build/_Users_me_app_macports_science_root-devel/root-devel/work/build/misc/minicern && /opt/local/bin/g95  -Dminicern_EXPORTS -m64 -std=legacy -O3 -arch x86_64 -fPIC -I/Users/me/.macports/opt/local/var/macports/build/_Users_me_app_macports_science_root-devel/root-devel/work/build/include -I/Users/me/.macports/opt/local/var/macports/build/_Users_me_app_macports_science_root-devel/root-devel/work/trunk/misc/minicern/inc    -c /Users/me/.macports/opt/local/var/macports/build/_Users_me_app_macports_science_root-devel/root-devel/work/trunk/misc/minicern/src/hbook.f -o CMakeFiles/minicern.dir/src/hbook.o
f951: error: unrecognized command line option "-std=legacy"
make[2]: *** [misc/minicern/CMakeFiles/minicern.dir/src/hbook.o] Error 1
make[2]: Leaving directory `/Users/me/.macports/opt/local/var/macports/build/_Users_me_app_macports_science_root-devel/root-devel/work/build'
make[1]: *** [misc/minicern/CMakeFiles/minicern.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

I now tried removing -std=legacy.

[cjones051073 (Chris Jones)]

To get a fortran compiler you need to do the equivalent of the gcc<XY> variants. This configures things to use gfortran of the appropriate version. I have no idea where g95 comes from ...

[cjones051073 (Chris Jones)]

basically you need to do

variant gcc47 conflicts gcc45 gcc46 gcc48 description {Compile using MacPorts gcc 4.7} {
   configure.compiler      macports-gcc-4.7
   depends_lib-append      port:gcc47
}

then do the cmake equivalent of

  configure.args-append \
	        --with-cc=${configure.cc} \
	        --with-cxx=${configure.cxx} \
	        --with-ld=${configure.cxx}
	    if { ${configure.f77} != "" } {
	        configure.args-append --with-f77=${configure.f77}
	    }

Note though I haven't got the gcc compilers to work with root6, hence they are currently commented out.

Also bear in mind you should make sure the port does not opportunistically use a fortran compiler. If the user doesn't request a gcc variant, the fortran compiler should not be used, even if it is present. That is what the above logic ensures.

cheers Chris

[mojca (Mojca Miklavec)]

I don't want to try out gcc4X variants if you already figured out that they don't work, at least not in the phase when I'm still fighting to get the most basic version to compile.

What do you mean with "the fortran compiler should not be used"? I don't find any option that would allow me to disable compilation of Fortran code. I think that I need at least one fortran compiler, even if clang in taken for CC and gfortran-mp-whatever is taken for FC. Does leaving the --with-f77 flag out really prevent Fortran code to compile?

In the meantime I realised that removing -std=legacy flag prevents building errors, but still throws all kinds of warnings during compilation. I'll try with gfortran now unless I figure out a way to avoid compilation of Fortran code altogether. (The last thing I remember from compiling Root was the following: ​http://lists.macosforge.org/pipermail/macports-users/2011-December/thread.html#26650)

[cjones051073 (Chris Jones)]

What do you mean with "the fortran compiler should not be used"? I don't find any option that would allow me to disable compilation of Fortran code. I think that I need at least one fortran compiler, even if clang in taken for CC and gfortran-mp-whatever is taken for FC. Does leaving the --with-f77 flag out really prevent Fortran code to compile?

for me yes. The Macports compilers have names the configure script doesn't now about, so it cannot find them. If the user has 'port selected' a gcc compiler, so 'gfortran' is available (as opposed to gfortran-mp-X.Y) then yes, the configure script does find it still.

[mojca (Mojca Miklavec)]

I see it now in main/CMakeLists.txt:

if(CMAKE_Fortran_COMPILER)
  ROOT_EXECUTABLE(g2root g2root.f LIBRARIES minicern)
  #ROOT_EXECUTABLE(h2root h2root.cxx LIBRARIES Core RIO Net Hist Graf Graf3d Gpad Tree Matrix MathCore Thread minicern)
endif()

Maybe fortran recently became optional after all. But I tried to set the variable CMAKE_Fortran_COMPILER to an empty string and it doesn't seem very promissing:

> cmake -DCMAKE_Fortran_COMPILER='' -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DCMAKE_INSTALL_PREFIX=/path/to/root_trunk-inst ../root_trunk-src
-- The C compiler identification is Clang 3.1.0
-- The CXX compiler identification is Clang 3.1.0
-- Check for working C compiler: /usr/bin/clang
-- Check for working C compiler: /usr/bin/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/clang++
-- Check for working CXX compiler: /usr/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- The Fortran compiler identification is unknown
...
> make
-- The Fortran compiler identification is G95
-- Check for working Fortran compiler: /opt/local/bin/g95
-- Check for working Fortran compiler: /opt/local/bin/g95  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /opt/local/bin/g95 supports Fortran 90
-- Checking whether /opt/local/bin/g95 supports Fortran 90 -- yes
-- CMAKE_BUILD_TYPE: RelWithDebInfo
-- Found a Mac OS X System 10.7
-- Found a 64bit system
-- Found LLVM compiler collection
-- ROOT Platform: macosx
-- ROOT Architecture: macosx64
-- Build Type: RelWithDebInfo
-- Compiler Flags:  -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common 
-- Looking for ZLib
...

[cjones051073 (Chris Jones)]

I have never tried with the g95 port installed, only the gcc compiler gfortran versions, which as I said have a name the configure script cannot guess. You might be correct that there is no way to prevent it finding a compiler if there with a name it expects. Try removing the g95 port...

That said, I have never seen compilation issues (using ./configure) related to fortran...

[cjones051073 (Chris Jones)]

It might also be the code doesn't compile at all using the g95 compiler ... Try using a gccXY gfortran compiler...

[mojca (Mojca Miklavec)]

The code compiles with g95 if I remove that flag -std=legacy (which broke compilation), but throws many errors. I'm now testing what happens if I use cmake -DCMAKE_Fortran_COMPILER='' (it finds a working Fortran compiler at some step, but I still have some hope that it won't actually be used. I only have to wait for another 40 minutes to figure that out.

[mojca (Mojca Miklavec)]

I seem to be unable to disable the Fortran compiler. It errors out in exactly the same way if I set it to an empty variable. I tried gfortran-mp-4.7 and it still throws many errors - I filed a ticket under ​https://savannah.cern.ch/bugs/index.php?99944. Let's see what the root developers respond.

[mojca (Mojca Miklavec)]

After I almost got the CMake-based Portfile working, I realized that CMake adds '-arch x86_64' to the fortran compiler. Arghhhh. I saw a possible solution in plplot port (browser:trunk/dports/science/plplot/Portfile​). I will try to mimick the plplot port, but I'll file a separate bug report.

[mojca (Mojca Miklavec)]

CMake-based Portfile for Root 6

[mojca (Mojca Miklavec)]

I attached root-devel.cmake.Portfile as a preliminary Portfile for the trunk version of Root based on CMake. Known issues:

• MacPorts automatically adds -arch x86_64 for Fortran. See #37732. This prevents compilation altogether. I should probably mimick plplots unless the bug gets fixed some time soon.
• It is obligatory to select +gcc4X to set up gfortran (it won't change the C/C++ compiler since Chris claims that it doesn't work and I didn't try it out: there are enough problems with other issues already). Using g95 requires some trivial patch to remove a flag.
• (I didn't yet figure out how to avoid Fortran altogether.)
• It uses an unofficial GitHub clone since it's a pain to develop a port based on SVN (each change requires a new svn checkout). This is temporary and easy to fix.
• It doesn't implement all options yet, but it should implement the default ones at least. The highest on priority list should be fixing Python variants.
• I'm not yet sure how to link against /opt/local/lib/libpng.dylib. It always finds the library from /usr.

Nevertheless I would be grateful for feedback, in particular as soon as the first issue is dealt with.

[cjones051073 (Chris Jones)]

Thanks for working on this ! I am busy for a few days so will not be able to look for a bit, but I will when I have time.

Cheers Chris

[mojca (Mojca Miklavec)]

Replying to jonesc@…:

For your private tests use git OK, but for the released portfile we should use the official ROOT SVN repository, not a private git clone "updated from time to time"

​http://root.cern.ch/drupal/content/root-has-moved-git

git clone http://root.cern.ch/git/root.git

and there is also (an official?) mirror at ​https://github.com/root-mirror/root/

Also, here is the updated URL to the ticket to help getting rid of fortran compile errors: ​https://sft.its.cern.ch/jira/browse/ROOT-4874 (even better would be to prevent fortran completely)

[mojca (Mojca Miklavec)]

My suggestion would be to try to create a CMake-based installation based on one of the preview releases from ​https://github.com/root-mirror/root/releases (currently the latest one is v5-99-03-01). I would suggest to take the sources from GitHub in fact. This can be easily changed when the official 6.0 gets released, but I would like to start playing with version 6 before it's ready to replace the version 5.

PS: of secondary importance, but it might be handy to be able to run Geant4 (which probably isn't aware of Root 6 yet) flawlessly while still being able to test Root 6, but I don't know what the best solution for that would be.

[mojca (Mojca Miklavec)]

Version v5-99-03-01 doesn't compile. Apparently master should still be used at the moment. I uploaded a new basic Portfile, but there are still problems with Fortran (​https://sft.its.cern.ch/jira/browse/ROOT-4874).

[cjones051073 (Chris Jones)]

Thanks for your continuing work on this ?

I agree it would be nice to allow root and root-devel to be installed at the same time. This of course will require one or other to install as 'root<X>' instead of just 'root'. I would suggest this should first be done for the root-devel port, so get it installing as root6 ? Longer term we can decide if the old root gets updated to install as root5 or not.

Chris

[mojca (Mojca Miklavec)]

Replying to jonesc@…:

I agree it would be nice to allow root and root-devel to be installed at the same time. I would suggest this should first be done for the root-devel port, so get it installing as root6 ?

Sounds fine.

Usually you can easily change this with something like -DCMAKE_INSTALL_PREFIX=${prefix}/whatever for the whole tree or with a combination of the following variables:

CMAKE_INSTALL_BINDIR
CMAKE_INSTALL_DATADIR
CMAKE_INSTALL_DATAROOTDIR
CMAKE_INSTALL_DOCDIR
CMAKE_INSTALL_INCLUDEDIR
CMAKE_INSTALL_LIBDIR

They can be relative paths, for example include/root/root6. I suggest to test this soon enough / before the official release, so that anything can be fixed upstream if needed. I really hope that Fortran configuration will be fixed soon as well.

PS: please try to make the cocoa work with this setup ;)

[mojca (Mojca Miklavec)]

Committed in r119871.