Re: [CMake] Comaptibility with older gcc
> C++ code is not compatible between different compilers. This is only kinda-sorta true. Clang and G++ interoperate quite nicely on Linux, for instance, since they both implement the Itanium-style ABI. I believe Intel's C++ compiler on Windows implements the same ABI as MSVC++. There are no guarantees of compatibility between different compilers, but it's a little much to say there is no compatibility. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Bundling for OS X
(Full source is available at https://github.com/rjhansen/sherpa )
I have a Qt 5.7 application which I'm trying to migrate from qmake to
cmake 3.7. So far it almost works on OS X, except when it comes to
making a proper app bundle.
The relevant contents of my CMakeLists.txt are as follows:
=
install(DIRECTORY "${QT_PLUGINS_DIR}/imageformats" DESTINATION
${plugin_dest_dir}/plugins COMPONENT Runtime)
install(CODE "
file(WRITE \"\${CMAKE_INSTALL_PREFIX}/${qtconf_dest_dir}/qt.conf\" \"\")
" COMPONENT Runtime)
set(DIRS ${QT_LIBRARY_DIRS})
install(CODE "
file(GLOB_RECURSE QTPLUGINS
\"\${CMAKE_INSTALL_PREFIX}/${plugin_dest_dir}/plugins/*${CMAKE_SHARED_LIBRARY_SUFFIX}\")
include(BundleUtilities)
fixup_bundle(\"${APPS}\" \"\${QTPLUGINS}\" \"${DIRS}\")
" COMPONENT Runtime)
# To Create a package, one can run "cpack -G DragNDrop
CPackConfig.cmake" on Mac OS X
# where CPackConfig.cmake is created by including CPack
# And then there's ways to customize this as well
set(CPACK_BINARY_DRAGNDROP ON)
include(CPack)
=
Some of this was taken from CMake's example Qt4/OS X application, but
Qt5 changed enough that the Qt4 example doesn't quite work. Although it
creates an app bundle, the linkage points all over the map:
=
quorra:Sherpa rjh$ otool -L Sherpa.app/Contents/MacOS/Sherpa
Sherpa.app/Contents/MacOS/Sherpa:
@rpath/QtWidgets.framework/Versions/5/QtWidgets (compatibility version
5.7.0, current version 5.7.0)
/usr/local/lib/libgpgme.11.dylib (compatibility version 29.0.0, current
version 29.0.0)
/usr/local/lib/libassuan.0.dylib (compatibility version 8.0.0, current
version 8.3.0)
/usr/local/opt/libgpg-error/lib/libgpg-error.0.dylib (compatibility
version 22.0.0, current version 22.0.0)
/usr/local/opt/minizip/lib/libminizip.1.dylib (compatibility version
2.0.0, current version 2.0.0)
@rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.7.0,
current version 5.7.0)
@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.7.0,
current version 5.7.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
307.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1238.0.0)
=
Qt comes with a tool, macdeployqt, which seems to mangle the app bundle
beyond reason:
=
quorra:Sherpa rjh$ ~/Qt5.7.0/5.7/clang_64/bin/macdeployqt Sherpa.app
quorra:Sherpa rjh$ open Sherpa.app
LSOpenURLsWithRole() failed with error -10810 for the file
/Users/rjh/Projects/Sherpa/Sherpa.app.
=
Although macdeployqt *appears* to copy and relink things correctly,
invoking the binary directly yields the problem: "dyld: initializer
function 0x1082cfbd5 not in mapped image for
/usr/local/lib/libgpg-error.0.dylib" -- whatever that means.
tl;dr -- How can I copy my libraries (GPGME_LIBRARY, ASSUAN_LIBRARY,
GPGERR_LIBRARY, MINIZIP_LIBRARY, as well as QtWidgets, QtCore, and
QtGui) into the bundle and run install_name_tool to correctly relink the
application to the in-bundle libs?
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CPack: avoid creating unnecessary man dirs
> Use `|CPACK_RPM_EXCLUDE_FROM_AUTO_FILELIST_ADDITION` to add a man's dir
> to 'exclude' list, so RPM package wouldn't have a dir, but files from
> it... so it wouldn't conflict w/ `filesystem` package.
Thank you; that solved one problem and exposed another.
In my old Autotools build, I used preprocessor defines to set at
compile-time where the binary should look for its data files. In my
top-level CMakeLists.txt I set a CMake variable as:
set(PKGDATADIR ${CMAKE_INSTALL_FULL_DATADIR}/nsrlsvr)
And in src/CMakeLists.txt I set the preprocessor define:
add_definitions(-DPKGDATADIR="${PKGDATADIR}")
When I build the RPM and install it, though, something weird happens:
[rjh@localhost nsrlsvr]$ /usr/bin/nsrlsvr --help
nsrlsvr options:
... (output omitted) ...
-f [ --file ] arg (=/usr/local/share/nsrlsvr/hashes.txt)
hash file
The default argument for -f is not /usr/share/nsrlsvr/hashes.txt, as it
should be for an RPM, but /usr/local/share/nsrlsvr/hashes.txt, as if it
were a locally-compiled package.
My first thought was that I should replace CMAKE_INSTALL_FULL_DATADIR
with CMAKE_INSTALL_DATADIR, but that was also less than useful:
nsrlsvr options:
... (output omitted) ...
-f [ --file ] arg (=share/nsrlsvr/hashes.txt)
hash file
How can I fix this?
("Have your code use a relative offset from where the binary is located"
is an acceptable answer; I'm hoping there's a better one, though!)
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] CPack: avoid creating unnecessary man dirs
I'm migrating a project from Autotools to CMake. So far it's been a
good experience save for installing manpages.
I'm using include(GNUInstallDirs) to help make the migration easier. In
my manpage subdir I have the following CMakeLists.txt:
set(MAN_NAMES nsrlsvr.1 nsrlupdate.1)
add_custom_target(man ALL DEPENDS ${MAN_NAMES})
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/nsrlsvr.1 DESTINATION
${CMAKE_INSTALL_MANDIR}/man1/)
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/nsrlupdate.1 DESTINATION
${CMAKE_INSTALL_MANDIR}/man1/)
This seems to work just fine for a "make install", and it successfully
generates RPMs with a "make package". However, those RPMs are
uninstallable on a Fedora system:
Error: Transaction check error:
file /usr/share/man from install of nsrlsvr-1.6.1-1.x86_64 conflicts
with file from package filesystem-3.2-37.fc24.x86_64
file /usr/share/man/man1 from install of nsrlsvr-1.6.1-1.x86_64
conflicts with file from package filesystem-3.2-37.fc24.x86_64
Apparently, CMake is trying to create dirs even if they already exist.
Is there any way to suppress this? What's the best way to address this?
(The full source tree, along with all the CMakeLists.txt files, is
available at https://github.com/rjhansen/nsrlsvr/ )
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Documentation strategy
I am; note the subject line. That is not enough to make me talk about it. My concern is not what you call a 'documentation strategy'. I think that's tail chasing, mostly. My concern is what I see as a tendency towards overbroad generalizations on your part. It's long and run-on but properly constructed. Is English not your 1st language? Note the implicit then, i.e. [then] there are lotsa extra barriers. When told that one is being unclear, it's usually better make things clear than to argue you're being perfectly clear. Also, run-on sentence construction is considered a grammatical error, which means that it's not properly constructed. The projects that see CMake as a slam dunk, are the ones that did an Autoconf build for the Unix stuff, and also had to maintain some horrible hand rolled Visual Studio build, typically with .BAT files. No, when you are definitely planning to port to Windows, and picking tools on that basis, you are not doing a Unix-only project anymore. You are at the planning stage of a cross-platform project. Please compare what you said, which I said was overly broad, with what you are now saying, which is substantially different. I have said what I intended to say, and for that reason I think I'm finished here. Please stop being overly broad; it just undercuts what you're trying to argue. -- Robert J. Hansen [EMAIL PROTECTED] Most people are never thought about after they're gone. 'I wonder where Rob got the plutonium?' is better than most get. -- Phil Munson ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Documentation strategy
Brandon Van Every wrote: They aren't going to buy a book to do an evaluation. They often will. I can shell out $40, wait a few days for it to arrive and get other paying work done in the meantime, then have enough data on hand to evaluate CMake properly in just the space of a few hours... or I can spend a few days discovering CMake through trial and error and not doing anything to improve the bottom line. In my case, the CMake book more than paid for itself. I cannot imagine that I am the only person who is in such a situation. A flaw in the analogy: everyone hates and wants to dump CVS. Everyone is strong language here. I prefer Subversion, but I know others who prefer CVS and have their own reasons for it. In contrast, the Unix-only crowd doesn't have much reason to drop Autoconf / Automake. I know many UNIX-only users who share my loathing of Autotools. Autotools tends to get used mostly for sake of its install base and for the perceived lack of other alternatives, not because people actually like Autotools. (Which some do, of course; but it appears to me they are a minority.) The projects that see CMake as a slam dunk, are the ones that did an Autoconf build for the Unix stuff, and also had to maintain some horrible hand rolled Visual Studio build, typically with .BAT files. At the time KDE converted to CMake it was a UNIX-only project, and they considered CMake to be a slam dunk. I consider CMake to be a win for my own UNIX-only projects, albeit not a slam dunk. (I'm not a CMake partisan so much as an anything but Autotools partisan.) I don't mean to be argumentative here, but it appears you're arguing far too broadly. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Documentation strategy
Brandon Van Every wrote: Also, students and other sorts of open source cheapskates do not buy books. As a graduate student who knows a lot of other students (both graduate and undergraduate), I can't accept this claim. Between me and my officemates, we probably have upwards of $5k in books we've purchased with our own money on the office bookshelf. Admittedly, the purchasing habits of graduate students may be different from the purchasing habits of undergraduates, but even the undergraduates in the department tend to buy books fairly frequently. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
