Project

General

Profile

Bug #423

no CPack support

Added by Rossen Apostolov over 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Erik Lindahl
Category:
mdrun
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

It will be very nice to have CPack support for packaging.


Related issues

Blocked by GROMACS - Bug #570: CMake binaries with shared libs won't run correctly without installing (Ubuntu CMake 2.6.2)Closed09/21/2010

History

#1 Updated by Szilárd Páll about 9 years ago

(In reply to comment #0)

It will be very nice to have CPack support for packaging.

AFAIK this has been implemented, just not sure it's properly tested. There is one issue, bug #570 which is related. I'm adding it to the dependencies.

Could you someone (Erik?) give an update on this?

#2 Updated by Erik Lindahl about 9 years ago

CPack support has been implemented, and I've tested it to work on Mac, Ubuntu, and Redhat. There might still be specific bugs on some systems, but it's probably better to take those in separate specific bugzillas!

#3 Updated by Szilárd Páll about 9 years ago

(In reply to comment #2)

CPack support has been implemented, and I've tested it to work on Mac, Ubuntu,
and Redhat. There might still be specific bugs on some systems, but it's
probably better to take those in separate specific bugzillas!

Bug #570 seems to be caused by some CPack related stuff - as suggested by Teemu. Any idea if that rpath trick is really needed?

#4 Updated by Erik Lindahl about 9 years ago

It is - otherwise dynamic libs won't work both on Mac & Linux, but there might be a better way to do it, of course. Still, given the choice between having packages that work versus developers being able to run dynamic builds without installing I'd go with the former for now!

#5 Updated by Teemu Murtola about 9 years ago

(In reply to comment #4)

It is - otherwise dynamic libs won't work both on Mac & Linux, but there might
be a better way to do it, of course. Still, given the choice between having
packages that work versus developers being able to run dynamic builds without
installing I'd go with the former for now!

The main problem is that with the current setup, CTest doesn't work with shared libraries: if you add some tests and run 'make test', all tests will fail instantly because the binaries cannot be executed. This should really be solved if we ever want to have a proper test suite! For unit tests, this can be worked around because the unit test binaries won't be installed, but will require extra CMake code. There's no easy workaround for regression tests for, e.g., mdrun.

If CPack really cannot create binary packages properly without breaking CTest, I would still argue that we should file a bug against CPack.

Also available in: Atom PDF