Package Details: clhep 2.4.1.0-2

Git Clone URL: https://aur.archlinux.org/clhep.git (read-only)
Package Base: clhep
Description: A Class library for High Energy Physics
Upstream URL: http://proj-clhep.web.cern.ch/
Licenses: GPL3
Submitter: JuliaRhea
Maintainer: donpicoro
Last Packager: donpicoro
Votes: 8
Popularity: 0.000000
First Submitted: 2007-10-17 17:47
Last Updated: 2018-11-23 10:23

Pinned Comments

donpicoro commented on 2018-11-23 10:55

NOTE to users compiling geant4 with the option GEANT4_USE_SYSTEM_CLHEP=ON:

The geant4 checks for clhep will fail as they will look for the static libraries which are removed by default.

To avoid the removal of clhep libraries needed by geant4 for its check make sure to add staticlibs to the options array.

Latest Comments

1 2 3 Next › Last »

donpicoro commented on 2018-11-23 10:55

NOTE to users compiling geant4 with the option GEANT4_USE_SYSTEM_CLHEP=ON:

The geant4 checks for clhep will fail as they will look for the static libraries which are removed by default.

To avoid the removal of clhep libraries needed by geant4 for its check make sure to add staticlibs to the options array.

Eothred commented on 2018-11-23 10:51

I know how to manually modify the packages for me, so for me any solution is ok. Just thought I should share the findings..

My thought is that clhep is a library, and provides a script which helps other software link to it. And these scripts look for files that makepkg is currently removing (which may be fair enough, static linking is a boo in my mind). So I think there should be a patch on clhep side to remove the static library part of these cmake checks. Maybe one could even send a patch upstream to have an option to only build dynamic libraries in the first place.

donpicoro commented on 2018-11-23 10:48

@Eothred: OK, I get it now. But would you agree that the packages as such should not be modified?

We should keep a "pinned comment" regarding this at both geant4 and clhep packages mentioning this for those users like you. Would this be an OK way to go for you? Thoughts?

Eothred commented on 2018-11-23 10:36

You can try to build geant4 with the option GEANT4_USE_SYSTEM_CLHEP on, and you should get the same error.

The cmake scripts provided by clhep for other software to link to clhep, includes checks to confirm that all "required files" are present. While I'd argue that the static libraries shouldn't be needed (by default), it looks for example for the CLHEP::VectorS which is the static Vector library. See README.md where this is mentioned.

donpicoro commented on 2018-11-23 10:30

Hello @Eothred,

I'm not sure I understand which check is failing for you. When I compile CLHEP by itself all the 44 tests pass without a hitch. Or perhaps you mean Geant4 check? (if so, which one? I am not aware of a check).

/Pico

Eothred commented on 2018-11-23 09:35

This took me a short while to realise. I tried to build geant4 linking to this package, but the cmake configuration failed.

In the end, I figured out that the cmake "checks" looks for the static libraries, which makepkg by default removes. I think for this package it would be correct to add "staticlibs" to the options array.

Maybe there is a patch one could apply to have cmake not look for the static libraries instead, but I don't know how to fix this.

donpicoro commented on 2016-05-28 14:24

Updated to 2.3.2.2 ;-)

parnmatt commented on 2015-09-22 15:23

Cheers @donpicoro, I can confirm that this now successfully builds, utilising all 8 of my cores.

Thanks for the swift response and fix.

donpicoro commented on 2015-09-22 14:17

Hi, parnmatt

I can't remember why I used the "-j1". I had troubles at some point and I can remember where/when was it. So now it's removed.

The compilation of the documentations seems like it is a no go. I found this
https://www.tug.org/pipermail/tex-live/2015-June/037019.html
which seems like the proper explanation for it.

Cheers and let me know if you have any more comments.

/Pico

parnmatt commented on 2015-09-22 13:28

…Also, is there any particular reason the PKGBUILD has a hard coded -j1 for making, rather than letting our makepkg.conf take care of it?
Does CLHEP have to be compiled on a single core?