Re: [CMake] How to link in different prebuilt objects based on configuration
I did eventually find a solution where I set up an imported target with IMPORTED_LOCATION and IMPORTED_LOCATION_DEBUG properties pointing to the object files, and then linked in that target with target_link_libraries(). I admit I wasn't completely sure if adding .obj/.o files to the link lines in this way would be well supported, though it did seem to work OK in practice in the generators I tested to cover what our customers and build systems use (Visual Studio, NMake Makefiles [JOM], Unix Makefiles for the Linux build, and Ninja on Linux). -- Daniel From: Robert Maynard [robert.mayn...@kitware.com] Sent: Tuesday, December 18, 2018 11:08 AM To: Daniel Schepler Cc: CMake MailingList Subject: Re: [CMake] How to link in different prebuilt objects based on configuration As far as I know this is a limitation of the MSVC project files, and CMake errors out on that generator rather than try and build an invalid project. Have you tried do something where you have the Config and Release objects as separate targets that always exist, but selectively conditionally to them based on the Config setting? On Thu, Dec 13, 2018 at 2:16 PM Daniel Schepler wrote: > > We have a build here where a large portion of our product is in source code > available to customers, but then there is a core which we only distribute as > prebuilt "private objects". However, then when we test the customer-type > build on Windows, we get an error like: > > --- > CMake Error in CMakeLists.txt: > Target "exata" has source files which vary by configuration. This is not > supported by the "Visual Studio 15 2017 Win64" generator. > > Config "Debug": > > E:/EXata_7_0/qualnet_dev_13_Dec18/kernel/obj/exata-main-windows-x64-vc14d.obj > > Config "Release": > > E:/EXata_7_0/qualnet_dev_13_Dec18/kernel/obj/exata-main-windows-x64-vc14.obj > --- > > (This object file is marked with source file property EXTERNAL_OBJECT=1.) > > Is this a limitation in Visual Studio projects, or a limitation in CMake? In > either case, what workaround could allow this build to support generating > Visual Studio projects? > -- > Daniel Schepler > -- > > 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: > https://cmake.org/mailman/listinfo/cmake -- 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: https://cmake.org/mailman/listinfo/cmake
[CMake] How to link in different prebuilt objects based on configuration
We have a build here where a large portion of our product is in source code available to customers, but then there is a core which we only distribute as prebuilt "private objects". However, then when we test the customer-type build on Windows, we get an error like: --- CMake Error in CMakeLists.txt: Target "exata" has source files which vary by configuration. This is not supported by the "Visual Studio 15 2017 Win64" generator. Config "Debug": E:/EXata_7_0/qualnet_dev_13_Dec18/kernel/obj/exata-main-windows-x64-vc14d.obj Config "Release": E:/EXata_7_0/qualnet_dev_13_Dec18/kernel/obj/exata-main-windows-x64-vc14.obj --- (This object file is marked with source file property EXTERNAL_OBJECT=1.) Is this a limitation in Visual Studio projects, or a limitation in CMake? In either case, what workaround could allow this build to support generating Visual Studio projects? -- Daniel Schepler -- 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: https://cmake.org/mailman/listinfo/cmake
Re: [CMake] Copying Shared Libraries (DLLs) Next to the Executable
Personally, I find it much simpler just to expect the Path to include the
locations of the DLL files as opposed to copying them. (And I often write
small batch scripts to set up this development environment, and then optionally
start cmake-gui.exe / devenv.exe / etc.)
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Marek Vojtko (Firaxis)
[marek.voj...@firaxis.com]
Sent: Wednesday, February 21, 2018 7:20 PM
To: cmake@cmake.org
Subject: [CMake] Copying Shared Libraries (DLLs) Next to the Executable
Hi,
I need to copy external shared libraries (DLLs on Windows) next to the
generated executable. Is calling "cmake -E copy_if_different" through a custom
command added to the executable target still the best way to achieve this?
CMake tracks include directories, compile definitions or options, link flags,
etc. through its dependency system, but it doesn't provide an easy way to list
/ copy all shared libraries a target depends on?
I am trying to follow the "new" CMake paradigms, using add_subdirectory(),
set_target*() with PUBLIC/PRIVATE/INTERFACE scope, etc. to create a modular,
re-usable setup, but that actively prevents me from using a custom command on
the executable target. To wit:
App depends on Lib. Lib depends on several third-party, pre-built DLLs and
encapsulates the logic of when to depend on them. The third-party, pre-built
shared libraries (DLLs) are located through custom Find*.cmake modules and used
as IMPORTED targets.
/CMakelists.txt
/App
/CMakelists.txt
/Lib
/CMakelists.txt
/CMakelists.txt
*
set(CMAKE_MODULE_PATH "")
project("DLLTest")
add_subdirectory("${CMAKE_CURRENT_SOURCE_DIR}/Lib")
add_subdirectory("${CMAKE_CURRENT_SOURCE_DIR}/App")
/App/CMakelists.txt
*
add_executable(App WIN32 main.cpp)
target_link_libraries(App PRIVATE Lib)
/Lib/CMakelists.txt
add_library(Lib STATIC lib.h lib.cpp)
target_include_directories(Lib PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}")
if(Lib_NEEDS_DEPENDENCY)
find_package(Dependency REQUIRED)
target_link_libraries(Lib PUBLIC Dependency::Dependency)
endif()
FindDependency.cmake
[snip]
add_library(Dependency::Dependency SHARED IMPORTED)
set_target_properties(Dependency::Dependency PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "inc"
IMPORTED_IMPLIB "dependency.lib"
IMPORTED_LOCATION "dependency.dll"
)
In this setup, it is impossible to propagate a shared library (DLL) from Lib to
App. This is because Lib and App have different BINARY_DIRs and Lib must create
its target before App calls target_link_libraries(). That means that Lib does
not know where App will generate its executable. If Lib is a SHARED target, I
cannot set its RUNTIME_OUTPUT_DIRECTORY to be the same as App's. If Lib depends
on IMPORTED targets (as is my case), I cannot create either a file(COPY) step,
or an install(FILES) step, or even an add_custom_command() step in Lib to copy
the shared library, because I don't know the destination.
The only solution, it would seem, is to add a custom command to App's target,
because then I know where to copy the shared libraries to. But that means that
App now has to know it needs to copy a shared library from a "hidden"
dependency of Lib. App also needs to know about every SHARED or IMPORTED target
Lib depends on, not to mention duplicate the logic in Lib's CMakelists.txt that
decided whether Lib depends on Dependency in the first place.
I was looking into GetPrerequisites and FixupBundle, but both of those operate
on an already existing executable and try to guess what shared libraries (DLLs)
it might need. It feels silly to guess at something that CMake already knows
(as the IMPORTED target sets the IMPORTED_IMPLIB and IMPORTED_LOCATION
properties).
Setting a common CMAKE_RUNTIME_OUTPUT_DIRECTORY for both App and Lib is
problematic if I have multiple executables in my root CMakelists.txt and they
depend on different versions of the shared libraries or I have other name
clashes.
Is there no automated way to get the list of shared libraries a target depends
on?
Thanks,
Marek
--
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:
https://cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topi
Re: [CMake] CMake fixup_bundle for ubuntu 16.04
You would need to set the INSTALL_RPATH property of the targets to something
like "$ORIGIN/../lib" .
You might also need to add "-Wl,--disable-new-dtags" to the CMAKE_*_LINK_FLAGS
variables - otherwise, the RPATH settings will only take effect for direct
dependencies of the executables (and any plugins or shared libraries) you build
but not for dependencies of these dependencies.
(We also tend not to include copies of glibc or OpenGL libraries - for the
former, that tends to have issues if there are any mismatches between the exact
build of glibc included in the installer and the NSS modules from the system.
For the latter, the OpenGL libraries vary too much between Mesa and the NVidia
and AMD proprietary driver versions for any one of them to work on all systems.)
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Waldo Valenzuela via CMake
[cmake@cmake.org]
Sent: Wednesday, December 13, 2017 11:15 AM
To: Miklos Espak
Cc: cmake@cmake.org
Subject: Re: [CMake] CMake fixup_bundle for ubuntu 16.04
Dear Miklos,
thanks for the email, and your suggestions, but the problem with fixup_bundle
in ubuntu is that is not fixing the libraries locations from the executables
meaning:
if I execute the idd command like this “ idd ./app” where “app” is the
executable, the locations of the library is still is “no found", that should be
in the location that was copy after running the INSTALL.
when you set LD_LIBRARY_PATH is for a temporally solution, or permanent if I
modified the environment configuration of O.S.. The idea is that I want to
create a standalone application.
Under this scenario, if I have an executable called “app” and a shared library
call “lib.so”, fixup_bundle should fix the location of the “lib.so” in the same
folder where is “app”.
Then if I run the command "idd ./app” the output should be:
lib.so => “”, where is folder where is located “app"
Cheers,
Waldo.
On 13 Dec 2017, at 03:58, Miklos Espak
<esp...@gmail.com<mailto:esp...@gmail.com>> wrote:
Hi,
you need to add the directory where the Qt libs have been installed (along with
your application binaries) to the LD_LIBRARY_PATH. In your case it is
'/home/waldo/Developer/install/Release/bratumia/bin/', as I see.
Also, you do *not* need to add the Qt plugin directories to the library path.
The plugins are loaded at run-time. So that they can be found, you need to
install a qt.conf file in the bin directory with the following contents:
[Paths]
Prefix=.
You also do *not* need to add "/usr/lib" and "/usr/lib/x86-..." to the library
path. These libraries are searched for by default. If you did it because your
Qt installation is there, that's wrong. The fixup_bundle function should have
copied the necessary Qt libs in the install bin folder, so you just need to add
that folder to the path.
Also, make sure that the DIRS variable contains all the directories where there
are libraries to install, including dependencies.
I hope that helps.
Best regards,
Miklos
On 11 December 2017 at 19:07, Waldo Valenzuela via CMake
<cmake@cmake.org<mailto:cmake@cmake.org>> wrote:
Dear All,
I am working on a multi-platform desktop app with Qt5-VTK8, on Windows and Mac
no problem to created the standalone app, but in Ubuntu 16.04 I have several
problems.
I am using CodeBlocks to compile and run the app, and from CodeBlocks when I
run the app there is no problem, it work normally like in windows and mac, but
after run the installation, and If I want to run the app from the installation
folder (./app ) I have several problems.
the CMakeList.txt is
FILE(GLOB_RECURSE QTPLUGINS_IMAGEFORMATS
${QT_BASE_DIRECTORY}/plugins/imageformats/*${CMAKE_SHARED_LIBRARY_SUFFIX})
FILE(GLOB_RECURSE QTPLUGINS_PLATFORMS
${QT_BASE_DIRECTORY}/plugins/platforms/*${CMAKE_SHARED_LIBRARY_SUFFIX})
SET(QTPLUGINS ${QTPLUGINS_IMAGEFORMATS} ${QTPLUGINS_PLATFORMS})
MESSAGE("Project libraries: ${QTPLUGINS}")
INSTALL(CODE "
INCLUDE(BundleUtilities)
FIXUP_BUNDLE(\"${APPS}\" \"${QTPLUGINS}\" \"${DIRS}\")
"
COMPONENT ${PROJECT_NAME})
First I have this:
-- fixup_bundle: fixing...
-- 132/260: fix-up not required on this platform
'/home/waldo/Developer/Qt/5.6.3/gcc_64/plugins/imageformats/libqicns.so'
-- 133/260: fix-up not required on this platform
'/home/waldo/Developer/install/Release/bratumia/bin/libQt5Core.so.5'
-- 134/260: fix-up not required on this platform
'/home/waldo/Developer/install/Release/bratumia/bin/libQt5Gui.so.5’
-- 167/260: fix-up not required on this platform
'/home/waldo/Developer/install/Release/bratumia/bin/libITKEXPAT-4.13.so.1'
-- 168/260: fix-up not required on this platform
'/home/waldo/Developer/install/Release/bratumia/bin/libITKIOBMP-4.13.so.1'
-- 169/260: fix-up not requir
Re: [CMake] CMake 3.7.1 gui fails to launch
Another alternative, which is the one we use here, is to configure the custom Qt build with a "-qtlibinfix" flag - which produces libraries with completely different SONAMEs so there's no conflict. (We use this in conjunction with an RPATH.) One thing that could break is that some distributions set QT_PLUGIN_PATH for KDE logins which causes errors on trying to load incompatible plugins, so they might need to unset QT_PLUGIN_PATH in their wrapper script. -- Daniel From: CMake [cmake-boun...@cmake.org] on behalf of Hendrik Sattler [p...@hendrik-sattler.de] Sent: Saturday, January 07, 2017 12:11 AM To: cmake@cmake.org; da...@daryllee.com; Alan W. Irwin Subject: Re: [CMake] CMake 3.7.1 gui fails to launch Am 6. Januar 2017 23:37:00 MEZ schrieb da...@daryllee.com: >And the answer is... > >I recently installed an IDE from a not-to-be-named company that I do a > >lot of business with. The installation of that software places their >installation directory in LD_LIBRARY_PATH and guess what? their >installation contains a copy of libQtGui.so and libQtCore.so. The >"ldd" tip led me to that discovery. For now I have put >/usr/lib/x86_64-linux-gnu in front of their path in LD_LIBRARY_PATH >and cmake-gui V3.7.1 is working. I may have to come up with a more >permanent fix, but for now their stuff seems to work and CMake seems >to work, so I'm claiming victory. Maybe as a customer you should tell them about this bad experience. They should either set RPATH in their programs or should set LD_LIBRARY_PATH only in a start wrapper script. In a program that lets the user start other programs, RPATH should be preferred or LD_LIBRARY_PATH should be cleaned up for child processes. HS -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -- 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 -- 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] Need ideas/opinions on third party library management
For what it's worth, what I've done here is to create binary packages of each third-party library for each supported platform (i.e. .deb packages for Ubuntu, .rpm packages for RHEL/CentOS, Chocolatey packages for Windows). Except for cases where the system already provided sufficient versions of some of the libraries. At the bottom of the internal dependency chain is a base package which sets up the infrastructure (e.g. an /etc/profile.d file to add a shell function to add entries to CMAKE_PREFIX_PATH, LD_LIBRARY_PATH, etc.) and at the top is a set of dependency metapackages, one for each product we have to build. And yes, the middle layer has a combination of large packages like Qt and Boost with smaller packages like Expat and SQLite. Pluses: - Extremely convenient for an internal developer to just follow a few instructions to add our internal repository, then run "apt-get install anchorage-exata-deps". - Similarly convenient for customers developing custom code on top of our code if we provide an archive of the required packages, then they can point apt/yum/chocolatey to a file: URL. - It's not too difficult to support installing multiple parallel versions of the development environment for different versions of the product - just have each one install to a different location, and then the developer selects what to use by running the appropriate shell function. - Greatly simplifies the CMake files for our code, since you just use the standard find_package() command (possibly requiring us to write a Find*.cmake module). - Flexibility of being able to easily experiment with a new or custom-compiled version of one of the dependencies. - If an internal developer happens to prefer working on a platform which we don't officially support (e.g. Debian testing or Mint), it's generally easy to git clone my packaging repositories and build packages for yourself. Minuses: - Duplicate packaging work for each different packaging tool when adding a new third-party library. - I haven't yet automated the process of building binary packages and uploading to our repository; so when updating any package to a new version (or adding a local patch) there's a lot of manual work to do. (dupload and reprepro help a bit for the Ubuntu builds, and nuget has a built-in facility to upload to our server; but I haven't found anything similar for the RPM builds.) - When we do a release and then need to "fork" the repository to a new location, it requires a rebuild of all packages at least on Linux. Overall, most of the pluses apply to everybody, whereas the minuses are just a burden on me (or a future maintainer of the repository). So overall, it's been a big improvement over what we used to do, which was to try to maintain binary builds of the third-party libraries in SVN. -- Daniel Schepler -- 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] MSVC /M[TD] as a compatible interface property?
A while ago I did an experiment along the same lines, using something like this in CMake/MTflags.cmake. (What we really needed was forcing /MT /D_HAS_ITERATOR_DEBUGGING=0 even on debug builds, because we were using an external library only available in /MT format. So I might have accidentally broken it while adapting it here.) add_library(MTflags INTERFACE) target_compile_options(MTflags INTERFACE "/MT$<$:d>") set_property(TARGET MTflags PROPERTY INTERFACE_MSVC_MT ON) set_property(TARGET MTflags APPEND PROPERTY COMPATIBLE_INTERFACE_BOOL MSVC_MT) # Example usage: # include(MTflags) # add_library(A STATIC src1.cpp src2.cpp...) # target_link_libraries(A PUBLIC MTflags) That almost did what we wanted. The biggest problem (and the one annoying enough to make me abandon the experiment for the time being) was: if you configured using the "NMake Makefiles" generator, then the compiler would give a warning on each source file because the build system was passing both the default /MD[d] and the additional /MT. -- Daniel Schepler From: CMake [cmake-boun...@cmake.org] on behalf of Walter Gray [chrysal...@gmail.com] Sent: Thursday, June 09, 2016 1:58 PM To: Cmake Mailing List Subject: [CMake] MSVC /M[TD] as a compatible interface property? Setting /MT or /MD is pretty important, and is a transitive requirement. See: https://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx The standard mechanism of using target_compile_options isn't quite appropriate because it will simply append the flags used by each library and use the last one with no complaint if there is a mismatch. Example: A uses /MT, B uses /MD, C Depends on both. This will result in errors when compiling, but will configure just fine. I would like to make it so that if there is a mismatch between linked targets, cmake will either fail or issue a warning. https://cmake.org/cmake/help/v3.5/manual/cmake-buildsystem.7.html#compatible-interface-properties This seems to be meant to be used for exactly this type of thing, but because there is no specific property for specifying MSVC_RUNTIME, that system cannot be used in this case. Any thoughts on how to address this? -- 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] CXX_COMPILE_FEATURES entry for thread safety of static local variable initialization
I don't see this in a quick scan through CMAKE_DIR/share/cmake-3.5/Help/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.rst. This would be the C++11 addition under http://en.cppreference.com/w/cpp/language/storage_duration#Static_local_variables - or, the feature matrix at https://msdn.microsoft.com/en-us/library/hh567368.aspx refers to this as "Magic statics" and refers to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm . Before I file a bug requesting an addition for this, I thought I'd check to see if there's something relevant in the C++ feature list that I missed in my quick scan. For now, I'm using a custom definition of #define CXX_STATIC_LOCAL_VAR_THREAD_SAFE_INIT \ (defined(__GNUC__) || defined(__clang__) || \ (defined(_MSC_VER) && _MSC_VER >= 1900)) // VS 2015 / vc14 (given that the rest of our program has a strong requirement on other C++11 features anyway). -- Daniel -- 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] Best way to handle application data path for local run vs. installation
For what it's worth, what we do here is have the executable search for a file
named paths.cfg in the same directory it's located in, and read settings from
that file to get the paths to load resources from. Then our CMake system is
set up to create one paths.cfg when building, and another when installing. Of
course, we use Qt which makes it easy both to get the executable location
directory (which you mentioned you don't want to do), and to read a
configuration file. Also, our installation is designed to be in a
self-contained directory, e.g. /opt/Scalable/product; but in an installation to
system directories, you wouldn't want to clutter /usr/bin with a paths.cfg
file, so you would probably want to have a hard-coded system directory fallback
compiled in to use if paths.cfg doesn't exist.
A possible hack that just occurred to me: maybe you could make use of the
different RPATH by compiling a simple path configuration "plugin" - the
executable would try to dlopen("mypaths.so") and if that's found call functions
in the plugin to get the paths. The plugin would only be compiled in the build
directory, and not installed. Of course, that would be totally non-portable to
Windows.
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Dmitry Marakasov
[amd...@amdmi3.ru]
Sent: Sunday, November 29, 2015 6:10 PM
To: cmake@cmake.org
Subject: [CMake] Best way to handle application data path for local run vs.
installation
Hi!
This question bugs me for a long time so I though maybe someone has
a solution. I have a project which includes an application and some
data for it. An application needs to know path to its data files, so
I pass it via compiler definition: ADD_DEFINITIONS(-DDATADIR="...")
The problem is that this path is different based on whether I want to
run the application from build directory:
ADD_DEFINITIONS(-DDATADIR="${PROJECT_SOURCE_DIR}/data")
or want to install it systemwide:
ADD_DEFINITIONS(-DDATADIR="${CMAKE_INSTALL_PREFIX}/share/myapp")
I want my project to both run from build directory and to be
installable systemwide, without the need to rebuild or specify extra
options.
- I don't want to make an applications search for its data relative
to executable path
- There's no cross-platform way to get an executable path
- This will break when executable is moved or hardlinked
- I don't want to try both paths, as this is error prone, as installed
executable may pick data files from repository or vice versa
- I don't want to make user specify additional cmake flags like
-DSYSTEMWIDE_INSTALLATION or -DRUN_LOCALLY.
- I don't want to use any wrapper scripts
- I don't want to build two executables
The best solution would be for cmake to fix path in executable file
right after installation, something similar to what cmake does with
rpaths. Or there could be a cross-platform way for executable to know
whether it was installed which I've missed.
Any ideas?
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ru http://amdmi3.ru
--
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
--
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] Custom message if target fails
I'm assuming this is under a Unix platform - in my experience, on Windows, I
get the color escape codes even running cmake builds under Jenkins. On Unix
platforms, you could install expect and use the unbuffer tool, e.g. "unbuffer
make -j8 -k".
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Daniel Wirtz
[daniel.wi...@simtech.uni-stuttgart.de]
Sent: Thursday, November 12, 2015 2:05 AM
To: cmake@cmake.org
Subject: Re: [CMake] Custom message if target fails
Hey,
neat idea, i've tried and it works (i have custom targets there).
However, the "nice" colored build text output of such a solution gets
lost completely (pipes etc); are there any alternative ideas/solutions?
thanks again!
Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a
+49 711 685 60044
On 11/12/2015 10:10 AM, Nils Gladitz wrote:
> On 11/12/2015 09:54 AM, Daniel Wirtz wrote:
>> Dear all,
>>
>> i've been thinking on this for a while but i can't seem to get my
>> head around how to solve this.
>> The task is simple: How can i display a custom error message if a
>> target fails to build for whatever reason?
>> - cmake ..
>> - make
>> -
>> - below the (compile-tool dependent error output) i'd like to print
>> something like "Whoops it went wrong, type this and that or visit
>> this or that website for help"
>>
>
> There is no generic build system feature for this.
>
> You haven't provided any details on what kind of target this concerns
> or what is to be diagnosed specifically but ...
>
> Assuming this is a custom target / custom command you could replace
> the actual command with a wrapper (e.g. cmake -P script) that:
> - runs the actual command (e.g. execute_process())
> - outputs a message based on the actual command's exit status
> (e.g. message("This and that"))
> - exits with (roughly) the same exit status as the actual command
> (e.g. message(FATAL_ERROR) on failure))
>
> For regular build targets (executables, libraries) there is nothing to
> be done at build time.
> Depending on what it is you are actually diagnosing you might want to
> try to diagnose it during configuration rather than during the build.
>
> Nils
--
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
--
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] Protobuf Libraries not found on OS X
Doesn't CMAKE_PREFIX_PATH work for you? -- Daniel Schepler From: CMake [cmake-boun...@cmake.org] on behalf of Michael Jackson [mike.jack...@bluequartz.net] Sent: Friday, September 04, 2015 10:33 AM To: CMake list Subject: Re: [CMake] Protobuf Libraries not found on OS X Odd, I built from source and there does not seem to be any way to add a custom search path (akin to QtDir or something like that) for the searching. I added a few lines to the FindProtobuf.cmake file to make it look for "Protobuf_DIR" as an environment variable. If I installed it into /usr/local I bit the default paths would find it. I guess I could submit the patch as a bug report for the next version of CMake. Thanks Mike Jackson On Sep 4, 2015, at 11:53 AM, Nils Guillermin <nils.guiller...@gmail.com<mailto:nils.guiller...@gmail.com>> wrote: I'm on Mac OS X 10.10.4 and I use protobuf installed through homebrew. Nils On Thu, Sep 3, 2015 at 1:48 PM, Michael Jackson <mike.jack...@bluequartz.net<mailto:mike.jack...@bluequartz.net>> wrote: I have compiled the Protocol Buffer library on OS X and I am using the following CMake code to try and find the compiled libraries: find_package(Protobuf REQUIRED) but when configuring I get the usual CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: PROTOBUF_LIBRARY (ADVANCED) Looking at the FindProtobuf.cmake file that came with CMake 3.3.0 it looks like the module would ONLY work with MSVC built Protobuf libraries as the specific paths that are searched for are Visual Studio specific. Is this the correct behavior? Does anyone else use Protobuffers on OS X? I am thinking of rolling my on FindProtobuf.cmake file to have cmake look in more places. --- Mike Jackson -- Powered by www.kitware.com<http://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 -- 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] [cmake-developers] CMake IR
This seems to work for me:
set(CMAKE_BUILD_TYPE_INIT RelWithDebInfo)
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Dan Kegel [d...@kegel.com]
Sent: Friday, July 31, 2015 9:38 AM
To: Ruslan Baratov
Cc: cmake; Bill Hoffman
Subject: Re: [CMake] [cmake-developers] CMake IR
On Fri, Jul 31, 2015 at 11:33 AM, Ruslan Baratov
ruslan_bara...@yahoo.com wrote:
I never use the GUI, and consider the cache an anti-feature there solely
to support GUI users. It complicates my life, and I'd love to see it go.
In what way do you think it is causing you trouble?
Here is an example:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(Foo)
if(A)
set(B Hello A CACHE STRING Do we use A?)
else()
set(B There is no A CACHE STRING Do we use A?)
endif()
User thinks: okay, if I set A=ON I will have B equal to Hello A.
What user really have:
rm -rf _builds
cmake -H. -B_builds
cmake -H. -B_builds -DA=ON
grep '\B\' _builds/CMakeCache.txt
B:STRING=There is no A
I'm not saying cache is a bad idea, I'm just saying that when users hit such
kind of situations that's one of the reason why they said CMake is not a
good script language. Just like CMake before CMP0054: user see `if(a
STREQUAL b)` and think okay, 'a' is not equal to 'b' so this condition is
always false... nope!
Here's another example from real life. Maybe I'm just being an idiot,
but this is what I had to do to set a default:
IF(DEFINED CMAKE_BUILD_TYPE AND (NOT ${CMAKE_BUILD_TYPE} STREQUAL None))
SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING Choose the
type of build, options are: Debug Release RelWithDebInfo)
ELSE()
SET(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING Choose the type
of build, options are: Debug Release RelWithDebInfo FORCE)
ENDIF()
Can someone give me the proper one-line way to set a default for
CMAKE_BUILD_TYPE, or is this an authentic problem?
- Dan
--
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
--
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] [cmake-developers] CMake IR
It doesn't look like it's documented, at least in the command line
--help-variable.
It's a special case, which I think works for a lot of the build flag related
cache variables (though for a lot of the others, you probably need to put
values in e.g. a c_flag_overrides.cmake included by setting
CMAKE_USER_MAKE_RULES_OVERRIDE so they can be dependent on detected
platform/compiler settings).
--
Daniel Schepler
From: daniel.r.ke...@gmail.com [daniel.r.ke...@gmail.com] on behalf of Dan
Kegel [d...@kegel.com]
Sent: Friday, July 31, 2015 10:21 AM
To: Daniel Schepler
Cc: cmake
Subject: Re: [CMake] [cmake-developers] CMake IR
On Fri, Jul 31, 2015 at 11:44 AM, Daniel Schepler
dschep...@scalable-networks.com wrote:
Here's another example from real life. Maybe I'm just being an idiot,
but this is what I had to do to set a default:
IF(DEFINED CMAKE_BUILD_TYPE AND (NOT ${CMAKE_BUILD_TYPE} STREQUAL None))
SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING Choose the
type of build, options are: Debug Release RelWithDebInfo)
ELSE()
SET(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING Choose the type
of build, options are: Debug Release RelWithDebInfo FORCE)
ENDIF()
Can someone give me the proper one-line way to set a default for
CMAKE_BUILD_TYPE, or is this an authentic problem?
This seems to work for me:
set(CMAKE_BUILD_TYPE_INIT RelWithDebInfo)
Wow, never heard of that variable, thanks
Is that documented?
Can you just slam _INIT on the end of any cache variable to give it a
default value, or is that a special case?
- Dan
--
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] Issues with adding -flto in CMAKE_C[XX]_FLAGS_RELEASE
I just tried an experiment on our code base, adding -flto to the default values of CMAKE_C_FLAGS_RELEASE and CMAKE_CXX_FLAGS_RELEASE, and setting CMAKE_AR to /usr/bin/gcc-ar-5, CMAKE_RANLIB to /usr/bin/gcc-ranlib-5. However, make VERBOSE=1 shows that the intermediate static libraries are still being created using /usr/bin/ar; and I can't find any other instances of /usr/bin/ar in CMakeCache.txt. That results in lots of BFD warnings showing up, and linker errors at the end. Is there something I'm missing that would make this able to work; or is this configuration not supported (yet)? -- Daniel Schepler -- 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] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc
I'd put debugging statements in to see what is being returned as
MYSQL_INCLUDE_DIR and MYSQL_LIBRARY; and if those look correct, I'd run make
VERBOSE=1 to check exactly what's on the compilation command line.
--
Daniel
From: Peleg Bar-Sapir [pel...@gmail.com]
Sent: Wednesday, April 29, 2015 4:46 PM
To: Daniel Schepler
Cc: cmake@cmake.org
Subject: Re: [CMake] Linking to MySQL C++ Connector libraries using extra
flags, Ubuntu 14.04 LTS, gcc
Hello Daniel,
Thanks for your help.
I took your file and plagiarized it, replacing
MariaDB/MARIADB/mariadb with MySQL/MYSQL/mysql accordinly -
and did the same for the CMakeLists.txt (I put FindMySQL.cmake in
/CMake/Modules). Running 'cmake .' now gives no error, but running
make gives me still the linking error:
$ make
[100%] Building CXX object
CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o
/home/[...]/find_visual/entity_find_visual.cpp:17:19: fatal error:
mysql.h: No such file or directory
#include mysql.h
^
compilation terminated.
make[2]: *** [CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o]
Error 1
make[1]: *** [CMakeFiles/entity_find_visual.dir/all] Error 2
make: *** [all] Error 2
This is almost exactly what happens when I run a Makefile without the flag:
$make foo
g++ foo.cpp foolib.cpp -o foo `pkg-config --cflags --libs gsl` -std=c++11
In file included from foo.cpp:5:0:
foolib.h:16:23: fatal error: my_global.h: No such file or directory
#include my_global.h
^
compilation terminated.
Am I missing something?
Peleg
On Thu, Apr 30, 2015 at 12:52 AM, Daniel Schepler
dschep...@scalable-networks.com wrote:
I'd say that most of the output of mysql_config --cflags and mysql_config
--libs is a bug - for the shared library, there's no need to explicitly
include the pthread etc. libraries (unless, of course, your program also uses
them directly). In CMake terms, they should have been PRIVATE dependencies
of the shared library, rather than PUBLIC. (I don't seem to have been able
to convince the MariaDB Connector/C developers of that, though...)
I'm attaching a file I wrote for our project to enable:
find_package(MariaDB REQUIRED)
include_directories(${MARIADB_INCLUDE_DIR})
target_link_libraries(mainexe ${MARIADB_LIBRARY})
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Peleg Bar-Sapir
[pel...@gmail.com]
Sent: Wednesday, April 29, 2015 2:56 PM
To: cmake@cmake.org
Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags,
Ubuntu 14.04 LTS, gcc
Hello,
First, I would like to point out that I'm new to CMake, and I'm not a
professional programer by any means - just a Physics research student.
I looked for answers to my issue online, but couldn't find anything
that helped me. I also asked my peers and friends, but unfortunately
none of them could find an answer as well.
I want to use MySQL connector for C++ in a program. Usually I do this
by using the 'mysql' and 'my_global' libraries, and then run gcc with
this added flag: `mysql_config --cflags --libs`.
Typing this command into my console results in:
$mysql_config --cflags --libs
-I/usr/include/mysql -DBIG_JOINS=1 -fno-strict-aliasing-g -DNDEBUG
-L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -ldl
meaning there are some linking flags that must be given so gcc would
compile my code, apart from just -lmysql or -l/usr/include/mysql.
My question is how do I ensure this works also with CMake? I
understand how to use the CMakeLists.txt file to configure additional
external libraries, but none of them require special flags as above,
at least in my basic use of them. Since there's no module for MySQL
connector, I'm a bit lost here.
Could anyone please give me a some advices, or point me to what should be
done?
Thanks,
Peleg Bar Sapir
--
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
--
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
Re: [CMake] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc
I'd say that most of the output of mysql_config --cflags and mysql_config
--libs is a bug - for the shared library, there's no need to explicitly include
the pthread etc. libraries (unless, of course, your program also uses them
directly). In CMake terms, they should have been PRIVATE dependencies of the
shared library, rather than PUBLIC. (I don't seem to have been able to
convince the MariaDB Connector/C developers of that, though...)
I'm attaching a file I wrote for our project to enable:
find_package(MariaDB REQUIRED)
include_directories(${MARIADB_INCLUDE_DIR})
target_link_libraries(mainexe ${MARIADB_LIBRARY})
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Peleg Bar-Sapir
[pel...@gmail.com]
Sent: Wednesday, April 29, 2015 2:56 PM
To: cmake@cmake.org
Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags,
Ubuntu 14.04 LTS, gcc
Hello,
First, I would like to point out that I'm new to CMake, and I'm not a
professional programer by any means - just a Physics research student.
I looked for answers to my issue online, but couldn't find anything
that helped me. I also asked my peers and friends, but unfortunately
none of them could find an answer as well.
I want to use MySQL connector for C++ in a program. Usually I do this
by using the 'mysql' and 'my_global' libraries, and then run gcc with
this added flag: `mysql_config --cflags --libs`.
Typing this command into my console results in:
$mysql_config --cflags --libs
-I/usr/include/mysql -DBIG_JOINS=1 -fno-strict-aliasing-g -DNDEBUG
-L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -ldl
meaning there are some linking flags that must be given so gcc would
compile my code, apart from just -lmysql or -l/usr/include/mysql.
My question is how do I ensure this works also with CMake? I
understand how to use the CMakeLists.txt file to configure additional
external libraries, but none of them require special flags as above,
at least in my basic use of them. Since there's no module for MySQL
connector, I'm a bit lost here.
Could anyone please give me a some advices, or point me to what should be done?
Thanks,
Peleg Bar Sapir
--
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
if (WIN32)
if (CMAKE_SIZEOF_VOID_P EQUAL 8)
set(MARIADB_WIN_PATH C:/Program Files/MariaDB/MariaDB C Client Library 64-bit)
else ()
set(MARIADB_WIN_PATH C:/Program Files (x86)/MariaDB/MariaDB C Client Library
C:/Program Files/MariaDB/MariaDB C Client Library)
endif ()
endif ()
# Look for the header file.
find_path(MARIADB_INCLUDE_DIR NAMES mysql.h
PATH_SUFFIXES include mariadb include/mariadb
PATHS /usr/include/mariadb ${MARIADB_WIN_PATH})
# Look for the library.
find_library(MARIADB_LIBRARY NAMES mariadb libmariadb
mariadbclient libmariadbclient
PATH_SUFFIXES lib mariadb lib/mariadb
PATHS ${MARIADB_WIN_PATH})
# Find version string.
if (MARIADB_INCLUDE_DIR AND EXISTS ${MARIADB_INCLUDE_DIR}/mysql_version.h)
file(STRINGS ${MARIADB_INCLUDE_DIR}/mysql_version.h mariadb_version_str
REGEX ^#define[\t ]+MARIADB_PACKAGE_VERSION[\t ]+\.*\)
string(REGEX REPLACE ^#define[\t ]+MARIADB_PACKAGE_VERSION[\t ]+\(.*)\.*
\\1 MARIADB_VERSION ${mariadb_version_str})
endif ()
# handle the find_package args and set MYSQL_FOUND
include(FindPackageHandleStandardArgs)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(MARIADB
REQUIRED_VARS MARIADB_LIBRARY MARIADB_INCLUDE_DIR
VERSION_VAR MARIADB_VERSION)
mark_as_advanced(MARIADB_INCLUDE_DIR MARIADB_LIBRARY)
--
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] Issues with adding -flto in CMAKE_C[XX]_FLAGS_RELEASE
I've managed to create a small test case that reproduces the issue, and posted a bug report: http://www.cmake.org/Bug/view.php?id=15547 . It would seem that the issue occurs if you try to update CMAKE_AR and CMAKE_RANLIB after a previous run of CMake - though not if you include those settings on the first CMake run. -- Daniel Schepler From: CMake [cmake-boun...@cmake.org] on behalf of Daniel Schepler [dschep...@scalable-networks.com] Sent: Wednesday, April 29, 2015 11:20 AM To: cmake@cmake.org Subject: [CMake] Issues with adding -flto in CMAKE_C[XX]_FLAGS_RELEASE I just tried an experiment on our code base, adding -flto to the default values of CMAKE_C_FLAGS_RELEASE and CMAKE_CXX_FLAGS_RELEASE, and setting CMAKE_AR to /usr/bin/gcc-ar-5, CMAKE_RANLIB to /usr/bin/gcc-ranlib-5. However, make VERBOSE=1 shows that the intermediate static libraries are still being created using /usr/bin/ar; and I can't find any other instances of /usr/bin/ar in CMakeCache.txt. That results in lots of BFD warnings showing up, and linker errors at the end. Is there something I'm missing that would make this able to work; or is this configuration not supported (yet)? -- Daniel Schepler -- 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] Linking to MySQL C++ Connector libraries using extra flags, Ubuntu 14.04 LTS, gcc
OK, my target_link_libraries() line was just an example not knowing your
executable name - you'd want to update it to
target_link_libraries(entity_find_visual ${MYSQL_LIBRARY}) . (And personally,
I'd group the find_package calls together, then combine the
target_link_libraries lines into one - target_link_libraries(entity_find_visual
${OpenCV_LIBS} ${MYSQL_LIBRARY}).)
--
Daniel
From: Peleg Bar-Sapir [pel...@gmail.com]
Sent: Wednesday, April 29, 2015 5:29 PM
To: Daniel Schepler
Cc: cmake@cmake.org
Subject: Re: [CMake] Linking to MySQL C++ Connector libraries using extra
flags, Ubuntu 14.04 LTS, gcc
For some reasons, now the cmake . command doesn't work either. I
haven't yet begun debugging, but I played a bit with the
CMakeLists.txt file, and then returned it to it's original state, with
your added lines (replacing mariadb with mysqldb, of course).
Now I get this error:
$ cmake .
CMake Error at CMakeLists.txt:9 (target_link_libraries):
Cannot specify link libraries for target mainexe which is not built by
this project.
The CMakeLists.txt looks like this:
cmake_minimum_required(VERSION 2.8)
project( entity_find_visual )
find_package( OpenCV REQUIRED )
add_executable( entity_find_visual entity_find_visual.cpp)
target_link_libraries( entity_find_visual ${OpenCV_LIBS} )
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_SOURCE_DIR}/cmake/Modules/)
find_package(MySQL REQUIRED)
include_directories(${MYSQL_INCLUDE_DIR})
target_link_libraries(mainexe ${MYSQL_LIBRARY})
(a bit ugly, I know, but it worked before).
I'm quite puzzled now, I must admit.
On Thu, Apr 30, 2015 at 1:50 AM, Daniel Schepler
dschep...@scalable-networks.com wrote:
I'd put debugging statements in to see what is being returned as
MYSQL_INCLUDE_DIR and MYSQL_LIBRARY; and if those look correct, I'd run make
VERBOSE=1 to check exactly what's on the compilation command line.
--
Daniel
From: Peleg Bar-Sapir [pel...@gmail.com]
Sent: Wednesday, April 29, 2015 4:46 PM
To: Daniel Schepler
Cc: cmake@cmake.org
Subject: Re: [CMake] Linking to MySQL C++ Connector libraries using extra
flags, Ubuntu 14.04 LTS, gcc
Hello Daniel,
Thanks for your help.
I took your file and plagiarized it, replacing
MariaDB/MARIADB/mariadb with MySQL/MYSQL/mysql accordinly -
and did the same for the CMakeLists.txt (I put FindMySQL.cmake in
/CMake/Modules). Running 'cmake .' now gives no error, but running
make gives me still the linking error:
$ make
[100%] Building CXX object
CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o
/home/[...]/find_visual/entity_find_visual.cpp:17:19: fatal error:
mysql.h: No such file or directory
#include mysql.h
^
compilation terminated.
make[2]: *** [CMakeFiles/entity_find_visual.dir/entity_find_visual.cpp.o]
Error 1
make[1]: *** [CMakeFiles/entity_find_visual.dir/all] Error 2
make: *** [all] Error 2
This is almost exactly what happens when I run a Makefile without the flag:
$make foo
g++ foo.cpp foolib.cpp -o foo `pkg-config --cflags --libs gsl` -std=c++11
In file included from foo.cpp:5:0:
foolib.h:16:23: fatal error: my_global.h: No such file or directory
#include my_global.h
^
compilation terminated.
Am I missing something?
Peleg
On Thu, Apr 30, 2015 at 12:52 AM, Daniel Schepler
dschep...@scalable-networks.com wrote:
I'd say that most of the output of mysql_config --cflags and mysql_config
--libs is a bug - for the shared library, there's no need to explicitly
include the pthread etc. libraries (unless, of course, your program also
uses them directly). In CMake terms, they should have been PRIVATE
dependencies of the shared library, rather than PUBLIC. (I don't seem to
have been able to convince the MariaDB Connector/C developers of that,
though...)
I'm attaching a file I wrote for our project to enable:
find_package(MariaDB REQUIRED)
include_directories(${MARIADB_INCLUDE_DIR})
target_link_libraries(mainexe ${MARIADB_LIBRARY})
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Peleg Bar-Sapir
[pel...@gmail.com]
Sent: Wednesday, April 29, 2015 2:56 PM
To: cmake@cmake.org
Subject: [CMake] Linking to MySQL C++ Connector libraries using extra flags,
Ubuntu 14.04 LTS, gcc
Hello,
First, I would like to point out that I'm new to CMake, and I'm not a
professional programer by any means - just a Physics research student.
I looked for answers to my issue online, but couldn't find anything
that helped me. I also asked my peers and friends, but unfortunately
none of them could find an answer as well.
I want to use MySQL connector for C++ in a program. Usually I do this
by using the 'mysql' and 'my_global' libraries, and then run gcc with
this added flag: `mysql_config --cflags --libs`.
Typing this command into my console results in:
$mysql_config
Re: [CMake] How to specify compiler only flags
As I understand it, configuration-specific properties are deprecated in favor
of generator expressions. For example:
target_compile_options(openjpeg PRIVATE
$$CONFIG:Release:-ffast-math)
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Orion Poplawski
[or...@cora.nwra.com]
Sent: Tuesday, April 28, 2015 1:15 PM
To: CMake Mailing List
Subject: [CMake] How to specify compiler only flags
I'm trying to patch the CMakeLists.txt for openjpeg. Currently it does:
# Do not use ffast-math for all build, it would produce incorrect results,
only set for release:
SET(CMAKE_C_FLAGS_RELEASE -ffast-math ${CMAKE_C_FLAGS_RELEASE})
Unfortunately, CMAKE_C_FLAGS are also used in link step, which for -ffast-math
causes problems for users of the shared library.
I'm unable to find an equivalent flag that is for compiling only. I see I can
set the COMPILE_FLAGS property for the library, but there does not appear to
be a COMPILE_FLAGS_RELEASE property that would only set it for the Release
build type.
Suggestions?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 http://www.nwra.com
--
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
--
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] how to use the FindMPI module correctly?
Would this work?
target_compile_options(core.x PUBLIC ${MPI_C_COMPILE_FLAGS})
--
Daniel
From: CMake [cmake-boun...@cmake.org] on behalf of Alexander Droste
[alexander.ra.dro...@googlemail.com]
Sent: Friday, April 03, 2015 2:54 PM
To: Thompson, KT
Cc: cmake@cmake.org
Subject: Re: [CMake] how to use the FindMPI module correctly?
Thanks for the validation.
But wouldn't the shorter version break in case MPI_C_COMPILE_FLAGS are
added in the future?
On 03.04.15 23:28, Thompson, KT wrote:
Alex,
Your setup looks fine. However, depending on your environment, you may be
able to use a simplified CMakeLists.txt. This is what I use on Linux with
g++ and OpenMPI.
#
cmake_minimum_required(VERSION 2.8)
project(hw CXX)
find_package( MPI )
include_directories( ${MPI_CXX_INCLUDE_PATH} )
add_executable( hw hw.cc )
target_link_libraries( hw ${MPI_CXX_LIBRARIES} )
#
-kt
-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Alexander Droste
Sent: Friday, April 03, 2015 12:24 PM
To: cmake@cmake.org
Subject: [CMake] how to use the FindMPI module correctly?
Hello everyone,
based on the documentation here:
http://www.cmake.org/cmake/help/v3.0/module/FindMPI.html
and posts on SO:
http://stackoverflow.com/questions/23163075/how-to-compile-an-mpi-included-c-program-using-cmake
I'm still not a 100% sure if I set up my CMake project correctly.
This is what I do:
#
#...
find_package(MPI REQUIRED)
add_executable(core.x main.c)
include_directories(SYSTEM ${MPI_C_INCLUDE_PATH})
link_directories(${MPI_C_LINK_FLAGS})
set(CMAKE_COMPILE_FLAGS ${CMAKE_COMPILE_FLAGS} ${MPI_C_COMPILE_FLAGS})
target_link_libraries(core.x ${MPI_C_LIBRARIES})
#-
Is this the correct way? Am I missing s.th.? I am especially unsure
about the compile flags variable.
At Usage (CMake documentation) it said that To use this module,
simply call FindMPI from a CMakeLists.txt file. So can I break down the
MPI setup to a single command. How do I call FindMPI? Or is it done by
calling find_package like I did?
The program build runs fine but I would like to ensure
that the cmake project is set up as correct and generic as possible.
Greetings,
Alex
--
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
--
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] how to use the FindMPI module correctly?
I mean replacing the set CMAKE_COMPILE_FLAGS line with my
target_compile_options line.
As for the message call, I usually use something more like: message(STATUS
MPI_C_COMPILE_FLAGS = ${MPI_C_COMPILE_FLAGS}) for debugging.
--
Daniel
From: Alexander Droste [alexander.ra.dro...@googlemail.com]
Sent: Friday, April 03, 2015 3:19 PM
To: Daniel Schepler
Cc: cmake@cmake.org
Subject: Re: [CMake] how to use the FindMPI module correctly?
Do you mean just using:
target_compile_options(core.x PUBLIC ${MPI_C_COMPILE_FLAGS})
but not:
include_directories(SYSTEM ${MPI_C_INCLUDE_PATH})
link_directories(${MPI_C_LINK_FLAGS})
set(CMAKE_COMPILE_FLAGS ${CMAKE_COMPILE_FLAGS} ${MPI_C_COMPILE_FLAGS})
target_link_libraries(core.x ${MPI_C_LIBRARIES})
Simply using your proposed line seems not to be sufficient. The library
symbols are not found then.
I believe the variable ${MPI_C_COMPILE_FLAGS} does not contain
anything in my case. Calling message(${MPI_C_COMPILE_FLAGS}) from cmake
gives me an error: message called with incorrect number of arguments
Does this mean it's empty? Variables containing flags do not produce
this error.
On 04.04.15 00:01, Daniel Schepler wrote:
Would this work?
target_compile_options(core.x PUBLIC ${MPI_C_COMPILE_FLAGS})
--
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] How can I make CTest not do dart-related stuff?
Here, to generate XML for Jenkins' xUnit plugin, we run ctest -T Test -j2 which has never complained about missing DartConfiguration.tcl. -- Daniel Schepler From: CMake [cmake-boun...@cmake.org] on behalf of Robert Dailey [rcdailey.li...@gmail.com] Sent: Friday, January 30, 2015 10:07 AM To: CMake Subject: [CMake] How can I make CTest not do dart-related stuff? I run ctest on my build server *just* to run the test executables and get result XML. I use a separate tool to parse the XML and upload it to an unrelated server (not CDash) I get errors like below: Cannot find file: /sourcerepo/build/DartConfiguration.tcl Can someone explain what CTest is doing and if there is a way to turn it off? -- 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 -- 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] Library include path question
How about something like (in the top-level directory for the projectlib
sources):
add_library(projectlib STATIC projectlib/foo.h projectlib/foo.cpp ...)
target_include_directories(projectlib PUBLIC . PRIVATE projectlib)
(Note that this will add the top-level directory as well as the projectlib
subdirectory for building projectlib sources - which is probably what you want
in order to be able to resolve inter-header dependencies.)
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Chris Johnson
[cxjohn...@gmail.com]
Sent: Monday, January 19, 2015 5:14 PM
To: cmake@cmake.org
Subject: [CMake] Library include path question
A common and useful method for avoiding name conflicts and keeping files
well-organized is to place them in a subdirectory unique to the library. For
example, the libraries for Graphviz and Postgres often install their API header
files in directories named install-prefix/include/graphviz and
install-prefix/include/libpq. So on my local development system, these
libraries' API header files are in /usr/local/include/graphviz/*.h and
/usr/local/include/libpq/*.h.
This is the convention that we use for our internal projects as well.
C++ code which needs to include these files by necessity must name that
subdirectory. For example, to use Postgres's API defined in libpq-fs.h, the
C++ code must look like this:
#include libpq/libpq-fs.h
We do the same for our internal libraries, for example, to use the projectlib
library from some program, the code would resemble:
#include projectlib/foo.h
In the library itself, however, the code is like this:
foo.h:
-
class Foo {
public:
Foo();
};
foo.cpp
---
#include foo.h
Foo::Foo() {
// constructor code
}
// etc.
That is, note that the header and source files are in the SAME directory.
CMake does not handle this well when trying to compile a program using the
library. CMake wants to look in the source directory or the build directory
for the header file, and those directory paths do not have the projectlib
prefix which is what the source code for the program expects (#include
projectlib/foo.h).
I've kludged around this by adding a function which does some ugly directory
creation in the build directory and then copies the headers to where the source
expects to find them.
But I think there's something about CMake I am not understanding correctly, or
a feature I should be using that I am unaware of, in order to make this all
work without writing code in my CMakeLists.txt files to copy source files to
expected places. This library file layout for headers and source is very
common in the Unix world, and we've modeled our largish (500 directories,
dozens of libraries) project on it.
Is there something about CMake I need to learn to make this work more cleanly?
Thanks,
..chris
Most libraries correctly put their headers into ./include/libdirname
39 # but CMake wants to look in the source or build dir, which doesn't have
40 # libdirname as a prefix. That prefix is used in the source files in
41 # their #include libdirname/libheader.h statements. Headers will not be
42 # found with that prefix when obtained from the source or build dir by
CMake.
--
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] Creating an installer using cpack
}
COMPONENT gui)
endif ()
endmacro ()
foreach (qt_plugin
accessible/qtaccessiblewidgets
codecs/qcncodecs
codecs/qjpcodecs
codecs/qkrcodecs
codecs/qtwcodecs
graphicssystems/qglgraphicssystem
graphicssystems/qtracegraphicssystem
iconengines/qsvgicon
imageformats/qgif
imageformats/qico
imageformats/qjpeg
imageformats/qmng
imageformats/qsvg
imageformats/qtga
imageformats/qtiff
sqldrivers/qsqlite)
if (WIN32)
set(qt_plugin_file ${qt_plugin}4.dll)
else ()
string(REGEX REPLACE /([^/]*)$ /lib\\1.so qt_plugin_file
${qt_plugin})
endif ()
set(qt_plugin_file ${QT_PLUGINS_DIR}/${qt_plugin_file})
if (EXISTS ${qt_plugin_file})
get_filename_component(plugin_dest_dir ${qt_plugin} PATH)
install_external_lib(${qt_plugin_file}
gui/lib/${BUILD_PLATFORM_BASE}/plugins/${plugin_dest_dir})
endif ()
endforeach ()
# The following is used to install required libraries
if (WIN32)
set(search_path ${QT_BINARY_DIR})
else ()
set(search_path ${QT_LIBRARY_DIR})
endif ()
foreach (lib_for_search_path ${EXPAT_LIBRARY} ${GLUT_LIBRARIES})
if (lib_for_search_path STREQUAL optimized OR
lib_for_search_path STREQUAL debug OR
lib_for_search_path STREQUAL general)
# ignore these markers
else ()
get_filename_component(search_dir ${lib_for_search_path} PATH)
list(APPEND search_path ${search_dir})
if (WIN32 AND search_dir MATCHES /lib)
string(REPLACE /lib /bin search_dir ${search_dir})
if (EXISTS ${search_dir})
list(APPEND search_path ${search_dir})
endif ()
endif ()
endif ()
endforeach ()
list(SORT search_path)
list(REMOVE_DUPLICATES search_path)
if (WIN32)
install(CODE
message(STATUS \Calculating required libraries...\)
include(GetPrerequisites)
set(search_path \${search_path}\)
get_prerequisites(\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE}/${BUILD_TARGET_GUI_NAME}.exe
prereqs 1 1 \\ \\${search_path}\)
file(GLOB_RECURSE qt_plugins
\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE}/plugins/*.dll)
foreach (plugin_file \${qt_plugins})
get_prerequisites(\${plugin_file} prereqs 1 1 \\
\\${search_path}\)
endforeach ()
foreach (libfile \${prereqs})
gp_resolve_item(\\ \${libfile} \\ \\${search_path}\
libfile_abs)
file(INSTALL \${libfile_abs} DESTINATION
\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE})
endforeach ()
COMPONENT gui)
set(CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION
gui/lib/${BUILD_PLATFORM_BASE})
include(InstallRequiredSystemLibraries)
else ()
# Linux
install(CODE
message(STATUS \Calculating required libraries...\)
include(GetPrerequisites)
set(search_path \${search_path}\)
get_prerequisites(\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE}/${BUILD_TARGET_GUI_NAME}
prereqs 0 1 \\ \\${search_path}\)
file(GLOB_RECURSE qt_plugins
\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE}/*.so)
foreach (plugin_file \${qt_plugins})
get_prerequisites(\${plugin_file} prereqs 0 1 \\
\\${search_path}\)
endforeach ()
foreach (libfile \${prereqs})
if (NOT (libfile MATCHES
\/(lib(c|dl|drm|fontconfig|freetype|gcc_s|gfortran|GL|GLU|glapi|gomp|ICE|idn|m|png12|pthread|resolv|rt|SM|stdc++|X11|X11-xcb|Xau|Xaw|Xaw7|xcb-dri2|xcb-glx|xcb|Xdamage|Xdmcp|Xext|Xfixes|Xmu|Xpm|Xrandr|Xrender|Xt|Xxf86vm|z).so(.|\\\$))\))
file(INSTALL \${libfile} DESTINATION
\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE})
if (IS_SYMLINK \${libfile})
get_filename_component(libfile_target \${libfile}
REALPATH)
file(INSTALL \${libfile_target} DESTINATION
\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/gui/lib/${BUILD_PLATFORM_BASE})
endif ()
endif ()
endforeach ()
COMPONENT gui)
endif ()
--
Daniel Schepler
-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Gonzalo Garramuno
Sent: Thursday, January 08, 2015 12:47 PM
To: cmake@cmake.org
Subject: [CMake] Creating an installer using cpack
I have a cmake file to build my project (mrViewer). The project has additional
script files that are not mentioned in my
[CMake] Installing vcomp120.dll
This should hopefully be an easy question: Our build of FreeImage has a dependency on vcomp120.dll. However, it would seem that GetPrerequisites.cmake is skipping that dependency because it's in the Visual Studio installation directory, and also InstallRequiredSystemLibraries.cmake doesn't seem to have any facilities for installing that (even optionally). So, my question is: what would be the best way to add an installation of that DLL so that we don't require the VS 2013 x64 redistributable, in such a way that it would be future-proof? -- Daniel -- 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] Problems with CMake 3.1.0-rc3 write_compiler_detection_header
Why would we need specific support for each compiler? Couldn't the module use check_cxx_source_compiles() etc. tests instead? -- Daniel Schepler From: CMake [cmake-boun...@cmake.org] on behalf of NoRulez [noru...@me.com] Sent: Monday, December 15, 2014 5:40 AM To: CMake MailingList Subject: Re: [CMake] Problems with CMake3.1.0-rc3 write_compiler_detection_header I see that only GNU and Clang is currently supported (set(compilers GNU Clang);) Is that right and would MSVC be added to the final 3.1.0 version? Thanks in advance Best Regards Am 15.12.2014 um 12:34 schrieb NoRulez noru...@me.com: Hello, I tried write_compiler_detection_header as in the example provided with VS2013 but i only get the following message: Unsupported compiler MSVC Any suggestions? Best Regards -- 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 -- 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 -- 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] Copying DLLs to output directory
And what if there are more dependencies? For example, we have a project here that uses Qt, Boost, OGRE, MYGUI, GDAL, Protobuf and EXPAT at least. And then if some of those builds aren't self-contained, you could add in dependencies like OpenSSL, libjpeg, libpng, etc. It seems like all those PATH entries could easily end up overflowing Windows' limit on the length of PATH. -- Daniel -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Somerville Sent: Friday, October 31, 2014 12:52 PM To: cmake@cmake.org Subject: Re: [CMake] Copying DLLs to output directory On 31/10/2014 19:42, Michael Jackson wrote: Never said it was pretty, but here is the code I use for Qt4 based projects. I think I had to revamp a lot of this for Qt5. I call it like so: CMP_COPY_QT4_RUNTIME_LIBRARIES( QtCore;QtGui;QtNetwork) This seems an awful lot of messing around when qt-project.org already dump all the debug and release libraries into the installation bin directory so all you need is to ensure that the installation bin directory is on your PATH when you run or debug executables, just like you have to to build using the tools like moc, qmake, dumpcpp, qrc, etc.. IMHO put he Qt bin directory on PATH for debugging and use BundleUtils FixupBundle to make deployable kits. No need to do any manual or scripted copying of libraries at all. Regards Bill. -- 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 -- 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] Copying DLLs to output directory
In my online research, I was finding limits more like 1024 or 2048 characters maximum. But if 32767 bytes is the real limit, and there are no compatibility issues with certain programs for values longer than 1024 characters, that would be great. -- Daniel -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Somerville Sent: Friday, October 31, 2014 2:12 PM To: cmake@cmake.org Subject: Re: [CMake] Copying DLLs to output directory On 31/10/2014 20:46, Daniel Schepler wrote: And what if there are more dependencies? For example, we have a project here that uses Qt, Boost, OGRE, MYGUI, GDAL, Protobuf and EXPAT at least. And then if some of those builds aren't self-contained, you could add in dependencies like OpenSSL, libjpeg, libpng, etc. It seems like all those PATH entries could easily end up overflowing Windows' limit on the length of PATH. Seriously? 32,767 bytes maximum in an environment variable. If you blow that then I suggest installing all those packages somewhere nearer the filesystem root! Regards Bill. -- 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 -- 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] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
Where would I find the list of available C++ language features? For instance, I would suppose there's one for auto, one for move constructors/assignment operators, and one for = delete of default constructors/destructors et al. These are probably the ones we'd be most interested in here, for the moment. (Though with our requirements to support older C++ compilers, we might not actually be able to use auto, as the fallback would need the full type anyway.) Also, is there a portability macro provided for the = delete feature? Also, how would I mark a target so that it activates C++11 features if available, but falls back to old C++ if not? I do see the section on detecting compiler features, but it's not clear to me how exactly how I'd make the target use CXX_STANDARD 11 only if available. -- Daniel -- 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] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
(Whoops, accidentally sent this via private email before.) My question was about this part of the example: add_executable(consumer_with consumer_with.cpp) target_link_libraries(consumer_with foo) set_property(TARGET consumer_with CXX_STANDARD 11) add_executable(consumer_no consumer_no.cpp) target_link_libraries(consumer_no foo) The question is: how do I detect whether CXX_STANDARD 11 is available before running the set_property(TARGET consumer_with CXX_STANDARD 11) line? -- Daniel -Original Message- From: Robert Maynard [mailto:robert.mayn...@kitware.com] Sent: Wednesday, October 29, 2014 10:43 AM To: Daniel Schepler Cc: CMake MailingList Subject: Re: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing! You can find the known compile features that can be detected at: http://www.cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html At the end of the compile-features manual page ( http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html ) there is a section on how to mark a library as having conditional support on C++11 features. On Wed, Oct 29, 2014 at 12:58 PM, Daniel Schepler dschep...@scalable-networks.com wrote: Where would I find the list of available C++ language features? For instance, I would suppose there's one for auto, one for move constructors/assignment operators, and one for = delete of default constructors/destructors et al. These are probably the ones we'd be most interested in here, for the moment. (Though with our requirements to support older C++ compilers, we might not actually be able to use auto, as the fallback would need the full type anyway.) Also, is there a portability macro provided for the = delete feature? Also, how would I mark a target so that it activates C++11 features if available, but falls back to old C++ if not? I do see the section on detecting compiler features, but it's not clear to me how exactly how I'd make the target use CXX_STANDARD 11 only if available. -- Daniel -- 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 -- 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] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing!
Thanks for the pointers, that does answer my question. I would just set CXX_STANDARD to 11 and leave CXX_STANDARD_REQUIRED unset. -- Daniel From: David Cole [mailto:dlrd...@aol.com] Sent: Wednesday, October 29, 2014 11:38 AM To: Daniel Schepler Cc: cmake@cmake.org Subject: Re: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing! I think your question about CXX_STANDARD is answered in the CXX_STANDARD docs: http://www.cmake.org/cmake/help/v3.1/prop_tgt/CXX_STANDARD.html If you MUST have it, you can set this property to ON: http://www.cmake.org/cmake/help/v3.1/prop_tgt/CXX_STANDARD_REQUIRED.html (Although I've not used it myself -- not sure what happens if the compiler does not support the standard. Hopefully, an error at CMake time... try it and let us know if it works for you.) HTH, David C. On Wed, Oct 29, 2014 at 2:15 PM, Daniel Schepler dschep...@scalable-networks.commailto:dschep...@scalable-networks.com wrote: (Whoops, accidentally sent this via private email before.) My question was about this part of the example: add_executable(consumer_with consumer_with.cpp) target_link_libraries(consumer_with foo) set_property(TARGET consumer_with CXX_STANDARD 11) add_executable(consumer_no consumer_no.cpp) target_link_libraries(consumer_no foo) The question is: how do I detect whether CXX_STANDARD 11 is available before running the set_property(TARGET consumer_with CXX_STANDARD 11) line? -- Daniel -Original Message- From: Robert Maynard [mailto:robert.mayn...@kitware.commailto:robert.mayn...@kitware.com] Sent: Wednesday, October 29, 2014 10:43 AM To: Daniel Schepler Cc: CMake MailingList Subject: Re: [CMake] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing! You can find the known compile features that can be detected at: http://www.cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html At the end of the compile-features manual page ( http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html ) there is a section on how to mark a library as having conditional support on C++11 features. On Wed, Oct 29, 2014 at 12:58 PM, Daniel Schepler dschep...@scalable-networks.commailto:dschep...@scalable-networks.com wrote: Where would I find the list of available C++ language features? For instance, I would suppose there's one for auto, one for move constructors/assignment operators, and one for = delete of default constructors/destructors et al. These are probably the ones we'd be most interested in here, for the moment. (Though with our requirements to support older C++ compilers, we might not actually be able to use auto, as the fallback would need the full type anyway.) Also, is there a portability macro provided for the = delete feature? Also, how would I mark a target so that it activates C++11 features if available, but falls back to old C++ if not? I do see the section on detecting compiler features, but it's not clear to me how exactly how I'd make the target use CXX_STANDARD 11 only if available. -- Daniel -- Powered by www.kitware.comhttp://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 -- Powered by www.kitware.comhttp://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 -- 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] Refer to all debug or release targets with generator expressions
I think this should work:
$$NOT:$CONFIG:Debug:${my_release_libs}
--
Daniel
-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert Dailey
Sent: Monday, October 27, 2014 5:12 PM
To: CMake
Subject: Re: [CMake] Refer to all debug or release targets with generator
expressions
I forgot to give a more concrete example. Consider this:
add_library( Foo INTERFACE )
target_link_libraries( Foo INTERFACE
$$CONFIG:Debug:${lib_debug}
$$CONFIG:Release:${lib_release}
$$CONFIG:RelWithDebInfo:${lib_release}
$$CONFIG:MinSizeRel:${lib_release}
)
Must I do it like this for each and every configuration?
On Mon, Oct 27, 2014 at 7:10 PM, Robert Dailey rcdailey.li...@gmail.com wrote:
I know that when defining link libraries, I can do this:
$$CONFIG:Debug:${my_debug_libs}
The debug libraries will be the same for all debug targets. Likewise
with Release targets. Is there a way to refer to *all* release targets
using generator expressions? There are 3 release configurations that
ship with CMake by default for IDEs like Visual Studio. It would be
redundant for me to specify a generator expression for each and every
configuration. It'd be simpler to somehow map my release libs to all
release configurations somehow since they do not differ.
Any ideas on how to do this?
--
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
--
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] Fwd: How to get the list of files that will be installed when installing a CMake component
What about checking install_manifest.txt after running the cmake command?
Or, if you have multiple components to package in this way, possibly you could
use a different CMAKE_INSTALL_PREFIX for each component. Then, either have the
installer generator use those directories for packing the installer components,
or use some scripting to combine the component installations into a final image
directory for the installer generator to read from.
--
Daniel
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Dattu koneru
Sent: Wednesday, October 01, 2014 1:10 AM
To: cmake@cmake.org
Subject: [CMake] Fwd: How to get the list of files that will be installed when
installing a CMake component
Hi ,
Is there any way to know programmatically ( in cmake ) what files will be
installed if a COMPONENT is installed ( something like a get_property of
component)?
Currently I am installing a COMPONENT to a temporary location for packaging (
not using CPack for packaging ) and then packaging using custom commands.
Invoking the following command during packaing in Cmake.
cmake -DCOMPONENT=my_test_component
-DCMAKE_INSTALL_PREFIX=${TMP_PACKAGING_ROOT}
-P ${CMAKE_BINARY_DIR}/cmake_install.cmake
I wanted to know if it is possible to get the list of files so that I can only
include those files explicitly in the package ? or possibly add them as outputs
to the custom command ?
( I tried asking in StackOverflow but no success )
--
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] VTK compiling problem with CMake
1LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt When we've seen this, it's usually been due to .NET being upgraded to 4.5, which is incompatible with the tools in the original version of Visual Studio 2010. Upgrading Visual Studio 2010 to SP1 usually resolves the issue. -- Daniel Schepler -- 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] Windows Path Issues
Maybe you need to set it to C:/software/propgcc/bin/propeller-elf-gcc.exe
instead? (Or ${WHATEVER_PATH}/propeller-elf-gcc${CMAKE_EXECUTABLE_SUFFIX} .)
--
Daniel
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of da...@zemon.name
Sent: Wednesday, August 06, 2014 8:50 AM
To: cmake@cmake.org
Subject: Re: [CMake] Windows Path Issues
I've run it from CMD this time instead of Git Bash. Same results:
C:\Users\IGEN006\WORKSPACE_C_CPP\PropWarecmake -G Unix Makefiles .
-- The C compiler identification is GNU 4.6.1
-- The CXX compiler identification is GNU 4.6.1
-- The COGCXX compiler identification is GNU 4.6.1
-- The ECOGC compiler identification is GNU 4.6.1
-- The ECOGCXX compiler identification is GNU 4.6.1
-- The ASM compiler identification is GNU
-- Found assembler: C:/software/propgcc/bin/propeller-elf-gcc
CMake Error at CMakeLists.txt:6 (project):
The CMAKE_C_COMPILER:
C:/software/propgcc/bin/propeller-elf-gcc
is not a full path to an existing compiler tool.
Tell CMake where to find the compiler by setting either the environment
variable CC or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.
Any ideas are greatly appreciated.
Thanks,
David
-Original Message-
From: da...@zemon.namemailto:da...@zemon.name
Sent: Tuesday, August 5, 2014 3:34pm
To: Ivan Hrasko abhra...@gmail.commailto:abhra...@gmail.com
Cc: cmake@cmake.orgmailto:cmake@cmake.org
Subject: Re: [CMake] Windows Path Issues
Sorry about that. I am using Git Bash which is definitely a confusing
environment. The compiler is PropGCC - the target is an embedded system.
PropGCC ships with GNU Make 3.81 (and make --version confirms that is the
version of make in my PATH).
Perhaps the output of bash --version will help:
bash-3.1$ bash --version
GNU bash, version 3.1.0(1)-release (i686-pc-msys)
Copyright (C) 2005 Free Software Foundation, Inc.
bash-3.1$
Thanks,
David
-Original Message-
From: Ivan Hrasko abhra...@gmail.commailto:abhra...@gmail.com
Sent: Tuesday, August 5, 2014 2:26pm
To: da...@zemon.namemailto:da...@zemon.name
Cc: cmake@cmake.orgmailto:cmake@cmake.org
Subject: Re: [CMake] Windows Path Issues
1. What your environment exactly is? It does not look like Windows only
(because I see in your log: bash-3.1$ cmake -G Unix Makefiles . ), so I
expect you are using something like Cygwin and when you use this kind of
environment you can
have problems with paths. For example C:/software/propgcc/bin/propeller-elf-gcc
is not a valid path for Cygwin, because cygwin uses /cygdrive/ in its path for
things which are located in Windows.
2. When I use cmake on Windows (just Windows, cmd, not Cygwin or else) I use
MinGW Makefiles not Unix Makefiles with GNU compilers.
2014-08-05 19:56 GMT+02:00 da...@zemon.namemailto:da...@zemon.name:
I'm generally a Linux guy but need this project to work on all three main
platforms.
I have my toolchain file working nicely in Linux, but for some reason I'm
getting an error on Windows. Here's top of the console output:
bash-3.1$ cmake -G Unix Makefiles .
-- The C compiler identification is GNU 4.6.1
-- The CXX compiler identification is GNU 4.6.1
-- The COGCXX compiler identification is GNU 4.6.1
-- The ECOGC compiler identification is GNU 4.6.1
-- The ECOGCXX compiler identification is GNU 4.6.1
-- The ASM compiler identification is GNU
-- Found assembler: C:/software/propgcc/bin/propeller-elf-gcc
CMake Error at CMakeLists.txt:6 (project):
The CMAKE_C_COMPILER:
C:/software/propgcc/bin/propeller-elf-gcc
is not a full path to an existing compiler tool.
Tell CMake where to find the compiler by setting either the environment
variable CC or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.
This doesn't make too much sense to me. Anyone know why it would find the
compiler at first and then loose it? The path that it lists is perfectly valid.
Thanks,
David
--
Powered by www.kitware.comhttp://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
--
Ivan Hrasko
abhra...@gmail.commailto:abhra...@gmail.com
--
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,
[CMake] Adding (not replacing) $ORIGIN to automatic build rpath
First, the background on why I want this: Our product uses a licensing library that creates a .so file alongside the executable, and at runtime does a dlopen() on that .so file. But it doesn't use a full path, so we need to put $ORIGIN into the RPATH or users will have to set LD_LIBRARY_PATH to the directory containing the executable. We don't have access to change the library to pass a full path to dlopen(), either. But we link against some other external libraries which might not be in the system path (e.g. the MariaDB LGPL'd client library which isn't currently available as a Debian package). So, setting properties INSTALL_RPATH \$ORIGIN and BUILD_WITH_INSTALL_RPATH won't work because that will replace the automatically determined rpath entirely with $ORIGIN.Is there any way to tell CMake to combine the two just for the build version? (The installed version will put non-system libraries into a self-contained bundle so we'll still want $ORIGIN as the RPATH there.) I haven't found any setting that will do this by scanning the rpath-related CMake variables or target properties. -- Daniel Schepler -- 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
