Mac OS X Frameworks Frameworks
Hi,
TL;DR
Do we want to do build KDE Frameworks as Mac OS X Frameworks?
Long Story:
on Mac OS X, libraries are typically deployed as Frameworks (e.g. a
directory containing the shared library, headers, resources and meta
data). A framework can be simply draggeddropped to Xcode projects and
it's also easier from command line:
clang++ -framework KF5Archive -framework QtCore main.cpp
(Assuming that Qt and KF5Archive are in a standard Framework path,
otherwise, add -F /path/to/framework).
I tried to create an OS X Framework out of KArchive and ended up with
attached patch (see also https://git.reviewboard.kde.org/r/115977/)
What needs to happen on KF5 side?
1) All public headers must be added as source files (e.g. to
add_library()) and set as PUBLIC_HEADER property on the target. Instead
of a manual install rule, we need to set PUBLIC_HEADER DESTINATION to
the install TARGETS rule.
2) Public (installed) headers must use
#include myOtherHeader // (double quotes)
to include headers belonging to the same framework
3) Public headers must use
#include KF5Whatever/foo.h
to include headers belonging to other frameworks
Is that worth the hassle? If yes, I can try to convert some of our libs
to OS X frameworks, hoping not to break things for other platforms ;)
Harald
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f5dc644..0c59012 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -53,6 +53,8 @@ ecm_setup_version(${KF5_VERSION}
PACKAGE_VERSION_FILE
${CMAKE_CURRENT_BINARY_DIR}/KF5ArchiveConfigVersion.cmake
)
+list(APPEND KArchive_GENERATED_HEADERS
${CMAKE_CURRENT_BINARY_DIR}/karchive_version.h)
+
add_subdirectory(src)
add_subdirectory(autotests)
add_subdirectory(tests)
@@ -69,10 +71,6 @@ ecm_configure_package_config_file(
INSTALL_DESTINATION ${CMAKECONFIG_INSTALL_DIR}
)
-install(FILES ${CMAKE_CURRENT_BINARY_DIR}/karchive_version.h
-DESTINATION ${INCLUDE_INSTALL_DIR}
-COMPONENT Devel)
-
install(FILES
${CMAKE_CURRENT_BINARY_DIR}/KF5ArchiveConfig.cmake
${CMAKE_CURRENT_BINARY_DIR}/KF5ArchiveConfigVersion.cmake
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 53e9728..2eaa05f 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -34,7 +34,27 @@ set(karchive_SRCS
kzip.cpp
)
-add_library(KF5Archive ${karchive_SRCS} ${karchive_OPTIONAL_SRCS})
+ecm_generate_headers(KArchive_HEADERS
+HEADER_NAMES
+KArchive
+KArchiveEntry
+KArchiveFile
+KArchiveDirectory
+KAr
+KCompressionDevice
+KFilterBase
+KFilterDev
+KTar
+KZip
+KZipFileEntry
+
+REQUIRED_HEADERS KArchive_HEADERS
+)
+
+list(APPEND KArchive_GENERATED_HEADERS
${CMAKE_CURRENT_BINARY_DIR}/karchive_export.h)
+
+add_library(KF5Archive ${karchive_SRCS} ${karchive_OPTIONAL_SRCS}
${KArchive_HEADERS} ${KArchive_GENERATED_HEADERS})
+set_target_properties(KF5Archive PROPERTIES FRAMEWORK TRUE)
generate_export_header(KF5Archive BASE_NAME KArchive)
add_library(KF5::Archive ALIAS KF5Archive)
@@ -56,25 +76,12 @@ set_target_properties(KF5Archive PROPERTIES
EXPORT_NAME Archive
)
-ecm_generate_headers(KArchive_HEADERS
-HEADER_NAMES
-KArchive
-KArchiveEntry
-KArchiveFile
-KArchiveDirectory
-KAr
-KCompressionDevice
-KFilterBase
-KFilterDev
-KTar
-KZip
-KZipFileEntry
-
-REQUIRED_HEADERS KArchive_HEADERS
-)
+set_target_properties(KF5Archive PROPERTIES PUBLIC_HEADER
${KArchive_HEADERS};${KArchive_GENERATED_HEADERS})
install(TARGETS KF5Archive
EXPORT KF5ArchiveTargets
+FRAMEWORK DESTINATION ${LIB_INSTALL_DIR}
+PUBLIC_HEADER DESTINATION ${INCLUDE_INSTALL_DIR}/KArchive
${INSTALL_TARGETS_DEFAULT_ARGS})
if(LIBLZMA_FOUND)
@@ -85,12 +92,6 @@ if(LIBLZMA_FOUND)
)
endif()
-install(FILES
-${CMAKE_CURRENT_BINARY_DIR}/karchive_export.h
-${KArchive_HEADERS}
-DESTINATION ${INCLUDE_INSTALL_DIR}/KArchive
-COMPONENT Devel)
-
include(ECMGeneratePriFile)
ecm_generate_pri_file(
BASE_NAME KArchive
diff --git a/src/karchive.h b/src/karchive.h
index d4209cf..a75d240 100644
--- a/src/karchive.h
+++ b/src/karchive.h
@@ -29,7 +29,7 @@
#include QtCore/QStringList
#include QtCore/QHash
-#include karchive_export.h
+#include karchive_export.h
#ifdef Q_OS_WIN
#include qplatformdefs.h // mode_t
diff --git a/src/karchivedirectory.h b/src/karchivedirectory.h
index 60225d0..d234fc8 100644
--- a/src/karchivedirectory.h
+++ b/src/karchivedirectory.h
@@ -28,7 +28,7 @@
#include QtCore/QString
#include QtCore/QStringList
-#include karchiveentry.h
+#include karchiveentry.h
class KArchiveDirectoryPrivate;
/**
diff --git a/src/karchiveentry.h b/src/karchiveentry.h
index aad6840..d5c68a9 100644
--- a/src/karchiveentry.h
+++ b/src/karchiveentry.h
@@ -24,7 +24,7 @@
#include sys/stat.h
#include sys/types.h
-#include karchive_export.h
+#include karchive_export.h
#ifdef Q_OS_WIN
#include qplatformdefs.h //
Re: Mac OS X Frameworks Frameworks
On 23 February 2014 20:15, Harald Fernengel har...@gmx.com wrote: TL;DR Do we want to do build KDE Frameworks as Mac OS X Frameworks? I think so, at least for the ones we want to be viewed as proper Qt Add-ons, it would enlarge our possible user-base. From experience in Qt the hard part is keeping the includes conforming, the rules would have to be well advertised and put in the coding standards. We really need a CI machine testing the build on OSX to make sure people don't keep breaking it. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Mac OS X Frameworks Frameworks
On 23 February 2014 20:15, Harald Fernengel har...@gmx.com wrote: Hi, TL;DR Do we want to do build KDE Frameworks as Mac OS X Frameworks? I think so, at least for the ones we want to be viewed as proper Qt Add-ons, it would enlarge our possible user-base. From experience in Qt the hard part is keeping the includes conforming, the rules would have to be well advertised and put in the coding standards. We really need a CI machine testing the build on OSX to make sure people don't keep breaking it. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Mac OS X Frameworks Frameworks
On Sun, Feb 23, 2014 at 8:15 PM, Harald Fernengel har...@gmx.com wrote: Hi, TL;DR Do we want to do build KDE Frameworks as Mac OS X Frameworks? Long Story: on Mac OS X, libraries are typically deployed as Frameworks (e.g. a directory containing the shared library, headers, resources and meta data). A framework can be simply draggeddropped to Xcode projects and it's also easier from command line: clang++ -framework KF5Archive -framework QtCore main.cpp (Assuming that Qt and KF5Archive are in a standard Framework path, otherwise, add -F /path/to/framework). I tried to create an OS X Framework out of KArchive and ended up with attached patch (see also https://git.reviewboard.kde.org/r/115977/) What needs to happen on KF5 side? 1) All public headers must be added as source files (e.g. to add_library()) and set as PUBLIC_HEADER property on the target. Instead of a manual install rule, we need to set PUBLIC_HEADER DESTINATION to the install TARGETS rule. 2) Public (installed) headers must use #include myOtherHeader // (double quotes) to include headers belonging to the same framework 3) Public headers must use #include KF5Whatever/foo.h to include headers belonging to other frameworks Is that worth the hassle? If yes, I can try to convert some of our libs to OS X frameworks, hoping not to break things for other platforms ;) Harald ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi, I would say that we should follow however it's done in Qt. So far we've been trying to provide as much of a similar experience as if it was another Qt module. Doing so here as well could be interesting too. The changes you propose make sense too, even on a linux system (although I'm unaware of how this PUBLIC_HEADER property works), so I wouldn't have a big problem to adopt them. What scares me the most is that things will break over time from people only testing on Linux, though. This could become frustrating, but also a huge step forward for the project. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Mac OS X Frameworks Frameworks
Hello, On Monday 24 February 2014 02:49:45 Aleix Pol wrote: I would say that we should follow however it's done in Qt. So far we've been trying to provide as much of a similar experience as if it was another Qt module. Doing so here as well could be interesting too. The changes you propose make sense too, even on a linux system (although I'm unaware of how this PUBLIC_HEADER property works), so I wouldn't have a big problem to adopt them. I agree with all the above. What scares me the most is that things will break over time from people only testing on Linux, though. This could become frustrating, but also a huge step forward for the project. Not a good reason to not do it though. At the end of the day we'll need the CI to provide windows and mac builds somehow... until then yes it'll be more painful than necessary on those platforms. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
