clhep: outdated (request for 2.1.1.0) & broken on Lion

[mojca (Mojca Miklavec)]

The package clhep seems to be really painful to build (CXX=/absolute/path/to/g++ fails, no matter what compiler is being used, but it works out of the box when no environmental variables for compiler are set, that is, outside of MacPorts).

The following modifications worked for me (leaving original patch intact):

name                clhep
version             2.1.1.0
...
checksums           md5 f8acb50a9cdb9ac8937fecfcb741ba10
...
# this should be conditional
configure.compiler gcc-4.2
# I'm not sure if this is absolutely needed/respected at all
build.args-append CC=gcc CXX=g++ CPP=g++

however work should be done by someone with enough knowledge to fix the original package. (On the other hand geant4 9.5 now includes clhep.)

[ryandesign (Ryan Carsten Schmidt)]

The Cc field must contain valid email addresses.

Please supply a main.log showing the failed build on Lion.

CXX=/absolute/path/to/g++ is simply how MacPorts does things, for reasons explained in UsingTheRightCompiler.

[mojca (Mojca Miklavec)]

Log file of clhep when compiled with an explicit CXX=/Developer/usr/bin/clang++

[mojca (Mojca Miklavec)]

log of current clhep build (old version) using macports

[mojca (Mojca Miklavec)]

I attached the logs: both the failed build with macports and the standalone compilation with an explicit setting of compiler. I'm sorry for screwing up the CC fields and thanks a lot for fixing them.

I have no idea why exactly the build fails (as I pointed out above, it is quite possible that build.args-append are not needed at all, but once I added both lines, the compilation was successful for the first time). Maybe it has to do with a buggy clang compiler, but the source code of clhep definitely has a lot of space for improvement of their configure scripts. The lines

if {${configure.compiler} == "llvm-gcc-4.2"} {
   configure.compiler gcc-4.2
}

didn't work for me for some reason, but I'm a complete newbie.

[ryandesign (Ryan Carsten Schmidt)]

While the main.log you attached is incomplete, it does show that you're using clang, and that the error is:

error: use of overloaded operator '^' is ambiguous

which sure sounds like a clang-specific complaint. Try using llvm-gcc-4.2 instead. See ProblemHotlist#compiler.

[ryandesign (Ryan Carsten Schmidt)]

proposed patch

[ryandesign (Ryan Carsten Schmidt)]

Attached is a diff that updates the port to 2.1.1.0, updates the license (though I couldn't figure out if it's LGPL-3 or LGPL-3+), and fixes the livecheck. It builds for me on Snow Leopard with Xcode 3.2.6. You could try this and see if it now works with clang or whether it still needs an alternate compiler block added.

[mojca (Mojca Miklavec)]

Current port is broken for me. Also when I tested new version without changing compiler (basically the same patch, but using a different checksum and without livecheck directive) it didn't work on Lion. I didn't try this particular patch, but based on the other two observation I'm 99 % sure that it would not work.

[mojca (Mojca Miklavec)]

Please also note that geant4 9.5 already comes with clhep included. But I don't know if any users need a standalone version of clhep or not.

[ryandesign (Ryan Carsten Schmidt)]

According to the geant4 9.5 documentation, you can still use an external clhep if you want, so we could continue to have separate ports. Or, since geant4 is the only port I found that declares a dependency on clhep, we could make clhep replaced_by geant4 and just use the included version. Cristiano, what's your feeling about this?

[mojca (Mojca Miklavec)]

See also ​https://savannah.cern.ch/bugs/index.php?89603. It seems that CMake is now the preferred method of compilation. CLHEP now compiles fine, it only doesn't work with clang(++) compiler, but that is a minor issue. Default compiler works. Howevery I didn't try it together with geant4 since I'm not sure how to reliably create a cmake-based package. But at least all the patches can now go away.

[mojca (Mojca Miklavec)]

The following Portfile almost works for me:

PortSystem          1.0
PortGroup           cmake 1.0
name                clhep
version             2.1.1.0
revision            1
categories          science
maintainers         pd.infn.it:cristiano.fontana
license             public-domain
description         A Class Library for High Energy Physics
long_description    A Class Library for High Energy Physics
homepage            http://www.cern.ch/clhep
platforms           darwin
extract.suffix      .tgz
master_sites        http://proj-clhep.web.cern.ch/proj-clhep/DISTRIBUTION/tarFiles/

checksums           md5 f8acb50a9cdb9ac8937fecfcb741ba10

# a workaround for out-of-source build; below we need to specify '${workpath}/${version}/CLHEP' as source
worksrcdir          ${version}/build
post-extract { file mkdir ${worksrcpath} }

# https://savannah.cern.ch/bugs/?89603 
if {${configure.compiler} == "clang"} {
   configure.compiler llvm-gcc-4.2
}

configure.args-append -DCMAKE_BUILD_TYPE:STRING=Release \
                      ${workpath}/${version}/CLHEP

# for docs also add
# -Dbuild_docs:BOOL=ON

By almost I mean that something goes wrong at the very end of process. Building fails, but if I cd there manually, it builds until the end, but then again it doesn't stage.

[mojca (Mojca Miklavec)]

I'm not sure if I should open a new ticket or not, but in the meantime a new version of clhep has been released which fixes some bugs that prevented smooth compilation of 2.1.1.0 with clang. Here is a port that works fine for me:

PortSystem          1.0
PortGroup           cmake 1.0
name                clhep
version             2.1.2.0
revision            0
categories          science
maintainers         pd.infn.it:cristiano.fontana
license             public-domain
description         A Class Library for High Energy Physics
long_description    A Class Library for High Energy Physics
homepage            http://www.cern.ch/clhep
platforms           darwin
extract.suffix      .tgz
master_sites        http://proj-clhep.web.cern.ch/proj-clhep/DISTRIBUTION/tarFiles/

checksums           md5 05fcf105cb9839e24fee58b7fc2878bb

# a workaround for out-of-source build; below we need to specify '${workpath}/${version}/CLHEP' as source
worksrcdir          ${version}/build
post-extract { file mkdir ${worksrcpath} }

configure.args-append -DCMAKE_BUILD_TYPE:STRING=Release \
                      ${workpath}/${version}/CLHEP

There is also a possibly relevant option CLHEP_BUILD_DOCS that I didn't yet try out. Until the decision about dropping the package is made: can somebody please update the port?

There is one tiny bug in macports though (or my misunderstanding?), but I'm not sure where it comes from. The build system doesn't quite respect the site from where it should fetch the package:

> sudo port install clhep
--->  Computing dependencies for clhep
--->  Fetching archive for clhep
--->  Attempting to fetch clhep-2.1.2.0_0.darwin_11.x86_64.tbz2 from http://packages.macports.org/clhep
--->  Fetching clhep
--->  Attempting to fetch clhep-2.1.2.0.tgz from http://her.gr.distfiles.macports.org/mirrors/macports/mpdistfiles/clhep
--->  Attempting to fetch clhep-2.1.2.0.tgz from http://proj-clhep.web.cern.ch/proj-clhep/DISTRIBUTION/tarFiles/
--->  Attempting to fetch clhep-2.1.2.0.tgz from http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/clhep
--->  Attempting to fetch clhep-2.1.2.0.tgz from http://distfiles.macports.org/clhep
--->  Attempting to fetch clhep-2.1.2.0.tgz from http://aarnet.au.distfiles.macports.org/pub/macports/mpdistfiles/clhep
--->  Attempting to fetch clhep-2.1.2.0.tgz from http://jog.id.distfiles.macports.org/macports/mpdistfiles/clhep
--->  Attempting to fetch clhep-2.1.2.0.tgz from http://lil.fr.distfiles.macports.org/clhep
--->  Attempting to fetch clhep-2.1.2.0.tgz from http://sea.us.distfiles.macports.org/macports/mpdistfiles/clhep
--->  Attempting to fetch clhep-2.1.2.0.tgz from http://svn.macports.org/repository/macports/distfiles/clhep
Error: Target org.macports.fetch returned: fetch failed
Log for clhep is at: /opt/local/var/macports/logs/_Users_mojca_app_macports_mojca_science_clhep/clhep/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>

> sudo port install clhep
--->  Computing dependencies for clhep
--->  Fetching clhep
--->  Attempting to fetch clhep-2.1.2.0.tgz from http://lil.fr.distfiles.macports.org/clhep
--->  Attempting to fetch clhep-2.1.2.0.tgz from http://proj-clhep.web.cern.ch/proj-clhep/DISTRIBUTION/tarFiles/
--->  Verifying checksum(s) for clhep
--->  Extracting clhep
--->  Configuring clhep
--->  Building clhep
--->  Staging clhep into destroot
--->  Installing clhep @2.1.2.0_0
--->  Activating clhep @2.1.2.0_0
--->  Cleaning clhep

[mojca (Mojca Miklavec)]

Please also note the Release notes:

==============================
16.12.11 Release CLHEP-2.1.2.0
==============================
2011-12-15 Lynn Garren <garren@fnal.gov>
        * cmake is now the preferred build option
        * building with autotools and configure is deprecated
        * you MUST use cmake when building with clang and other exotic compilers
        * various improvements to the cmake build from Ben Morgan (Warwick)
        * to build documents, call cmake with -DCLHEP_BUILD_DOCS=ON
        * lib/CLHEP-<version> contains cmake files for use by find_package 
        * lib/pkgconfig contains clhep.pc  

Autotools are deprecated and not supported for patching any more.

The port that I posted above doesn't require any patches (as opposed to the version which is currently in MacPorts) which I find very important. Well, it would be nice of MacPorts if it allowed out-of-source builds with CMake. That would allow to avoid the dirty trick with

post-extract { file mkdir ${worksrcpath} }

But that's an independent issue - something for a new ticket.

[ryandesign (Ryan Carsten Schmidt)]

I've updated clhep to 2.1.2.0 in r88364. The configure patch may not have been necessary anymore, but the post-build removal of -arch flags from -config scripts still was, so I did not remove it. Note that the license has changed to LGPL-3. In the future please provide unified diffs of your proposed changes instead of complete Portfiles, and attach them as files instead of pasting them.