Switch Charm Time Tracker to Qt5 build and take maintainership
Details
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 11759 Build 12103: arc lint + arc unit
Event Timeline
Adding linimon@ , for the change in powerpc64. I imagine adding compiler:c++-11-lib and dropping the homebrew setting of compiler flags is enough to unbreak on PPC, but I have no hardware to tell.
deskutils/charmtimetracker/Makefile | ||
---|---|---|
18 | ^ = instead of += |
deskutils/charmtimetracker/files/patch-CMakeLists.txt | ||
---|---|---|
7 | why not look for qtkeychain? |
deskutils/charmtimetracker/Makefile | ||
---|---|---|
17–18 | ^you could switch this to cmake:outsource |
deskutils/charmtimetracker/Makefile | ||
---|---|---|
18 | also, I think there is no CHARM_FORCE_QT5 only a CHARM_FORCE_QT4 -- so you can get rid of that, I guess. CMakeLists.txt:OPTION( CHARM_FORCE_QT4 "Force building Charm with Qt4" OFF ) |
deskutils/charmtimetracker/Makefile | ||
---|---|---|
23–24 | But you cannot use PORTDOCS if you do not have a DOCS option. |
deskutils/charmtimetracker/Makefile | ||
---|---|---|
23–24 | Only the PORTDOCS, so I'll add this to the pkg-plist instead. | |
deskutils/charmtimetracker/files/patch-CMakeLists.txt | ||
7 | Trying to be predictable: there's no option to switch keychain-checking on or off, so if you have keychain (accidentally) installed, it will link to that. So instead, turn off the feature entirely, so that sloppy builds will still match what packages would produce. |
Brain fart: since LICENSE_FILE is set, the license is already installed
by ports infrastructure, so patch it out of the CMakeLists again.
deskutils/charmtimetracker/files/patch-CMakeLists.txt | ||
---|---|---|
7 | Why not simply depend on security/qtkeychain-qt5? -- or add an option() to cmake to toggle support for it... or even simpler as it is a find_package(FooBar) call you can toggle it via CMAKE_DISABLE_FIND_PACKAGE_FooBar [1]. |
Disabled though a simpler mechanism suggested by tcberner@ . The keychain is used only if tasks are imported from an external file, which then communicates with lotsofcake.kdab.com ; unless you are a KDAB employee using this port, this is unlikely to be relevant. Note that git master now requires keychain, and still connects to internal KDAB systems. That's a bridge we'll cross when we get to it.