2537f26de6
Up unto here this code is only very rudiemantery tested. This is a firest attempt of making cpack more user-friendly. The basic idea is to generate a component for package type so that we can have different paths depending on whether we build an RPM, a DEB, a TGZ, or a MacOS installer. The cpack package config file will then chose the correct components to use. In a later point this should make it possible to build these with `make packages` and the ugly iteration with calling cmake between each package would be obsolete. While this solution is a bit more bloated, it is also much more flexible and it will be much easier to use. Another benefit is, that this will get rid of all warnings during a cpack run |
||
|---|---|---|
| .. | ||
| bindingtester | ||
| c | ||
| flow | ||
| go | ||
| java | ||
| python | ||
| ruby | ||
| CMakeLists.txt | ||
| __init__.py | ||