From mingli.yu at windriver.com Fri Mar 1 04:49:58 2019 From: mingli.yu at windriver.com (Yu, Mingli) Date: Fri, 1 Mar 2019 17:49:58 +0800 Subject: [CMake] make[2]: *** No rule to make target 'sql/sql_yacc.cc', needed by 'libmysqld/CMakeFiles/sql_embedded.dir/__/sql/sql_yacc.cc.o'. Stop. Message-ID: <5C790046.5010902@windriver.com> Hi Expert, I encounter build issue when compile mariadb from https://downloads.mariadb.org/mariadb/10.3.13/ make[2]: *** No rule to make target 'sql/sql_yacc.cc', needed by 'libmysqld/CMakeFiles/sql_embedded.dir/__/sql/sql_yacc.cc.o'. Stop. And the content of libmysqld/CMakeLists.txt as attached, any ideas? Thanks, Mingli -------------- next part -------------- Subject: [meta-webserver][PATCH] apache2: Fix CVE-2018-11763 # Copyright (c) 2006, 2011, Oracle and/or its affiliates. # Copyright (c) 2009, 2018, MariaDB Corporation # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; version 2 of the License. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ADD_DEFINITIONS(-DMYSQL_SERVER -DEMBEDDED_LIBRARY ${SSL_DEFINES}) INCLUDE_DIRECTORIES( ${CMAKE_SOURCE_DIR}/include ${CMAKE_SOURCE_DIR}/libmysqld ${CMAKE_SOURCE_DIR}/sql ${CMAKE_BINARY_DIR}/sql ${PCRE_INCLUDES} ${ZLIB_INCLUDE_DIR} ${SSL_INCLUDE_DIRS} ${SSL_INTERNAL_INCLUDE_DIRS} ) SET(GEN_SOURCES ${CMAKE_BINARY_DIR}/sql/sql_yacc.hh ${CMAKE_BINARY_DIR}/sql/sql_yacc.cc ${CMAKE_BINARY_DIR}/sql/sql_yacc_ora.hh ${CMAKE_BINARY_DIR}/sql/sql_yacc_ora.cc ${CMAKE_BINARY_DIR}/sql/lex_hash.h ) SET_SOURCE_FILES_PROPERTIES(${GEN_SOURCES} PROPERTIES GENERATED TRUE) SET(SQL_EMBEDDED_SOURCES emb_qcache.cc libmysqld.c lib_sql.cc libmysql.c ../sql-common/errmsg.c ../sql-common/client.c ../sql-common/my_user.c ../sql-common/pack.c ../sql-common/client_plugin.c ../sql-common/mysql_async.c ../sql/password.c ../sql/discover.cc ../sql/derror.cc ../sql/field.cc ../sql/field_conv.cc ../sql/field_comp.cc ../sql/filesort_utils.cc ../sql/sql_digest.cc ../sql/filesort.cc ../sql/gstream.cc ../sql/slave.cc ../sql/signal_handler.cc ../sql/handler.cc ../sql/hash_filo.cc ../sql/hostname.cc ../sql/init.cc ../sql/item_buff.cc ../sql/item_cmpfunc.cc ../sql/item.cc ../sql/item_create.cc ../sql/item_func.cc ../sql/item_geofunc.cc ../sql/item_row.cc ../sql/item_strfunc.cc ../sql/item_subselect.cc ../sql/item_sum.cc ../sql/item_timefunc.cc ../sql/item_xmlfunc.cc ../sql/item_jsonfunc.cc ../sql/key.cc ../sql/lock.cc ../sql/log.cc ../sql/log_event.cc ../sql/mf_iocache.cc ../sql/my_decimal.cc ../sql/net_serv.cc ../sql/opt_range.cc ../sql/opt_sum.cc ../sql/parse_file.cc ../sql/procedure.cc ../sql/protocol.cc ../sql/records.cc ../sql/repl_failsafe.cc ../sql/rpl_filter.cc ../sql/rpl_record.cc ../sql/des_key_file.cc ../sql/rpl_injector.cc ../sql/set_var.cc ../sql/spatial.cc ../sql/sp_cache.cc ../sql/sp.cc ../sql/sp_head.cc ../sql/sp_pcontext.cc ../sql/sp_rcontext.cc ../sql/sql_acl.cc ../sql/sql_analyse.cc ../sql/sql_base.cc ../sql/sql_cache.cc ../sql/sql_class.cc ../sql/sql_crypt.cc ../sql/sql_cursor.cc ../sql/sql_db.cc ../sql/sql_delete.cc ../sql/sql_derived.cc ../sql/sql_do.cc ../sql/sql_error.cc ../sql/sql_handler.cc ../sql/sql_get_diagnostics.cc ../sql/sql_help.cc ../sql/sql_insert.cc ../sql/datadict.cc ../sql/sql_admin.cc ../sql/sql_truncate.cc ../sql/sql_reload.cc ../sql/sql_lex.cc ../sql/keycaches.cc ../sql/sql_list.cc ../sql/sql_load.cc ../sql/sql_locale.cc ../sql/sql_binlog.cc ../sql/sql_manager.cc ../sql/sql_parse.cc ../sql/sql_bootstrap.cc ../sql/sql_partition.cc ../sql/sql_plugin.cc ../sql/debug_sync.cc ../sql/opt_table_elimination.cc ../sql/sql_prepare.cc ../sql/sql_rename.cc ../sql/sql_repl.cc ../sql/sql_select.cc ../sql/sql_servers.cc ../sql/group_by_handler.cc ../sql/sql_show.cc ../sql/sql_state.c ../sql/sql_statistics.cc ../sql/sql_string.cc ../sql/sql_tablespace.cc ../sql/sql_table.cc ../sql/sql_test.cc ../sql/sql_trigger.cc ../sql/sql_udf.cc ../sql/sql_union.cc ../sql/sql_update.cc ../sql/sql_view.cc ../sql/sql_profile.cc ../sql/gcalc_tools.cc ../sql/gcalc_slicescan.cc ../sql/strfunc.cc ../sql/table.cc ../sql/thr_malloc.cc ../sql/sql_time.cc ../sql/tztime.cc ../sql/uniques.cc ../sql/unireg.cc ../sql/partition_info.cc ../sql/sql_connect.cc ../sql/scheduler.cc ../sql/sql_audit.cc ../sql/sql_alter.cc ../sql/sql_partition_admin.cc ../sql/event_parse_data.cc ../sql/sql_signal.cc ../sql/sys_vars.cc ${CMAKE_BINARY_DIR}/sql/sql_builtin.cc ../sql/mdl.cc ../sql/transaction.cc ../sql/sql_join_cache.cc ../sql/multi_range_read.cc ../sql/opt_index_cond_pushdown.cc ../sql/opt_subselect.cc ../sql/create_options.cc ../sql/rpl_utility.cc ../sql/rpl_reporting.cc ../sql/sql_expression_cache.cc ../sql/my_apc.cc ../sql/my_apc.h ../sql/my_json_writer.cc ../sql/my_json_writer.h ../sql/rpl_gtid.cc ../sql/sql_explain.cc ../sql/sql_explain.h ../sql/sql_analyze_stmt.cc ../sql/sql_analyze_stmt.h ../sql/compat56.cc ../sql/sql_type.cc ../sql/sql_type.h ../sql/table_cache.cc ../sql/mf_iocache_encr.cc ../sql/item_inetfunc.cc ../sql/wsrep_dummy.cc ../sql/encryption.cc ../sql/item_windowfunc.cc ../sql/sql_window.cc ../sql/sql_cte.cc ../sql/sql_sequence.cc ../sql/sql_sequence.h ../sql/ha_sequence.cc ../sql/ha_sequence.h ../sql/temporary_tables.cc ../sql/session_tracker.cc ../sql/proxy_protocol.cc ../sql/sql_tvc.cc ../sql/sql_tvc.h ../sql/opt_split.cc ../sql/item_vers.cc ${GEN_SOURCES} ${MYSYS_LIBWRAP_SOURCE} ) ADD_CONVENIENCE_LIBRARY(sql_embedded ${SQL_EMBEDDED_SOURCES}) DTRACE_INSTRUMENT(sql_embedded) ADD_DEPENDENCIES(sql_embedded GenError GenServerSource) # On Windows, static embedded server library is called mysqlserver.lib # On Unix, it is libmysqld.a IF(WIN32) SET(MYSQLSERVER_OUTPUT_NAME mysqlserver) SET(COMPONENT_MYSQLSERVER "Embedded") SET(COMPONENT_LIBMYSQLD "Embedded") ELSE() SET(MYSQLSERVER_OUTPUT_NAME mariadbd) SET(COMPONENT_MYSQLSERVER "Development") SET(COMPONENT_LIBMYSQLD "Server") ENDIF() SET(LIBS dbug strings mysys mysys_ssl pcre vio ${ZLIB_LIBRARY} ${SSL_LIBRARIES} ${LIBWRAP} ${LIBCRYPT} ${LIBDL} ${MYSQLD_STATIC_PLUGIN_LIBS} sql_embedded ) # Some storage engine were compiled for embedded specifically # (with corresponding target ${engine}_embedded) SET(EMBEDDED_LIBS) FOREACH(LIB ${LIBS}) IF(TARGET ${LIB}_embedded) LIST(APPEND EMBEDDED_LIBS ${LIB}_embedded) ELSE() LIST(APPEND EMBEDDED_LIBS ${LIB}) ENDIF() ENDFOREACH() MERGE_LIBRARIES(mysqlserver STATIC ${EMBEDDED_LIBS} OUTPUT_NAME ${MYSQLSERVER_OUTPUT_NAME} COMPONENT ${COMPONENT_MYSQLSERVER}) IF(UNIX) INSTALL_SYMLINK(libmysqld.a mysqlserver ${INSTALL_LIBDIR} ${COMPONENT_MYSQLSERVER}) ENDIF() INSTALL(FILES embedded_priv.h DESTINATION ${INSTALL_INCLUDEDIR}/server/private COMPONENT ${COMPONENT_MYSQLSERVER}) SET(CLIENT_API_FUNCTIONS_5_1 get_tty_password mysql_thread_end mysql_thread_init myodbc_remove_escape mysql_affected_rows mysql_autocommit mysql_stmt_bind_param mysql_stmt_bind_result mysql_change_user mysql_character_set_name mysql_close mysql_commit mysql_data_seek mysql_debug mysql_dump_debug_info mysql_eof mysql_errno mysql_error mysql_escape_string mysql_hex_string mysql_stmt_execute mysql_stmt_fetch mysql_stmt_fetch_column mysql_fetch_field mysql_fetch_field_direct mysql_fetch_fields mysql_fetch_lengths mysql_fetch_row mysql_field_count mysql_field_seek mysql_field_tell mysql_free_result mysql_get_parameters mysql_get_client_info mysql_get_host_info mysql_get_proto_info mysql_get_server_info mysql_get_client_version mysql_get_ssl_cipher mysql_info mysql_init mysql_insert_id mysql_kill mysql_set_server_option mysql_list_dbs mysql_list_fields mysql_list_processes mysql_list_tables mysql_more_results mysql_next_result mysql_num_fields mysql_num_rows mysql_options mysql_stmt_param_count mysql_stmt_param_metadata mysql_ping mysql_stmt_result_metadata mysql_query mysql_read_query_result mysql_real_connect mysql_real_escape_string mysql_real_query mysql_refresh mysql_rollback mysql_row_seek mysql_row_tell mysql_select_db mysql_stmt_send_long_data mysql_send_query mysql_shutdown mysql_ssl_set mysql_stat mysql_stmt_affected_rows mysql_stmt_close mysql_stmt_reset mysql_stmt_data_seek mysql_stmt_errno mysql_stmt_error mysql_stmt_free_result mysql_stmt_num_rows mysql_stmt_row_seek mysql_stmt_row_tell mysql_stmt_store_result mysql_store_result mysql_thread_id mysql_thread_safe mysql_use_result mysql_warning_count mysql_stmt_sqlstate mysql_sqlstate mysql_get_server_version mysql_stmt_prepare mysql_stmt_init mysql_stmt_insert_id mysql_stmt_attr_get mysql_stmt_attr_set mysql_stmt_field_count mysql_set_local_infile_default mysql_set_local_infile_handler mysql_embedded mysql_server_init mysql_server_end mysql_set_character_set mysql_get_character_set_info # These are documented in Paul DuBois' MySQL book, # so we treat them as part of the de-facto API. handle_options load_defaults free_defaults my_print_help ) SET(CLIENT_API_FUNCTIONS_5_5 my_progname mysql_stmt_next_result # Charsets my_charset_bin my_charset_latin1 my_charset_utf8_general_ci # Client plugins mysql_client_find_plugin mysql_client_register_plugin mysql_load_plugin mysql_load_plugin_v mysql_plugin_options # Async API mysql_get_timeout_value mysql_get_timeout_value_ms mysql_get_socket mysql_autocommit_cont mysql_autocommit_start mysql_change_user_cont mysql_change_user_start mysql_close_cont mysql_close_start mysql_commit_cont mysql_commit_start mysql_dump_debug_info_cont mysql_dump_debug_info_start mysql_fetch_row_cont mysql_fetch_row_start mysql_free_result_cont mysql_free_result_start mysql_kill_cont mysql_kill_start mysql_list_dbs_cont mysql_list_dbs_start mysql_list_fields_cont mysql_list_fields_start mysql_list_processes_cont mysql_list_processes_start mysql_list_tables_cont mysql_list_tables_start mysql_next_result_cont mysql_next_result_start mysql_ping_cont mysql_ping_start mysql_query_cont mysql_query_start mysql_read_query_result_cont mysql_read_query_result_start mysql_real_connect_cont mysql_real_connect_start mysql_real_query_cont mysql_real_query_start mysql_refresh_cont mysql_refresh_start mysql_rollback_cont mysql_rollback_start mysql_select_db_cont mysql_select_db_start mysql_send_query_cont mysql_send_query_start mysql_set_character_set_cont mysql_set_character_set_start mysql_set_server_option_cont mysql_set_server_option_start mysql_shutdown_cont mysql_shutdown_start mysql_stat_cont mysql_stat_start mysql_stmt_close_cont mysql_stmt_close_start mysql_stmt_execute_cont mysql_stmt_execute_start mysql_stmt_fetch_cont mysql_stmt_fetch_start mysql_stmt_free_result_cont mysql_stmt_free_result_start mysql_stmt_next_result_cont mysql_stmt_next_result_start mysql_stmt_prepare_cont mysql_stmt_prepare_start mysql_stmt_reset_cont mysql_stmt_reset_start mysql_stmt_send_long_data_cont mysql_stmt_send_long_data_start mysql_stmt_store_result_cont mysql_stmt_store_result_start mysql_store_result_cont mysql_store_result_start #dynamic columns api dynamic_column_create dynamic_column_create_many dynamic_column_update dynamic_column_update_many dynamic_column_exists dynamic_column_list dynamic_column_get dynamic_column_prepare_decimal mariadb_dyncol_create_many_num mariadb_dyncol_create_many_named mariadb_dyncol_update_many_num mariadb_dyncol_update_many_named mariadb_dyncol_exists_num mariadb_dyncol_exists_named mariadb_dyncol_free mariadb_dyncol_list_num mariadb_dyncol_list_named mariadb_dyncol_get_num mariadb_dyncol_get_named mariadb_dyncol_has_names mariadb_dyncol_check mariadb_dyncol_json mariadb_dyncol_val_str mariadb_dyncol_val_long mariadb_dyncol_val_double mariadb_dyncol_unpack mariadb_dyncol_unpack_free mariadb_dyncol_column_cmp_named mariadb_dyncol_column_count mariadb_dyncol_prepare_decimal # mariadb_deinitialize_ssl # low-level API to MySQL protocol mysql_net_read_packet mysql_net_field_length # Added in MariaDB-10.0 to stay compatible with MySQL-5.6, yuck! mysql_options4 ) SET(CLIENT_API_FUNCTIONS ${CLIENT_API_FUNCTIONS_5_1} ${CLIENT_API_FUNCTIONS_5_5} ) # List of exported functions in embedded (client api except client plugin or # async (*_start/*_cont functions) SET(EMBEDDED_API) FOREACH(f ${CLIENT_API_FUNCTIONS}) IF(f MATCHES "plugin|_start$|_cont$") # Ignore functions, embedded does not export them ELSE() SET(EMBEDDED_API ${EMBEDDED_API} ${f}) ENDIF() ENDFOREACH() IF(NOT DISABLE_SHARED) MERGE_LIBRARIES(libmysqld SHARED mysqlserver EXPORTS ${EMBEDDED_API} COMPONENT ${COMPONENT_LIBMYSQLD}) IF(UNIX) # Name the shared library, handle versioning (provides same api as client # library hence the same version) SET_TARGET_PROPERTIES(libmysqld PROPERTIES OUTPUT_NAME mariadbd SOVERSION "${SHARED_LIB_MAJOR_VERSION}") INSTALL_SYMLINK(libmysqld.so libmysqld ${INSTALL_LIBDIR} ${COMPONENT_LIBMYSQLD}) # Clean direct output flags, as 2 targets have the same base name # libmysqld SET_TARGET_PROPERTIES(libmysqld PROPERTIES CLEAN_DIRECT_OUTPUT 1) TARGET_LINK_LIBRARIES(libmysqld ${CRC32_LIBRARY}) SET_TARGET_PROPERTIES(mysqlserver PROPERTIES CLEAN_DIRECT_OUTPUT 1) TARGET_LINK_LIBRARIES(mysqlserver ${CRC32_LIBRARY}) IF(LIBMYSQLD_SO_EXTRA_LIBS) TARGET_LINK_LIBRARIES(libmysqld ${LIBMYSQLD_SO_EXTRA_LIBS}) ENDIF() ENDIF() ENDIF() From kyle.edwards at kitware.com Fri Mar 1 09:58:01 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Fri, 01 Mar 2019 09:58:01 -0500 Subject: [CMake] make[2]: *** No rule to make target 'sql/sql_yacc.cc', needed by 'libmysqld/CMakeFiles/sql_embedded.dir/__/sql/sql_yacc.cc.o'. Stop. In-Reply-To: <5C790046.5010902@windriver.com> References: <5C790046.5010902@windriver.com> Message-ID: <1551452281.22984.2.camel@kitware.com> On Fri, 2019-03-01 at 17:49 +0800, Yu, Mingli wrote: > Hi Expert, > > I encounter build issue when compile mariadb from? > https://downloads.mariadb.org/mariadb/10.3.13/ > > > make[2]: *** No rule to make target 'sql/sql_yacc.cc', needed by? > 'libmysqld/CMakeFiles/sql_embedded.dir/__/sql/sql_yacc.cc.o'.??Stop. > > And the content of libmysqld/CMakeLists.txt as attached, any ideas? I don't see anything in this file for actually *generating* sql_yacc.cc. This should be generated by using add_custom_command() to call yacc. Is that happening in another file? Kyle From robert.maynard at kitware.com Fri Mar 1 14:28:50 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 1 Mar 2019 14:28:50 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.14.0-rc3 is ready for testing Message-ID: I am proud to announce the third CMake 3.14 release candidate. https://cmake.org/download/ The first two 3.14.0 release candidates included the FindOcatave module. This has been removed in rc3 pending further development. Documentation is available at: https://cmake.org/cmake/help/v3.14 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.14/release/3.14.html Some of the more significant changes in CMake 3.14 are: * Support for running CMake on Windows XP and Windows Vista has been dropped. The precompiled Windows binaries provided on "cmake.org" now require Windows 7 or higher. * CMake now supports Cross Compiling for iOS, tvOS, or watchOS using simple toolchain files. * The "Visual Studio 16 2019" generator was added. This is experimental and based on "Visual Studio 2019 Preview 4" because this version of VS has not been released. The VS 2019 generator differs from generators for earlier versions in that it does not provide variants that specify the target platform in the generator name. Instead "CMAKE_GENERATOR_PLATFORM" must be used, e.g. through the "-A" command-line option. Furthermore, the default target platform (architecture) is now based on the *host* platform. The VS host toolset selection is now based on the host architecture as well. * The "Green Hills MULTI" generator has been updated to include Object Library support, support for target renaming and destination output control properties, and other improvements. * A "CMAKE_BUILD_RPATH_USE_ORIGIN" variable and corresponding "BUILD_RPATH_USE_ORIGIN" target property were added to enable use of relative runtime paths (RPATHs). This helps achieving relocatable and reproducible builds that are invariant of the build directory. * The "install(TARGETS)" command learned how to install to an appropriate default directory for a given target type, based on variables from the "GNUInstallDirs" module and built-in defaults, in lieu of a "DESTINATION" argument. * The "install(FILES)" and "install(DIRECTORY)" commands learned a new set of parameters for installing files as a file type, setting the destination based on the appropriate variables from "GNUInstallDirs" and built-in defaults, in lieu of a "DESTINATION" argument. * The "install(CODE)" and "install(SCRIPT)" commands learned to support generator expressions. See policy "CMP0087". * The "if()" command gained support for checking if cache variables are defined with the "DEFINED CACHE{VAR}" syntax. * A file-based api for clients to get semantic buildsystem information has been added. See the "cmake-file-api(7)" manual. This is intended to replace the "cmake-server(7)" mode for IDEs. * The "cmake(1)" Build Tool Mode ("cmake --build") gained "-- verbose" and "-v" options to specify verbose build output. Some generators such as Xcode don't support this option currently. * The "cmake(1)" "-E compare_files" command learned a new "--ignore- eol" option to specify that end-of-line differences (e.g. LF vs CRLF) should be ignored when comparing files. CMake 3.14 Release Notes ************************ Changes made since CMake 3.13 include the following. New Features ============ Generators ---------- * The "Visual Studio 16 2019" generator was added. This is experimental and based on "Visual Studio 2019 Preview 4" because this version of VS has not been released. The VS 2019 generator differs from generators for earlier versions in that it does not provide variants that specify the target platform in the generator name. Instead "CMAKE_GENERATOR_PLATFORM" must be used, e.g. through the "-A" command-line option. Furthermore, the default target platform (architecture) is now based on the *host* platform. The VS host toolset selection is now based on the host architecture as well. * The "Green Hills MULTI" generator has been updated: * Now supports Object Libraries. * Now warns on unsupported project types such as shared libraries. * Now generates a top-level ".top.gpj" for each directory calling the "project()" command. The top-level project file "default.gpj" is no longer created. * Now honors target renaming and destination output control properties such as "RUNTIME_OUTPUT_DIRECTORY" and "OUTPUT_NAME". This also fixes support for installation rules generated by "install()". * Now honors source file properties "INCLUDE_DIRECTORIES", "COMPILE_DEFINITIONS", and "COMPILE_OPTIONS". * Now supports Dynamic Download Integrity Applications which did not include Integrate Files via "GHS_INTEGRITY_APP" and setting a target link flag of "-dynamic". * The contents of project files now sorts sources groups and files by name. Set the "GHS_NO_SOURCE_GROUP_FILE" target property to "ON" to generate a single project file for the target instead of a project file for each source group. Set the "CMAKE_GHS_NO_SOURCE_GROUP_FILE" variable to enable this for all targets. File-Based API -------------- * A file-based api for clients to get semantic buildsystem information has been added. See the "cmake-file-api(7)" manual. This is intended to replace the "cmake-server(7)" mode for IDEs. Platforms --------- * CMake now supports Cross Compiling for iOS, tvOS, or watchOS using simple toolchain files. Command-Line ------------ * The "cmake(1)" Build Tool Mode ("cmake --build") gained "-- verbose" and "-v" options to specify verbose build output. Some generators such as Xcode don't support this option currently. * The "cmake(1)" "-E compare_files" command learned a new "--ignore- eol" option to specify that end-of-line differences (e.g. LF vs CRLF) should be ignored when comparing files. * The "cmake-gui(1)" dialog gained new "-S" and "-B" arguments to explicitly specify source and build directories. Commands -------- * The "file()" command learned a new sub-command, "CREATE_LINK", which can be used to create hard or symbolic links. * The "file()" command learned a new sub-command, "READ_SYMLINK", which can be used to determine the path that a symlink points to. * The "file()" command gained a "SIZE" mode to get the size of a file on disk. * The "find_package()" command learned to optionally resolve symbolic links in the paths to package configuration files. See the "CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS" variable. * The "get_filename_component()" command gained new "LAST_EXT" and "NAME_WLE" variants to work with the extension after the last "." in the name. * The "if()" command gained support for checking if cache variables are defined with the "DEFINED CACHE{VAR}" syntax. * The "install(CODE)" and "install(SCRIPT)" commands learned to support generator expressions. See policy "CMP0087". * The "install(TARGETS)" command learned how to install to an appropriate default directory for a given target type, based on variables from the "GNUInstallDirs" module and built-in defaults, in lieu of a "DESTINATION" argument. * The "install(FILES)" and "install(DIRECTORY)" commands learned a new set of parameters for installing files as a file type, setting the destination based on the appropriate variables from "GNUInstallDirs" and built-in defaults, in lieu of a "DESTINATION" argument. * The "list()" operations "REMOVE_ITEM", "REMOVE_DUPLICATES", "SORT", "REVERSE", and "FILTER" all now accept a non-existent variable as the list since these operations on empty lists is also the empty list. * The "list()" operation "REMOVE_AT" now indicates that the given indices are invalid for a non-existent variable or empty list. * The "try_compile()" and "try_run()" commands gained a new "LINK_OPTIONS" option. Variables --------- * A "CMAKE_BUILD_RPATH_USE_ORIGIN" variable and corresponding "BUILD_RPATH_USE_ORIGIN" target property were added to enable use of relative runtime paths (RPATHs). This helps achieving relocatable and reproducible builds that are invariant of the build directory. Properties ---------- * A "CMAKE_ROLE" global property was added to allow scripts to determine whether they're running in project mode, script mode, find-package mode, CTest, or CPack. * The "CUDA_RESOLVE_DEVICE_SYMBOLS" target property is now supported on shared library, module library, and executable targets. Previously it was only honored on static libraries. * The "EXCLUDE_FROM_ALL" target property was created to override the setting of its directory. A target will now be built as part of "all" if its "EXCLUDE_FROM_ALL" property is set to "OFF", even if its containing directory is marked as "EXCLUDE_FROM_ALL". * "INTERFACE_POSITION_INDEPENDENT_CODE" target property gains the support of "generator expressions". Modules ------- * The family of modules to check capabilities (like "CheckCSourceCompiles") gain capability to manage "LINK_OPTIONS". * A "CheckFortranSourceRuns" module was added to provide a "check_fortran_source_runs()" command to check if a Fortran source snippet compiles and runs. * The "CMakePackageConfigHelpers" module?s "write_basic_package_version_file()" command gained a new "ARCH_INDEPENDENT" option for supporting architecture-independent packages. * The "ExternalProject" module "ExternalProject_Add()" command gained "LOG_DIR" and "LOG_MERGED_STDOUTERR" options to control logging. * The "ExternalProject" module "ExternalProject_Add()" command gained "LOG_PATCH" to optionally log the patch step. * The "ExternalProject" module's "ExternalProject_Add()" command learned to apply "SOURCE_SUBDIR" when "BUILD_IN_SOURCE" is also used. The "BUILD_COMMAND" is run in the given "SOURCE_SUBDIR" of the "SOURCE_DIR". * The "FetchContent" module gained a new "FetchContent_MakeAvailable()" command. It accepts a list of dependency names, which it then iterates over, populating and adding each one to the main build using the canonical pattern. This significantly reduces the amount of boilerplate needed in a project. * The "FindBISON" module's "BISON_TARGET" command now runs "bison" with "CMAKE_CURRENT_BINARY_DIR" as the working directory. See policy "CMP0088". * The "FindCURL" module gained support for requesting protocols as package components. * The "FindFontconfig" module was added to find fontconfig. * The "FindGDAL" module now provides imported targets. * The "FindGIF" module now provides imported targets. * The "FindGit" module now provides an imported target for the Git executable. * The "FindIce" module learned to find "slice2confluence" and "slice2matlab". * The "FindLibinput" module was added to find libinput. * The "FindLibLZMA" module now provides imported targets. * The "FindMatlab" module gained new options "R2017b" and "R2018a" to specify the MEX API version to use; these options mirror the new options to the "mex" command in MATLAB R2018a. The option "MX_LIBRARY" is no longer needed. * The "FindPostgreSQL" module now provides imported targets. * The "FindPython", "FindPython2", and "FindPython3" modules gained support for "NumPy" component. * The "FindPython2", "FindPython3", and "FindPython" modules now support running in script mode by skipping the creation of imported targets and helper functions. * The "FindSQLite3" module was added to find the SQLite v3.x library. * The "FindX11" had the following variables renamed in order to match their library names rather than header names. The old variables are provided for compatibility: * "X11_Xxf86misc_INCLUDE_PATH" instead of "X11_xf86misc_INCLUDE_PATH" * "X11_Xxf86misc_LIB" instead of "X11_xf86misc_LIB" * "X11_Xxf86misc_FOUND" instead of "X11_xf86misc_FOUND" * "X11_Xxf86vm_INCLUDE_PATH" instead of "X11_xf86vmode_INCLUDE_PATH" * "X11_Xxf86vm_LIB" instead of "X11_xf86vmode_LIB" * "X11_Xxf86vm_FOUND" instead of "X11_xf86vmode_FOUND" * "X11_xkbfile_INCLUDE_PATH" instead of "X11_Xkbfile_INCLUDE_PATH" * "X11_xkbfile_LIB" instead of "X11_Xkbfile_LIB" * "X11_xkbfile_FOUND" instead of "X11_Xkbfile_FOUND" * "X11_Xtst_INCLUDE_PATH" instead of "X11_XTest_INCLUDE_PATH" * "X11_Xtst_LIB" instead of "X11_XTest_LIB" * "X11_Xtst_FOUND" instead of "X11_XTest_FOUND" * "X11_Xss_INCLUDE_PATH" instead of "X11_Xscreensaver_INCLUDE_PATH" * "X11_Xss_LIB" instead of "X11_Xscreensaver_LIB" * "X11_Xss_FOUND" instead of "X11_Xscreensaver_FOUND" The following variables are deprecated completely since they were essentially duplicates: * "X11_Xinput_INCLUDE_PATH" (use "X11_Xi_INCLUDE_PATH") * "X11_Xinput_LIB" (use "X11_Xi_LIB") * "X11_Xinput_FOUND" (use "X11_Xi_FOUND") * The "FindX11" now provides "X11_Xext_INCLUDE_PATH". * The "FindX11" now provides imported targets. * The "UseSWIG" module learned to pass "-module " to the "SWIG" compiler if the file property "SWIG_MODULE_NAME" is defined. See policy "CMP0086". * The "UseSWIG" module gained an option to specify "SWIG" source file extensions. Generator Expressions --------------------- * The "$" and "$" "generator expressions" were added. * The "$" generator expression now correctly handles an empty argument. See "CMP0085" for details. Autogen ------- * The "AUTOMOC_EXECUTABLE", "AUTORCC_EXECUTABLE", and "AUTOUIC_EXECUTABLE" target properties were added. They all take a path to an executable and force automoc/autorcc/autouic to use this executable. Setting these will also prevent the configure time testing for these executables. This is mainly useful when you build these tools yourself. * The new variables "CMAKE_GLOBAL_AUTOGEN_TARGET", "CMAKE_GLOBAL_AUTOGEN_TARGET_NAME", "CMAKE_GLOBAL_AUTORCC_TARGET" and "CMAKE_GLOBAL_AUTORCC_TARGET_NAME" control the generation of global "autogen" and "autorcc" targets. * A new "CMAKE_AUTOGEN_ORIGIN_DEPENDS" variable and "AUTOGEN_ORIGIN_DEPENDS" target property may be set to enable or disable forwarding of the origin target dependencies to the corresponding "_autogen" target. CTest ----- * "ctest(1)" gained a "--show-only=json-v1" option to show the list of tests in a machine-readable JSON format. See the Show as JSON Object Model section of the manual. * The "ctest_submit()" command learned a new "Done" part that can be used to inform CDash that a build is complete and that no more parts will be uploaded. * CTest learned to accept the dashboard server submission URL from a single variable. See the "SubmitURL" setting in "ctest(1)", the "CTEST_SUBMIT_URL" variable, and the "SUBMIT_URL" argument of the "ctest_submit()" command. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0064" and "CMP0065" ("CMP0063" and below were already deprecated). The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. * The "Xcode" generator deprecated support for Xcode versions prior to Xcode 5. Support for those will be dropped in a future version of CMake. * The "FindQt" module is no longer used by the "find_package()" command as a find module. This allows the Qt Project upstream to optionally provide its own "QtConfig.cmake" package configuration file and have applications use it via "find_package(Qt)" rather than "find_package(Qt CONFIG)". See policy "CMP0084". * Support for running CMake on Windows XP and Windows Vista has been dropped. The precompiled Windows binaries provided on "cmake.org" now require Windows 7 or higher. * CTest no longer supports submissions via "ftp", "scp", "cp", and "xmlrpc". CDash is the only maintained testing dashboard for CTest, and it only supports submissions over "http" and "https". Other Changes ============= * Object library linking has been fixed to propagate private link libraries of object libraries to consuming targets. * Install rules under "add_subdirectory()" now interleave with those in the calling directory. See policy "CMP0082" for details. * CMake now imposes a maximum recursion limit to prevent a stack overflow on scripts that recurse infinitely. The limit can be adjusted at runtime with "CMAKE_MAXIMUM_RECURSION_DEPTH". * When using cppcheck via the "CMAKE__CPPCHECK" variable or "_CPPCHECK" property, the build will now fail if "cppcheck" returns non-zero as configured by its command-line options. * Required link options to manage Position Independent Executable are now added when "POSITION_INDEPENDENT_CODE" is set. The project is responsible for using the "CheckPIESupported" module to check for "PIE" support to ensure that the "POSITION_INDEPENDENT_CODE" target property will be honored at link time for executables. This behavior is controlled by policy "CMP0083". * Visual Studio Generators for VS 2010 and above learned to support the "VS_DEBUGGER_*" properties on targets created via "add_custom_target()". * The "CPack" module no longer defaults to the "paxr" value in the "CPACK_DEBIAN_ARCHIVE_TYPE" variable, because "dpkg" has never supported the PAX tar format. The "paxr" value will be mapped to "gnutar" and a deprecation message emitted. * CMake no longer issues a warning if a target listed in an "install(TARGETS)" command has its "EXCLUDE_FROM_ALL" property set to true. ---------------------------------------------------------------------------- Changes made since CMake 3.14.0-rc2: Brad King (17): Prefix implicit include directories with sysroot on construction Restore unconditional use of "standard" include directories Do not explicitly report "standard" include directories as implicit Use -? instead of /? to test compiler for MSVC-like command-line support VS: Factor out a method to set the Windows SDK version internally VS: Tell VS 2019 to use Windows SDK 8.1 explicitly when needed Fortran: Do not suppress explicit use of implicit include directories Tests: Restore support for CMake 3.1 through 3.6 with MSVC FindThreads: Fix libc check to use proper header for pthread_kill VS: Fix detection of clang-cl with -T llvm include_external_msproject: Restore support for EXCLUDE_FROM_ALL FindOctave: Remove module pending further work FindThreads: Revert libc symbol check to pthread_create VS: Drop workaround needed only for VS 2019 preview 2 and 3 Help: Update VS 2019 generator release note for preview 4 ExternalProject: Restore default log dir with custom stamp dir CMake 3.14.0-rc3 Christian Pfeiffer (1): FindJNI: Unify path search, fix support for Java 9 Craig Scott (12): Help: Remove outdated statement about get_filename_component() Help: Clarify and improve readability of link-related file subcommands Release notes: Make ExternalProject dot points consistent Help: Clarify ExternalProject_Add()'s LOG_MERGED_STDOUTERR behavior EXCLUDE_FROM_ALL: Don't warn if installing target excluded from all CheckLangSourceRuns: Capture run output to log files Help: User-provided variable names for try_* commands Help: try_compile() readability and grammar improvements Help: Consistency in try_compile() docs for target type Help: Caveat for try_compile() and CMAKE_TRY_COMPILE_PLATFORM_VARIABLES Help: Add release note for new ARCH_INDEPENDENT option Help: Fix minor inaccuracies of what BUILD_RPATH_USE_ORIGIN affects Kyle Edwards (1): CMAKE_ROLE: Fix value in --build for Visual Studio generators Maikel van den Hurk (1): Add ASM Compiler detection for QCC Marc Chevrier (1): PIE link options: No warning when policy CMP0083 is not set. Mathieu Garaud (1): Extend C++17/C++14 feature checks to cover more standard library APIs Paul Seyfert (1): Help: Fix --build-and-test synopsis in ctest(1) Robert Maynard (1): CUDA: Filter out -framework arguments during device linking Sebastian Holtermann (2): Autogen: Add output caching GetExecutableTestOutput Autogen: Use output caching GetExecutableTestOutput Yves Frederix (1): FindBoost: Find boost libraries built with --layout=tagged From mario at emmenlauer.de Sun Mar 3 05:28:43 2019 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Sun, 3 Mar 2019 11:28:43 +0100 Subject: [CMake] install(EXPORT "XXXTargets" ...) includes target "XXX" which requires target "caffe2_library"... Message-ID: Dear all, I'm trying to build a C++ project based on PyTorch with cmake package configuration files. The includes and libs generally seem to work after doing: find_package(Torch 1.0.0 REQUIRED) But when I try to generate package configuration for my library, cmake shows an error: CMake Error: install(EXPORT "XXXTargets" ...) includes target "XXX" which requires target "caffe2_library" that is not in the export set. I read a number of suggestions but they refer to the case where "caffe2_library" would be one of my generated targets. I tried to generate a target for "caffe2_library" and failed, and now I'm a bit at a loss. Can someone lend me a hand? Here is a cropped version of my CMakeLists.txt: cmake_minimum_required(VERSION 3.8 FATAL_ERROR) project(XXX VERSION 1.0.0) find_package(Torch 1.0.0 REQUIRED) add_library(${PROJECT_NAME} include/XXX.hh src/XXX.cc) target_include_directories(${PROJECT_NAME} PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/src ${CMAKE_CURRENT_BINARY_DIR} PUBLIC $ $ ${TORCH_INCLUDE_DIRS}) target_link_libraries(${PROJECT_NAME} PUBLIC ${TORCH_LIBRARIES}) export(TARGETS ${PROJECT_NAME} FILE cmake/${PROJECT_NAME}Targets.cmake) export(PACKAGE ${PROJECT_NAME}) install(TARGETS ${PROJECT_NAME} EXPORT ${PROJECT_NAME}Targets ARCHIVE DESTINATION lib LIBRARY DESTINATION lib RUNTIME DESTINATION bin INCLUDES DESTINATION include) install(EXPORT ${PROJECT_NAME}Targets DESTINATION lib/cmake/) All the best, Mario Emmenlauer From knut.klingbeil at io-warnemuende.de Sun Mar 3 15:17:22 2019 From: knut.klingbeil at io-warnemuende.de (Knut Klingbeil) Date: Sun, 3 Mar 2019 21:17:22 +0100 Subject: [CMake] Does FindMPI affects INSTALL_RPATH? Message-ID: Dear list, sorry for the stupid question, but I wonder whether I am doing something wrong... I have to use some rpath information that is stored in the LDFLAGS environment variable of the hosting system. A serial compilation works fine, the rpath is correctly set in the build and install binary. However, changing to a parallel compilation and using FindMPI, the rpath of the libs is only available in the build binary. I can fix it by manually setting -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=ON, but is this on purpose? Thanks and Cheers, Knut -- Dr. Knut Klingbeil Dept. for Physical Oceanography and Instrumentation Leibniz Institute for Baltic Sea Research Seestrasse 15 18119 Rostock-Warnemuende, Germany http://www.io-warnemuende.de/kk.html mail : knut.klingbeil at io-warnemuende.de phone: +49 - 381 - 5197 - 153 fax : +49 - 381 - 5197 - 114 From knut.klingbeil at io-warnemuende.de Sun Mar 3 15:21:05 2019 From: knut.klingbeil at io-warnemuende.de (Knut Klingbeil) Date: Sun, 3 Mar 2019 21:21:05 +0100 Subject: [CMake] Does FindMPI affects INSTALL_RPATH? Message-ID: <13c54a64-062d-742f-d5da-71d637a83db1@io-warnemuende.de> Dear list, sorry for possible double-posting... first post sent before confirming the subscription request :-) I have to use some rpath information that is stored in the LDFLAGS environment variable of the hosting system. A serial compilation works fine, the rpath is correctly set in the build and install binary. However, changing to a parallel compilation and using FindMPI, the rpath is only available in the build binary. I can fix it by manually setting -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=ON, but is this on purpose? Thanks and Cheers, Knut -- Dr. Knut Klingbeil Dept. for Physical Oceanography and Instrumentation Leibniz Institute for Baltic Sea Research Seestrasse 15 18119 Rostock-Warnemuende, Germany http://www.io-warnemuende.de/kk.html mail : knut.klingbeil at io-warnemuende.de phone: +49 - 381 - 5197 - 153 fax : +49 - 381 - 5197 - 114 From mingli.yu at windriver.com Sun Mar 3 22:49:21 2019 From: mingli.yu at windriver.com (Yu, Mingli) Date: Mon, 4 Mar 2019 11:49:21 +0800 Subject: [CMake] make[2]: *** No rule to make target 'sql/sql_yacc.cc', needed by 'libmysqld/CMakeFiles/sql_embedded.dir/__/sql/sql_yacc.cc.o'. Stop. In-Reply-To: <1551452281.22984.2.camel@kitware.com> References: <5C790046.5010902@windriver.com> <1551452281.22984.2.camel@kitware.com> Message-ID: <5C7CA041.5030108@windriver.com> On 2019?03?01? 22:58, Kyle Edwards wrote: > On Fri, 2019-03-01 at 17:49 +0800, Yu, Mingli wrote: >> Hi Expert, >> >> I encounter build issue when compile mariadb from >> https://downloads.mariadb.org/mariadb/10.3.13/ >> >> >> make[2]: *** No rule to make target 'sql/sql_yacc.cc', needed by >> 'libmysqld/CMakeFiles/sql_embedded.dir/__/sql/sql_yacc.cc.o'. Stop. >> >> And the content of libmysqld/CMakeLists.txt as attached, any ideas? > > I don't see anything in this file for actually *generating* > sql_yacc.cc. This should be generated by using add_custom_command() to > call yacc. Is that happening in another file? Hi Kyle, Thanks very much for your respond! The CMakeLists.txt as attached as CMakeLists1.txt is under /source/libmysqld/CMakeLists.txt and there are some logics about sql_yacc.cc is in CMakeLists2.txt which actually under /source/sql/CMakeLists.txt. Is there any means to make the logic run in /source/sql/CMakeLists.txt before which is in /source/libmysqld/CMakeLists.txt? Thanks, > > Kyle > -------------- next part -------------- Subject: [meta-webserver][PATCH] apache2: Fix CVE-2018-11763 # Copyright (c) 2006, 2011, Oracle and/or its affiliates. # Copyright (c) 2009, 2018, MariaDB Corporation # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; version 2 of the License. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ADD_DEFINITIONS(-DMYSQL_SERVER -DEMBEDDED_LIBRARY ${SSL_DEFINES}) INCLUDE_DIRECTORIES( ${CMAKE_SOURCE_DIR}/include ${CMAKE_SOURCE_DIR}/libmysqld ${CMAKE_SOURCE_DIR}/sql ${CMAKE_BINARY_DIR}/sql ${PCRE_INCLUDES} ${ZLIB_INCLUDE_DIR} ${SSL_INCLUDE_DIRS} ${SSL_INTERNAL_INCLUDE_DIRS} ) SET(GEN_SOURCES ${CMAKE_BINARY_DIR}/sql/sql_yacc.hh ${CMAKE_BINARY_DIR}/sql/sql_yacc.cc ${CMAKE_BINARY_DIR}/sql/sql_yacc_ora.hh ${CMAKE_BINARY_DIR}/sql/sql_yacc_ora.cc ${CMAKE_BINARY_DIR}/sql/lex_hash.h ) SET_SOURCE_FILES_PROPERTIES(${GEN_SOURCES} PROPERTIES GENERATED TRUE) SET(SQL_EMBEDDED_SOURCES emb_qcache.cc libmysqld.c lib_sql.cc libmysql.c ../sql-common/errmsg.c ../sql-common/client.c ../sql-common/my_user.c ../sql-common/pack.c ../sql-common/client_plugin.c ../sql-common/mysql_async.c ../sql/password.c ../sql/discover.cc ../sql/derror.cc ../sql/field.cc ../sql/field_conv.cc ../sql/field_comp.cc ../sql/filesort_utils.cc ../sql/sql_digest.cc ../sql/filesort.cc ../sql/gstream.cc ../sql/slave.cc ../sql/signal_handler.cc ../sql/handler.cc ../sql/hash_filo.cc ../sql/hostname.cc ../sql/init.cc ../sql/item_buff.cc ../sql/item_cmpfunc.cc ../sql/item.cc ../sql/item_create.cc ../sql/item_func.cc ../sql/item_geofunc.cc ../sql/item_row.cc ../sql/item_strfunc.cc ../sql/item_subselect.cc ../sql/item_sum.cc ../sql/item_timefunc.cc ../sql/item_xmlfunc.cc ../sql/item_jsonfunc.cc ../sql/key.cc ../sql/lock.cc ../sql/log.cc ../sql/log_event.cc ../sql/mf_iocache.cc ../sql/my_decimal.cc ../sql/net_serv.cc ../sql/opt_range.cc ../sql/opt_sum.cc ../sql/parse_file.cc ../sql/procedure.cc ../sql/protocol.cc ../sql/records.cc ../sql/repl_failsafe.cc ../sql/rpl_filter.cc ../sql/rpl_record.cc ../sql/des_key_file.cc ../sql/rpl_injector.cc ../sql/set_var.cc ../sql/spatial.cc ../sql/sp_cache.cc ../sql/sp.cc ../sql/sp_head.cc ../sql/sp_pcontext.cc ../sql/sp_rcontext.cc ../sql/sql_acl.cc ../sql/sql_analyse.cc ../sql/sql_base.cc ../sql/sql_cache.cc ../sql/sql_class.cc ../sql/sql_crypt.cc ../sql/sql_cursor.cc ../sql/sql_db.cc ../sql/sql_delete.cc ../sql/sql_derived.cc ../sql/sql_do.cc ../sql/sql_error.cc ../sql/sql_handler.cc ../sql/sql_get_diagnostics.cc ../sql/sql_help.cc ../sql/sql_insert.cc ../sql/datadict.cc ../sql/sql_admin.cc ../sql/sql_truncate.cc ../sql/sql_reload.cc ../sql/sql_lex.cc ../sql/keycaches.cc ../sql/sql_list.cc ../sql/sql_load.cc ../sql/sql_locale.cc ../sql/sql_binlog.cc ../sql/sql_manager.cc ../sql/sql_parse.cc ../sql/sql_bootstrap.cc ../sql/sql_partition.cc ../sql/sql_plugin.cc ../sql/debug_sync.cc ../sql/opt_table_elimination.cc ../sql/sql_prepare.cc ../sql/sql_rename.cc ../sql/sql_repl.cc ../sql/sql_select.cc ../sql/sql_servers.cc ../sql/group_by_handler.cc ../sql/sql_show.cc ../sql/sql_state.c ../sql/sql_statistics.cc ../sql/sql_string.cc ../sql/sql_tablespace.cc ../sql/sql_table.cc ../sql/sql_test.cc ../sql/sql_trigger.cc ../sql/sql_udf.cc ../sql/sql_union.cc ../sql/sql_update.cc ../sql/sql_view.cc ../sql/sql_profile.cc ../sql/gcalc_tools.cc ../sql/gcalc_slicescan.cc ../sql/strfunc.cc ../sql/table.cc ../sql/thr_malloc.cc ../sql/sql_time.cc ../sql/tztime.cc ../sql/uniques.cc ../sql/unireg.cc ../sql/partition_info.cc ../sql/sql_connect.cc ../sql/scheduler.cc ../sql/sql_audit.cc ../sql/sql_alter.cc ../sql/sql_partition_admin.cc ../sql/event_parse_data.cc ../sql/sql_signal.cc ../sql/sys_vars.cc ${CMAKE_BINARY_DIR}/sql/sql_builtin.cc ../sql/mdl.cc ../sql/transaction.cc ../sql/sql_join_cache.cc ../sql/multi_range_read.cc ../sql/opt_index_cond_pushdown.cc ../sql/opt_subselect.cc ../sql/create_options.cc ../sql/rpl_utility.cc ../sql/rpl_reporting.cc ../sql/sql_expression_cache.cc ../sql/my_apc.cc ../sql/my_apc.h ../sql/my_json_writer.cc ../sql/my_json_writer.h ../sql/rpl_gtid.cc ../sql/sql_explain.cc ../sql/sql_explain.h ../sql/sql_analyze_stmt.cc ../sql/sql_analyze_stmt.h ../sql/compat56.cc ../sql/sql_type.cc ../sql/sql_type.h ../sql/table_cache.cc ../sql/mf_iocache_encr.cc ../sql/item_inetfunc.cc ../sql/wsrep_dummy.cc ../sql/encryption.cc ../sql/item_windowfunc.cc ../sql/sql_window.cc ../sql/sql_cte.cc ../sql/sql_sequence.cc ../sql/sql_sequence.h ../sql/ha_sequence.cc ../sql/ha_sequence.h ../sql/temporary_tables.cc ../sql/session_tracker.cc ../sql/proxy_protocol.cc ../sql/sql_tvc.cc ../sql/sql_tvc.h ../sql/opt_split.cc ../sql/item_vers.cc ${GEN_SOURCES} ${MYSYS_LIBWRAP_SOURCE} ) ADD_CONVENIENCE_LIBRARY(sql_embedded ${SQL_EMBEDDED_SOURCES}) DTRACE_INSTRUMENT(sql_embedded) ADD_DEPENDENCIES(sql_embedded GenError GenServerSource) # On Windows, static embedded server library is called mysqlserver.lib # On Unix, it is libmysqld.a IF(WIN32) SET(MYSQLSERVER_OUTPUT_NAME mysqlserver) SET(COMPONENT_MYSQLSERVER "Embedded") SET(COMPONENT_LIBMYSQLD "Embedded") ELSE() SET(MYSQLSERVER_OUTPUT_NAME mariadbd) SET(COMPONENT_MYSQLSERVER "Development") SET(COMPONENT_LIBMYSQLD "Server") ENDIF() SET(LIBS dbug strings mysys mysys_ssl pcre vio ${ZLIB_LIBRARY} ${SSL_LIBRARIES} ${LIBWRAP} ${LIBCRYPT} ${LIBDL} ${MYSQLD_STATIC_PLUGIN_LIBS} sql_embedded ) # Some storage engine were compiled for embedded specifically # (with corresponding target ${engine}_embedded) SET(EMBEDDED_LIBS) FOREACH(LIB ${LIBS}) IF(TARGET ${LIB}_embedded) LIST(APPEND EMBEDDED_LIBS ${LIB}_embedded) ELSE() LIST(APPEND EMBEDDED_LIBS ${LIB}) ENDIF() ENDFOREACH() MERGE_LIBRARIES(mysqlserver STATIC ${EMBEDDED_LIBS} OUTPUT_NAME ${MYSQLSERVER_OUTPUT_NAME} COMPONENT ${COMPONENT_MYSQLSERVER}) IF(UNIX) INSTALL_SYMLINK(libmysqld.a mysqlserver ${INSTALL_LIBDIR} ${COMPONENT_MYSQLSERVER}) ENDIF() INSTALL(FILES embedded_priv.h DESTINATION ${INSTALL_INCLUDEDIR}/server/private COMPONENT ${COMPONENT_MYSQLSERVER}) SET(CLIENT_API_FUNCTIONS_5_1 get_tty_password mysql_thread_end mysql_thread_init myodbc_remove_escape mysql_affected_rows mysql_autocommit mysql_stmt_bind_param mysql_stmt_bind_result mysql_change_user mysql_character_set_name mysql_close mysql_commit mysql_data_seek mysql_debug mysql_dump_debug_info mysql_eof mysql_errno mysql_error mysql_escape_string mysql_hex_string mysql_stmt_execute mysql_stmt_fetch mysql_stmt_fetch_column mysql_fetch_field mysql_fetch_field_direct mysql_fetch_fields mysql_fetch_lengths mysql_fetch_row mysql_field_count mysql_field_seek mysql_field_tell mysql_free_result mysql_get_parameters mysql_get_client_info mysql_get_host_info mysql_get_proto_info mysql_get_server_info mysql_get_client_version mysql_get_ssl_cipher mysql_info mysql_init mysql_insert_id mysql_kill mysql_set_server_option mysql_list_dbs mysql_list_fields mysql_list_processes mysql_list_tables mysql_more_results mysql_next_result mysql_num_fields mysql_num_rows mysql_options mysql_stmt_param_count mysql_stmt_param_metadata mysql_ping mysql_stmt_result_metadata mysql_query mysql_read_query_result mysql_real_connect mysql_real_escape_string mysql_real_query mysql_refresh mysql_rollback mysql_row_seek mysql_row_tell mysql_select_db mysql_stmt_send_long_data mysql_send_query mysql_shutdown mysql_ssl_set mysql_stat mysql_stmt_affected_rows mysql_stmt_close mysql_stmt_reset mysql_stmt_data_seek mysql_stmt_errno mysql_stmt_error mysql_stmt_free_result mysql_stmt_num_rows mysql_stmt_row_seek mysql_stmt_row_tell mysql_stmt_store_result mysql_store_result mysql_thread_id mysql_thread_safe mysql_use_result mysql_warning_count mysql_stmt_sqlstate mysql_sqlstate mysql_get_server_version mysql_stmt_prepare mysql_stmt_init mysql_stmt_insert_id mysql_stmt_attr_get mysql_stmt_attr_set mysql_stmt_field_count mysql_set_local_infile_default mysql_set_local_infile_handler mysql_embedded mysql_server_init mysql_server_end mysql_set_character_set mysql_get_character_set_info # These are documented in Paul DuBois' MySQL book, # so we treat them as part of the de-facto API. handle_options load_defaults free_defaults my_print_help ) SET(CLIENT_API_FUNCTIONS_5_5 my_progname mysql_stmt_next_result # Charsets my_charset_bin my_charset_latin1 my_charset_utf8_general_ci # Client plugins mysql_client_find_plugin mysql_client_register_plugin mysql_load_plugin mysql_load_plugin_v mysql_plugin_options # Async API mysql_get_timeout_value mysql_get_timeout_value_ms mysql_get_socket mysql_autocommit_cont mysql_autocommit_start mysql_change_user_cont mysql_change_user_start mysql_close_cont mysql_close_start mysql_commit_cont mysql_commit_start mysql_dump_debug_info_cont mysql_dump_debug_info_start mysql_fetch_row_cont mysql_fetch_row_start mysql_free_result_cont mysql_free_result_start mysql_kill_cont mysql_kill_start mysql_list_dbs_cont mysql_list_dbs_start mysql_list_fields_cont mysql_list_fields_start mysql_list_processes_cont mysql_list_processes_start mysql_list_tables_cont mysql_list_tables_start mysql_next_result_cont mysql_next_result_start mysql_ping_cont mysql_ping_start mysql_query_cont mysql_query_start mysql_read_query_result_cont mysql_read_query_result_start mysql_real_connect_cont mysql_real_connect_start mysql_real_query_cont mysql_real_query_start mysql_refresh_cont mysql_refresh_start mysql_rollback_cont mysql_rollback_start mysql_select_db_cont mysql_select_db_start mysql_send_query_cont mysql_send_query_start mysql_set_character_set_cont mysql_set_character_set_start mysql_set_server_option_cont mysql_set_server_option_start mysql_shutdown_cont mysql_shutdown_start mysql_stat_cont mysql_stat_start mysql_stmt_close_cont mysql_stmt_close_start mysql_stmt_execute_cont mysql_stmt_execute_start mysql_stmt_fetch_cont mysql_stmt_fetch_start mysql_stmt_free_result_cont mysql_stmt_free_result_start mysql_stmt_next_result_cont mysql_stmt_next_result_start mysql_stmt_prepare_cont mysql_stmt_prepare_start mysql_stmt_reset_cont mysql_stmt_reset_start mysql_stmt_send_long_data_cont mysql_stmt_send_long_data_start mysql_stmt_store_result_cont mysql_stmt_store_result_start mysql_store_result_cont mysql_store_result_start #dynamic columns api dynamic_column_create dynamic_column_create_many dynamic_column_update dynamic_column_update_many dynamic_column_exists dynamic_column_list dynamic_column_get dynamic_column_prepare_decimal mariadb_dyncol_create_many_num mariadb_dyncol_create_many_named mariadb_dyncol_update_many_num mariadb_dyncol_update_many_named mariadb_dyncol_exists_num mariadb_dyncol_exists_named mariadb_dyncol_free mariadb_dyncol_list_num mariadb_dyncol_list_named mariadb_dyncol_get_num mariadb_dyncol_get_named mariadb_dyncol_has_names mariadb_dyncol_check mariadb_dyncol_json mariadb_dyncol_val_str mariadb_dyncol_val_long mariadb_dyncol_val_double mariadb_dyncol_unpack mariadb_dyncol_unpack_free mariadb_dyncol_column_cmp_named mariadb_dyncol_column_count mariadb_dyncol_prepare_decimal # mariadb_deinitialize_ssl # low-level API to MySQL protocol mysql_net_read_packet mysql_net_field_length # Added in MariaDB-10.0 to stay compatible with MySQL-5.6, yuck! mysql_options4 ) SET(CLIENT_API_FUNCTIONS ${CLIENT_API_FUNCTIONS_5_1} ${CLIENT_API_FUNCTIONS_5_5} ) # List of exported functions in embedded (client api except client plugin or # async (*_start/*_cont functions) SET(EMBEDDED_API) FOREACH(f ${CLIENT_API_FUNCTIONS}) IF(f MATCHES "plugin|_start$|_cont$") # Ignore functions, embedded does not export them ELSE() SET(EMBEDDED_API ${EMBEDDED_API} ${f}) ENDIF() ENDFOREACH() IF(NOT DISABLE_SHARED) MERGE_LIBRARIES(libmysqld SHARED mysqlserver EXPORTS ${EMBEDDED_API} COMPONENT ${COMPONENT_LIBMYSQLD}) IF(UNIX) # Name the shared library, handle versioning (provides same api as client # library hence the same version) SET_TARGET_PROPERTIES(libmysqld PROPERTIES OUTPUT_NAME mariadbd SOVERSION "${SHARED_LIB_MAJOR_VERSION}") INSTALL_SYMLINK(libmysqld.so libmysqld ${INSTALL_LIBDIR} ${COMPONENT_LIBMYSQLD}) # Clean direct output flags, as 2 targets have the same base name # libmysqld SET_TARGET_PROPERTIES(libmysqld PROPERTIES CLEAN_DIRECT_OUTPUT 1) TARGET_LINK_LIBRARIES(libmysqld ${CRC32_LIBRARY}) SET_TARGET_PROPERTIES(mysqlserver PROPERTIES CLEAN_DIRECT_OUTPUT 1) TARGET_LINK_LIBRARIES(mysqlserver ${CRC32_LIBRARY}) IF(LIBMYSQLD_SO_EXTRA_LIBS) TARGET_LINK_LIBRARIES(libmysqld ${LIBMYSQLD_SO_EXTRA_LIBS}) ENDIF() ENDIF() ENDIF() -------------- next part -------------- # Copyright (c) 2006, 2014, Oracle and/or its affiliates. # Copyright (c) 2010, 2018, MariaDB Corporation # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; version 2 of the License. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA IF(WITH_WSREP AND NOT EMBEDDED_LIBRARY) SET(WSREP_INCLUDES ${CMAKE_SOURCE_DIR}/wsrep) SET(WSREP_SOURCES wsrep_check_opts.cc wsrep_hton.cc wsrep_mysqld.cc wsrep_notify.cc wsrep_sst.cc wsrep_utils.cc wsrep_var.cc wsrep_binlog.cc wsrep_applier.cc wsrep_thd.cc wsrep_xid.cc ) SET(WSREP_LIB wsrep) ELSE() SET(WSREP_SOURCES wsrep_dummy.cc) ENDIF() INCLUDE_DIRECTORIES( ${CMAKE_SOURCE_DIR}/include ${CMAKE_SOURCE_DIR}/sql ${PCRE_INCLUDES} ${ZLIB_INCLUDE_DIR} ${SSL_INCLUDE_DIRS} ${CMAKE_BINARY_DIR}/sql ${WSREP_INCLUDES} ) IF(NOT CMAKE_CROSSCOMPILING) ADD_CUSTOM_COMMAND( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/lex_token.h COMMAND gen_lex_token > lex_token.h DEPENDS gen_lex_token) ELSE() ADD_CUSTOM_COMMAND( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/lex_token.h COMMAND gen_lex_token > lex_token.h) ENDIF() ADD_DEFINITIONS(-DMYSQL_SERVER -DHAVE_EVENT_SCHEDULER) IF(SSL_DEFINES) ADD_DEFINITIONS(${SSL_DEFINES}) ENDIF() SET (SQL_SOURCE ../sql-common/client.c compat56.cc derror.cc des_key_file.cc discover.cc ../sql-common/errmsg.c field.cc field_conv.cc field_comp.cc filesort_utils.cc filesort.cc gstream.cc signal_handler.cc handler.cc hostname.cc init.cc item.cc item_buff.cc item_cmpfunc.cc item_create.cc item_func.cc item_geofunc.cc item_row.cc item_strfunc.cc item_subselect.cc item_sum.cc item_timefunc.cc key.cc log.cc lock.cc log_event.cc rpl_record.cc rpl_reporting.cc log_event_old.cc rpl_record_old.cc mf_iocache.cc my_decimal.cc mysqld.cc net_serv.cc keycaches.cc ../sql-common/client_plugin.c opt_range.cc opt_sum.cc ../sql-common/pack.c parse_file.cc password.c procedure.cc protocol.cc records.cc repl_failsafe.cc rpl_filter.cc session_tracker.cc set_var.cc slave.cc sp.cc sp_cache.cc sp_head.cc sp_pcontext.cc sp_rcontext.cc spatial.cc sql_acl.cc sql_analyse.cc sql_base.cc sql_cache.cc sql_class.cc sql_client.cc sql_crypt.cc sql_cursor.cc sql_db.cc sql_delete.cc sql_derived.cc sql_digest.cc sql_do.cc sql_error.cc sql_handler.cc sql_get_diagnostics.cc sql_help.cc sql_insert.cc sql_lex.cc sql_list.cc sql_load.cc sql_manager.cc sql_parse.cc sql_bootstrap.cc sql_partition.cc sql_plugin.cc sql_prepare.cc sql_rename.cc debug_sync.cc sql_repl.cc sql_select.cc sql_show.cc sql_state.c group_by_handler.cc sql_statistics.cc sql_string.cc lex_string.h sql_table.cc sql_test.cc sql_trigger.cc sql_udf.cc sql_union.cc sql_update.cc sql_view.cc strfunc.cc table.cc thr_malloc.cc sql_time.cc tztime.cc unireg.cc item_xmlfunc.cc uniques.cc rpl_tblmap.cc sql_binlog.cc event_scheduler.cc event_data_objects.cc event_queue.cc event_db_repository.cc sql_tablespace.cc events.cc ../sql-common/my_user.c partition_info.cc rpl_utility.cc rpl_injector.cc sql_locale.cc rpl_rli.cc rpl_mi.cc sql_servers.cc sql_audit.cc sql_connect.cc scheduler.cc sql_partition_admin.cc sql_profile.cc event_parse_data.cc sql_alter.cc sql_signal.cc mdl.cc sql_admin.cc transaction.cc sys_vars.cc sql_truncate.cc datadict.cc sql_reload.cc item_inetfunc.cc # added in MariaDB: sql_explain.cc sql_analyze_stmt.cc sql_join_cache.cc create_options.cc multi_range_read.cc opt_index_cond_pushdown.cc opt_subselect.cc opt_table_elimination.cc sql_expression_cache.cc gcalc_slicescan.cc gcalc_tools.cc threadpool_common.cc ../sql-common/mysql_async.c my_apc.cc mf_iocache_encr.cc item_jsonfunc.cc my_json_writer.cc rpl_gtid.cc rpl_parallel.cc semisync.cc semisync_master.cc semisync_slave.cc semisync_master_ack_receiver.cc sql_type.cc item_windowfunc.cc sql_window.cc sql_cte.cc item_vers.cc sql_sequence.cc sql_sequence.h ha_sequence.h sql_tvc.cc sql_tvc.h opt_split.cc ${WSREP_SOURCES} table_cache.cc encryption.cc temporary_tables.cc proxy_protocol.cc ${CMAKE_CURRENT_BINARY_DIR}/sql_builtin.cc ${CMAKE_CURRENT_BINARY_DIR}/sql_yacc.cc ${CMAKE_CURRENT_BINARY_DIR}/sql_yacc_ora.cc ${CMAKE_CURRENT_BINARY_DIR}/lex_hash.h ${CMAKE_CURRENT_BINARY_DIR}/lex_token.h ${MYSYS_LIBWRAP_SOURCE} ) IF (CMAKE_SYSTEM_NAME MATCHES "Linux" OR CMAKE_SYSTEM_NAME MATCHES "Windows" OR CMAKE_SYSTEM_NAME MATCHES "SunOS" OR HAVE_KQUEUE) ADD_DEFINITIONS(-DHAVE_POOL_OF_THREADS) IF(WIN32) SET(SQL_SOURCE ${SQL_SOURCE} threadpool_win.cc) ENDIF() SET(SQL_SOURCE ${SQL_SOURCE} threadpool_generic.cc) ENDIF() MYSQL_ADD_PLUGIN(partition ha_partition.cc STORAGE_ENGINE DEFAULT STATIC_ONLY RECOMPILE_FOR_EMBEDDED) MYSQL_ADD_PLUGIN(sql_sequence ha_sequence.cc STORAGE_ENGINE MANDATORY STATIC_ONLY RECOMPILE_FOR_EMBEDDED) ADD_LIBRARY(sql STATIC ${SQL_SOURCE}) DTRACE_INSTRUMENT(sql) TARGET_LINK_LIBRARIES(sql ${MYSQLD_STATIC_PLUGIN_LIBS} mysys mysys_ssl dbug strings vio pcre ${LIBWRAP} ${LIBCRYPT} ${LIBDL} ${CMAKE_THREAD_LIBS_INIT} ${WSREP_LIB} ${SSL_LIBRARIES} ${LIBSYSTEMD}) IF(WIN32) SET(MYSQLD_SOURCE main.cc nt_servc.cc message.rc) TARGET_LINK_LIBRARIES(sql psapi) ELSE() SET(MYSQLD_SOURCE main.cc ${DTRACE_PROBES_ALL}) ENDIF() IF(MSVC AND NOT WITHOUT_DYNAMIC_PLUGINS) # mysqld.exe must to export symbols from some specific libs. # These symbols are used by dynamic plugins, that "link" to mysqld. # # To do that, we # # 1. Generate mysqld_lib.def text file with all symbols from static # libraries mysys, dbug, strings, sql. # 2. Then we call # lib.exe /DEF:mysqld_lib.def ... # to create import library mysqld_lib.lib and export library mysqld_lib.exp # 3. mysqld.exe links with mysqld_lib.exp (exporting symbols) # 4. plugins link with mysqld_lib.lib (importing symbols) # # We do not not regenerate .def, .lib and .exp # without necessity.E.g source modifications, that do not # change list of exported symbols, will not result in a relink for plugins. SET(MYSQLD_DEF ${CMAKE_CURRENT_BINARY_DIR}/mysqld_lib.def) SET(MYSQLD_EXP ${CMAKE_CURRENT_BINARY_DIR}/mysqld_lib.exp) SET(MYSQLD_LIB ${CMAKE_CURRENT_BINARY_DIR}/mysqld_lib.lib) SET(MYSQLD_CORELIBS sql mysys dbug strings) FOREACH (CORELIB ${MYSQLD_CORELIBS}) SET (LIB_LOCATIONS ${LIB_LOCATIONS} $) ENDFOREACH (CORELIB) SET(_PLATFORM x86) IF(CMAKE_SIZEOF_VOID_P EQUAL 8) SET(_PLATFORM x64) ENDIF() # Create a cmake script to generate import and export libs # from a .def file SET(CMAKE_CONFIGURABLE_FILE_CONTENT " IF ((mysqld_lib.def IS_NEWER_THAN mysqld_lib.lib) OR (mysqld_lib.def IS_NEWER_THAN mysqld_lib.exp)) FILE(REMOVE mysqld_lib.lib mysqld_lib.exp) SET(ENV{VS_UNICODE_OUTPUT}) EXECUTE_PROCESS ( COMMAND \"${CMAKE_LINKER}\" /lib /NAME:mysqld.exe \"/DEF:${MYSQLD_DEF}\" /MACHINE:${_PLATFORM} RESULT_VARIABLE ret) IF(NOT ret EQUAL 0) MESSAGE(FATAL_ERROR \"process failed ret=\${ret}\") ENDIF() ENDIF() ") CONFIGURE_FILE( ${PROJECT_SOURCE_DIR}/cmake/configurable_file_content.in make_mysqld_lib.cmake) IF(CMAKE_VERSION VERSION_GREATER "3.2.0") SET(MYSQLD_LIB_BYPRODUCTS BYPRODUCTS ${MYSQLD_DEF} ${MYSQLD_LIB} ${MYSQLD_EXP}) ENDIF() # Create a cmake script to generate import and export libs # from a .def file SET(CMAKE_CONFIGURABLE_FILE_CONTENT " IF ((mysqld_lib.def IS_NEWER_THAN mysqld_lib.lib) OR (mysqld_lib.def IS_NEWER_THAN mysqld_lib.exp)) FILE(REMOVE mysqld_lib.lib mysqld_lib.exp) SET(ENV{VS_UNICODE_OUTPUT}) EXECUTE_PROCESS ( COMMAND \"${CMAKE_LINKER}\" /lib /NAME:mysqld.exe \"/DEF:${MYSQLD_DEF}\" /MACHINE:${_PLATFORM} RESULT_VARIABLE ret) IF(NOT ret EQUAL 0) MESSAGE(FATAL_ERROR \"process failed ret=\${ret}\") ENDIF() ENDIF() ") CONFIGURE_FILE( ${PROJECT_SOURCE_DIR}/cmake/configurable_file_content.in make_mysqld_lib.cmake) ADD_CUSTOM_COMMAND( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/mysqld_lib.stamp ${MYSQLD_LIB_BYPRODUCTS} COMMENT "Generating mysqld_lib.def, mysqld_lib.lib, mysqld_lib.exp" COMMAND cscript //nologo ${PROJECT_SOURCE_DIR}/win/create_def_file.js ${_PLATFORM} /forLib ${LIB_LOCATIONS} > mysqld_lib.def.tmp COMMAND ${CMAKE_COMMAND} -E copy_if_different mysqld_lib.def.tmp mysqld_lib.def COMMAND ${CMAKE_COMMAND} -E remove mysqld_lib.def.tmp COMMAND ${CMAKE_COMMAND} -P make_mysqld_lib.cmake COMMAND ${CMAKE_COMMAND} -E touch mysqld_lib.stamp WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} DEPENDS ${MYSQLD_CORELIBS} ) ADD_CUSTOM_TARGET(gen_mysqld_lib DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/mysqld_lib.stamp) ADD_LIBRARY(mysqld_import_lib UNKNOWN IMPORTED GLOBAL) SET_TARGET_PROPERTIES(mysqld_import_lib PROPERTIES IMPORTED_LOCATION ${MYSQLD_LIB}) ENDIF() MYSQL_ADD_EXECUTABLE(mysqld ${MYSQLD_SOURCE} DESTINATION ${INSTALL_SBINDIR} COMPONENT Server) IF(APPLE) # Add CoreServices framework since some dloadable plugins may need it FIND_LIBRARY(CORESERVICES NAMES CoreServices) IF(CORESERVICES) TARGET_LINK_LIBRARIES(mysqld LINK_PRIVATE ${CORESERVICES}) ENDIF() ENDIF() IF(NOT WITHOUT_DYNAMIC_PLUGINS) IF(NOT MSVC) SET_TARGET_PROPERTIES(mysqld PROPERTIES ENABLE_EXPORTS TRUE) ENDIF() GET_TARGET_PROPERTY(mysqld_link_flags mysqld LINK_FLAGS) IF(NOT mysqld_link_flags) SET(mysqld_link_flags) ENDIF() IF (MINGW OR CYGWIN) SET_TARGET_PROPERTIES(mysqld PROPERTIES LINK_FLAGS "${mysqld_link_flags} -Wl,--export-all-symbols") ENDIF() IF(MSVC) SET_TARGET_PROPERTIES(mysqld PROPERTIES LINK_FLAGS "${mysqld_link_flags} \"${MYSQLD_EXP}\"") ADD_DEPENDENCIES(mysqld gen_mysqld_lib) ENDIF() ENDIF(NOT WITHOUT_DYNAMIC_PLUGINS) TARGET_LINK_LIBRARIES(mysqld LINK_PRIVATE sql) # Provide plugins with minimal set of libraries SET(INTERFACE_LIBS ${LIBRT}) IF(INTERFACE_LIBS) TARGET_LINK_LIBRARIES(mysqld LINK_PUBLIC ${INTERFACE_LIBS}) ENDIF() # On Solaris, some extra effort is required in order to get dtrace probes # from static libraries DTRACE_INSTRUMENT_STATIC_LIBS(mysqld "sql;mysys;mysys_ssl;${MYSQLD_STATIC_PLUGIN_LIBS}") SET(WITH_MYSQLD_LDFLAGS "" CACHE STRING "Additional linker flags for mysqld") MARK_AS_ADVANCED(WITH_MYSQLD_LDFLAGS) IF(WITH_MYSQLD_LDFLAGS) GET_TARGET_PROPERTY(MYSQLD_LINK_FLAGS mysqld LINK_FLAGS) IF(NOT MYSQLD_LINK_FLAGS) SET(MYSQLD_LINK_FLAGS) ENDIF() SET_TARGET_PROPERTIES(mysqld PROPERTIES LINK_FLAGS "${MYSQLD_LINK_FLAGS} ${WITH_MYSQLD_LDFLAGS}") ENDIF() FIND_PACKAGE(BISON 2.0) # Handle out-of-source build from source package with possibly broken # bison. Copy bison output to from source to build directory, if not already # there IF (NOT BISON_FOUND) IF (NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR}) FOREACH(file sql_yacc.cc sql_yacc.hh sql_yacc_ora.cc sql_yacc_ora.hh) IF(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/${file} AND (NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/${file})) CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/${file} ${CMAKE_CURRENT_BINARY_DIR}/${file} COPYONLY) ENDIF() ENDFOREACH() ENDIF() IF(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/sql_yacc.cc) # Output files are missing, bail out. SET(ERRMSG "Bison (GNU parser generator) is required to build MySQL." "Please install bison." ) IF(WIN32) SET(ERRMSG ${ERRMSG} "You can download bison from http://gnuwin32.sourceforge.net/packages/bison.htm " "Choose 'Complete package, except sources' installation. We recommend to " "install bison into a directory without spaces, e.g C:\\GnuWin32.") ENDIF() MESSAGE(FATAL_ERROR ${ERRMSG}) ENDIF() ELSE() BISON_TARGET(gen_sql_yacc ${CMAKE_CURRENT_SOURCE_DIR}/sql_yacc.yy ${CMAKE_CURRENT_BINARY_DIR}/sql_yacc.cc COMPILE_FLAGS "-p MYSQL") BISON_TARGET(gen_sql_yacc_ora ${CMAKE_CURRENT_SOURCE_DIR}/sql_yacc_ora.yy ${CMAKE_CURRENT_BINARY_DIR}/sql_yacc_ora.cc COMPILE_FLAGS "-p ORA") ENDIF() IF(NOT CMAKE_CROSSCOMPILING) ADD_EXECUTABLE(gen_lex_token gen_lex_token.cc ${CMAKE_CURRENT_BINARY_DIR}/sql_yacc.hh) ADD_EXECUTABLE(gen_lex_hash gen_lex_hash.cc) ENDIF() IF(NOT CMAKE_CROSSCOMPILING) ADD_CUSTOM_COMMAND( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/lex_hash.h COMMAND gen_lex_hash > lex_hash.h DEPENDS gen_lex_hash) ELSE() ADD_CUSTOM_COMMAND( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/lex_hash.h COMMAND gen_lex_hash > lex_hash.h) ENDIF() MYSQL_ADD_EXECUTABLE(mysql_tzinfo_to_sql tztime.cc COMPONENT Server) SET_TARGET_PROPERTIES(mysql_tzinfo_to_sql PROPERTIES COMPILE_FLAGS "-DTZINFO2SQL") TARGET_LINK_LIBRARIES(mysql_tzinfo_to_sql mysys mysys_ssl) ADD_CUSTOM_TARGET( GenServerSource DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/lex_hash.h ${CMAKE_CURRENT_BINARY_DIR}/lex_token.h ${CMAKE_CURRENT_BINARY_DIR}/sql_yacc_ora.cc ) IF(WIN32 OR HAVE_DLOPEN AND NOT DISABLE_SHARED) ADD_LIBRARY(udf_example MODULE udf_example.c udf_example.def) SET_TARGET_PROPERTIES(udf_example PROPERTIES PREFIX "") TARGET_LINK_LIBRARIES(udf_example strings) ENDIF() CONFIGURE_FILE( ${CMAKE_SOURCE_DIR}/cmake/make_dist.cmake.in ${CMAKE_BINARY_DIR}/make_dist.cmake @ONLY) ADD_CUSTOM_TARGET(dist COMMAND ${CMAKE_COMMAND} -P ${CMAKE_BINARY_DIR}/make_dist.cmake DEPENDS ${CMAKE_BINARY_DIR}/sql/sql_yacc.cc ${CMAKE_BINARY_DIR}/sql/sql_yacc.hh DEPENDS ${CMAKE_BINARY_DIR}/sql/sql_yacc_ora.cc ${CMAKE_BINARY_DIR}/sql/sql_yacc_ora.hh WORKING_DIRECTORY ${CMAKE_BINARY_DIR} ) ADD_CUSTOM_TARGET(distclean COMMAND ${CMAKE_COMMAND} -E echo WARNING: distclean target is not functional COMMAND ${CMAKE_COMMAND} -E echo Use 'git clean -Xdf' instead VERBATIM ) IF(INSTALL_LAYOUT STREQUAL "STANDALONE") # Copy db.opt into data/test/ SET(DBOPT_FILE ${CMAKE_SOURCE_DIR}/support-files/db.opt ) INSTALL(FILES ${DBOPT_FILE} DESTINATION data/test COMPONENT DataFiles) # Install initial database on windows IF(WIN32 AND TARGET mysqld AND NOT CMAKE_CROSSCOMPILING) IF(MSVC_IDE OR CMAKE_GENERATOR MATCHES "Xcode") SET (CONFIG_PARAM -DCONFIG=${CMAKE_CFG_INTDIR}) ENDIF() MAKE_DIRECTORY(${CMAKE_CURRENT_BINARY_DIR}/data) ADD_CUSTOM_COMMAND( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/initdb.dep COMMAND ${CMAKE_COMMAND} ${CONFIG_PARAM} -DTOP_SRCDIR="${CMAKE_SOURCE_DIR}" -DBINDIR="${CMAKE_CURRENT_BINARY_DIR}" -DMYSQLD_EXECUTABLE="$" -DCMAKE_CFG_INTDIR="${CMAKE_CFG_INTDIR}" -P ${CMAKE_SOURCE_DIR}/cmake/create_initial_db.cmake COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_CURRENT_BINARY_DIR}/initdb.dep WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/data DEPENDS mysqld ) ADD_CUSTOM_TARGET(initial_database ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/initdb.dep ) INSTALL(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/data DESTINATION . COMPONENT DataFiles PATTERN "initdb.dep" EXCLUDE PATTERN "bootstrap.sql" EXCLUDE PATTERN "aria*" EXCLUDE ) ELSE() # Not windows or cross compiling, just install an empty directory INSTALL(FILES ${DUMMY_FILE} DESTINATION data/mysql COMPONENT DataFiles) ENDIF(WIN32 AND TARGET mysqld AND NOT CMAKE_CROSSCOMPILING) ENDIF(INSTALL_LAYOUT STREQUAL "STANDALONE") IF(WIN32) SET(my_bootstrap_sql ${CMAKE_CURRENT_BINARY_DIR}/my_bootstrap.sql) FILE(TO_NATIVE_PATH ${my_bootstrap_sql} native_outfile) # Create bootstrapper SQL script ADD_CUSTOM_COMMAND(OUTPUT ${my_bootstrap_sql} COMMAND ${CMAKE_COMMAND} -E chdir ${CMAKE_SOURCE_DIR}/scripts cmd /c copy mysql_system_tables.sql+mysql_system_tables_data.sql+fill_help_tables.sql+mysql_performance_tables.sql+mysql_test_db.sql ${native_outfile} DEPENDS ${CMAKE_SOURCE_DIR}/scripts/mysql_system_tables.sql ${CMAKE_SOURCE_DIR}/scripts/mysql_system_tables_data.sql ${CMAKE_SOURCE_DIR}/scripts/fill_help_tables.sql ${CMAKE_SOURCE_DIR}/scripts/mysql_performance_tables.sql ${CMAKE_SOURCE_DIR}/scripts/mysql_test_db.sql ) ADD_CUSTOM_COMMAND( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/mysql_bootstrap_sql.c COMMAND comp_sql mysql_bootstrap_sql ${CMAKE_CURRENT_BINARY_DIR}/my_bootstrap.sql mysql_bootstrap_sql.c WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} DEPENDS comp_sql ${my_bootstrap_sql} ) MYSQL_ADD_EXECUTABLE(mysql_install_db mysql_install_db.cc ${CMAKE_CURRENT_BINARY_DIR}/mysql_bootstrap_sql.c COMPONENT Server ) SET_TARGET_PROPERTIES(mysql_install_db PROPERTIES COMPILE_FLAGS -DINSTALL_PLUGINDIR=${INSTALL_PLUGINDIR}) TARGET_LINK_LIBRARIES(mysql_install_db mysys shlwapi) ADD_LIBRARY(winservice STATIC winservice.c) TARGET_LINK_LIBRARIES(winservice shell32) MYSQL_ADD_EXECUTABLE(mysql_upgrade_service mysql_upgrade_service.cc upgrade_conf_file.cc COMPONENT Server) TARGET_LINK_LIBRARIES(mysql_upgrade_service mysys winservice) ENDIF(WIN32) INSTALL(DIRECTORY . DESTINATION ${INSTALL_INCLUDEDIR}/server/private COMPONENT Development FILES_MATCHING PATTERN "*.h" PATTERN share EXCLUDE PATTERN CMakeFiles EXCLUDE) From bruce.r.stephens at gmail.com Mon Mar 4 07:00:10 2019 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Mon, 4 Mar 2019 12:00:10 +0000 Subject: [CMake] make[2]: *** No rule to make target 'sql/sql_yacc.cc', needed by 'libmysqld/CMakeFiles/sql_embedded.dir/__/sql/sql_yacc.cc.o'. Stop. In-Reply-To: <5C7CA041.5030108@windriver.com> References: <5C790046.5010902@windriver.com> <1551452281.22984.2.camel@kitware.com> <5C7CA041.5030108@windriver.com> Message-ID: On Mon, 4 Mar 2019 at 04:00, Yu, Mingli wrote: > Is there any means to make the logic run in /source/sql/CMakeLists.txt > before which is in /source/libmysqld/CMakeLists.txt? Use a dependency between targets. There's a limitation/bug with things that depend on files created by add_custom_command() in different directories (different CMakeLists,txt files). So create a target for the generated file (in the directory where it's created), and use add_dependencies() for the thing that uses the file. From mario at emmenlauer.de Tue Mar 5 10:28:48 2019 From: mario at emmenlauer.de (Mario Emmenlauer) Date: Tue, 5 Mar 2019 16:28:48 +0100 Subject: [CMake] install(EXPORT "XXXTargets" ...) includes target "XXX" which requires target "caffe2_library"... In-Reply-To: References: Message-ID: Does someone know how to generate these missing targets or how to fix this? Thanks for any help! All the best, Mario On 03.03.19 11:28, Mario Emmenlauer wrote: > > Dear all, > > I'm trying to build a C++ project based on PyTorch with cmake package > configuration files. The includes and libs generally seem to work after > doing: > > find_package(Torch 1.0.0 REQUIRED) > > But when I try to generate package configuration for my library, cmake > shows an error: > CMake Error: install(EXPORT "XXXTargets" ...) includes target "XXX" which requires target "caffe2_library" that is not in the export set. > > I read a number of suggestions but they refer to the case where > "caffe2_library" would be one of my generated targets. I tried to > generate a target for "caffe2_library" and failed, and now I'm a > bit at a loss. Can someone lend me a hand? > > > Here is a cropped version of my CMakeLists.txt: > > cmake_minimum_required(VERSION 3.8 FATAL_ERROR) > project(XXX VERSION 1.0.0) > find_package(Torch 1.0.0 REQUIRED) > add_library(${PROJECT_NAME} include/XXX.hh src/XXX.cc) > > target_include_directories(${PROJECT_NAME} > PRIVATE > ${CMAKE_CURRENT_SOURCE_DIR}/src > ${CMAKE_CURRENT_BINARY_DIR} > PUBLIC > $ > $ > ${TORCH_INCLUDE_DIRS}) > > target_link_libraries(${PROJECT_NAME} > PUBLIC > ${TORCH_LIBRARIES}) > > export(TARGETS ${PROJECT_NAME} FILE cmake/${PROJECT_NAME}Targets.cmake) > export(PACKAGE ${PROJECT_NAME}) > > install(TARGETS ${PROJECT_NAME} > EXPORT ${PROJECT_NAME}Targets > ARCHIVE DESTINATION lib > LIBRARY DESTINATION lib > RUNTIME DESTINATION bin > INCLUDES DESTINATION include) > > install(EXPORT ${PROJECT_NAME}Targets > DESTINATION lib/cmake/) > > > All the best, > > Mario Emmenlauer > Viele Gruesse, Mario Emmenlauer -- BioDataAnalysis GmbH, Mario Emmenlauer Tel. Buero: +49-89-74677203 Balanstr. 43 mailto: memmenlauer * biodataanalysis.de D-81669 M?nchen http://www.biodataanalysis.de/ From oliviergomez.og at gmail.com Tue Mar 5 12:01:35 2019 From: oliviergomez.og at gmail.com (Olivier Gomez) Date: Tue, 5 Mar 2019 10:01:35 -0700 (MST) Subject: [CMake] Remove a custom command added with add_custom_command( POST_BUILD ...) Message-ID: <1551805295283-0.post@n2.nabble.com> Hello, I have been searching for a way to remove a custom command (POST_BUILD event) from a target in CMake but, so far, I've found nothing. I tried to add another custom command to override the first one but it seems to append a second command. I tough that could work because of the first signature of add_custom_command() that can take an optional argument named APPEND. https://cmake.org/cmake/help/v3.4/command/add_custom_command.html#generating-files Then, I looked for a target property that contains the POST_BUILD custom command (to erase it) but, again, I found nothing related (I listed every property using the "cmake --help-property-list" command). The context is that I configure a project using a "CMake SDK" from a third party library (custom functions that create and configure a shared library target basically). Until recently, I used to create those target by myself using standard CMake command. But now I switched to the "SDK" because it does a lot of specific thing depending on the platform (and between the current version of the SDK and all the legacy version) and I don't want to rewrite everything. Specifically, this SDK add a custom command as a POST_BUILD event to run a tool that perform a signature on the produced library. As it is a proprietary tool that requires a valid licence to work, I want to remove that command in order to have a successful build even if i don't currently have a licence on my machine. So ... is there some way to remove a custom command in CMake ? (or ignore failed command maybe) Best regards, Olivier Gomez -- Sent from: http://cmake.3232098.n2.nabble.com/ From kyle.edwards at kitware.com Tue Mar 5 12:58:34 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Tue, 05 Mar 2019 12:58:34 -0500 Subject: [CMake] Remove a custom command added with add_custom_command( POST_BUILD ...) In-Reply-To: <1551805295283-0.post@n2.nabble.com> References: <1551805295283-0.post@n2.nabble.com> Message-ID: <1551808714.22984.5.camel@kitware.com> On Tue, 2019-03-05 at 10:01 -0700, Olivier Gomez wrote: > Hello, > > I have been searching for a way to remove a custom command > (POST_BUILD > event) from a target in CMake but, so far, I've found nothing. > > I tried to add another custom command to override the first one but > it seems > to append a second command.? > I tough that could work because of the first signature of > add_custom_command() that can take an optional argument named APPEND. > https://cmake.org/cmake/help/v3.4/command/add_custom_command.html#gen > erating-files > Then, I looked for a target property that contains the POST_BUILD > custom > command (to erase it) but, again, I found nothing related (I listed > every > property using the "cmake --help-property-list" command). > > > The context is that I configure a project using a "CMake SDK" from a > third > party library (custom functions that create and configure a shared > library > target basically). > Until recently, I used to create those target by myself using > standard CMake > command. > But now I switched to the "SDK" because it does a lot of specific > thing > depending on the platform (and between the current version of the SDK > and > all the legacy version) and I don't want to rewrite everything. > > Specifically, this SDK add a custom command as a POST_BUILD event to > run a > tool that perform a signature on the produced library. As it is a > proprietary tool that requires a valid licence to work, I want to > remove > that command in order to have a successful build even if i don't > currently > have a licence on my machine. > > So ... is there some way to remove a custom command in CMake ? (or > ignore > failed command maybe) CMake doesn't have a way to remove a custom command from a target. Your best bet would be to either: 1) Fork the SDK for your project to remove the proprietary tool, or 2) Submit a patch upstream to add an option to disable the proprietary tool. Kyle From elliottslaughter at gmail.com Tue Mar 5 17:14:46 2019 From: elliottslaughter at gmail.com (Elliott Slaughter) Date: Tue, 5 Mar 2019 14:14:46 -0800 Subject: [CMake] Conditional includes generate unconditional dependencies Message-ID: One of my colleagues recently pointed out to me that CMake generates unconditional dependencies for headers that are included behind an #ifdef even when said #ifdef is disabled. I've managed to confirm this with CMake 3.13.4 using the following reproducer: git clone https://github.com/elliottslaughter/test-cmake-conditional-include.git ./test.sh Is there a way to get CMake dependency generation to obey the conditional? The workaround we've found so far are undesirable (marking the entire folder as a system path, which isn't appropriate in our use case) or ugly (using implicit depends include transforms). We understand that the build would be "correct" in any case, as CMake's dependency generation is conservative, but in our case this is causing massive performance issues as the build machine is an embedded device attached to NFS and the dependency tree we're pulling in so large that we're thrashing the file system. Thanks. -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliviergomez.og at gmail.com Wed Mar 6 01:41:22 2019 From: oliviergomez.og at gmail.com (Olivier Gomez) Date: Wed, 6 Mar 2019 07:41:22 +0100 Subject: [CMake] Remove a custom command added with add_custom_command( POST_BUILD ...) In-Reply-To: <1551808714.22984.5.camel@kitware.com> References: <1551805295283-0.post@n2.nabble.com> <1551808714.22984.5.camel@kitware.com> Message-ID: Thank you for your suggestions. I think the best option is a patch but it will take some time ... I guess I will have to find a workaround in the meantime ! Anyway, thanks again ! Olivier Le mar. 5 mars 2019 ? 18:58, Kyle Edwards a ?crit : > On Tue, 2019-03-05 at 10:01 -0700, Olivier Gomez wrote: > > Hello, > > > > I have been searching for a way to remove a custom command > > (POST_BUILD > > event) from a target in CMake but, so far, I've found nothing. > > > > I tried to add another custom command to override the first one but > > it seems > > to append a second command. > > I tough that could work because of the first signature of > > add_custom_command() that can take an optional argument named APPEND. > > https://cmake.org/cmake/help/v3.4/command/add_custom_command.html#gen > > erating-files > > Then, I looked for a target property that contains the POST_BUILD > > custom > > command (to erase it) but, again, I found nothing related (I listed > > every > > property using the "cmake --help-property-list" command). > > > > > > The context is that I configure a project using a "CMake SDK" from a > > third > > party library (custom functions that create and configure a shared > > library > > target basically). > > Until recently, I used to create those target by myself using > > standard CMake > > command. > > But now I switched to the "SDK" because it does a lot of specific > > thing > > depending on the platform (and between the current version of the SDK > > and > > all the legacy version) and I don't want to rewrite everything. > > > > Specifically, this SDK add a custom command as a POST_BUILD event to > > run a > > tool that perform a signature on the produced library. As it is a > > proprietary tool that requires a valid licence to work, I want to > > remove > > that command in order to have a successful build even if i don't > > currently > > have a licence on my machine. > > > > So ... is there some way to remove a custom command in CMake ? (or > > ignore > > failed command maybe) > > CMake doesn't have a way to remove a custom command from a target. Your > best bet would be to either: > > 1) Fork the SDK for your project to remove the proprietary tool, or > 2) Submit a patch upstream to add an option to disable the proprietary > tool. > > Kyle > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Wed Mar 6 02:36:35 2019 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Wed, 6 Mar 2019 08:36:35 +0100 Subject: [CMake] Remove a custom command added with add_custom_command( POST_BUILD ...) In-Reply-To: References: <1551805295283-0.post@n2.nabble.com> <1551808714.22984.5.camel@kitware.com> Message-ID: <984a2112-52ef-4e79-aa44-c6d04934f8f6@Spark> In the meantime if this POST_BUILD command calls a specific tool you can create a no-op shell script with the same name and put its location in the PATH variable. Le 6 mars 2019 ? 07:41 +0100, Olivier Gomez , a ?crit : > Thank you for your suggestions. > I think the best option is a patch but it will take some time ... I guess I will have to find a workaround in the meantime ! > > Anyway, thanks again ! > Olivier > > > Le mar. 5 mars 2019 ? 18:58, Kyle Edwards a ?crit?: > > > On Tue, 2019-03-05 at 10:01 -0700, Olivier Gomez wrote: > > > > Hello, > > > > > > > > I have been searching for a way to remove a custom command > > > > (POST_BUILD > > > > event) from a target in CMake but, so far, I've found nothing. > > > > > > > > I tried to add another custom command to override the first one but > > > > it seems > > > > to append a second command. > > > > I tough that could work because of the first signature of > > > > add_custom_command() that can take an optional argument named APPEND. > > > > https://cmake.org/cmake/help/v3.4/command/add_custom_command.html#gen > > > > erating-files > > > > Then, I looked for a target property that contains the POST_BUILD > > > > custom > > > > command (to erase it) but, again, I found nothing related (I listed > > > > every > > > > property using the "cmake --help-property-list" command). > > > > > > > > > > > > The context is that I configure a project using a "CMake SDK" from a > > > > third > > > > party library (custom functions that create and configure a shared > > > > library > > > > target basically). > > > > Until recently, I used to create those target by myself using > > > > standard CMake > > > > command. > > > > But now I switched to the "SDK" because it does a lot of specific > > > > thing > > > > depending on the platform (and between the current version of the SDK > > > > and > > > > all the legacy version) and I don't want to rewrite everything. > > > > > > > > Specifically, this SDK add a custom command as a POST_BUILD event to > > > > run a > > > > tool that perform a signature on the produced library. As it is a > > > > proprietary tool that requires a valid licence to work, I want to > > > > remove > > > > that command in order to have a successful build even if i don't > > > > currently > > > > have a licence on my machine. > > > > > > > > So ... is there some way to remove a custom command in CMake ? (or > > > > ignore > > > > failed command maybe) > > > > > > CMake doesn't have a way to remove a custom command from a target. Your > > > best bet would be to either: > > > > > > 1) Fork the SDK for your project to remove the proprietary tool, or > > > 2) Submit a patch upstream to add an option to disable the proprietary > > > tool. > > > > > > Kyle > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliviergomez.og at gmail.com Wed Mar 6 03:03:19 2019 From: oliviergomez.og at gmail.com (Olivier Gomez) Date: Wed, 6 Mar 2019 09:03:19 +0100 Subject: [CMake] Remove a custom command added with add_custom_command( POST_BUILD ...) In-Reply-To: <984a2112-52ef-4e79-aa44-c6d04934f8f6@Spark> References: <1551805295283-0.post@n2.nabble.com> <1551808714.22984.5.camel@kitware.com> <984a2112-52ef-4e79-aa44-c6d04934f8f6@Spark> Message-ID: That could work too but as the SDK is a single cmake file that rely on nothing else, I can make a copy of it in my repo, remove the add_custom_command() call and use that local version until the patch is done. It won't force me to change the environment on every computer. But I'll keep that idea for other cases ! Thanks. Olivier Le mer. 6 mars 2019 ? 08:38, Marc CHEVRIER a ?crit : > In the meantime if this POST_BUILD command calls a specific tool you can > create a no-op shell script with the same name and put its location in the > PATH variable. > Le 6 mars 2019 ? 07:41 +0100, Olivier Gomez , > a ?crit : > > Thank you for your suggestions. > I think the best option is a patch but it will take some time ... I guess > I will have to find a workaround in the meantime ! > > Anyway, thanks again ! > Olivier > > Le mar. 5 mars 2019 ? 18:58, Kyle Edwards a > ?crit : > >> On Tue, 2019-03-05 at 10:01 -0700, Olivier Gomez wrote: >> > Hello, >> > >> > I have been searching for a way to remove a custom command >> > (POST_BUILD >> > event) from a target in CMake but, so far, I've found nothing. >> > >> > I tried to add another custom command to override the first one but >> > it seems >> > to append a second command. >> > I tough that could work because of the first signature of >> > add_custom_command() that can take an optional argument named APPEND. >> > https://cmake.org/cmake/help/v3.4/command/add_custom_command.html#gen >> > erating-files >> > Then, I looked for a target property that contains the POST_BUILD >> > custom >> > command (to erase it) but, again, I found nothing related (I listed >> > every >> > property using the "cmake --help-property-list" command). >> > >> > >> > The context is that I configure a project using a "CMake SDK" from a >> > third >> > party library (custom functions that create and configure a shared >> > library >> > target basically). >> > Until recently, I used to create those target by myself using >> > standard CMake >> > command. >> > But now I switched to the "SDK" because it does a lot of specific >> > thing >> > depending on the platform (and between the current version of the SDK >> > and >> > all the legacy version) and I don't want to rewrite everything. >> > >> > Specifically, this SDK add a custom command as a POST_BUILD event to >> > run a >> > tool that perform a signature on the produced library. As it is a >> > proprietary tool that requires a valid licence to work, I want to >> > remove >> > that command in order to have a successful build even if i don't >> > currently >> > have a licence on my machine. >> > >> > So ... is there some way to remove a custom command in CMake ? (or >> > ignore >> > failed command maybe) >> >> CMake doesn't have a way to remove a custom command from a target. Your >> best bet would be to either: >> >> 1) Fork the SDK for your project to remove the proprietary tool, or >> 2) Submit a patch upstream to add an option to disable the proprietary >> tool. >> >> Kyle >> > -- > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Stewart at sig.com Wed Mar 6 15:33:20 2019 From: Robert.Stewart at sig.com (Stewart, Robert) Date: Wed, 6 Mar 2019 20:33:20 +0000 Subject: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS Message-ID: <31b0896761334faaa4f671e599e45ee9@msx.bala.susq.com> We've recently upgraded CMake from 2.8+ to 3.5+ (different versions on different platforms). In so doing, our CMake invocation of CPack to create RPMs now fails and I'm hoping someone can help. I have a spec file and I want to run rpmbuild -bb, but I can't figure out how to do it. We have been using a custom spec file all along, but I found information indicating that doing so is (now?) considered a hack and that everything should be possible merely by setting CPACK_* variables. Unfortunately, that's not the case. With the following %files entries, CPackRPM.cmake chokes: %defattr(-, %{user}, %{group}, 0755) %dir %{destination} %dir %{versioned} %dir %{foo} %{foo}/*.sh %attr(555, %{user}, %{group}) %{foo}/a %dir %{bar} %attr(544, %{user}, %{group}) %{bar}/b %attr(444, %{user}, %{group}) %{bar}/*common %{bar}/lib The result is that my attempt to port to the all-variable approach failed, so I'm setting CPACK_RPM_USER_BINARY_SPECFILE to refer to my spec file as before. Unfortunately, when I do so, CPackRPM.cmake doesn't set RPMBUILD_FLAGS, and that leads to rpmbuild doing nothing useful. The issue is in the following code: # We should generate a USER spec file template: # - either because the user asked for it : CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE # - or the user did not provide one : NOT CPACK_RPM_USER_BINARY_SPECFILE if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT CPACK_RPM_USER_BINARY_SPECFILE) set(RPMBUILD_FLAGS "-bb") I tried just setting RPMBUILD_FLAGS to -bb in my CMakeLists.txt, where I include CPack, but that isn't propagated to CPackRPM.cmake. I tried adding a custom target that invoked "${CMAKE_CPACK_COMMAND} -D RPMBUILD_FLAGS=-bb", but that didn't work either. If the regex processing of the %files content were more robust, I wouldn't trip over the RPMBUILD_FLAGS issue, but either CPACK_RPM_USER_BINARY_SPECFILE is supported or it isn't, and since it is currently, it should be possible for me to set RPMBUILD_FLAGS. Ideas? ___ Rob ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From Robert.Stewart at sig.com Thu Mar 7 08:48:42 2019 From: Robert.Stewart at sig.com (Stewart, Robert) Date: Thu, 7 Mar 2019 13:48:42 +0000 Subject: [CMake] Improve CPackRPM debug output Message-ID: <41fb5975591b4096801b5e0a204bf30c@msx.bala.susq.com> I suggest adding the following to CPackRPM.cmake at https://github.com/Kitware/CMake/blob/8f05be992172e6d65bbb23426231fa253d7f15c9/Modules/Internal/CPack/CPackRPM.cmake#L1776 to aid understanding of what CPackRPM.cmake is doing: if(CPACK_RPM_PACKAGE_DEBUG OR CPACK_RPMBUILD_EXEC_RESULT) message("CPackRPM:Debug: running \"${RPMBUILD_EXECUTABLE}\" ${RPMBUILD_FLAGS} --define \"%_topdir ${CPACK_RPM_DIRECTORY}\" --buildroot \"%_topdir/${CPACK_PACKAGE_FILE_NAME}${CPACK_RPM_PACKAGE_COMPONENT_PART_PATH}\" --target \"${CPACK_RPM_PACKAGE_ARCHITECTURE}\" \"${CPACK_RPM_BINARY_SPECFILE}\" in \"${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}${CPACK_RPM_PACKAGE_COMPONENT_PART_PATH}\"") endif() (It wasn't worth my trouble to fork the project and issue a pull request for this. Should I file a bug?) ___ Rob ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From Robert.Stewart at sig.com Thu Mar 7 08:52:51 2019 From: Robert.Stewart at sig.com (Stewart, Robert) Date: Thu, 7 Mar 2019 13:52:51 +0000 Subject: [CMake] Improve CPackRPM debug output In-Reply-To: <41fb5975591b4096801b5e0a204bf30c@msx.bala.susq.com> References: <41fb5975591b4096801b5e0a204bf30c@msx.bala.susq.com> Message-ID: On Thursday, March 07, 2019 8:49 AM, I wrote: > > I suggest adding the following to CPackRPM.cmake [snip]: > > if(CPACK_RPM_PACKAGE_DEBUG OR CPACK_RPMBUILD_EXEC_RESULT) > message("CPackRPM:Debug: running > \"${RPMBUILD_EXECUTABLE}\" ${RPMBUILD_FLAGS} > --define \"%_topdir ${CPACK_RPM_DIRECTORY}\" > --buildroot > \"%_topdir/${CPACK_PACKAGE_FILE_NAME}${CPACK_RPM_PACKAGE_COMP > ONENT_PART_PATH}\" > --target \"${CPACK_RPM_PACKAGE_ARCHITECTURE}\" > \"${CPACK_RPM_BINARY_SPECFILE}\" > in > \"${CPACK_TOPLEVEL_DIRECTORY}/${CPACK_PACKAGE_FILE_NAME}${CPA > CK_RPM_PACKAGE_COMPONENT_PART_PATH}\"") > endif() I failed to note that the leading whitespace is significant in the message() call. It produces more readable output, though it doesn't eliminate all line wrapping. ___ Rob ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. From jasonlee at lanl.gov Thu Mar 7 12:59:33 2019 From: jasonlee at lanl.gov (Lee, Jason) Date: Thu, 7 Mar 2019 17:59:33 +0000 Subject: [CMake] find_path still using other paths with NO_DEFAULT_PATH on OSX Message-ID: Hi. I'm trying to use find_path to find a header file on OSX with variations of the call find_path(SYS_XATTR NAMES xattr.h PATHS /usr/include PATH_SUFFIXES sys NO_DEFAULT_PATH) However, no matter what is done, the path "/System/Library/Frameworks/Kernel.framework/Headers" is always selected (because there is a sys/xattr.h there), even though NO_DEFAULT_PATH should force find_path to only search "/usr/include". Adding set(CMAKE_FIND_FRAMEWORK "NEVER") and set(CMAKE_FIND_APPBUNDLE "NEVER") does not make a difference. I tried this with many different versions of CMake 3, and this is happening on all of them. How do I get find_path to find the correct path? Thank you. Jason Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From aduque at neuro.ciren.cu Fri Mar 8 09:08:25 2019 From: aduque at neuro.ciren.cu (Armando Abreu Duque) Date: Fri, 8 Mar 2019 09:08:25 -0500 Subject: [CMake] How can I configure ITK for an MFC VS2010 using CMake? Message-ID: Hi. I am a novice using CMake and I am interesting in create a MFC VS2010 Project for use the ITK Library with CMake. When I set up and generated ITK for VS2010 in CMake, and after compiling in VS2010, I discovered that the default settings in the Properties of the created project are related to the Win32 project type. How can I configure the ITK project in CMake that can give me a default MFC configuration? I posted this topic in ITK disclosure site and they recommended me to go to this link: https://stackoverflow.com/questions/11580748/using-cmake-for-making-a-projec t-which-includes-mfc . It illustrates me but I wonder if it is enough with what he tells me. That is why I refer to you, since my question is specific with CMake Attached screenshots showing the settings of the Project Properties in MFC. This is what I need to do in this way because I am maintaining an MFC type project previously created and I want to be able to use the ITK libraries in this project. Thanks in advance any help. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 7023 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MFC_Project _Properties_General_Debug.png Type: image/png Size: 33152 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MFC_Project _Properties_General_Release.png Type: image/png Size: 40506 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MFC_Project _Properties_CodeGeneration_Debug.png Type: image/png Size: 38028 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MFC_Project _Properties_CodeGeneration_Release.png Type: image/png Size: 37912 bytes Desc: not available URL: From patrick.boettcher at posteo.de Fri Mar 8 09:45:50 2019 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Fri, 8 Mar 2019 15:45:50 +0100 Subject: [CMake] How to run the install step of an ExternalProject when installing the whole project? Message-ID: <20190308154550.3d07f853@yaise-pc1> Hi list, I have several externalprojects in my build. Some of them have a quite complete install-step which I would like to have running when the parent-build is installed (and not during the compile build of the parent). How can I achieve that? (It is related to the usage of the DESTDIR-variable which is only present during make install, but not during make) Thanks in advance for any help, -- Patrick. From patrick.boettcher at posteo.de Fri Mar 8 10:01:46 2019 From: patrick.boettcher at posteo.de (Patrick Boettcher) Date: Fri, 8 Mar 2019 16:01:46 +0100 Subject: [CMake] How to run the install step of an ExternalProject when installing the whole project? In-Reply-To: <20190308154550.3d07f853@yaise-pc1> References: <20190308154550.3d07f853@yaise-pc1> Message-ID: <20190308160146.6ddd0abf@yaise-pc1> On Fri, 8 Mar 2019 15:45:50 +0100 Patrick Boettcher wrote: > Hi list, > > I have several externalprojects in my build. Some of them have a quite > complete install-step which I would like to have running when the > parent-build is installed (and not during the compile build of the > parent). > > How can I achieve that? I found a way, but is it the best one? The external-project gets its INSTALL_COMMAND set to "". And then I add: ExternalProject_Get_Property(project-ext BINARY_DIR) install(CODE "execute_process(COMMAND ${CMAKE_COMMAND} --build ${BINARY_DIR} --target install)") -- Patrick. From robert.maynard at kitware.com Fri Mar 8 11:24:59 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 8 Mar 2019 11:24:59 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.14.0-rc4 is ready for testing Message-ID: I am proud to announce the fourth CMake 3.14 release candidate. https://cmake.org/download/ The first two 3.14.0 release candidates included the FindOcatave module. This has been removed in rc3, and rc4 pending further development. Documentation is available at: https://cmake.org/cmake/help/v3.14 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.14/release/3.14.html Some of the more significant changes in CMake 3.14 are: * Support for running CMake on Windows XP and Windows Vista has been dropped. The precompiled Windows binaries provided on "cmake.org" now require Windows 7 or higher. * CMake now supports Cross Compiling for iOS, tvOS, or watchOS using simple toolchain files. * The "Visual Studio 16 2019" generator was added. This is experimental and based on "Visual Studio 2019 Preview 4" because this version of VS has not been released. The VS 2019 generator differs from generators for earlier versions in that it does not provide variants that specify the target platform in the generator name. Instead "CMAKE_GENERATOR_PLATFORM" must be used, e.g. through the "-A" command-line option. Furthermore, the default target platform (architecture) is now based on the *host* platform. The VS host toolset selection is now based on the host architecture as well. * The "Green Hills MULTI" generator has been updated to include Object Library support, support for target renaming and destination output control properties, and other improvements. * A "CMAKE_BUILD_RPATH_USE_ORIGIN" variable and corresponding "BUILD_RPATH_USE_ORIGIN" target property were added to enable use of relative runtime paths (RPATHs). This helps achieving relocatable and reproducible builds that are invariant of the build directory. * The "install(TARGETS)" command learned how to install to an appropriate default directory for a given target type, based on variables from the "GNUInstallDirs" module and built-in defaults, in lieu of a "DESTINATION" argument. * The "install(FILES)" and "install(DIRECTORY)" commands learned a new set of parameters for installing files as a file type, setting the destination based on the appropriate variables from "GNUInstallDirs" and built-in defaults, in lieu of a "DESTINATION" argument. * The "install(CODE)" and "install(SCRIPT)" commands learned to support generator expressions. See policy "CMP0087". * The "if()" command gained support for checking if cache variables are defined with the "DEFINED CACHE{VAR}" syntax. * A file-based api for clients to get semantic buildsystem information has been added. See the "cmake-file-api(7)" manual. This is intended to replace the "cmake-server(7)" mode for IDEs. * The "cmake(1)" Build Tool Mode ("cmake --build") gained "-- verbose" and "-v" options to specify verbose build output. Some generators such as Xcode don't support this option currently. * The "cmake(1)" "-E compare_files" command learned a new "--ignore- eol" option to specify that end-of-line differences (e.g. LF vs CRLF) should be ignored when comparing files. CMake 3.14 Release Notes ************************ Changes made since CMake 3.13 include the following. New Features ============ Generators ---------- * The "Visual Studio 16 2019" generator was added. This is experimental and based on "Visual Studio 2019 Preview 4" because this version of VS has not been released. The VS 2019 generator differs from generators for earlier versions in that it does not provide variants that specify the target platform in the generator name. Instead "CMAKE_GENERATOR_PLATFORM" must be used, e.g. through the "-A" command-line option. Furthermore, the default target platform (architecture) is now based on the *host* platform. The VS host toolset selection is now based on the host architecture as well. * The "Green Hills MULTI" generator has been updated: * Now supports Object Libraries. * Now warns on unsupported project types such as shared libraries. * Now generates a top-level ".top.gpj" for each directory calling the "project()" command. The top-level project file "default.gpj" is no longer created. * Now honors target renaming and destination output control properties such as "RUNTIME_OUTPUT_DIRECTORY" and "OUTPUT_NAME". This also fixes support for installation rules generated by "install()". * Now honors source file properties "INCLUDE_DIRECTORIES", "COMPILE_DEFINITIONS", and "COMPILE_OPTIONS". * Now supports Dynamic Download Integrity Applications which did not include Integrate Files via "GHS_INTEGRITY_APP" and setting a target link flag of "-dynamic". * The contents of project files now sorts sources groups and files by name. Set the "GHS_NO_SOURCE_GROUP_FILE" target property to "ON" to generate a single project file for the target instead of a project file for each source group. Set the "CMAKE_GHS_NO_SOURCE_GROUP_FILE" variable to enable this for all targets. File-Based API -------------- * A file-based api for clients to get semantic buildsystem information has been added. See the "cmake-file-api(7)" manual. This is intended to replace the "cmake-server(7)" mode for IDEs. Platforms --------- * CMake now supports Cross Compiling for iOS, tvOS, or watchOS using simple toolchain files. Command-Line ------------ * The "cmake(1)" Build Tool Mode ("cmake --build") gained "-- verbose" and "-v" options to specify verbose build output. Some generators such as Xcode don't support this option currently. * The "cmake(1)" "-E compare_files" command learned a new "--ignore- eol" option to specify that end-of-line differences (e.g. LF vs CRLF) should be ignored when comparing files. * The "cmake-gui(1)" dialog gained new "-S" and "-B" arguments to explicitly specify source and build directories. Commands -------- * The "file()" command learned a new sub-command, "CREATE_LINK", which can be used to create hard or symbolic links. * The "file()" command learned a new sub-command, "READ_SYMLINK", which can be used to determine the path that a symlink points to. * The "file()" command gained a "SIZE" mode to get the size of a file on disk. * The "find_package()" command learned to optionally resolve symbolic links in the paths to package configuration files. See the "CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS" variable. * The "get_filename_component()" command gained new "LAST_EXT" and "NAME_WLE" variants to work with the extension after the last "." in the name. * The "if()" command gained support for checking if cache variables are defined with the "DEFINED CACHE{VAR}" syntax. * The "install(CODE)" and "install(SCRIPT)" commands learned to support generator expressions. See policy "CMP0087". * The "install(TARGETS)" command learned how to install to an appropriate default directory for a given target type, based on variables from the "GNUInstallDirs" module and built-in defaults, in lieu of a "DESTINATION" argument. * The "install(FILES)" and "install(DIRECTORY)" commands learned a new set of parameters for installing files as a file type, setting the destination based on the appropriate variables from "GNUInstallDirs" and built-in defaults, in lieu of a "DESTINATION" argument. * The "list()" operations "REMOVE_ITEM", "REMOVE_DUPLICATES", "SORT", "REVERSE", and "FILTER" all now accept a non-existent variable as the list since these operations on empty lists is also the empty list. * The "list()" operation "REMOVE_AT" now indicates that the given indices are invalid for a non-existent variable or empty list. * The "try_compile()" and "try_run()" commands gained a new "LINK_OPTIONS" option. Variables --------- * A "CMAKE_BUILD_RPATH_USE_ORIGIN" variable and corresponding "BUILD_RPATH_USE_ORIGIN" target property were added to enable use of relative runtime paths (RPATHs). This helps achieving relocatable and reproducible builds that are invariant of the build directory. Properties ---------- * A "CMAKE_ROLE" global property was added to allow scripts to determine whether they're running in project mode, script mode, find-package mode, CTest, or CPack. * The "CUDA_RESOLVE_DEVICE_SYMBOLS" target property is now supported on shared library, module library, and executable targets. Previously it was only honored on static libraries. * The "EXCLUDE_FROM_ALL" target property was created to override the setting of its directory. A target will now be built as part of "all" if its "EXCLUDE_FROM_ALL" property is set to "OFF", even if its containing directory is marked as "EXCLUDE_FROM_ALL". * "INTERFACE_POSITION_INDEPENDENT_CODE" target property gains the support of "generator expressions". Modules ------- * The family of modules to check capabilities (like "CheckCSourceCompiles") gain capability to manage "LINK_OPTIONS". * A "CheckFortranSourceRuns" module was added to provide a "check_fortran_source_runs()" command to check if a Fortran source snippet compiles and runs. * The "CMakePackageConfigHelpers" module?s "write_basic_package_version_file()" command gained a new "ARCH_INDEPENDENT" option for supporting architecture-independent packages. * The "ExternalProject" module "ExternalProject_Add()" command gained "LOG_DIR" and "LOG_MERGED_STDOUTERR" options to control logging. * The "ExternalProject" module "ExternalProject_Add()" command gained "LOG_PATCH" to optionally log the patch step. * The "ExternalProject" module's "ExternalProject_Add()" command learned to apply "SOURCE_SUBDIR" when "BUILD_IN_SOURCE" is also used. The "BUILD_COMMAND" is run in the given "SOURCE_SUBDIR" of the "SOURCE_DIR". * The "FetchContent" module gained a new "FetchContent_MakeAvailable()" command. It accepts a list of dependency names, which it then iterates over, populating and adding each one to the main build using the canonical pattern. This significantly reduces the amount of boilerplate needed in a project. * The "FindBISON" module's "BISON_TARGET" command now runs "bison" with "CMAKE_CURRENT_BINARY_DIR" as the working directory. See policy "CMP0088". * The "FindCURL" module gained support for requesting protocols as package components. * The "FindFontconfig" module was added to find fontconfig. * The "FindGDAL" module now provides imported targets. * The "FindGIF" module now provides imported targets. * The "FindGit" module now provides an imported target for the Git executable. * The "FindIce" module learned to find "slice2confluence" and "slice2matlab". * The "FindLibinput" module was added to find libinput. * The "FindLibLZMA" module now provides imported targets. * The "FindMatlab" module gained new options "R2017b" and "R2018a" to specify the MEX API version to use; these options mirror the new options to the "mex" command in MATLAB R2018a. The option "MX_LIBRARY" is no longer needed. * The "FindPostgreSQL" module now provides imported targets. * The "FindPython", "FindPython2", and "FindPython3" modules gained support for "NumPy" component. * The "FindPython2", "FindPython3", and "FindPython" modules now support running in script mode by skipping the creation of imported targets and helper functions. * The "FindSQLite3" module was added to find the SQLite v3.x library. * The "FindX11" had the following variables renamed in order to match their library names rather than header names. The old variables are provided for compatibility: * "X11_Xxf86misc_INCLUDE_PATH" instead of "X11_xf86misc_INCLUDE_PATH" * "X11_Xxf86misc_LIB" instead of "X11_xf86misc_LIB" * "X11_Xxf86misc_FOUND" instead of "X11_xf86misc_FOUND" * "X11_Xxf86vm_INCLUDE_PATH" instead of "X11_xf86vmode_INCLUDE_PATH" * "X11_Xxf86vm_LIB" instead of "X11_xf86vmode_LIB" * "X11_Xxf86vm_FOUND" instead of "X11_xf86vmode_FOUND" * "X11_xkbfile_INCLUDE_PATH" instead of "X11_Xkbfile_INCLUDE_PATH" * "X11_xkbfile_LIB" instead of "X11_Xkbfile_LIB" * "X11_xkbfile_FOUND" instead of "X11_Xkbfile_FOUND" * "X11_Xtst_INCLUDE_PATH" instead of "X11_XTest_INCLUDE_PATH" * "X11_Xtst_LIB" instead of "X11_XTest_LIB" * "X11_Xtst_FOUND" instead of "X11_XTest_FOUND" * "X11_Xss_INCLUDE_PATH" instead of "X11_Xscreensaver_INCLUDE_PATH" * "X11_Xss_LIB" instead of "X11_Xscreensaver_LIB" * "X11_Xss_FOUND" instead of "X11_Xscreensaver_FOUND" The following variables are deprecated completely since they were essentially duplicates: * "X11_Xinput_INCLUDE_PATH" (use "X11_Xi_INCLUDE_PATH") * "X11_Xinput_LIB" (use "X11_Xi_LIB") * "X11_Xinput_FOUND" (use "X11_Xi_FOUND") * The "FindX11" now provides "X11_Xext_INCLUDE_PATH". * The "FindX11" now provides imported targets. * The "UseSWIG" module learned to pass "-module " to the "SWIG" compiler if the file property "SWIG_MODULE_NAME" is defined. See policy "CMP0086". * The "UseSWIG" module gained an option to specify "SWIG" source file extensions. Generator Expressions --------------------- * The "$" and "$" "generator expressions" were added. * The "$" generator expression now correctly handles an empty argument. See "CMP0085" for details. Autogen ------- * The "AUTOMOC_EXECUTABLE", "AUTORCC_EXECUTABLE", and "AUTOUIC_EXECUTABLE" target properties were added. They all take a path to an executable and force automoc/autorcc/autouic to use this executable. Setting these will also prevent the configure time testing for these executables. This is mainly useful when you build these tools yourself. * The new variables "CMAKE_GLOBAL_AUTOGEN_TARGET", "CMAKE_GLOBAL_AUTOGEN_TARGET_NAME", "CMAKE_GLOBAL_AUTORCC_TARGET" and "CMAKE_GLOBAL_AUTORCC_TARGET_NAME" control the generation of global "autogen" and "autorcc" targets. * A new "CMAKE_AUTOGEN_ORIGIN_DEPENDS" variable and "AUTOGEN_ORIGIN_DEPENDS" target property may be set to enable or disable forwarding of the origin target dependencies to the corresponding "_autogen" target. CTest ----- * "ctest(1)" gained a "--show-only=json-v1" option to show the list of tests in a machine-readable JSON format. See the Show as JSON Object Model section of the manual. * The "ctest_submit()" command learned a new "Done" part that can be used to inform CDash that a build is complete and that no more parts will be uploaded. * CTest learned to accept the dashboard server submission URL from a single variable. See the "SubmitURL" setting in "ctest(1)", the "CTEST_SUBMIT_URL" variable, and the "SUBMIT_URL" argument of the "ctest_submit()" command. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0064" and "CMP0065" ("CMP0063" and below were already deprecated). The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. * The "Xcode" generator deprecated support for Xcode versions prior to Xcode 5. Support for those will be dropped in a future version of CMake. * The "FindQt" module is no longer used by the "find_package()" command as a find module. This allows the Qt Project upstream to optionally provide its own "QtConfig.cmake" package configuration file and have applications use it via "find_package(Qt)" rather than "find_package(Qt CONFIG)". See policy "CMP0084". * Support for running CMake on Windows XP and Windows Vista has been dropped. The precompiled Windows binaries provided on "cmake.org" now require Windows 7 or higher. * CTest no longer supports submissions via "ftp", "scp", "cp", and "xmlrpc". CDash is the only maintained testing dashboard for CTest, and it only supports submissions over "http" and "https". Other Changes ============= * Object library linking has been fixed to propagate private link libraries of object libraries to consuming targets. * Install rules under "add_subdirectory()" now interleave with those in the calling directory. See policy "CMP0082" for details. * CMake now imposes a maximum recursion limit to prevent a stack overflow on scripts that recurse infinitely. The limit can be adjusted at runtime with "CMAKE_MAXIMUM_RECURSION_DEPTH". * When using cppcheck via the "CMAKE__CPPCHECK" variable or "_CPPCHECK" property, the build will now fail if "cppcheck" returns non-zero as configured by its command-line options. * Required link options to manage Position Independent Executable are now added when "POSITION_INDEPENDENT_CODE" is set. The project is responsible for using the "CheckPIESupported" module to check for "PIE" support to ensure that the "POSITION_INDEPENDENT_CODE" target property will be honored at link time for executables. This behavior is controlled by policy "CMP0083". * Visual Studio Generators for VS 2010 and above learned to support the "VS_DEBUGGER_*" properties on targets created via "add_custom_target()". * The "CPack" module no longer defaults to the "paxr" value in the "CPACK_DEBIAN_ARCHIVE_TYPE" variable, because "dpkg" has never supported the PAX tar format. The "paxr" value will be mapped to "gnutar" and a deprecation message emitted. * CMake no longer issues a warning if a target listed in an "install(TARGETS)" command has its "EXCLUDE_FROM_ALL" property set to true. ---------------------------------------------------------------------------- Changes made since CMake 3.14.0-rc3: Brad King (4): VS: Fix Fortran target type selection with RC sources install: Do not crash on imported global target C++ feature checks: Match warnings more strictly CMake 3.14.0-rc4 Craig Scott (4): Help: clarify DESTINATION and TYPE usage for install() Help: Sort lists of (CMAKE_)XCODE_SCHEME_... variables and properties Help: Trivial typo fix for CMAKE_XCODE_GENERATE_SCHEME Help: Remove note that Xcode scheme generator is experimental Luca Cappa (1): VS: Encode newlines in XML attributes Marc Chevrier (1): FindPython: Fix NumPy component include directory Ruslan Baratov (4): iOS: Add IOS variable Help: find_package with fat iOS libraries Help: Example of tweaking iOS/tvOS/watchOS build Help: CMAKE_MACOSX_BUNDLE is ON for iOS/tvOS/watchOS From workbench at gmx.at Sat Mar 9 02:38:55 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Sat, 9 Mar 2019 08:38:55 +0100 Subject: [CMake] Troubles with include_directories Message-ID: <5a7b302f-aa30-5116-d8a6-c92cde2e41f9@gmx.at> Hi everyone, i've a project setup that looks like this: abc.h def.h and all my other .cpp and .h files are in the folder intern. Now my CMakeLists.txt looks like this: cmake_minimum_required(VERSION 3.7) project(BS_Application) set(SRC ??? BS_AppTypes.hpp ??? BS_IEvent.hpp ??? BS_ISystem.hpp ??? BS_IWindow.hpp ??? BS_ITimerTask.hpp ??? BS_IEventConsumer.hpp ??? BS_Application.cpp ??? BS_Button.cpp ??? BS_ContextSDL.cpp ??? BS_ISystem.cpp ??? BS_System.cpp ??? BS_SystemSDL.cpp ??? BS_WindowSDL.cpp ??? BS_ContextSDL.cpp ??? BS_DisplayManagerSDL.cpp ??? BS_Button.cpp ??? BS_EventManager.cpp ??? BS_EventPrinter.cpp ??? BS_ModifierKeys.cpp ??? BS_DisplayManager.cpp ) set(INC ??? intern ) include_directories(${INC}) add_library(BS_Application STATIC ${SRC}) Where all files above BS_Application.cpp are in the folder intern but he is not able to find BS_Application.cpp but i added it to the include_direcotires, what am i doing wrong here ? best regards! From workbench at gmx.at Sat Mar 9 02:53:21 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Sat, 9 Mar 2019 08:53:21 +0100 Subject: [CMake] Troubles with include_directories In-Reply-To: <5a7b302f-aa30-5116-d8a6-c92cde2e41f9@gmx.at> References: <5a7b302f-aa30-5116-d8a6-c92cde2e41f9@gmx.at> Message-ID: <2aeda0bf-ee0c-eb31-98d9-004356ecbacd@gmx.at> I mean belov, all files bellow BS_IEventConsumer.hpp (beginning with BS_Application) are in the intern folder in the same path as the other files above BS_Application. best regards! On 09.03.19 08:38, Workbench at gmx.at wrote: > Hi everyone, > > i've a project setup that looks like this: > > > abc.h > > def.h > > and all my other .cpp and .h files are in the folder intern. Now my > CMakeLists.txt looks like this: > > cmake_minimum_required(VERSION 3.7) > project(BS_Application) > set(SRC > ??? BS_AppTypes.hpp > ??? BS_IEvent.hpp > ??? BS_ISystem.hpp > ??? BS_IWindow.hpp > ??? BS_ITimerTask.hpp > ??? BS_IEventConsumer.hpp > ??? BS_Application.cpp > ??? BS_Button.cpp > ??? BS_ContextSDL.cpp > ??? BS_ISystem.cpp > ??? BS_System.cpp > ??? BS_SystemSDL.cpp > ??? BS_WindowSDL.cpp > ??? BS_ContextSDL.cpp > ??? BS_DisplayManagerSDL.cpp > ??? BS_Button.cpp > ??? BS_EventManager.cpp > ??? BS_EventPrinter.cpp > ??? BS_ModifierKeys.cpp > ??? BS_DisplayManager.cpp > ) > set(INC > ??? intern > ) > include_directories(${INC}) > add_library(BS_Application STATIC ${SRC}) > > Where all files above BS_Application.cpp are in the folder intern but > he is not able to find BS_Application.cpp but i added it to the > include_direcotires, what am i doing wrong here ? > > > best regards! > From workbench at gmx.at Sun Mar 10 05:40:49 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Sun, 10 Mar 2019 10:40:49 +0100 Subject: [CMake] Question about INSTALL_COMMAND for ExternalProject_Add() Message-ID: <96080f63-d03d-68f8-d204-ddf91a99e344@gmx.at> Hi everyone, i've managed to use ExternalProject_Add to install GLFW but i have troubles with glad... Here is my code for GLFW wich is working: include(ExternalProject) ExternalProject_Add(GLFW ??? PREFIX ${LIBDIR}/${CMAKE_BUILD_TYPE}/glfw-log ??? GIT_REPOSITORY https://github.com/glfw/glfw.git ??? GIT_TAG 3.2.1 ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glfw ??? UPDATE_COMMAND "" ??? PATCH_COMMAND "" ??? INSTALL_DIR ${LIBDIR}/glfw ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String={CMAKE_BUILD_TYPE} -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glfw ) Now i tried the same with GLAD but i had to add INSTALL_COMMAND to make it work but i've no clue what i should enter there to install it the same way i did with glfw.. ExternalProject_Add(GLAD ??? PREFIX ${LIBDIR}/${CMAKE_BUILD_TYPE}/glad-log ??? GIT_REPOSITORY https://github.com/Dav1dde/glad.git ??? GIT_TAG v0.1.29 ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glad ??? UPDATE_COMMAND "" ??? PATCH_COMMAND "" ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}/glad ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String=${CMAKE_BUILD_TYPE} -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glad ??? INSTALL_COMMAND "??" ) I hope someone can help me, i'm a bit clueless about this. best regards! -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 2452 bytes Desc: not available URL: From workbench at gmx.at Sun Mar 10 06:44:48 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Sun, 10 Mar 2019 11:44:48 +0100 Subject: [CMake] Question about INSTALL_COMMAND for ExternalProject_Add() In-Reply-To: <96080f63-d03d-68f8-d204-ddf91a99e344@gmx.at> References: <96080f63-d03d-68f8-d204-ddf91a99e344@gmx.at> Message-ID: Now i've managed to create the right INSTALL_COMMAND but i don't know how to link with my executable. i tried add_executable(MyApp ${src}) target_link_libraries(MyApp STATIC GLFW GLAD) and i get the following error message: CMake Error at CMakeLists.txt:96 (target_link_libraries): ? Target "LIBGLAD" of type UTILITY may not be linked into another target. ? One may link only to INTERFACE, OBJECT, STATIC or SHARED libraries, or to ? executables with the ENABLE_EXPORTS property set. CMake Error at CMakeLists.txt:96 (target_link_libraries): ? Target "LIBGLFW" of type UTILITY may not be linked into another target. ? One may link only to INTERFACE, OBJECT, STATIC or SHARED libraries, or to ? executables with the ENABLE_EXPORTS property set. target_link_libraries(M On 10.03.19 10:40, Workbench at gmx.at wrote: > Hi everyone, > > i've managed to use ExternalProject_Add to install GLFW but i have > troubles with glad... > > Here is my code for GLFW wich is working: > > include(ExternalProject) > ExternalProject_Add(GLFW > ??? PREFIX ${LIBDIR}/${CMAKE_BUILD_TYPE}/glfw-log > ??? GIT_REPOSITORY https://github.com/glfw/glfw.git > ??? GIT_TAG 3.2.1 > ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glfw > ??? UPDATE_COMMAND "" > ??? PATCH_COMMAND "" > ??? INSTALL_DIR ${LIBDIR}/glfw > ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String={CMAKE_BUILD_TYPE} > -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glfw > ) > > Now i tried the same with GLAD but i had to add INSTALL_COMMAND to make > it work but i've no clue what i should enter there to install it the > same way i did with glfw.. > > ExternalProject_Add(GLAD > ??? PREFIX ${LIBDIR}/${CMAKE_BUILD_TYPE}/glad-log > ??? GIT_REPOSITORY https://github.com/Dav1dde/glad.git > ??? GIT_TAG v0.1.29 > ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glad > ??? UPDATE_COMMAND "" > ??? PATCH_COMMAND "" > ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}/glad > ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String=${CMAKE_BUILD_TYPE} > -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glad > ??? INSTALL_COMMAND "??" > ) > > > I hope someone can help me, i'm a bit clueless about this. > > > best regards! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 2452 bytes Desc: not available URL: From workbench at gmx.at Sun Mar 10 07:38:06 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Sun, 10 Mar 2019 12:38:06 +0100 Subject: [CMake] Question about INSTALL_COMMAND for ExternalProject_Add() In-Reply-To: References: <96080f63-d03d-68f8-d204-ddf91a99e344@gmx.at> Message-ID: <19a778dd-d3b5-a85a-3994-4ef5b3e0aee9@gmx.at> I came a step forward, now it looks like this: include(ExternalProject) ExternalProject_Add(glfw3 ??? PREFIX ${CMAKE_BINARY_DIR}/glfw-log ??? GIT_REPOSITORY https://github.com/glfw/glfw.git ??? GIT_TAG 3.2.1 ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glfw ??? UPDATE_COMMAND "" ??? PATCH_COMMAND "" ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/glfw ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String={CMAKE_BUILD_TYPE} -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glfw ) ExternalProject_Add(glad ??? PREFIX ${CMAKE_BINARY_DIR}/glad-log ??? GIT_REPOSITORY https://github.com/Dav1dde/glad.git ??? GIT_TAG v0.1.29 ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glad ??? UPDATE_COMMAND "" ??? PATCH_COMMAND "" ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/glad ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String=${CMAKE_BUILD_TYPE} -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glad -DGLAD_EXPORT=True -DGLAD_INSTALL=True ??? CONFIGURE_COMMAND ${CMAKE_BUILD_DIR}/ ??? INSTALL_COMMAND ??? ??? COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_BINARY_DIR}/glad-log/src/glad-build/libglad.a ${LIB_DIR}/glad/lib/libglad.a ??? ??? COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_BINARY_DIR}/glad-log/src/glad-build/include ${LIB_DIR}/glad/ ) find_package(glad REQUIRED) find_package(glfw3 REQUIRED) add_executable(Test01 source/test/Test01.cpp) target_link_libraries(Test01 PRIVATE glad glfw3) But now i've the following problem, i get the error message: CMake Error at CMakeLists.txt:95 (find_package): ? By not providing "Findglad.cmake" in CMAKE_MODULE_PATH this project has ? asked CMake to find a package configuration file provided by "glad", but ? CMake did not find one. ? Could not find a package configuration file provided by "glad" with any of ? the following names: ??? gladConfig.cmake ??? glad-config.cmake ? Add the installation prefix of "glad" to CMAKE_PREFIX_PATH or set ? "glad_DIR" to a directory containing one of the above files.? If "glad" ? provides a separate development package or SDK, be sure it has been ? installed. The problem is gladConfig.cmake is created after the configure procedure, how can i solve this issue ?? best regards! On 10.03.19 11:44, Workbench at gmx.at wrote: > > Now i've managed to create the right INSTALL_COMMAND but i don't know > how to link with my executable. i tried > > add_executable(MyApp ${src}) > > target_link_libraries(MyApp STATIC GLFW GLAD) > > and i get the following error message: > > CMake Error at CMakeLists.txt:96 (target_link_libraries): > ? Target "LIBGLAD" of type UTILITY may not be linked into another target. > ? One may link only to INTERFACE, OBJECT, STATIC or SHARED libraries, > or to > ? executables with the ENABLE_EXPORTS property set. > > > CMake Error at CMakeLists.txt:96 (target_link_libraries): > ? Target "LIBGLFW" of type UTILITY may not be linked into another target. > ? One may link only to INTERFACE, OBJECT, STATIC or SHARED libraries, > or to > ? executables with the ENABLE_EXPORTS property set. > > > > target_link_libraries(M > > On 10.03.19 10:40, Workbench at gmx.at wrote: >> Hi everyone, >> >> i've managed to use ExternalProject_Add to install GLFW but i have >> troubles with glad... >> >> Here is my code for GLFW wich is working: >> >> include(ExternalProject) >> ExternalProject_Add(GLFW >> ??? PREFIX ${LIBDIR}/${CMAKE_BUILD_TYPE}/glfw-log >> ??? GIT_REPOSITORY https://github.com/glfw/glfw.git >> ??? GIT_TAG 3.2.1 >> ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glfw >> ??? UPDATE_COMMAND "" >> ??? PATCH_COMMAND "" >> ??? INSTALL_DIR ${LIBDIR}/glfw >> ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String={CMAKE_BUILD_TYPE} >> -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glfw >> ) >> >> Now i tried the same with GLAD but i had to add INSTALL_COMMAND to make >> it work but i've no clue what i should enter there to install it the >> same way i did with glfw.. >> >> ExternalProject_Add(GLAD >> ??? PREFIX ${LIBDIR}/${CMAKE_BUILD_TYPE}/glad-log >> ??? GIT_REPOSITORY https://github.com/Dav1dde/glad.git >> ??? GIT_TAG v0.1.29 >> ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glad >> ??? UPDATE_COMMAND "" >> ??? PATCH_COMMAND "" >> ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}/glad >> ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String=${CMAKE_BUILD_TYPE} >> -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glad >> ??? INSTALL_COMMAND "??" >> ) >> >> >> I hope someone can help me, i'm a bit clueless about this. >> >> >> best regards! >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 2452 bytes Desc: not available URL: From workbench at gmx.at Sun Mar 10 08:20:25 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Sun, 10 Mar 2019 13:20:25 +0100 Subject: [CMake] Question about INSTALL_COMMAND for ExternalProject_Add() In-Reply-To: <19a778dd-d3b5-a85a-3994-4ef5b3e0aee9@gmx.at> References: <96080f63-d03d-68f8-d204-ddf91a99e344@gmx.at> <19a778dd-d3b5-a85a-3994-4ef5b3e0aee9@gmx.at> Message-ID: I got the problem solved again, but now i'm stuck... now i've the following: add_library(glad STATIC IMPORTED) set_target_properties(glad PROPERTIES IMPORTED_LOCATION ${LIB_DIR}/glad/lib/libglad.a) add_library(glfw3 STATIC IMPORTED) set_target_properties(glfw3 PROPERTIES IMPORTED_LOCATION ${LIB_DIR}/glew/lib/libglfw3.a) add_executable(Test01 source/test/Test01.cpp) target_link_libraries(Test01 PRIVATE glad glfw3) But now he can't find the header files which are also created after the configuration, how to solve this problem ?? I hope you see i put much effort in this and find most of the problems alone, i hope this time someone can help me out. best regards! On 10.03.19 12:38, Workbench at gmx.at wrote: > > I came a step forward, now it looks like this: > > include(ExternalProject) > ExternalProject_Add(glfw3 > ??? PREFIX ${CMAKE_BINARY_DIR}/glfw-log > ??? GIT_REPOSITORY https://github.com/glfw/glfw.git > ??? GIT_TAG 3.2.1 > ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glfw > ??? UPDATE_COMMAND "" > ??? PATCH_COMMAND "" > ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/glfw > ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String={CMAKE_BUILD_TYPE} > -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glfw > ) > > ExternalProject_Add(glad > ??? PREFIX ${CMAKE_BINARY_DIR}/glad-log > ??? GIT_REPOSITORY https://github.com/Dav1dde/glad.git > ??? GIT_TAG v0.1.29 > ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glad > ??? UPDATE_COMMAND "" > ??? PATCH_COMMAND "" > ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/glad > ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String=${CMAKE_BUILD_TYPE} > -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glad -DGLAD_EXPORT=True > -DGLAD_INSTALL=True > ??? CONFIGURE_COMMAND ${CMAKE_BUILD_DIR}/ > ??? INSTALL_COMMAND > ??? ??? COMMAND ${CMAKE_COMMAND} -E copy > ${CMAKE_BINARY_DIR}/glad-log/src/glad-build/libglad.a > ${LIB_DIR}/glad/lib/libglad.a > ??? ??? COMMAND ${CMAKE_COMMAND} -E copy_directory > ${CMAKE_BINARY_DIR}/glad-log/src/glad-build/include ${LIB_DIR}/glad/ > ) > find_package(glad REQUIRED) > find_package(glfw3 REQUIRED) > add_executable(Test01 source/test/Test01.cpp) > target_link_libraries(Test01 PRIVATE glad glfw3) > > But now i've the following problem, i get the error message: > > CMake Error at CMakeLists.txt:95 (find_package): > ? By not providing "Findglad.cmake" in CMAKE_MODULE_PATH this project has > ? asked CMake to find a package configuration file provided by "glad", but > ? CMake did not find one. > > ? Could not find a package configuration file provided by "glad" with > any of > ? the following names: > > ??? gladConfig.cmake > ??? glad-config.cmake > > ? Add the installation prefix of "glad" to CMAKE_PREFIX_PATH or set > ? "glad_DIR" to a directory containing one of the above files.? If "glad" > ? provides a separate development package or SDK, be sure it has been > ? installed. > > The problem is gladConfig.cmake is created after the configure > procedure, how can i solve this issue ?? > > > best regards! > > > > > On 10.03.19 11:44, Workbench at gmx.at wrote: >> >> Now i've managed to create the right INSTALL_COMMAND but i don't know >> how to link with my executable. i tried >> >> add_executable(MyApp ${src}) >> >> target_link_libraries(MyApp STATIC GLFW GLAD) >> >> and i get the following error message: >> >> CMake Error at CMakeLists.txt:96 (target_link_libraries): >> ? Target "LIBGLAD" of type UTILITY may not be linked into another target. >> ? One may link only to INTERFACE, OBJECT, STATIC or SHARED libraries, >> or to >> ? executables with the ENABLE_EXPORTS property set. >> >> >> CMake Error at CMakeLists.txt:96 (target_link_libraries): >> ? Target "LIBGLFW" of type UTILITY may not be linked into another target. >> ? One may link only to INTERFACE, OBJECT, STATIC or SHARED libraries, >> or to >> ? executables with the ENABLE_EXPORTS property set. >> >> >> >> target_link_libraries(M >> >> On 10.03.19 10:40, Workbench at gmx.at wrote: >>> Hi everyone, >>> >>> i've managed to use ExternalProject_Add to install GLFW but i have >>> troubles with glad... >>> >>> Here is my code for GLFW wich is working: >>> >>> include(ExternalProject) >>> ExternalProject_Add(GLFW >>> ??? PREFIX ${LIBDIR}/${CMAKE_BUILD_TYPE}/glfw-log >>> ??? GIT_REPOSITORY https://github.com/glfw/glfw.git >>> ??? GIT_TAG 3.2.1 >>> ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glfw >>> ??? UPDATE_COMMAND "" >>> ??? PATCH_COMMAND "" >>> ??? INSTALL_DIR ${LIBDIR}/glfw >>> ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String={CMAKE_BUILD_TYPE} >>> -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glfw >>> ) >>> >>> Now i tried the same with GLAD but i had to add INSTALL_COMMAND to make >>> it work but i've no clue what i should enter there to install it the >>> same way i did with glfw.. >>> >>> ExternalProject_Add(GLAD >>> ??? PREFIX ${LIBDIR}/${CMAKE_BUILD_TYPE}/glad-log >>> ??? GIT_REPOSITORY https://github.com/Dav1dde/glad.git >>> ??? GIT_TAG v0.1.29 >>> ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glad >>> ??? UPDATE_COMMAND "" >>> ??? PATCH_COMMAND "" >>> ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}/glad >>> ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String=${CMAKE_BUILD_TYPE} >>> -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glad >>> ??? INSTALL_COMMAND "??" >>> ) >>> >>> >>> I hope someone can help me, i'm a bit clueless about this. >>> >>> >>> best regards! >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 2452 bytes Desc: not available URL: From workbench at gmx.at Sun Mar 10 10:47:26 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Sun, 10 Mar 2019 15:47:26 +0100 Subject: [CMake] Question about INSTALL_COMMAND for ExternalProject_Add() In-Reply-To: References: <96080f63-d03d-68f8-d204-ddf91a99e344@gmx.at> <19a778dd-d3b5-a85a-3994-4ef5b3e0aee9@gmx.at> Message-ID: <5dfaca6f-e7e8-a0b6-0062-ad345f64c8cc@gmx.at> I finally got it working, for other who might have the same problem: You just have to use ExternalProject_Add(ftgl-dl ... .... ) add_executable(Test01 ${SRC}) add_dependencies(Test01 ftgl-dl) That all! Happy coding! best regards! On 10.03.19 13:20, Workbench at gmx.at wrote: > > I got the problem solved again, but now i'm stuck... now i've the > following: > > > add_library(glad STATIC IMPORTED) > set_target_properties(glad PROPERTIES IMPORTED_LOCATION > ${LIB_DIR}/glad/lib/libglad.a) > > add_library(glfw3 STATIC IMPORTED) > set_target_properties(glfw3 PROPERTIES IMPORTED_LOCATION > ${LIB_DIR}/glew/lib/libglfw3.a) > > > add_executable(Test01 source/test/Test01.cpp) > target_link_libraries(Test01 PRIVATE glad glfw3) > > But now he can't find the header files which are also created after > the configuration, how to solve this problem ?? > > I hope you see i put much effort in this and find most of the problems > alone, i hope this time someone can help me out. > > > best regards! > > > On 10.03.19 12:38, Workbench at gmx.at wrote: >> >> I came a step forward, now it looks like this: >> >> include(ExternalProject) >> ExternalProject_Add(glfw3 >> ??? PREFIX ${CMAKE_BINARY_DIR}/glfw-log >> ??? GIT_REPOSITORY https://github.com/glfw/glfw.git >> ??? GIT_TAG 3.2.1 >> ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glfw >> ??? UPDATE_COMMAND "" >> ??? PATCH_COMMAND "" >> ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/glfw >> ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String={CMAKE_BUILD_TYPE} >> -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glfw >> ) >> >> ExternalProject_Add(glad >> ??? PREFIX ${CMAKE_BINARY_DIR}/glad-log >> ??? GIT_REPOSITORY https://github.com/Dav1dde/glad.git >> ??? GIT_TAG v0.1.29 >> ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glad >> ??? UPDATE_COMMAND "" >> ??? PATCH_COMMAND "" >> ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/glad >> ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String=${CMAKE_BUILD_TYPE} >> -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glad -DGLAD_EXPORT=True >> -DGLAD_INSTALL=True >> ??? CONFIGURE_COMMAND ${CMAKE_BUILD_DIR}/ >> ??? INSTALL_COMMAND >> ??? ??? COMMAND ${CMAKE_COMMAND} -E copy >> ${CMAKE_BINARY_DIR}/glad-log/src/glad-build/libglad.a >> ${LIB_DIR}/glad/lib/libglad.a >> ??? ??? COMMAND ${CMAKE_COMMAND} -E copy_directory >> ${CMAKE_BINARY_DIR}/glad-log/src/glad-build/include ${LIB_DIR}/glad/ >> ) >> find_package(glad REQUIRED) >> find_package(glfw3 REQUIRED) >> add_executable(Test01 source/test/Test01.cpp) >> target_link_libraries(Test01 PRIVATE glad glfw3) >> >> But now i've the following problem, i get the error message: >> >> CMake Error at CMakeLists.txt:95 (find_package): >> ? By not providing "Findglad.cmake" in CMAKE_MODULE_PATH this project has >> ? asked CMake to find a package configuration file provided by >> "glad", but >> ? CMake did not find one. >> >> ? Could not find a package configuration file provided by "glad" with >> any of >> ? the following names: >> >> ??? gladConfig.cmake >> ??? glad-config.cmake >> >> ? Add the installation prefix of "glad" to CMAKE_PREFIX_PATH or set >> ? "glad_DIR" to a directory containing one of the above files.? If "glad" >> ? provides a separate development package or SDK, be sure it has been >> ? installed. >> >> The problem is gladConfig.cmake is created after the configure >> procedure, how can i solve this issue ?? >> >> >> best regards! >> >> >> >> >> On 10.03.19 11:44, Workbench at gmx.at wrote: >>> >>> Now i've managed to create the right INSTALL_COMMAND but i don't >>> know how to link with my executable. i tried >>> >>> add_executable(MyApp ${src}) >>> >>> target_link_libraries(MyApp STATIC GLFW GLAD) >>> >>> and i get the following error message: >>> >>> CMake Error at CMakeLists.txt:96 (target_link_libraries): >>> ? Target "LIBGLAD" of type UTILITY may not be linked into another >>> target. >>> ? One may link only to INTERFACE, OBJECT, STATIC or SHARED >>> libraries, or to >>> ? executables with the ENABLE_EXPORTS property set. >>> >>> >>> CMake Error at CMakeLists.txt:96 (target_link_libraries): >>> ? Target "LIBGLFW" of type UTILITY may not be linked into another >>> target. >>> ? One may link only to INTERFACE, OBJECT, STATIC or SHARED >>> libraries, or to >>> ? executables with the ENABLE_EXPORTS property set. >>> >>> >>> >>> target_link_libraries(M >>> >>> On 10.03.19 10:40, Workbench at gmx.at wrote: >>>> Hi everyone, >>>> >>>> i've managed to use ExternalProject_Add to install GLFW but i have >>>> troubles with glad... >>>> >>>> Here is my code for GLFW wich is working: >>>> >>>> include(ExternalProject) >>>> ExternalProject_Add(GLFW >>>> ??? PREFIX ${LIBDIR}/${CMAKE_BUILD_TYPE}/glfw-log >>>> ??? GIT_REPOSITORY https://github.com/glfw/glfw.git >>>> ??? GIT_TAG 3.2.1 >>>> ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glfw >>>> ??? UPDATE_COMMAND "" >>>> ??? PATCH_COMMAND "" >>>> ??? INSTALL_DIR ${LIBDIR}/glfw >>>> ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String={CMAKE_BUILD_TYPE} >>>> -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glfw >>>> ) >>>> >>>> Now i tried the same with GLAD but i had to add INSTALL_COMMAND to make >>>> it work but i've no clue what i should enter there to install it the >>>> same way i did with glfw.. >>>> >>>> ExternalProject_Add(GLAD >>>> ??? PREFIX ${LIBDIR}/${CMAKE_BUILD_TYPE}/glad-log >>>> ??? GIT_REPOSITORY https://github.com/Dav1dde/glad.git >>>> ??? GIT_TAG v0.1.29 >>>> ??? SOURCE_DIR ${CMAKE_BINARY_DIR}/glad >>>> ??? UPDATE_COMMAND "" >>>> ??? PATCH_COMMAND "" >>>> ??? INSTALL_DIR ${CMAKE_BINARY_DIR}/${CMAKE_BUILD_TYPE}/glad >>>> ??? CMAKE_ARGS -DCMAKE_BUILD_TYPE:String=${CMAKE_BUILD_TYPE} >>>> -DCMAKE_INSTALL_PREFIX=${LIB_DIR}/glad >>>> ??? INSTALL_COMMAND "??" >>>> ) >>>> >>>> >>>> I hope someone can help me, i'm a bit clueless about this. >>>> >>>> >>>> best regards! >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 2452 bytes Desc: not available URL: From eric.noulard at gmail.com Sun Mar 10 11:09:16 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Sun, 10 Mar 2019 16:09:16 +0100 Subject: [CMake] Troubles with include_directories In-Reply-To: <5a7b302f-aa30-5116-d8a6-c92cde2e41f9@gmx.at> References: <5a7b302f-aa30-5116-d8a6-c92cde2e41f9@gmx.at> Message-ID: Le sam. 9 mars 2019 ? 08:44, Workbench at gmx.at a ?crit : > Hi everyone, > > i've a project setup that looks like this: > > > abc.h > > def.h > > and all my other .cpp and .h files are in the folder intern. Now my > CMakeLists.txt looks like this: > > cmake_minimum_required(VERSION 3.7) > project(BS_Application) > set(SRC > BS_AppTypes.hpp > BS_IEvent.hpp > BS_ISystem.hpp > BS_IWindow.hpp > BS_ITimerTask.hpp > BS_IEventConsumer.hpp > BS_Application.cpp > BS_Button.cpp > BS_ContextSDL.cpp > BS_ISystem.cpp > BS_System.cpp > BS_SystemSDL.cpp > BS_WindowSDL.cpp > BS_ContextSDL.cpp > BS_DisplayManagerSDL.cpp > BS_Button.cpp > BS_EventManager.cpp > BS_EventPrinter.cpp > BS_ModifierKeys.cpp > BS_DisplayManager.cpp > ) > set(INC > intern > ) > include_directories(${INC}) > add_library(BS_Application STATIC ${SRC}) > > Where all files above BS_Application.cpp are in the folder intern but he > is not able to find BS_Application.cpp but i added it to the > include_direcotires, what am i doing wrong here ? > First of all usage of include_directories is a discouraged old-style variable oriented CMake. You should prefer target oriented rule. Namelly target_include_directories(). You can have a look at: https://steveire.wordpress.com/2017/11/05/embracing-modern-cmake/ and/or refered presentation from Daniel Pfeifer or Mathieu Ropert there in. It'll get you a broad view of the "Modern CMake way to go". Now both commands (target_include_directories or include_directories) influence where *header* file are found. So that if you say include_directories(${INC}) add_library(BS_Application STATIC BS_Application.cpp) CMake won't go looking for "BS_Application.cpp" inside ${INC}. You should refer to your source files with the proper path: i.e. add_library(BS_Application STATIC ${INC}/BS_Application.cpp) You may consider having a look at how to use target_source as well. Craig Scott published a nice blog entry about that: https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/ Regards, Eric > 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: > https://cmake.org/mailman/listinfo/cmake > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From workbench at gmx.at Sun Mar 10 17:01:30 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Sun, 10 Mar 2019 22:01:30 +0100 Subject: [CMake] Troubles with include_directories In-Reply-To: References: <5a7b302f-aa30-5116-d8a6-c92cde2e41f9@gmx.at> Message-ID: <444cd5aa-1189-a991-a6bd-f6e9681d46bd@gmx.at> I talked a long time on irc.freenode.org #cmake channel and got told everything you told me and more, i'm now aware of much more knowledge than before thanks to that channel. Thanks for your late answer anyway. best regards! On 10.03.19 16:09, Eric Noulard wrote: > > > Le?sam. 9 mars 2019 ??08:44, Workbench at gmx.at > > > a ?crit?: > > Hi everyone, > > i've a project setup that looks like this: > > > abc.h > > def.h > > and all my other .cpp and .h files are in the folder intern. Now my > CMakeLists.txt looks like this: > > cmake_minimum_required(VERSION 3.7) > project(BS_Application) > set(SRC > ???? BS_AppTypes.hpp > ???? BS_IEvent.hpp > ???? BS_ISystem.hpp > ???? BS_IWindow.hpp > ???? BS_ITimerTask.hpp > ???? BS_IEventConsumer.hpp > ???? BS_Application.cpp > ???? BS_Button.cpp > ???? BS_ContextSDL.cpp > ???? BS_ISystem.cpp > ???? BS_System.cpp > ???? BS_SystemSDL.cpp > ???? BS_WindowSDL.cpp > ???? BS_ContextSDL.cpp > ???? BS_DisplayManagerSDL.cpp > ???? BS_Button.cpp > ???? BS_EventManager.cpp > ???? BS_EventPrinter.cpp > ???? BS_ModifierKeys.cpp > ???? BS_DisplayManager.cpp > ) > set(INC > ???? intern > ) > include_directories(${INC}) > add_library(BS_Application STATIC ${SRC}) > > Where all files above BS_Application.cpp are in the folder intern > but he > is not able to find BS_Application.cpp but i added it to the > include_direcotires, what am i doing wrong here ? > > > First of all usage of include_directories is a discouraged old-style > variable oriented CMake. > You should prefer target oriented rule. > Namelly?target_include_directories(). > You can have a look > at:?https://steveire.wordpress.com/2017/11/05/embracing-modern-cmake/ > and/or > refered presentation from Daniel Pfeifer or Mathieu Ropert there in. > It'll get you a broad view of the "Modern CMake way to go". > > Now both commands (target_include_directories or include_directories) > influence where *header* file are found. > So that if you say > > include_directories(${INC}) > add_library(BS_Application STATIC BS_Application.cpp) > > CMake won't go looking for "BS_Application.cpp" inside ${INC}. > You should refer to your source files with the proper path: > i.e. > add_library(BS_Application STATIC ${INC}/BS_Application.cpp) > > You may consider having a look at how to use target_source as well. > Craig Scott published a nice blog entry about that: > https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/ > > Regards, > Eric > > > 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: > https://cmake.org/mailman/listinfo/cmake > > > > -- > Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 2452 bytes Desc: not available URL: From daniel.wynne at mobotix.com Mon Mar 11 10:30:37 2019 From: daniel.wynne at mobotix.com (Daniel Wynne) Date: Mon, 11 Mar 2019 15:30:37 +0100 Subject: [CMake] Why do we need NVIDIA Nsight Tegrato create Visual Studio Android Projects? Message-ID: <96dd366e-1ae1-91e8-373d-7d2150ec6484@mobotix.com> Hi All! Short question: why do we need NVIDIA Nsight Tegra to setup a Visual Studio Android project? Despite of it being a helpful tool, the necessity for it to create the project file is unclear to me. Could you please enlighten me? Kind Regards Daniel From Felix.Ramold at kuka.com Mon Mar 11 11:19:48 2019 From: Felix.Ramold at kuka.com (Ramold, Felix) Date: Mon, 11 Mar 2019 15:19:48 +0000 Subject: [CMake] Invalid escape sequence in macro Message-ID: <81c845aa523b454486e5b25f17ef7878@DEAU1SVMAIL03.kuka.int.kuka.com> Hi, today i ran into an error with escape characters in macros. Is this a known issue? Is this by design? How can I workaround? Code: function(f STRING) message(STATUS ${STRING}) endfunction() macro(m STRING) message(STATUS ${STRING}) endmacro() set(CONTENT "bla bla \/\/") message(STATUS ${CONTENT}) f(${CONTENT}) m(${CONTENT}) Output: ramold at xxx MINGW64 /c/Program Files/CMake/cmake-3.13.4-win64-x64/bin $ ./cmake.exe -P test.cmake CMake Warning (dev) at test.cmake:9 (set): Syntax error in cmake code at C:/Program Files/CMake/cmake-3.13.4-win64-x64/bin/test.cmake:9 when parsing string bla bla \/\/ Invalid escape sequence \/ Policy CMP0010 is not set: Bad variable reference syntax is an error. Run "cmake --help-policy CMP0010" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it. -- bla bla \/\/ -- bla bla \/\/ CMake Warning (dev) at test.cmake:6 (message): Syntax error in cmake code at C:/Program Files/CMake/cmake-3.13.4-win64-x64/bin/test.cmake:6 when parsing string bla bla \/\/ Invalid escape sequence \/ Policy CMP0010 is not set: Bad variable reference syntax is an error. Run "cmake --help-policy CMP0010" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): test.cmake:12 (m) This warning is for project developers. Use -Wno-dev to suppress it. -- bla bla \/\/ Regards, Felix Ramold From Stephan.Szabo at sony.com Mon Mar 11 12:28:12 2019 From: Stephan.Szabo at sony.com (Stephan.Szabo at sony.com) Date: Mon, 11 Mar 2019 16:28:12 +0000 Subject: [CMake] Invalid escape sequence in macro In-Reply-To: <81c845aa523b454486e5b25f17ef7878@DEAU1SVMAIL03.kuka.int.kuka.com> References: <81c845aa523b454486e5b25f17ef7878@DEAU1SVMAIL03.kuka.int.kuka.com> Message-ID: <6DC96A862F4DA14CB85E89B984CCB288014F2C0350@USCULXMSG06.am.sony.com> I would expect that you're running into a consequence of: "In a function, ARGN, ARGC, ARGV and ARGV0, ARGV1, ... are true variables in the usual CMake sense. In a macro, they are not, they are string replacements much like the C preprocessor would do with a macro." So I would expect the backslash escapes are done first on the set line, and then the value of the variable after the escaping are replaced into the message line in the macro which will then try to handle escapes again. It seems like a function may be better for this sort of thing, but what does the actual use case look like? Regards, Steph -----Original Message----- From: CMake On Behalf Of Ramold, Felix Sent: Monday, March 11, 2019 8:20 AM To: cmake at cmake.org Subject: [CMake] Invalid escape sequence in macro Hi, today i ran into an error with escape characters in macros. Is this a known issue? Is this by design? How can I workaround? Code: function(f STRING) message(STATUS ${STRING}) endfunction() macro(m STRING) message(STATUS ${STRING}) endmacro() set(CONTENT "bla bla \/\/") message(STATUS ${CONTENT}) f(${CONTENT}) m(${CONTENT}) Output: ramold at xxx MINGW64 /c/Program Files/CMake/cmake-3.13.4-win64-x64/bin $ ./cmake.exe -P test.cmake CMake Warning (dev) at test.cmake:9 (set): Syntax error in cmake code at C:/Program Files/CMake/cmake-3.13.4-win64-x64/bin/test.cmake:9 when parsing string bla bla \/\/ Invalid escape sequence \/ Policy CMP0010 is not set: Bad variable reference syntax is an error. Run "cmake --help-policy CMP0010" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it. -- bla bla \/\/ -- bla bla \/\/ CMake Warning (dev) at test.cmake:6 (message): Syntax error in cmake code at C:/Program Files/CMake/cmake-3.13.4-win64-x64/bin/test.cmake:6 when parsing string bla bla \/\/ Invalid escape sequence \/ Policy CMP0010 is not set: Bad variable reference syntax is an error. Run "cmake --help-policy CMP0010" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): test.cmake:12 (m) This warning is for project developers. Use -Wno-dev to suppress it. -- bla bla \/\/ Regards, Felix Ramold -- 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 From Micha.Renner at t-online.de Mon Mar 11 12:59:13 2019 From: Micha.Renner at t-online.de (Micha Renner) Date: Mon, 11 Mar 2019 17:59:13 +0100 Subject: [CMake] cpack_add_component Message-ID: <5474093310c47f9610fc6f37bf0f08efa6deba96.camel@t-online.de> In CPack I can add a component with cpack_add_component and describe the component with the additional arguments of the macro. I can also describe the component if I use the varibales of type CPACK_COMPONENT__XXX (e.g. CPACK_COMPONENT__HIDDEN). So which one is the right way? Or doesn't matter which way I use. Regards Michael From kyle.edwards at kitware.com Mon Mar 11 13:11:38 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Mon, 11 Mar 2019 13:11:38 -0400 Subject: [CMake] cpack_add_component In-Reply-To: <5474093310c47f9610fc6f37bf0f08efa6deba96.camel@t-online.de> References: <5474093310c47f9610fc6f37bf0f08efa6deba96.camel@t-online.de> Message-ID: <1552324298.22984.8.camel@kitware.com> On Mon, 2019-03-11 at 17:59 +0100, Micha Renner wrote: > In CPack I can add a component with cpack_add_component and describe > the component with the additional arguments of the macro. > I can also describe the component if I use the varibales of type > CPACK_COMPONENT__XXX (e.g. > CPACK_COMPONENT__HIDDEN). > So which one is the right way? Or doesn't matter which way I use. The cpack_add_component() macro is merely a convenience function to set the CPACK_COMPONENT__XXX variables. You can use either one. I typically use the macros. Kyle From hex7c3 at gmail.com Mon Mar 11 20:03:24 2019 From: hex7c3 at gmail.com (hex) Date: Tue, 12 Mar 2019 00:03:24 +0000 Subject: [CMake] further configuration of generated projects outside of CMake? Message-ID: hi everyone, There are many generators supported in CMake. A CMake build system allows me to generate the preferred build environment for everyone, visual studio, eclipse, ninja you name it. The problem I see with this is that projects are generated output files, and even if that gives everyone the starting point in the way he/she is used to, they will probably want to further customize their project preferences. But every build folder, every library that is added to the project sources later on in CMake must be reflected in those projects as well. This means any customizations done outside of CMake is lost. I cannot see how to overcome this limitation. What is the workflow for generated projects here? Another question, I didn't know there is a generator for sublime text 2: https://cmake.org/cmake/help/latest/generator/Sublime%20Text%202.html Is the source code for generators available? I think it would be fun adding some improvements. best regards! From zlynx at acm.org Mon Mar 11 23:00:24 2019 From: zlynx at acm.org (Zan Lynx) Date: Mon, 11 Mar 2019 21:00:24 -0600 Subject: [CMake] further configuration of generated projects outside of CMake? In-Reply-To: References: Message-ID: On March 11, 2019 6:03:24 PM MDT, hex wrote: >hi everyone, > >There are many generators supported in CMake. A CMake build system >allows me to generate the preferred build environment for everyone, >visual studio, eclipse, ninja you name it. > >The problem I see with this is that projects are generated output >files, >and even if that gives everyone the starting point in the way he/she is > >used to, they will probably want to further customize their project >preferences. But every build folder, every library that is added to the > >project sources later on in CMake must be reflected in those projects >as >well. This means any customizations done outside of CMake is lost. > You don't ship the generated files with the source. Everyone runs cmake for themselves. And if you did ship some, like a Makefile, you would not customize that any more than you'd customize it from an autoconf project. -- Knowledge is Power -- Power Corrupts Study Hard -- Be Evil From keller.steve at gmx.de Tue Mar 12 01:37:21 2019 From: keller.steve at gmx.de (Steve Keller) Date: Tue, 12 Mar 2019 06:37:21 +0100 Subject: [CMake] How can I automatically optionally build a submodule? Message-ID: How can I build a module in a subdirectory automatically if a required package is available, but not fail if it's not. Say I have a top-level CMakeLists.txt with add_subdirectory(foo) add_subdirectory(bar) and in directory foo I have in CMakeLists.txt find_package(yadda, REQUIRED) I want the submodule foo to be build automatically if the package yadda is found. Otherwise, foo should be left out and the top-level build should not fail but continue. Steve From hex7c3 at gmail.com Tue Mar 12 07:52:32 2019 From: hex7c3 at gmail.com (hex) Date: Tue, 12 Mar 2019 11:52:32 +0000 Subject: [CMake] further configuration of generated projects outside of CMake? In-Reply-To: References: Message-ID: Oh, I see now. The generator only adds the project files and the rest of the build output remains exactly the same with or without a generator. So I only use the generator once. Folders and libraries are not added in Eclipse GUI but rather in CMake project as you'd normally do. The project is already configured for the standard build targets normally used. If I had a new build target at some point, like `make doxygen` I'd probably edit the project manually and add it. On 12/03/19 03:00, Zan Lynx wrote: > On March 11, 2019 6:03:24 PM MDT, hex wrote: >> hi everyone, >> >> There are many generators supported in CMake. A CMake build system >> allows me to generate the preferred build environment for everyone, >> visual studio, eclipse, ninja you name it. >> >> The problem I see with this is that projects are generated output >> files, >> and even if that gives everyone the starting point in the way he/she is >> >> used to, they will probably want to further customize their project >> preferences. But every build folder, every library that is added to the >> >> project sources later on in CMake must be reflected in those projects >> as >> well. This means any customizations done outside of CMake is lost. >> > You don't ship the generated files with the source. Everyone runs > cmake for themselves. > > And if you did ship some, like a Makefile, you would not customize > that any more than you'd customize it from an autoconf project. From AlbrechtS.fltk at online.de Tue Mar 12 07:54:01 2019 From: AlbrechtS.fltk at online.de (Albrecht Schlosser) Date: Tue, 12 Mar 2019 12:54:01 +0100 Subject: [CMake] How can I automatically optionally build a submodule? In-Reply-To: References: Message-ID: On 12.03.2019 06:37 Steve Keller wrote: > How can I build a module in a subdirectory automatically if a required > package is available, but not fail if it's not. Say I have a > top-level CMakeLists.txt with > > add_subdirectory(foo) > add_subdirectory(bar) > > and in directory foo I have in CMakeLists.txt > > find_package(yadda, REQUIRED) > > I want the submodule foo to be build automatically if the package > yadda is found. Otherwise, foo should be left out and the top-level > build should not fail but continue. If you want yadda to be optional then don't use REQUIRED. find_package(yadda) if (yadda_FOUND) message(STATUS "found yadda, building bar ...") # add your code to build bar here endif () This should do what you want - unless I misunderstood your question. From Felix.Ramold at kuka.com Tue Mar 12 08:13:45 2019 From: Felix.Ramold at kuka.com (Ramold, Felix) Date: Tue, 12 Mar 2019 12:13:45 +0000 Subject: [CMake] Invalid escape sequence in macro In-Reply-To: <6DC96A862F4DA14CB85E89B984CCB288014F2C0350@USCULXMSG06.am.sony.com> References: <81c845aa523b454486e5b25f17ef7878@DEAU1SVMAIL03.kuka.int.kuka.com> <6DC96A862F4DA14CB85E89B984CCB288014F2C0350@USCULXMSG06.am.sony.com> Message-ID: <9eb9627ef3b243fcb5ed7cddee566ce9@DEAU1SVMAIL03.kuka.int.kuka.com> Thank you, Steph This might be related. I think the macro somehow resolves the escapes before executing the marco commands. Today I found out, this error is much worse in a project (instead of a script). Please see the updated code (now we escape correctly at declaration): function(f STRING) message(STATUS "In function: ${STRING}") endfunction() macro(m STRING) message(STATUS "In macro: ${STRING}") endmacro() set(CONTENT "bla bla \\/\\/") message(STATUS "No call1: ${CONTENT}") f(${CONTENT}) m(${CONTENT}) message(STATUS "No call2: ${CONTENT}") Output: C:\Program Files\CMake\cmake-3.13.4-win64-x64\bin>cmake -P test.cmake -- No call1: bla bla \/\/ -- In function: bla bla \/\/ CMake Warning (dev) at test.cmake:6 (message): Syntax error in cmake code at C:/Program Files/CMake/cmake-3.13.4-win64-x64/bin/test.cmake:6 when parsing string In macro: bla bla \/\/ Invalid escape sequence \/ Policy CMP0010 is not set: Bad variable reference syntax is an error. Run "cmake --help-policy CMP0010" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): test.cmake:12 (m) This warning is for project developers. Use -Wno-dev to suppress it. -- In macro: bla bla \/\/ -- No call2: bla bla \/\/ Tthis gets way worse when it is a project: project(testEscape) cmake_minimum_required(VERSION 3.10) ... The error is not reported. Silently the string is modified and printed wrongly! C:\Program Files\CMake>cmake-3.13.4-win64-x64\bin\cmake.exe . -Bbuild313 -- Building for: Visual Studio 14 2015 -- The C compiler identification is MSVC 19.0.23918.0 -- The CXX compiler identification is MSVC 19.0.23918.0 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- No call1: bla bla \/\/ -- In function: bla bla \/\/ -- In macro: bla bla // -- No call2: bla bla \/\/ -- Configuring done -- Generating done -- Build files have been written to: C:/Program Files/CMake/build313 Note that previous policies stopped configuration. Change cmake_minimum_required(VERSION 3.0) And you get: ... -- No call1: bla bla \& -- In function: bla bla \& CMake Error at CMakeLists.txt:9 (message): Syntax error in cmake code at C:/Program Files/CMake/CMakeLists.txt:9 when parsing string In macro: bla bla \& Invalid escape sequence \& Call Stack (most recent call first): CMakeLists.txt:15 (m) -- Configuring incomplete, errors occurred! Regards, Felix -----Urspr?ngliche Nachricht----- Von: Stephan.Szabo at sony.com [mailto:Stephan.Szabo at sony.com] Gesendet: Montag, 11. M?rz 2019 17:28 An: Ramold, Felix; cmake at cmake.org Betreff: RE: Invalid escape sequence in macro I would expect that you're running into a consequence of: "In a function, ARGN, ARGC, ARGV and ARGV0, ARGV1, ... are true variables in the usual CMake sense. In a macro, they are not, they are string replacements much like the C preprocessor would do with a macro." So I would expect the backslash escapes are done first on the set line, and then the value of the variable after the escaping are replaced into the message line in the macro which will then try to handle escapes again. It seems like a function may be better for this sort of thing, but what does the actual use case look like? Regards, Steph -----Original Message----- From: CMake On Behalf Of Ramold, Felix Sent: Monday, March 11, 2019 8:20 AM To: cmake at cmake.org Subject: [CMake] Invalid escape sequence in macro Hi, today i ran into an error with escape characters in macros. Is this a known issue? Is this by design? How can I workaround? Code: function(f STRING) message(STATUS ${STRING}) endfunction() macro(m STRING) message(STATUS ${STRING}) endmacro() set(CONTENT "bla bla \/\/") message(STATUS ${CONTENT}) f(${CONTENT}) m(${CONTENT}) Output: ramold at xxx MINGW64 /c/Program Files/CMake/cmake-3.13.4-win64-x64/bin $ ./cmake.exe -P test.cmake CMake Warning (dev) at test.cmake:9 (set): Syntax error in cmake code at C:/Program Files/CMake/cmake-3.13.4-win64-x64/bin/test.cmake:9 when parsing string bla bla \/\/ Invalid escape sequence \/ Policy CMP0010 is not set: Bad variable reference syntax is an error. Run "cmake --help-policy CMP0010" for policy details. Use the cmake_policy command to set the policy and suppress this warning. This warning is for project developers. Use -Wno-dev to suppress it. -- bla bla \/\/ -- bla bla \/\/ CMake Warning (dev) at test.cmake:6 (message): Syntax error in cmake code at C:/Program Files/CMake/cmake-3.13.4-win64-x64/bin/test.cmake:6 when parsing string bla bla \/\/ Invalid escape sequence \/ Policy CMP0010 is not set: Bad variable reference syntax is an error. Run "cmake --help-policy CMP0010" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Call Stack (most recent call first): test.cmake:12 (m) This warning is for project developers. Use -Wno-dev to suppress it. -- bla bla \/\/ Regards, Felix Ramold -- 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 From mailinglists at xgm.de Tue Mar 12 08:53:26 2019 From: mailinglists at xgm.de (Florian Lindner) Date: Tue, 12 Mar 2019 13:53:26 +0100 Subject: [CMake] Correct Boost version found, linked against wrong one Message-ID: Hello, I have a simple cmake file for a small project. That project uses boost and links again a shared lib that also uses boost: find_library(precice precice PATHS $ENV{PRECICE_ROOT}/build $ENV{PRECICE_ROOT}/build/last) find_package(Boost 1.60.0 REQUIRED COMPONENTS system program_options filesystem) add_executable(preciceMap src/preciceMap.cpp src/common.cpp) target_include_directories(preciceMap PRIVATE ${Boost_INCLUDE_DIRS}) target_link_libraries(preciceMap ${Boost_LIBRARIES}) target_link_libraries(preciceMap ${precice}) output is: :~/software/aste/build> cmake .. -- The C compiler identification is GNU 8.2.0 -- The CXX compiler identification is GNU 8.2.0 -- Cray Programming Environment 2.5.17 C -- Check for working C compiler: /opt/cray/pe/craype/2.5.17/bin/cc -- Check for working C compiler: /opt/cray/pe/craype/2.5.17/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Cray Programming Environment 2.5.17 CXX -- Check for working CXX compiler: /opt/cray/pe/craype/2.5.17/bin/CC -- Check for working CXX compiler: /opt/cray/pe/craype/2.5.17/bin/CC -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Build configuration: Debug CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message): Imported targets not available for Boost version 106600 Call Stack (most recent call first): /usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES) /usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:21 (find_package) CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message): Imported targets not available for Boost version 106600 Call Stack (most recent call first): /usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES) /usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:21 (find_package) CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message): Imported targets not available for Boost version 106600 Call Stack (most recent call first): /usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES) /usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES) CMakeLists.txt:21 (find_package) -- Boost version: 1.66.0 -- Found the following Boost libraries: -- system -- program_options -- filesystem -- Found MPI_C: /opt/cray/pe/craype/2.5.17/bin/cc -- Found MPI_CXX: /opt/cray/pe/craype/2.5.17/bin/CC -- Configuring done -- Generating done -- Build files have been written to: /zhome/academic/HLRS/ipv/ipvflind/software/aste/build :~/software/aste/build> make Scanning dependencies of target preciceMap [ 20%] Building CXX object CMakeFiles/preciceMap.dir/src/preciceMap.cpp.o [ 40%] Building CXX object CMakeFiles/preciceMap.dir/src/common.cpp.o [ 60%] Linking CXX executable preciceMap /usr/bin/ld: warning: libboost_system.so.1.66.0, needed by /zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so, may conflict with libboost_system.so.1.54.0 /usr/bin/ld: warning: libboost_filesystem.so.1.66.0, needed by /zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so, may conflict with libboost_filesystem.so.1.54.0 /usr/bin/ld: warning: libboost_program_options.so.1.66.0, needed by /zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so, may conflict with libboost_program_options.so.1.54.0 /usr/bin/ld: CMakeFiles/preciceMap.dir/src/common.cpp.o: undefined reference to symbol '_ZN5boost15program_options3argB5cxx11E' /opt/hlrs/tools/boost/1.66.0/lib/libboost_program_options.so.1.66.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status CMakeFiles/preciceMap.dir/build.make:124: recipe for target 'preciceMap' failed make[2]: *** [preciceMap] Error 1 CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/preciceMap.dir/all' failed make[1]: *** [CMakeFiles/preciceMap.dir/all] Error 2 Makefile:83: recipe for target 'all' failed make: *** [all] Error 2 CMake finds boost 1.66 but why does it try to link against 1.54.0? $BOOST_ROOT is set and $LIBRARY_PATH, $LD_LIBRARY_PATH and $CPLUS_INCLUDE_PATH are also set appropriately. :~/software/aste/build> ls $BOOST_ROOT/lib/*filesystem* /opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.a /opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.so /opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.so.1.66.0 :~/software/aste/build> ls /usr/lib64/*filesystem* /usr/lib64/libboost_filesystem-mt.so /usr/lib64/libboost_filesystem.so /usr/lib64/libboost_filesystem.so.1.54.0 Maybe it prefers the -mt variants? But how can I get it to link against the correct files, i.e., 1.66? Or is the "DSO missing from command line" another problem? All I found about that is that boost_system should be added, but that's already the case. cmake version is 3.5.2 Thanks, Florian From daniel.wynne at mobotix.com Tue Mar 12 09:18:45 2019 From: daniel.wynne at mobotix.com (Daniel Wynne) Date: Tue, 12 Mar 2019 14:18:45 +0100 Subject: [CMake] Why do we need NVIDIA Nsight Tegrato create Visual Studio Android Projects? In-Reply-To: <96dd366e-1ae1-91e8-373d-7d2150ec6484@mobotix.com> References: <96dd366e-1ae1-91e8-373d-7d2150ec6484@mobotix.com> Message-ID: <3b23d9af-8c3d-aec7-324c-1307ca571cc1@mobotix.com> We would like to use Xamarin for our x-platform app-development with VS. Is any support for that planned in the near future? Am 11.03.2019 um 15:30 schrieb Daniel Wynne: > Hi All! > > Short question: why do we need NVIDIA Nsight Tegra to setup a Visual > Studio Android project? Despite of it being a helpful tool, the > necessity for it to create the project file is unclear to me. > > Could you please enlighten me? > > Kind Regards > > Daniel > From Simon.Richter at hogyros.de Tue Mar 12 09:59:25 2019 From: Simon.Richter at hogyros.de (Simon Richter) Date: Tue, 12 Mar 2019 14:59:25 +0100 Subject: [CMake] How can I automatically optionally build a submodule? In-Reply-To: References: Message-ID: <6ff3b6a2-5b8a-5b8f-b14f-426028a041c3@hogyros.de> Hi, On 12.03.19 06:37, Steve Keller wrote: > How can I build a module in a subdirectory automatically if a required > package is available, but not fail if it's not. Say I have a > top-level CMakeLists.txt with With my Debian Developer hat on: please also add a mechanism to manually specify whether the optional component should be built. If the dependency changes and suddenly a component goes missing without triggering a build failure, that can be rather annoying for users. Without a package system, this also means that old files may stick around after installation, so your program should be aware that installed plugins could be built against an older API and weren't updated during the last install run. Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From xl64100 at gmail.com Tue Mar 12 10:44:23 2019 From: xl64100 at gmail.com (Xavier Lacoste) Date: Tue, 12 Mar 2019 15:44:23 +0100 Subject: [CMake] BUG?: ExternalProject_add with CMAKE_COMMAND and Re-run cmake Message-ID: Hello, I use External_project and set up a cmake subproject that uses au specific CMAKE_COMMAND (a wrapper that does export environment variables) This wrapper is correctly called on first configure but not if CMake decides to rerun CMake at build step. [ 45%] Performing build step for 'lap_project' cd /appli_RD/LACOSTE/OMEGA/cmakesuperbuild/build-gnu-debug/lap/build-debug && /appli_RD/LACOSTE/OMEGA/cmakesuperbuild/build-gnu-debug/make_wrapper_lap.sh gmake[3]: entrant dans le r?pertoire ? /appli_RD/LACOSTE/OMEGA/cmakesuperbuild/build-gnu-debug/lap/build-debug ? /appli_MTS/SIP/devtools/cmake/3.8.2/x86_64/Linux/SUSE11.3/bin/cmake -H/appli_RD/LACOSTE/OMEGA/cmakesuperbuild/lap -B/appli_RD/LACOSTE/OMEGA/cmakesuperbuild/build-gnu-debug/lap/build-debug --check-build-system CMakeFiles/Makefile.cmake 0 Re-run cmake file: Makefile older than: /appli_RD/LACOSTE/OMEGA/cmakesuperbuild/lap/test/CMakeLists.txt My only workaround is to rm the project subdirectory and rerun make (in that case the wrapper is used): [ 50%] Performing configure step for 'lap_project' cd /appli_RD/LACOSTE/OMEGA/cmakesuperbuild/build-gnu-debug/lap/build-debug && /appli_RD/LACOSTE/OMEGA/cmakesuperbuild/build-gnu-debug/cmake_wrapper_lap.sh I tried passing -DCMAKE_COMMAND=mywrapper.sh but it only raise a warning saying that this variable was not used by the project. IMHO it?s a but in ExternalProject_add(). Correct ? Any advice or help is welcome. Regards, XL. From Andreas-Naumann at gmx.net Tue Mar 12 14:18:46 2019 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Tue, 12 Mar 2019 19:18:46 +0100 Subject: [CMake] Correct Boost version found, linked against wrong one In-Reply-To: References: Message-ID: Hey Florian, Am 12.03.19 um 13:53 schrieb Florian Lindner: > Hello, > > I have a simple cmake file for a small project. That project uses boost and links again a shared lib that also uses boost: > > find_library(precice precice PATHS $ENV{PRECICE_ROOT}/build $ENV{PRECICE_ROOT}/build/last) > find_package(Boost 1.60.0 REQUIRED COMPONENTS system program_options filesystem) > > add_executable(preciceMap src/preciceMap.cpp src/common.cpp) > target_include_directories(preciceMap PRIVATE ${Boost_INCLUDE_DIRS}) > target_link_libraries(preciceMap ${Boost_LIBRARIES}) > target_link_libraries(preciceMap ${precice}) > > output is: > > > :~/software/aste/build> cmake .. > -- The C compiler identification is GNU 8.2.0 > -- The CXX compiler identification is GNU 8.2.0 > -- Cray Programming Environment 2.5.17 C > -- Check for working C compiler: /opt/cray/pe/craype/2.5.17/bin/cc > -- Check for working C compiler: /opt/cray/pe/craype/2.5.17/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Cray Programming Environment 2.5.17 CXX > -- Check for working CXX compiler: /opt/cray/pe/craype/2.5.17/bin/CC > -- Check for working CXX compiler: /opt/cray/pe/craype/2.5.17/bin/CC -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Build configuration: Debug > CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message): > Imported targets not available for Boost version 106600 > Call Stack (most recent call first): > /usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES) > /usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES) > CMakeLists.txt:21 (find_package) > > > CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message): > Imported targets not available for Boost version 106600 > Call Stack (most recent call first): > /usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES) > /usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES) > CMakeLists.txt:21 (find_package) > > > CMake Warning at /usr/share/cmake/Modules/FindBoost.cmake:725 (message): > Imported targets not available for Boost version 106600 > Call Stack (most recent call first): > /usr/share/cmake/Modules/FindBoost.cmake:763 (_Boost_COMPONENT_DEPENDENCIES) > /usr/share/cmake/Modules/FindBoost.cmake:1315 (_Boost_MISSING_DEPENDENCIES) > CMakeLists.txt:21 (find_package) > > > -- Boost version: 1.66.0 > -- Found the following Boost libraries: > -- system > -- program_options > -- filesystem > -- Found MPI_C: /opt/cray/pe/craype/2.5.17/bin/cc > -- Found MPI_CXX: /opt/cray/pe/craype/2.5.17/bin/CC > -- Configuring done > -- Generating done > -- Build files have been written to: /zhome/academic/HLRS/ipv/ipvflind/software/aste/build > > :~/software/aste/build> make > Scanning dependencies of target preciceMap > [ 20%] Building CXX object CMakeFiles/preciceMap.dir/src/preciceMap.cpp.o > [ 40%] Building CXX object CMakeFiles/preciceMap.dir/src/common.cpp.o > [ 60%] Linking CXX executable preciceMap > /usr/bin/ld: warning: libboost_system.so.1.66.0, needed by /zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so, may conflict with libboost_system.so.1.54.0 > /usr/bin/ld: warning: libboost_filesystem.so.1.66.0, needed by /zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so, may conflict with libboost_filesystem.so.1.54.0 > /usr/bin/ld: warning: libboost_program_options.so.1.66.0, needed by /zhome/academic/HLRS/ipv/ipvflind/software/precice/build/last/libprecice.so, may conflict with libboost_program_options.so.1.54.0 > /usr/bin/ld: CMakeFiles/preciceMap.dir/src/common.cpp.o: undefined reference to symbol '_ZN5boost15program_options3argB5cxx11E' > /opt/hlrs/tools/boost/1.66.0/lib/libboost_program_options.so.1.66.0: error adding symbols: DSO missing from command line > collect2: error: ld returned 1 exit status > CMakeFiles/preciceMap.dir/build.make:124: recipe for target 'preciceMap' failed > make[2]: *** [preciceMap] Error 1 > CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/preciceMap.dir/all' failed > make[1]: *** [CMakeFiles/preciceMap.dir/all] Error 2 > Makefile:83: recipe for target 'all' failed > make: *** [all] Error 2 > > > > CMake finds boost 1.66 but why does it try to link against 1.54.0? $BOOST_ROOT is set and $LIBRARY_PATH, $LD_LIBRARY_PATH and $CPLUS_INCLUDE_PATH are also set appropriately. > > :~/software/aste/build> ls $BOOST_ROOT/lib/*filesystem* > /opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.a /opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.so /opt/hlrs/tools/boost/1.66.0/lib/libboost_filesystem.so.1.66.0 > > :~/software/aste/build> ls /usr/lib64/*filesystem* > /usr/lib64/libboost_filesystem-mt.so /usr/lib64/libboost_filesystem.so /usr/lib64/libboost_filesystem.so.1.54.0 > > Maybe it prefers the -mt variants? But how can I get it to link against the correct files, i.e., 1.66? > > Or is the "DSO missing from command line" another problem? All I found about that is that boost_system should be added, but that's already the case. > > cmake version is 3.5.2 Can you run make with VERBOSE=1 and give as the output please? To me it looks like, that cmake discards the library directory and links with -lboost_filesystem instead of the fullpath. This happened in my environment whenever the environment variable LIBRARY_DIR contains the boost library directory. Nevertheless, you should unset LIBRARY_DIR with cmake. Otherwise, the compiler gcc will treat the folders in this variable as system folders. > > Thanks, > Florian Hth, Andreas From dev at thiagocrepaldi.com Tue Mar 12 19:24:24 2019 From: dev at thiagocrepaldi.com (Thiago Crepaldi) Date: Tue, 12 Mar 2019 16:24:24 -0700 Subject: [CMake] Target not linking to Boost header libs compiled with ExternalProject_Add Message-ID: Hi all, I have created a small example app that links to Boost regex (works) and to a Boost header-only lib property_tree (fails). Using CMake 3.12.2 on a Ubuntu 18.10 x64, I get this error: [50%] Building CXX object CMakeFiles/dummy.dir/main.cpp.o small_superbuild/src/main.cpp:3:10: fatal error: boost/property_tree/ptree.hpp: No such file or directory #include I have used the superbuild pattern to build upstream boost if not found in the system and finally link to the main app called "dummy". The idea is from https://github.com/dev-cafe/cmake-cookbook/tree/master/chapter-08/recipe-02/cxx-example The folder structure for this dummy project is as follow: ******************************************************************************* CMakeLists.txt ******************************************************************************* cmake_minimum_required(VERSION 3.5) set( DUMMY_APP_PROJECT_VERSION 0.1 CACHE INTERNAL "Dummy App project version" FORCE) project(dummy_app VERSION ${DUMMY_APP_PROJECT_VERSION} LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_EXTENSIONS OFF) set(CMAKE_CXX_STANDARD_REQUIRED ON) # Superbuild stuff set(EP_BASE ${CMAKE_BINARY_DIR}/subprojects) set_property(DIRECTORY PROPERTY EP_BASE ${EP_BASE}) set(STAGED_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/stage) include(ExternalProject) # Add external dependencies add_subdirectory(external/upstream) # Dummy App project (main target) ExternalProject_Add(${PROJECT_NAME}_core DEPENDS boost_external SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/src CMAKE_ARGS -DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER} -DCMAKE_CXX_STANDARD=${CMAKE_CXX_STANDARD} -DCMAKE_CXX_EXTENSIONS=${CMAKE_CXX_EXTENSIONS} -DCMAKE_CXX_STANDARD_REQUIRED=${CMAKE_CXX_STANDARD_REQUIRED} -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} -DCMAKE_PREFIX_PATH=${CMAKE_PREFIX_PATH} -DCMAKE_INSTALL_PREFIX=${STAGED_INSTALL_PREFIX}/dummy_app CMAKE_CACHE_ARGS -DCMAKE_CXX_FLAGS:STRING=${CMAKE_CXX_FLAGS} -DCMAKE_INCLUDE_PATH:INTERNAL=${BOOST_INCLUDEDIR};${GOOGLETEST_INCLUDEDIR} -DCMAKE_LIBRARY_PATH:INTERNAL=${BOOST_LIBRARYDIR};${GOOGLETEST_LIBRARYDIR} -DDUMMY_APP_PROJECT_VERSION:INTERNAL=${DUMMY_APP_PROJECT_VERSION} -DSTAGED_INSTALL_PREFIX:INTERNAL=${STAGED_INSTALL_PREFIX} -DBOOST_ROOT:INTERNAL=${BOOST_ROOT} -DBOOST_INCLUDEDIR:INTERNAL=${BOOST_INCLUDEDIR} -DBOOST_LIBRARYDIR:INTERNAL=${BOOST_LIBRARYDIR} -DBOOST_MINIMUM_REQUIRED:INTERNAL=${BOOST_MINIMUM_REQUIRED} -DBOOST_COMPONENTS_REQUIRED:INTERNAL=${BOOST_COMPONENTS_REQUIRED} BUILD_ALWAYS 1 ) ******************************************************************************* external/upstream/CMakeLists.txt ******************************************************************************* # Boost dependencies add_subdirectory(boost) ******************************************************************************* external/upstream/boost/CMakeLists.txt ******************************************************************************* set( BOOST_MINIMUM_REQUIRED "1.65" CACHE INTERNAL "Minimum Boost version required by the build" FORCE ) set( BOOST_COMPONENTS_REQUIRED regex CACHE INTERNAL "Boost components required by the build (separated by semicolon)" FORCE ) find_package(Boost ${BOOST_MINIMUM_REQUIRED} COMPONENTS ${BOOST_COMPONENTS_REQUIRED}) if(Boost_FOUND) message(STATUS "Found Boost version ${Boost_MAJOR_VERSION}.${Boost_MINOR_VERSION}.${Boost_SUBMINOR_VERSION} at the host environment") add_library(boost_external INTERFACE) get_filename_component(_boost_root_dir "${Boost_LIBRARY_DIRS}" PATH) set( BOOST_ROOT ${_boost_root_dir} CACHE INTERNAL "Path to externally built Boost installation root" FORCE ) set( BOOST_INCLUDEDIR ${Boost_INCLUDE_DIRS} CACHE INTERNAL "Path to externally built Boost include directories" FORCE ) set( BOOST_LIBRARYDIR ${Boost_LIBRARY_DIRS} CACHE INTERNAL "Path to externally built Boost library directories" FORCE ) # Unset internal variables unset(_boost_root_dir) else() message(STATUS "Boost ${BOOST_MINIMUM_REQUIRED} could not be located. Building Boost instead") if(CMAKE_CXX_COMPILER_ID MATCHES "GNU") if(APPLE) set(_toolset "darwin") else() set(_toolset "gcc") endif() elseif(CMAKE_CXX_COMPILER_ID MATCHES ".*Clang") set(_toolset "clang") elseif(CMAKE_CXX_COMPILER_ID MATCHES "Intel") if(APPLE) set(_toolset "intel-darwin") else() set(_toolset "intel-linux") endif() endif() # Non-empty list. Compiled libraries needed if(NOT "${BOOST_COMPONENTS_REQUIRED}" STREQUAL "") # Replace unit_test_framework (used by CMake's find_package) with test (understood by Boost build toolchain) string(REPLACE "unit_test_framework" "test" _b2_needed_components "${BOOST_COMPONENTS_REQUIRED}") # Generate argument for BUILD_BYPRODUCTS set(_build_byproducts) set(_b2_select_libraries) foreach(_lib IN LISTS _b2_needed_components) list(APPEND _build_byproducts ${STAGED_INSTALL_PREFIX}/boost/lib/libboost_${_lib}${CMAKE_SHARED_LIBRARY_SUFFIX}) list(APPEND _b2_select_libraries --with-${_lib}) endforeach() # Transform the ;-separated list to a ,-separated list (digested by the Boost build toolchain!) string(REPLACE ";" "," _b2_needed_components "${_b2_needed_components}") set(_bootstrap_select_libraries "--with-libraries=${_b2_needed_components}") string(REPLACE ";" ", " printout "${BOOST_COMPONENTS_REQUIRED}") message(STATUS " Libraries to be built: ${printout}") endif() include(ExternalProject) ExternalProject_Add(boost_external GIT_REPOSITORY https://github.com/boostorg/boost.git GIT_TAG "boost-1.65.0" GIT_PROGRESS 0 CONFIGURE_COMMAND /bootstrap.sh --with-toolset=${_toolset} --prefix=${STAGED_INSTALL_PREFIX}/boost ${_bootstrap_select_libraries} BUILD_COMMAND /b2 -q link=shared threading=multi variant=release toolset=${_toolset} ${_b2_select_libraries} LOG_BUILD 1 BUILD_IN_SOURCE 1 INSTALL_COMMAND /b2 -q install link=shared threading=multi variant=release toolset=${_toolset} ${_b2_select_libraries} LOG_INSTALL 1 BUILD_BYPRODUCTS "${_build_byproducts}" ) set( BOOST_ROOT ${STAGED_INSTALL_PREFIX}/boost CACHE INTERNAL "Path to internally built Boost installation root" FORCE ) set( BOOST_INCLUDEDIR ${BOOST_ROOT}/include CACHE INTERNAL "Path to internally built Boost include directories" FORCE ) set( BOOST_LIBRARYDIR ${BOOST_ROOT}/lib CACHE INTERNAL "Path to internally built Boost library directories" FORCE ) # Unset internal variables unset(_toolset) unset(_b2_needed_components) unset(_build_byproducts) unset(_b2_select_libraries) unset(_boostrap_select_libraries) endif() ******************************************************************************* src/CMakeLists.txt ******************************************************************************* # TODO: Properly export target cmake_minimum_required(VERSION 3.5) project(dummy_core VERSION ${DUMMY_APP_PROJECT_VERSION} LANGUAGES CXX) set(DUMMY_APP_SRC main.cpp) add_executable(dummy ${DUMMY_APP_SRC}) set_target_properties(dummy PROPERTIES CXX_STANDARD ${CMAKE_CXX_STANDARD} CXX_EXTENSIONS ${CMAKE_CXX_EXTENSIONS} CXX_STANDARD_REQUIRED ${CMAKE_CXX_STANDARD_REQUIRED}) # Boost is used for CTF parsing find_package(Boost ${BOOST_MINIMUM_REQUIRED} COMPONENTS ${BOOST_COMPONENTS_REQUIRED} REQUIRED) # Includes target_include_directories(dummy PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include ${BOOST_INCLUDEDIR}) # Libs target_link_libraries(dummy PUBLIC Boost::boost ${Boost_LIBRARIES}) # Install both targets install(TARGETS dummy DESTINATION bin) ******************************************************************************* src/main.cpp ******************************************************************************* #include #include #include #include int main(){ // Header only boost library boost::property_tree::ptree pt; boost::property_tree::read_json("data.json", pt); // regular boost lib std::string line; boost::regex pat( "^Subject: (Re: |Aw: )*(.*)" ); while (std::cin) { std::getline(std::cin, line); boost::smatch matches; if (boost::regex_match(line, matches, pat)) std::cout << matches[2] << std::endl; } } As you can see, linking to a an actual library using this approach is not a problem. However, using property_tree, which is a header only lib, fails to compile. By reading https://cmake.org/cmake/help/v3.12/module/FindBoost.html, I learned that there is a Boost::boost target to link agains for the header-only libs, but doing target_link_libraries(dummy PUBLIC Boost::boost ${Boost_LIBRARIES} Boost::boost) didnt help either. Looking CMakeCache.txt of dummy_core project, I can see Boost_INCLUDE_DIR:PATH=(...)/small_superbuild/build/stage/boost/include, which does not include (...)/small_superbuild/build/subprojects/Source/boost_external/libs/property_tree/include/ Any idea what is happening? -- Thiago From rjvbertin at gmail.com Wed Mar 13 11:51:42 2019 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 13 Mar 2019 16:51:42 +0100 Subject: [CMake] cmake and high-dpi support on Mac Message-ID: <3159796.4rTYbcjOjd@portia.local> Hi, CMake had hardcoded default support for high-dpi screens in the applications it generated for Apple's desktop OS at some point, but that was removed very quickly in 286c75f7f034c5fdcd43bcb755da74d09c809642. It is my understanding that you don't actually need to set the high-dpi key explicitly, but that it defaults to on for the desktop OS. IOW, it's enough to set the NSPrincipalClass property to NSApplication. I cannot check this myself, and I have no idea if and how NSPrincipalClass can be set for Apple's other OS variants. But maybe one could use this property in a minimal-change change to enable high-dpi support automatically in applications that do not provide their own Info.plist: add this to the bundle plist template: + NSPrincipalClass + <${MACOSX_BUNDLE_PRINCIPALCLASS}/> If the target OS is known when the MACOSX_BUNDLE_* variables get their default, MACOSX_BUNDLE_PRINCIPALCLASS could default to whatever class is appropriate for the target OS, otherwise it would just be set to NSApplication (and users targetting other OS variants would have to set the property explicitly, which is still less cumbersome than providing a custom template). Thoughts please? Thanks, R. From hex7c3 at gmail.com Wed Mar 13 13:59:03 2019 From: hex7c3 at gmail.com (hex) Date: Wed, 13 Mar 2019 17:59:03 +0000 Subject: [CMake] further configuration of generated projects outside of CMake? In-Reply-To: References: Message-ID: I see now the generators are part of CMake sources on gitlab... that answers my questions. thank you, Zan Lynx. > >> On March 11, 2019 6:03:24 PM MDT, hex wrote: >>> >> Another question, I didn't know there is a generator for sublime text 2: >> >> https://cmake.org/cmake/help/latest/generator/Sublime%20Text%202.html >> >> Is the source code for generators available? I think it would be fun >> adding some improvements. >> >> best regards! From paul at mad-scientist.net Thu Mar 14 01:12:53 2019 From: paul at mad-scientist.net (Paul Smith) Date: Thu, 14 Mar 2019 01:12:53 -0400 Subject: [CMake] Visual Studio generator running custom_command twice Message-ID: <501bdd6832d5967a468e7e1283b7aa1530ef1223.camel@mad-scientist.net> I have a situation where I've created a custom command to generate .cpp files to be compiled (in my case running bison/flex). I'm using CMake 3.13.4 However, I have to compile this code in two different ways for two different targets. I am seeing the Visual Studio generator re-running bison/flex once for each of these targets, which is (a) not necessary and (b) causes my builds to fail since it often happens that the second run can't replace the output files (due to Windows' annoying habit of locking files that are open). I have a custom command like this: add_custom_command(OUTPUT ${OUT_DIR}/MyParser.tab.cpp ${OUT_DIR}/MyParser.tab.hpp COMMAND ${CMAKE_COMMAND} -E make_directory ${OUT_DIR} COMMAND ${BISON} -d -o ${OUT_DIR}/MyParser.tab.cpp MyParser.y DEPENDS MyParser.y COMMENT "Building MyParser parser") set(MyParserOutput ${OUT_DIR}/MyParser.tab.cpp ${OUT_DIR}/MyParser.tab.hpp) add_custom_target(MyGenParser DEPENDS ${MyParserOutput}) Then I have two different libraries, both depending on this: add_library(OneLib STATIC ${MyParserOutput} ...) target_compile_definitions(OneLib PRIVATE -DONELIB) target_include_directories(OneLib PRIVATE ${OUT_DIR}) add_dependencies(OneLib MyGenparser) add_library(TwoLib STATIC ${MyParserOutput} ...) target_compile_definitions(TwoLib PRIVATE -DTWOLIB) target_include_directories(TwoLib PRIVATE ${OUT_DIR}) add_dependencies(TwoLib MyGenparser) On Linux and MacOS, this works fine. However on Windows with Visual Studio I see the custom target being run twice, once for each library: 18:27:10 21>PrepareForBuild: 18:27:10 Creating directory "OneLib.dir\RelWithDebInfo\". 18:27:10 Creating directory "OneLib.dir\RelWithDebInfo\OneLib.tlog\". 18:27:10 InitializeBuildStatus: 18:27:10 Creating "OneLib.dir\RelWithDebInfo\OneLib.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified. 18:27:10 ComputeCustomBuildOutput: 18:27:10 Creating directory "D:\builds\src\". 18:27:10 CustomBuild: 18:27:10 Building MyParser parser Then again later: 18:27:20 69>PrepareForBuild: 18:27:20 Creating directory "TwoLib.dir\RelWithDebInfo\". 18:27:20 Creating directory "TwoLib.dir\RelWithDebInfo\TwoLib.tlog\". 18:27:20 InitializeBuildStatus: 18:27:20 Creating "TwoLib.dir\RelWithDebInfo\TwoLib.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified. 18:27:20 CustomBuild: 18:27:20 Building MyParser parser See how this second one is re-building the parser; then this fails because the output file is locked by Windows (in use by the compiler): 18:27:21 69>CustomBuild: 18:27:21 bison.exe: could not create D:/builds/src/MyParser.tab.cpp 18:27:25 69>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(209,5): error MSB6006: "cmd.exe" exited with code 1. [D:\builds\TwoLib.vcxproj] How can I get CMake to only run the bison command one time, then use the output for two different libraries? From robert.maynard at kitware.com Thu Mar 14 11:58:16 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 14 Mar 2019 11:58:16 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.14.0 available for download Message-ID: I am happy to announce that CMake 3.14.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.14 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.14/release/3.14.html Some of the more significant changes in CMake 3.14 are: * Support for running CMake on Windows XP and Windows Vista has been dropped. The precompiled Windows binaries provided on "cmake.org" now require Windows 7 or higher. * CMake now supports Cross Compiling for iOS, tvOS, or watchOS using simple toolchain files. * The "Visual Studio 16 2019" generator was added. This is experimental and based on "Visual Studio 2019 Preview 4" because this version of VS has not been released. The VS 2019 generator differs from generators for earlier versions in that it does not provide variants that specify the target platform in the generator name. Instead "CMAKE_GENERATOR_PLATFORM" must be used, e.g. through the "-A" command-line option. Furthermore, the default target platform (architecture) is now based on the *host* platform. The VS host toolset selection is now based on the host architecture as well. * The "Green Hills MULTI" generator has been updated to include Object Library support, support for target renaming and destination output control properties, and other improvements. * A "CMAKE_BUILD_RPATH_USE_ORIGIN" variable and corresponding "BUILD_RPATH_USE_ORIGIN" target property were added to enable use of relative runtime paths (RPATHs). This helps achieving relocatable and reproducible builds that are invariant of the build directory. * The "install(TARGETS)" command learned how to install to an appropriate default directory for a given target type, based on variables from the "GNUInstallDirs" module and built-in defaults, in lieu of a "DESTINATION" argument. * The "install(FILES)" and "install(DIRECTORY)" commands learned a new set of parameters for installing files as a file type, setting the destination based on the appropriate variables from "GNUInstallDirs" and built-in defaults, in lieu of a "DESTINATION" argument. * The "install(CODE)" and "install(SCRIPT)" commands learned to support generator expressions. See policy "CMP0087". * The "if()" command gained support for checking if cache variables are defined with the "DEFINED CACHE{VAR}" syntax. * A file-based api for clients to get semantic buildsystem information has been added. See the "cmake-file-api(7)" manual. This is intended to replace the "cmake-server(7)" mode for IDEs. * The "cmake(1)" Build Tool Mode ("cmake --build") gained "-- verbose" and "-v" options to specify verbose build output. Some generators such as Xcode don't support this option currently. * The "cmake(1)" "-E compare_files" command learned a new "--ignore- eol" option to specify that end-of-line differences (e.g. LF vs CRLF) should be ignored when comparing files. CMake 3.14 Release Notes ************************ Changes made since CMake 3.13 include the following. New Features ============ Generators ---------- * The "Visual Studio 16 2019" generator was added. This is experimental and based on "Visual Studio 2019 Preview 4" because this version of VS has not been released. The VS 2019 generator differs from generators for earlier versions in that it does not provide variants that specify the target platform in the generator name. Instead "CMAKE_GENERATOR_PLATFORM" must be used, e.g. through the "-A" command-line option. Furthermore, the default target platform (architecture) is now based on the *host* platform. The VS host toolset selection is now based on the host architecture as well. * The "Green Hills MULTI" generator has been updated: * Now supports Object Libraries. * Now warns on unsupported project types such as shared libraries. * Now generates a top-level ".top.gpj" for each directory calling the "project()" command. The top-level project file "default.gpj" is no longer created. * Now honors target renaming and destination output control properties such as "RUNTIME_OUTPUT_DIRECTORY" and "OUTPUT_NAME". This also fixes support for installation rules generated by "install()". * Now honors source file properties "INCLUDE_DIRECTORIES", "COMPILE_DEFINITIONS", and "COMPILE_OPTIONS". * Now supports Dynamic Download Integrity Applications which did not include Integrate Files via "GHS_INTEGRITY_APP" and setting a target link flag of "-dynamic". * The contents of project files now sorts sources groups and files by name. Set the "GHS_NO_SOURCE_GROUP_FILE" target property to "ON" to generate a single project file for the target instead of a project file for each source group. Set the "CMAKE_GHS_NO_SOURCE_GROUP_FILE" variable to enable this for all targets. File-Based API -------------- * A file-based api for clients to get semantic buildsystem information has been added. See the "cmake-file-api(7)" manual. This is intended to replace the "cmake-server(7)" mode for IDEs. Platforms --------- * CMake now supports Cross Compiling for iOS, tvOS, or watchOS using simple toolchain files. Command-Line ------------ * The "cmake(1)" Build Tool Mode ("cmake --build") gained "-- verbose" and "-v" options to specify verbose build output. Some generators such as Xcode don't support this option currently. * The "cmake(1)" "-E compare_files" command learned a new "--ignore- eol" option to specify that end-of-line differences (e.g. LF vs CRLF) should be ignored when comparing files. * The "cmake-gui(1)" dialog gained new "-S" and "-B" arguments to explicitly specify source and build directories. Commands -------- * The "file()" command learned a new sub-command, "CREATE_LINK", which can be used to create hard or symbolic links. * The "file()" command learned a new sub-command, "READ_SYMLINK", which can be used to determine the path that a symlink points to. * The "file()" command gained a "SIZE" mode to get the size of a file on disk. * The "find_package()" command learned to optionally resolve symbolic links in the paths to package configuration files. See the "CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS" variable. * The "get_filename_component()" command gained new "LAST_EXT" and "NAME_WLE" variants to work with the extension after the last "." in the name. * The "if()" command gained support for checking if cache variables are defined with the "DEFINED CACHE{VAR}" syntax. * The "install(CODE)" and "install(SCRIPT)" commands learned to support generator expressions. See policy "CMP0087". * The "install(TARGETS)" command learned how to install to an appropriate default directory for a given target type, based on variables from the "GNUInstallDirs" module and built-in defaults, in lieu of a "DESTINATION" argument. * The "install(FILES)" and "install(DIRECTORY)" commands learned a new set of parameters for installing files as a file type, setting the destination based on the appropriate variables from "GNUInstallDirs" and built-in defaults, in lieu of a "DESTINATION" argument. * The "list()" operations "REMOVE_ITEM", "REMOVE_DUPLICATES", "SORT", "REVERSE", and "FILTER" all now accept a non-existent variable as the list since these operations on empty lists is also the empty list. * The "list()" operation "REMOVE_AT" now indicates that the given indices are invalid for a non-existent variable or empty list. * The "try_compile()" and "try_run()" commands gained a new "LINK_OPTIONS" option. Variables --------- * A "CMAKE_BUILD_RPATH_USE_ORIGIN" variable and corresponding "BUILD_RPATH_USE_ORIGIN" target property were added to enable use of relative runtime paths (RPATHs). This helps achieving relocatable and reproducible builds that are invariant of the build directory. Properties ---------- * A "CMAKE_ROLE" global property was added to allow scripts to determine whether they're running in project mode, script mode, find-package mode, CTest, or CPack. * The "CUDA_RESOLVE_DEVICE_SYMBOLS" target property is now supported on shared library, module library, and executable targets. Previously it was only honored on static libraries. * The "EXCLUDE_FROM_ALL" target property was created to override the setting of its directory. A target will now be built as part of "all" if its "EXCLUDE_FROM_ALL" property is set to "OFF", even if its containing directory is marked as "EXCLUDE_FROM_ALL". * "INTERFACE_POSITION_INDEPENDENT_CODE" target property gains the support of "generator expressions". Modules ------- * The family of modules to check capabilities (like "CheckCSourceCompiles") gain capability to manage "LINK_OPTIONS". * A "CheckFortranSourceRuns" module was added to provide a "check_fortran_source_runs()" command to check if a Fortran source snippet compiles and runs. * The "CMakePackageConfigHelpers" module?s "write_basic_package_version_file()" command gained a new "ARCH_INDEPENDENT" option for supporting architecture-independent packages. * The "ExternalProject" module "ExternalProject_Add()" command gained "LOG_DIR" and "LOG_MERGED_STDOUTERR" options to control logging. * The "ExternalProject" module "ExternalProject_Add()" command gained "LOG_PATCH" to optionally log the patch step. * The "ExternalProject" module's "ExternalProject_Add()" command learned to apply "SOURCE_SUBDIR" when "BUILD_IN_SOURCE" is also used. The "BUILD_COMMAND" is run in the given "SOURCE_SUBDIR" of the "SOURCE_DIR". * The "FetchContent" module gained a new "FetchContent_MakeAvailable()" command. It accepts a list of dependency names, which it then iterates over, populating and adding each one to the main build using the canonical pattern. This significantly reduces the amount of boilerplate needed in a project. * The "FindBISON" module's "BISON_TARGET" command now runs "bison" with "CMAKE_CURRENT_BINARY_DIR" as the working directory. See policy "CMP0088". * The "FindCURL" module gained support for requesting protocols as package components. * The "FindFontconfig" module was added to find fontconfig. * The "FindGDAL" module now provides imported targets. * The "FindGIF" module now provides imported targets. * The "FindGit" module now provides an imported target for the Git executable. * The "FindIce" module learned to find "slice2confluence" and "slice2matlab". * The "FindLibinput" module was added to find libinput. * The "FindLibLZMA" module now provides imported targets. * The "FindMatlab" module gained new options "R2017b" and "R2018a" to specify the MEX API version to use; these options mirror the new options to the "mex" command in MATLAB R2018a. The option "MX_LIBRARY" is no longer needed. * The "FindPostgreSQL" module now provides imported targets. * The "FindPython", "FindPython2", and "FindPython3" modules gained support for "NumPy" component. * The "FindPython2", "FindPython3", and "FindPython" modules now support running in script mode by skipping the creation of imported targets and helper functions. * The "FindSQLite3" module was added to find the SQLite v3.x library. * The "FindX11" had the following variables renamed in order to match their library names rather than header names. The old variables are provided for compatibility: * "X11_Xxf86misc_INCLUDE_PATH" instead of "X11_xf86misc_INCLUDE_PATH" * "X11_Xxf86misc_LIB" instead of "X11_xf86misc_LIB" * "X11_Xxf86misc_FOUND" instead of "X11_xf86misc_FOUND" * "X11_Xxf86vm_INCLUDE_PATH" instead of "X11_xf86vmode_INCLUDE_PATH" * "X11_Xxf86vm_LIB" instead of "X11_xf86vmode_LIB" * "X11_Xxf86vm_FOUND" instead of "X11_xf86vmode_FOUND" * "X11_xkbfile_INCLUDE_PATH" instead of "X11_Xkbfile_INCLUDE_PATH" * "X11_xkbfile_LIB" instead of "X11_Xkbfile_LIB" * "X11_xkbfile_FOUND" instead of "X11_Xkbfile_FOUND" * "X11_Xtst_INCLUDE_PATH" instead of "X11_XTest_INCLUDE_PATH" * "X11_Xtst_LIB" instead of "X11_XTest_LIB" * "X11_Xtst_FOUND" instead of "X11_XTest_FOUND" * "X11_Xss_INCLUDE_PATH" instead of "X11_Xscreensaver_INCLUDE_PATH" * "X11_Xss_LIB" instead of "X11_Xscreensaver_LIB" * "X11_Xss_FOUND" instead of "X11_Xscreensaver_FOUND" The following variables are deprecated completely since they were essentially duplicates: * "X11_Xinput_INCLUDE_PATH" (use "X11_Xi_INCLUDE_PATH") * "X11_Xinput_LIB" (use "X11_Xi_LIB") * "X11_Xinput_FOUND" (use "X11_Xi_FOUND") * The "FindX11" now provides "X11_Xext_INCLUDE_PATH". * The "FindX11" now provides imported targets. * The "UseSWIG" module learned to pass "-module " to the "SWIG" compiler if the file property "SWIG_MODULE_NAME" is defined. See policy "CMP0086". * The "UseSWIG" module gained an option to specify "SWIG" source file extensions. Generator Expressions --------------------- * The "$" and "$" "generator expressions" were added. * The "$" generator expression now correctly handles an empty argument. See "CMP0085" for details. Autogen ------- * The "AUTOMOC_EXECUTABLE", "AUTORCC_EXECUTABLE", and "AUTOUIC_EXECUTABLE" target properties were added. They all take a path to an executable and force automoc/autorcc/autouic to use this executable. Setting these will also prevent the configure time testing for these executables. This is mainly useful when you build these tools yourself. * The new variables "CMAKE_GLOBAL_AUTOGEN_TARGET", "CMAKE_GLOBAL_AUTOGEN_TARGET_NAME", "CMAKE_GLOBAL_AUTORCC_TARGET" and "CMAKE_GLOBAL_AUTORCC_TARGET_NAME" control the generation of global "autogen" and "autorcc" targets. * A new "CMAKE_AUTOGEN_ORIGIN_DEPENDS" variable and "AUTOGEN_ORIGIN_DEPENDS" target property may be set to enable or disable forwarding of the origin target dependencies to the corresponding "_autogen" target. CTest ----- * "ctest(1)" gained a "--show-only=json-v1" option to show the list of tests in a machine-readable JSON format. See the Show as JSON Object Model section of the manual. * The "ctest_submit()" command learned a new "Done" part that can be used to inform CDash that a build is complete and that no more parts will be uploaded. * CTest learned to accept the dashboard server submission URL from a single variable. See the "SubmitURL" setting in "ctest(1)", the "CTEST_SUBMIT_URL" variable, and the "SUBMIT_URL" argument of the "ctest_submit()" command. Deprecated and Removed Features =============================== * An explicit deprecation diagnostic was added for policies "CMP0064" and "CMP0065" ("CMP0063" and below were already deprecated). The "cmake-policies(7)" manual explains that the OLD behaviors of all policies are deprecated and that projects should port to the NEW behaviors. * The "Xcode" generator deprecated support for Xcode versions prior to Xcode 5. Support for those will be dropped in a future version of CMake. * The "FindQt" module is no longer used by the "find_package()" command as a find module. This allows the Qt Project upstream to optionally provide its own "QtConfig.cmake" package configuration file and have applications use it via "find_package(Qt)" rather than "find_package(Qt CONFIG)". See policy "CMP0084". * Support for running CMake on Windows XP and Windows Vista has been dropped. The precompiled Windows binaries provided on "cmake.org" now require Windows 7 or higher. * CTest no longer supports submissions via "ftp", "scp", "cp", and "xmlrpc". CDash is the only maintained testing dashboard for CTest, and it only supports submissions over "http" and "https". Other Changes ============= * Object library linking has been fixed to propagate private link libraries of object libraries to consuming targets. * Install rules under "add_subdirectory()" now interleave with those in the calling directory. See policy "CMP0082" for details. * CMake now imposes a maximum recursion limit to prevent a stack overflow on scripts that recurse infinitely. The limit can be adjusted at runtime with "CMAKE_MAXIMUM_RECURSION_DEPTH". * When using cppcheck via the "CMAKE__CPPCHECK" variable or "_CPPCHECK" property, the build will now fail if "cppcheck" returns non-zero as configured by its command-line options. * Required link options to manage Position Independent Executable are now added when "POSITION_INDEPENDENT_CODE" is set. The project is responsible for using the "CheckPIESupported" module to check for "PIE" support to ensure that the "POSITION_INDEPENDENT_CODE" target property will be honored at link time for executables. This behavior is controlled by policy "CMP0083". * Visual Studio Generators for VS 2010 and above learned to support the "VS_DEBUGGER_*" properties on targets created via "add_custom_target()". * The "CPack" module no longer defaults to the "paxr" value in the "CPACK_DEBIAN_ARCHIVE_TYPE" variable, because "dpkg" has never supported the PAX tar format. The "paxr" value will be mapped to "gnutar" and a deprecation message emitted. * CMake no longer issues a warning if a target listed in an "install(TARGETS)" command has its "EXCLUDE_FROM_ALL" property set to true. ---------------------------------------------------------------------------- Changes made since CMake 3.14.0-rc4: Brad King (2): VS: Revert "Use MSBuild matching toolset host architecture" CMake 3.14.0 Nils Gladitz (1): CMake: Fix WiX installer downgrades with versioned binaries From frodak17 at gmail.com Thu Mar 14 12:53:09 2019 From: frodak17 at gmail.com (frodak17) Date: Thu, 14 Mar 2019 12:53:09 -0400 Subject: [CMake] Visual Studio generator running custom_command twice In-Reply-To: <501bdd6832d5967a468e7e1283b7aa1530ef1223.camel@mad-scientist.net> References: <501bdd6832d5967a468e7e1283b7aa1530ef1223.camel@mad-scientist.net> Message-ID: On Thu, Mar 14, 2019 at 1:13 AM Paul Smith wrote: > I have a situation where I've created a custom command to generate .cpp > files to be compiled (in my case running bison/flex). > > I'm using CMake 3.13.4 > > set(MyParserOutput > ${OUT_DIR}/MyParser.tab.cpp > ${OUT_DIR}/MyParser.tab.hpp) > > add_custom_target(MyGenParser DEPENDS ${MyParserOutput}) > > Then I have two different libraries, both depending on this: > > add_library(OneLib STATIC ${MyParserOutput} ...) > add_dependencies(OneLib MyGenparser) > > > add_library(TwoLib STATIC ${MyParserOutput} ...) > add_dependencies(TwoLib MyGenparser) > > > From add_custom_command() Do not list the output in more than one independent target that may build in parallel or the two instances of the rule may conflict (instead use the add_custom_target() command to drive the command and make the other targets depend on that one) Removing ${MyParserOutput} from both add_library() should fix the issue. Best regards, F -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Thu Mar 14 13:30:12 2019 From: frodak17 at gmail.com (frodak17) Date: Thu, 14 Mar 2019 13:30:12 -0400 Subject: [CMake] Visual Studio generator running custom_command twice In-Reply-To: References: <501bdd6832d5967a468e7e1283b7aa1530ef1223.camel@mad-scientist.net> Message-ID: On Thu, Mar 14, 2019 at 12:53 PM frodak17 wrote: > > > On Thu, Mar 14, 2019 at 1:13 AM Paul Smith wrote: > >> I have a situation where I've created a custom command to generate .cpp >> files to be compiled (in my case running bison/flex). >> >> I'm using CMake 3.13.4 >> >> set(MyParserOutput >> ${OUT_DIR}/MyParser.tab.cpp >> ${OUT_DIR}/MyParser.tab.hpp) >> >> add_custom_target(MyGenParser DEPENDS ${MyParserOutput}) >> >> Then I have two different libraries, both depending on this: >> >> add_library(OneLib STATIC ${MyParserOutput} ...) >> add_dependencies(OneLib MyGenparser) >> >> >> add_library(TwoLib STATIC ${MyParserOutput} ...) >> add_dependencies(TwoLib MyGenparser) >> >> >> From add_custom_command() > Do not list the output in more than one independent target that may build > in parallel or the two instances of the rule may conflict (instead use the > add_custom_target() > > command to drive the command and make the other targets depend on that one) > > Removing ${MyParserOutput} from both add_library() should fix the issue. > > Best regards, > F > Sorry, It didn't register at first that about the cpp file that needs to get compiled into the library. That makes it a little more complicated. In that case you need to keep ${MyParserOutput} and set the GENERATED properties for the files. Also the building the custom target needs to be done in a separate directory as the add_custom_commands() need to be in a different CMakeLists.txt file from the libraries. Otherwise the rules get pulled into the libraries and cause the commands to be run multiple times. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Mar 14 14:37:00 2019 From: sean at rogue-research.com (Sean McBride) Date: Thu, 14 Mar 2019 14:37:00 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.14.0 available for download In-Reply-To: References: Message-ID: <20190314183700.1997078875@mail.rogue-research.com> On Thu, 14 Mar 2019 11:58:16 -0400, Robert Maynard via CMake said: >I am happy to announce that CMake 3.14.0 is now available for download at: > https://cmake.org/download/ Pi version on Pi Day. Nicely done! :) Couldn't you have waited until 3:14 to release it? :) Sean From kyle.edwards at kitware.com Thu Mar 14 14:46:16 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 14 Mar 2019 14:46:16 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.14.0 available for download In-Reply-To: <20190314183700.1997078875@mail.rogue-research.com> References: <20190314183700.1997078875@mail.rogue-research.com> Message-ID: <1552589176.22482.4.camel@kitware.com> On Thu, 2019-03-14 at 14:37 -0400, Sean McBride wrote: > On Thu, 14 Mar 2019 11:58:16 -0400, Robert Maynard via CMake said: > > > > > I am happy to announce that CMake 3.14.0 is now available for > > download at: > > ?https://cmake.org/download/ > Pi version on Pi Day.??Nicely done!??:)??Couldn't you have waited > until 3:14 to release it???:) We thought about releasing it at 1:59, but we didn't want to wait until the afternoon :) Kyle From lokiofasgard501 at gmail.com Thu Mar 14 19:56:17 2019 From: lokiofasgard501 at gmail.com (Gavin M2301) Date: Thu, 14 Mar 2019 19:56:17 -0400 Subject: [CMake] not sure if I am verifying download correctly: something kooky Message-ID: Hi- gpg2 --verify cmake-3.14.0-SHA-256.txt.asc cmake-3.14.0-SHA-256.txt gpg: Signature made Thu, Mar 14, 2019 10:26:24 AM EDT gpg: using RSA key C6C265324BBEBDC350B513D02D2CEF1034921684 gpg: Can't check signature: No public key sha256sum cmake-3.14.0-win64-x64.msi 4cbc62929f313d9890d377fa022753e9e5509e7afa3e16978127b7b2813633cf *cmake-3.14.0-win64-x64.msi 4cbc62929f313d9890d377fa022753e9e5509e7afa3e16978127b7b2813633cf cmake-3.14.0-win64-x64.msi gpg2--keyid-format long --show-key cmake-3.14.0-SHA-256.txt.asc -bash: gpg2--keyid-format: command not found That last one might be because it is a new gpg2 version. https://serverfault.com/questions/896228/how-to-verify-a-file-using-an-asc-signature-file So, I got a good sha256sum but can't verify the signature. Per the website, EC8FEF3A7BFB4EDA I am wondering if PGP is different than GPG and that is the issue. I don't think that is the issue though. Please advise. Thnx. for any assistance: Roboloki Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From workbench at gmx.at Thu Mar 14 20:53:15 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Fri, 15 Mar 2019 01:53:15 +0100 Subject: [CMake] Basic question how to find -lm include and lib dir with find_package or otherwise Message-ID: <82eaa454-4113-6ea3-d3ed-18f01e17240e@gmx.at> Hi everyone, i'm searching for a way to find the right include dir so that -lm can be found, the is not find_package for this, is /usr/lib and /usr/include a default because he find it without me adding any include or lib path for the build. best regards! -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 2452 bytes Desc: not available URL: From roman.wueger at gmx.at Fri Mar 15 01:28:19 2019 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Fri, 15 Mar 2019 06:28:19 +0100 Subject: [CMake] XCode target membership Message-ID: <699382FA-9CB5-4122-84C4-FEC7F0E99B35@gmx.at> Hello, since Xcode 10 I noticed that I must check the Checkbox (Target membership on the right pane) for my target when I want that the assets are recognized for the specified target. Is there a way to automatically set this option via CMake? The problem is that when I forget to set this check mark (or it is an automated build), then no app icon will be set. Thanks in advance Regards Roman From frodak17 at gmail.com Fri Mar 15 07:46:11 2019 From: frodak17 at gmail.com (frodak17) Date: Fri, 15 Mar 2019 07:46:11 -0400 Subject: [CMake] Basic question how to find -lm include and lib dir with find_package or otherwise In-Reply-To: <82eaa454-4113-6ea3-d3ed-18f01e17240e@gmx.at> References: <82eaa454-4113-6ea3-d3ed-18f01e17240e@gmx.at> Message-ID: On Thu, Mar 14, 2019 at 8:53 PM Workbench at gmx.at wrote: > Hi everyone, > > i'm searching for a way to find the right include dir so that -lm can be > found, the is not find_package for this, is /usr/lib and /usr/include a > default because he find it without me adding any include or lib path for > the build. > > > It seems strange that you need to do this. In my experience 'm' is just the math portion of the 'c' library. Depending on which host and toolset you are using there can be multiple version of the 'm' library depending on target architecture and other options used. The linker should just use the correct 'm' library just as it uses the correct 'c' library. It could be in /usr/lib depending on how the compiler was packaged for your host. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Fri Mar 15 08:54:32 2019 From: brad.king at kitware.com (Brad King) Date: Fri, 15 Mar 2019 08:54:32 -0400 Subject: [CMake] XCode target membership In-Reply-To: <699382FA-9CB5-4122-84C4-FEC7F0E99B35@gmx.at> References: <699382FA-9CB5-4122-84C4-FEC7F0E99B35@gmx.at> Message-ID: <4da86386-fa29-06ea-d11a-602fc60396ce@kitware.com> On 3/15/19 1:28 AM, Roman W?ger wrote: > since Xcode 10 I noticed that I must check the Checkbox > (Target membership on the right pane) for my target when I want > that the assets are recognized for the specified target. > > Is there a way to automatically set this option via CMake? The problem > is that when I forget to set this check mark (or it is an automated build), > then no app icon will be set. Please open an issue tracker entry for this. Thanks, -Brad From workbench at gmx.at Fri Mar 15 12:03:28 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Fri, 15 Mar 2019 17:03:28 +0100 Subject: [CMake] Question about find_packages. Message-ID: Hi everyone, i try to use find_packages for clang, i'm on debian and have installed libclang-4.0-dev package, now i've the files in /usr/lib/llvm4-0/lib/libclang-4.0.so and the include in /usr/lib/llvm-4.0/include/clang - how can i make find_package find those ?? best regards! -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 2452 bytes Desc: not available URL: From workbench at gmx.at Fri Mar 15 12:06:51 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Fri, 15 Mar 2019 17:06:51 +0100 Subject: [CMake] Question about find_packages. In-Reply-To: References: Message-ID: <52f8f79c-509e-9008-d6f9-da4913fb8dc2@gmx.at> I allways get the error: CMake Error at CMakeLists.txt:78 (find_package): ? Could not find a package configuration file provided by "Clang" (requested ? version 4.0) with any of the following names: ??? libclang-4.0.soConfig.cmake ??? libclang-4.0.so-config.cmake ? Add the installation prefix of "Clang" to CMAKE_PREFIX_PATH or set ? "Clang_DIR" to a directory containing one of the above files.? If "Clang" ? provides a separate development package or SDK, be sure it has been ? installed. -- Configuring incomplete, errors occurred! On 15.03.19 17:03, Workbench at gmx.at wrote: > Hi everyone, > > i try to use find_packages for clang, i'm on debian and have installed > libclang-4.0-dev package, now i've the files in > /usr/lib/llvm4-0/lib/libclang-4.0.so and the include in > /usr/lib/llvm-4.0/include/clang - how can i make find_package find those ?? > > > best regards! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 2452 bytes Desc: not available URL: From kyle.edwards at kitware.com Fri Mar 15 12:08:55 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Fri, 15 Mar 2019 12:08:55 -0400 Subject: [CMake] Question about find_packages. In-Reply-To: References: Message-ID: <1552666135.22482.6.camel@kitware.com> On Fri, 2019-03-15 at 17:03 +0100, Workbench at gmx.at wrote: > Hi everyone, > > i try to use find_packages for clang, i'm on debian and have > installed > libclang-4.0-dev package, now i've the files in > /usr/lib/llvm4-0/lib/libclang-4.0.so and the include in > /usr/lib/llvm-4.0/include/clang - how can i make find_package find > those ?? LLVM contains package config files which give you all of this information. Use find_package() as normal: find_package(LLVM) And then invoke CMake with: $ cmake . -DLLVM_DIR=/usr/lib/llvm-4.0/cmake Kyle From chuck.atkins at kitware.com Fri Mar 15 12:44:50 2019 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Fri, 15 Mar 2019 12:44:50 -0400 Subject: [CMake] Basic question how to find -lm include and lib dir with find_package or otherwise In-Reply-To: References: <82eaa454-4113-6ea3-d3ed-18f01e17240e@gmx.at> Message-ID: Usually you don't need to use the full path to libm, and it's only needed sometimes depending on your compiler and toolchain. I typically use something like the following to deal with both the implicit and explicit scenarios: include(CheckCSourceCompiles) set(LIBM_TEST_SOURCE "#include\nfloat f; int main(){sqrt(f);return 0;}") check_c_source_compiles("${LIBM_TEST_SOURCE}" HAVE_MATH) if(HAVE_MATH) set(LIBM_LIBRARIES) else() set(CMAKE_REQUIRED_LIBRARIES m) check_c_source_compiles("${LIBM_TEST_SOURCE}" HAVE_LIBM_MATH) unset(CMAKE_REQUIRED_LIBRARIES) if(NOT HAVE_LIBM_MATH) message(FATAL_ERROR "Unable to use C math library functions") endif() set(LIBM_LIBRARIES m) endif() target_link_libraries(fooTarget PRIVATE ${LIBM_LIBRARIES}) ---------- Chuck Atkins Staff R&D Engineer, Scientific Computing Kitware, Inc. On Fri, Mar 15, 2019 at 7:46 AM frodak17 wrote: > > > On Thu, Mar 14, 2019 at 8:53 PM Workbench at gmx.at wrote: > >> Hi everyone, >> >> i'm searching for a way to find the right include dir so that -lm can be >> found, the is not find_package for this, is /usr/lib and /usr/include a >> default because he find it without me adding any include or lib path for >> the build. >> >> >> > It seems strange that you need to do this. In my experience 'm' is just > the math portion of the 'c' library. Depending on which host and toolset > you are using there can be multiple version of the 'm' library depending on > target architecture and other options used. The linker should just use the > correct 'm' library just as it uses the correct 'c' library. It could be > in /usr/lib depending on how the compiler was packaged for your host. > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mad-scientist.net Fri Mar 15 13:23:04 2019 From: paul at mad-scientist.net (Paul Smith) Date: Fri, 15 Mar 2019 13:23:04 -0400 Subject: [CMake] Visual Studio generator running custom_command twice In-Reply-To: References: <501bdd6832d5967a468e7e1283b7aa1530ef1223.camel@mad-scientist.net> Message-ID: <4277e94f76800837c6a740843cbae4e6542ed13b.camel@mad-scientist.net> On Thu, 2019-03-14 at 13:30 -0400, frodak17 wrote: > On Thu, Mar 14, 2019 at 12:53 PM frodak17 wrote: > > On Thu, Mar 14, 2019 at 1:13 AM Paul Smith > > wrote: > > > I have a situation where I've created a custom command to > > > generate .cpp > > > > > > files to be compiled (in my case running bison/flex). > > > > > > > > > > > > I'm using CMake 3.13.4 > > > > > > > > > > > > set(MyParserOutput > > > > > > ${OUT_DIR}/MyParser.tab.cpp > > > > > > ${OUT_DIR}/MyParser.tab.hpp) > > > > > > > > > > > > add_custom_target(MyGenParser DEPENDS ${MyParserOutput}) > > > > > > > > > > > > Then I have two different libraries, both depending on this: > > > > > > > > > > > > add_library(OneLib STATIC ${MyParserOutput} ...) > > > > > > > > > add_dependencies(OneLib MyGenparser) > > > > > > > > > > > > > > > > > > add_library(TwoLib STATIC ${MyParserOutput} ...) > > > > > > > > > add_dependencies(TwoLib MyGenparser) > > > > > > > > From add_custom_command() > > Do not list the output in more than one independent target that > > may build in parallel or the two instances of the rule may conflict > > (instead use the add_custom_target() command to drive the > > command and make the other targets depend on that one) Yeah, I did see that in the manual and I do that, as above. It wan't at all clear to me that in addition to those requirements, I ALSO could NOT list the output of the add_custom_command() in any of my other targets. That's unfortunate :(. > In that case you need to keep ${MyParserOutput} and set the GENERATED > properties for the files. > > Also the building the custom target needs to be done in a separate > directory as the add_custom_commands() need to be in a different > CMakeLists.txt file from the libraries. Otherwise the rules get > pulled into the libraries and cause the commands to be run multiple > times. Ouch. That's painful as it could mean moving my code around. However in this case it ended up not being too horrible because my parser input files happened to be in a subdirectory already, so I created a new CMakeLists.txt file there that only ran the generators, then used set(... PARENT_SCOPE) to publish the variables to the parent directory. I did then have to add a GENERATED property to those files in the parent directory, as you noted, so overall it's a bit leaky in terms of abstractions, but it seems to work... now when I run on Windows I see that the generators are run only one time. Thanks for the help!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From workbench at gmx.at Sat Mar 16 08:11:48 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Sat, 16 Mar 2019 13:11:48 +0100 Subject: [CMake] Question about find_package Message-ID: Hi everyone, i'm on debian strech and there is a package called clang-4.0 that contains a ClangConfig.cmake in the path /usr/local/llvm/cmake but find_package(Clang 4.0 REQUIRED) is not able to find it.. it worked the day before.. i don't know what i'm doing wrong here. best regards! -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 2452 bytes Desc: not available URL: From workbench at gmx.at Sat Mar 16 08:34:44 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Sat, 16 Mar 2019 13:34:44 +0100 Subject: [CMake] Question about find_package In-Reply-To: References: Message-ID: <434e9479-cdcb-3ae2-ea4f-6533cc872f87@gmx.at> The ClangConfig.cmake file is in /usr/share/llvm4.0/cmake ... On 16.03.19 13:11, Workbench at gmx.at wrote: > Hi everyone, > > i'm on debian strech and there is a package called clang-4.0 that > contains a ClangConfig.cmake in the > > path /usr/local/llvm/cmake but find_package(Clang 4.0 REQUIRED) is not > able to find it.. it worked the day before.. i don't know what i'm doing > wrong here. > > > best regards! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 2452 bytes Desc: not available URL: From workbench at gmx.at Sat Mar 16 15:50:34 2019 From: workbench at gmx.at (Workbench@gmx.at) Date: Sat, 16 Mar 2019 20:50:34 +0100 Subject: [CMake] Question about find_package In-Reply-To: <434e9479-cdcb-3ae2-ea4f-6533cc872f87@gmx.at> References: <434e9479-cdcb-3ae2-ea4f-6533cc872f87@gmx.at> Message-ID: <2edab73c-a7de-d39e-ad75-8f52ac06cf94@gmx.at> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862328 On 16.03.19 13:34, Workbench at gmx.at wrote: > > The ClangConfig.cmake file is in /usr/share/llvm4.0/cmake ... > > On 16.03.19 13:11, Workbench at gmx.at wrote: >> Hi everyone, >> >> i'm on debian strech and there is a package called clang-4.0 that >> contains a ClangConfig.cmake in the >> >> path /usr/local/llvm/cmake but find_package(Clang 4.0 REQUIRED) is not >> able to find it.. it worked the day before.. i don't know what i'm doing >> wrong here. >> >> >> best regards! >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pEpkey.asc Type: application/pgp-keys Size: 2452 bytes Desc: not available URL: From systemangle at gmail.com Mon Mar 18 01:52:55 2019 From: systemangle at gmail.com (Ali Angle) Date: Mon, 18 Mar 2019 10:52:55 +0500 Subject: [CMake] complication issue Message-ID: Issue is described over here: https://stackoverflow.com/questions/55211221/cmake-build-problem-when-building-code-for-avr Can we make cmake use absolute paths in build commands and avoid change directory, and make build directory as working directory during build process ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From systemangle at gmail.com Mon Mar 18 08:26:08 2019 From: systemangle at gmail.com (Ali Angle) Date: Mon, 18 Mar 2019 17:26:08 +0500 Subject: [CMake] complication issue In-Reply-To: References: Message-ID: example code added to : https://github.com/systemangle/mcve_avr I think this may not be path related. But something is clearly wrong. On Mon, 18 Mar 2019 at 10:52, Ali Angle wrote: > > Issue is described over here: > https://stackoverflow.com/questions/55211221/cmake-build-problem-when-building-code-for-avr > > Can we make cmake use absolute paths in build commands and avoid change > directory, and make build directory as working directory during build > process ? > -- A.A Regards, sYsTeamAngle -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwan.work at gmail.com Mon Mar 18 11:42:43 2019 From: rwan.work at gmail.com (Raymond Wan) Date: Mon, 18 Mar 2019 23:42:43 +0800 Subject: [CMake] complication issue In-Reply-To: References: Message-ID: <6e4ba32a-f435-e530-f1fa-27fc2462280f@gmail.com> Hi Ali, On 18/3/2019 1:52 PM, Ali Angle wrote: > Issue is described over here: > https://stackoverflow.com/questions/55211221/cmake-build-problem-when-building-code-for-avr I'm not too sure what you're talking about in this posting, but I am also not too familiar with AVR. At the beginning of your Stackoverflow post, you said, "When I build using make everything works fine. but when I use cmake it doesn't compile ok" and this statement isn't quite clear. If you hand-coded a Makefile, then you would compile with that. But CMake is used to create a Makefile. When you say it doesn't compile...are you saying you are having a problem at the CMake step or the Make step? Are you comparing a Makefile that you made vs a CMakeLists.txt that you made? Or is one made by someone else? Ray From rwan.work at gmail.com Tue Mar 19 00:58:18 2019 From: rwan.work at gmail.com (Raymond Wan) Date: Tue, 19 Mar 2019 12:58:18 +0800 Subject: [CMake] complication issue In-Reply-To: References: <6e4ba32a-f435-e530-f1fa-27fc2462280f@gmail.com> Message-ID: Hi Ali, Please keep replies (to me, at least) to the CMake mailing list, as well. I'm not too knowledgeable with CMake and it's always useful for all parties to have a discussion public so that others can jump in and contribute something. Quite frankly, your sentence below doesn't make sense to me. I mean, Makefiles and CMakeLists.txt are just text files. If two Makefiles are "running the exact commands", then they will behave exactly the same. The question is are the Makefiles *identical* and if not, then you need to work backwards to where in the CMakeLists.txt has that change been introduced. Ray On Tue, Mar 19, 2019 at 1:43 AM Ali Angle wrote: > > Hi Raymond, > Please see the example code attached. In simple terms Makefile generated by cmake is running exactly the same commands as the Makefile file created by me. But the output differs and doesn't work when build using cmake generated Makefile. > > On Mon, 18 Mar 2019 at 20:42, Raymond Wan wrote: >> >> >> Hi Ali, >> >> >> On 18/3/2019 1:52 PM, Ali Angle wrote: >> > Issue is described over here: >> > https://stackoverflow.com/questions/55211221/cmake-build-problem-when-building-code-for-avr >> >> >> I'm not too sure what you're talking about in this posting, >> but I am also not too familiar with AVR. >> >> At the beginning of your Stackoverflow post, you said, "When >> I build using make everything works fine. but when I use >> cmake it doesn't compile ok" and this statement isn't quite >> clear. If you hand-coded a Makefile, then you would compile >> with that. But CMake is used to create a Makefile. When >> you say it doesn't compile...are you saying you are having a >> problem at the CMake step or the Make step? >> >> Are you comparing a Makefile that you made vs a >> CMakeLists.txt that you made? Or is one made by someone else? >> >> Ray >> >> >> -- >> >> 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 > > > > -- > A.A > > > Regards, > sYsTeamAngle From lassi.niemisto at wapice.com Tue Mar 19 03:12:02 2019 From: lassi.niemisto at wapice.com (=?iso-8859-1?Q?Lassi_Niemist=F6?=) Date: Tue, 19 Mar 2019 07:12:02 +0000 Subject: [CMake] Trigger rebuild when a system header changes Message-ID: Hello, It seems CMake has a special handling for system header dependencies. I.e. if my .c file includes /usr/include/someheader.h, modifying the someheader.h does not cause the .c file to be rebuilt. How to work around this issue? We have some custom libraries that get installed to system paths and they change relatively often. It is error-prone for the developers to accidentally keep using the library with old header compiled in. Things I have tried this far: * add_dependencies(target /path/to/header.h) --> no luck * add_library(include_deplib /path/to/header.h) + target_link_libraries(target include_deplib) --> needs additional tweaking to be legal, still does not work * OBJECT_DEPENDS property pointing to the .h file--> This works but I need to do this for each c. file separately I wonder if this should be this difficult, I am probably missing something? Can I just somehow enable tracking system headers also as expected-to-change dependencies? -Lassi -------------- next part -------------- An HTML attachment was scrubbed... URL: From mojca.miklavec.lists at gmail.com Tue Mar 19 04:16:27 2019 From: mojca.miklavec.lists at gmail.com (Mojca Miklavec) Date: Tue, 19 Mar 2019 16:16:27 +0800 Subject: [CMake] Specifying both native and cross compiler at the same time Message-ID: Hi, I would like a build setup for a project to work correctly for both native and cross compilation, however one part requires native compilation and execution of the binary to generate some data tables as part of the build process (the temporary native binary is then discarded / not installed). What I seem to be unable to figure out is how to specify the compiler(s) and flags separately for the native and cross compiler. I want them to be specified by the user or package manager rather than the author of cmake files. One particular problem is when cross-compiling on mac with mingw (gcc) while using clang as the native compiler (the two compilers have incompatible flags). How can I specify two sets of compilers and flags at configure time? (The same question puzzles me in autoconf world as well. Please don't say that the native compiler should be found automatically as I really need to specify which one to use, ancient systems don't have support for C++11 with the default compiler etc.) Thank you very much, Mojca -------------- next part -------------- An HTML attachment was scrubbed... URL: From lassi.niemisto at wapice.com Tue Mar 19 05:55:49 2019 From: lassi.niemisto at wapice.com (=?utf-8?B?TGFzc2kgTmllbWlzdMO2?=) Date: Tue, 19 Mar 2019 09:55:49 +0000 Subject: [CMake] Specifying both native and cross compiler at the same time In-Reply-To: References: Message-ID: Hello, I spent a lot of time figuring out how to support multiple compilers in parallel. Here is how I did it: ? Write a toolchain file for each of your compiler setups. Specify any toolchain specific compiler flags there. See https://cmake.org/cmake/help/v3.14/manual/cmake-toolchains.7.html ? Write one top-level CMakeLists which o Calls cmake for your actual CMakeLists with execute_process and each time specify different ?DCMAKE_TOOLCHAIN_FILE and different build directory o Implement a mechanism how the actual cmake tree can publish target names to top-level. I wrote them to a file in the root of build directory. Of course you can also hardcode the target names on top-level but a dynamic mechanism makes it less cluttered. o In the top-level cmake, after generating the architecture specific trees, read the published targets and add a custom target for each of the published targets from the architecture specific trees. Each custom target just calls make in the respective architecture specific build directory. The other point, using the compiled binary as part of the compilation is not necessarily very good idea (sounds like chicken-egg to me). Could you instead compile the native binary separately and put it as a ?released version? somewhere and use the last released version in your compilation phase. The ?cmake way? would be to regenerate cmake each time you want to switch between the architectures. But if cmake generation and build is heavy, this is a major usability issue. Hence the above hack solution. -Lassi From: CMake On Behalf Of Mojca Miklavec Sent: tiistai 19. maaliskuuta 2019 10.16 To: cmake at cmake.org Subject: [CMake] Specifying both native and cross compiler at the same time Hi, I would like a build setup for a project to work correctly for both native and cross compilation, however one part requires native compilation and execution of the binary to generate some data tables as part of the build process (the temporary native binary is then discarded / not installed). What I seem to be unable to figure out is how to specify the compiler(s) and flags separately for the native and cross compiler. I want them to be specified by the user or package manager rather than the author of cmake files. One particular problem is when cross-compiling on mac with mingw (gcc) while using clang as the native compiler (the two compilers have incompatible flags). How can I specify two sets of compilers and flags at configure time? (The same question puzzles me in autoconf world as well. Please don't say that the native compiler should be found automatically as I really need to specify which one to use, ancient systems don't have support for C++11 with the default compiler etc.) Thank you very much, Mojca -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjwrona1992 at gmail.com Tue Mar 19 13:13:54 2019 From: tjwrona1992 at gmail.com (Timothy Wrona) Date: Tue, 19 Mar 2019 13:13:54 -0400 Subject: [CMake] Specifying code in one subdirectory depends on a library from another subdirectory Message-ID: I am working on a complex CMake project that is part of a large legacy system that uses a top level project and "add_subdirectory" to create subprojects. I have run into an issue because now one of the subprojects is dependant on another subproject, but I can't seem to find a clear way to tell CMake about this dependency. Consider this example: my_project/ CMakeLists.txt: add_subdirectory('subproject1') add_subdirectory('subproject2') my_project/subproject1/ CMakeLists.txt: add_executable(subproject1_exe ) target_link_libraries(subproject1_exe subproject2_lib) # <-- THIS is the problem my_project/subproject2/ CMakeLists.txt: add_library(subproject2_lib ) The actual code is much more complex than this, but this simple example illustrates the problem. The actual compilation error I am getting is caused by subproject1 including a header file that gets generated when subproject2 is built. Does anyone know how to properly tell CMake about the dependency so it will build correctly? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjwrona1992 at gmail.com Tue Mar 19 13:41:03 2019 From: tjwrona1992 at gmail.com (Timothy Wrona) Date: Tue, 19 Mar 2019 13:41:03 -0400 Subject: [CMake] Specifying code in one subdirectory depends on a library from another subdirectory In-Reply-To: References: Message-ID: Seems I might be able to answer my own question. It looks like "add_dependencies(subproject1_exe subproject2_lib)" worked. I had to do a clean first though because it didn't work the first time since some old files were left around. Hope this helps anyone else with a similar issue! On Tue, Mar 19, 2019 at 1:13 PM Timothy Wrona wrote: > I am working on a complex CMake project that is part of a large legacy > system that uses a top level project and "add_subdirectory" to create > subprojects. > > I have run into an issue because now one of the subprojects is dependant > on another subproject, but I can't seem to find a clear way to tell CMake > about this dependency. > > Consider this example: > > my_project/ > CMakeLists.txt: > add_subdirectory('subproject1') > add_subdirectory('subproject2') > > my_project/subproject1/ > CMakeLists.txt: > add_executable(subproject1_exe ) > target_link_libraries(subproject1_exe subproject2_lib) # <-- > THIS is the problem > > my_project/subproject2/ > CMakeLists.txt: > add_library(subproject2_lib ) > > The actual code is much more complex than this, but this simple example > illustrates the problem. The actual compilation error I am getting is > caused by subproject1 including a header file that gets generated when > subproject2 is built. > > Does anyone know how to properly tell CMake about the dependency so it > will build correctly? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjwrona1992 at gmail.com Tue Mar 19 13:46:28 2019 From: tjwrona1992 at gmail.com (Timothy Wrona) Date: Tue, 19 Mar 2019 13:46:28 -0400 Subject: [CMake] Specifying code in one subdirectory depends on a library from another subdirectory In-Reply-To: References: Message-ID: Never mind... I spoke too soon. add_dependencies isn't working. It is correctly making the other project build first, but the header file is for some reason not generated until after it is needed. On Tue, Mar 19, 2019 at 1:41 PM Timothy Wrona wrote: > Seems I might be able to answer my own question. > > It looks like "add_dependencies(subproject1_exe subproject2_lib)" worked. > > I had to do a clean first though because it didn't work the first time > since some old files were left around. > > Hope this helps anyone else with a similar issue! > > On Tue, Mar 19, 2019 at 1:13 PM Timothy Wrona > wrote: > >> I am working on a complex CMake project that is part of a large legacy >> system that uses a top level project and "add_subdirectory" to create >> subprojects. >> >> I have run into an issue because now one of the subprojects is dependant >> on another subproject, but I can't seem to find a clear way to tell CMake >> about this dependency. >> >> Consider this example: >> >> my_project/ >> CMakeLists.txt: >> add_subdirectory('subproject1') >> add_subdirectory('subproject2') >> >> my_project/subproject1/ >> CMakeLists.txt: >> add_executable(subproject1_exe ) >> target_link_libraries(subproject1_exe subproject2_lib) # <-- >> THIS is the problem >> >> my_project/subproject2/ >> CMakeLists.txt: >> add_library(subproject2_lib ) >> >> The actual code is much more complex than this, but this simple example >> illustrates the problem. The actual compilation error I am getting is >> caused by subproject1 including a header file that gets generated when >> subproject2 is built. >> >> Does anyone know how to properly tell CMake about the dependency so it >> will build correctly? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsvargas at gmail.com Tue Mar 19 16:28:44 2019 From: rsvargas at gmail.com (Rafael Vargas) Date: Tue, 19 Mar 2019 17:28:44 -0300 Subject: [CMake] Specifying code in one subdirectory depends on a library from another subdirectory Message-ID: How is this file subproject1 depends on generated? I have a project where some file was generated using add_custom_command, like this: add_custom_command( OUTPUT ${FILE_NAME} COMMAND ${CMD_LINE} ) So, in order to my lib to depend on this file I created a custom target add_custom_target( target_name, ALL DEPENDS ${FILE_NAME} ) and then added as a dependency to my lib: add_dependencies( my_lib_name, target_name ${FILE_NAME} ) See and try adding an explicit dependency on the generated file like this. Em ter, 19 de mar de 2019 ?s 14:46, Timothy Wrona escreveu: > Never mind... I spoke too soon. add_dependencies isn't working. It is > correctly making the other project build first, but the header file is for > some reason not generated until after it is needed. > > On Tue, Mar 19, 2019 at 1:41 PM Timothy Wrona > wrote: > >> Seems I might be able to answer my own question. >> >> It looks like "add_dependencies(subproject1_exe subproject2_lib)" worked. >> >> I had to do a clean first though because it didn't work the first time >> since some old files were left around. >> >> Hope this helps anyone else with a similar issue! >> >> On Tue, Mar 19, 2019 at 1:13 PM Timothy Wrona >> wrote: >> >>> I am working on a complex CMake project that is part of a large legacy >>> system that uses a top level project and "add_subdirectory" to create >>> subprojects. >>> >>> I have run into an issue because now one of the subprojects is dependant >>> on another subproject, but I can't seem to find a clear way to tell >>> CMake about this dependency. >>> >>> Consider this example: >>> >>> my_project/ >>> CMakeLists.txt: >>> add_subdirectory('subproject1') >>> add_subdirectory('subproject2') >>> >>> my_project/subproject1/ >>> CMakeLists.txt: >>> add_executable(subproject1_exe ) >>> target_link_libraries(subproject1_exe subproject2_lib) # <-- >>> THIS is the problem >>> >>> my_project/subproject2/ >>> CMakeLists.txt: >>> add_library(subproject2_lib ) >>> >>> The actual code is much more complex than this, but this simple example >>> illustrates the problem. The actual compilation error I am getting is >>> caused by subproject1 including a header file that gets generated when >>> subproject2 is built. >>> >>> Does anyone know how to properly tell CMake about the dependency so it >>> will build correctly? >>> >> -- -- Rafael Vargas -------------- next part -------------- An HTML attachment was scrubbed... URL: From foss at grueninger.de Tue Mar 19 19:01:28 2019 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Wed, 20 Mar 2019 00:01:28 +0100 Subject: [CMake] PIE-pie_off and CMP0083-cmp0083_new fail for openSuse Leap 15.0 Message-ID: Dear CMake, while trying to update the RPMs for openSuse with the Open Build service, I stumbled upon a strange problem. Following the same spec file for all target plattforms, CMake is first built and then the tests are executed. The tests pass for different types of openSuse versions (Factory, Tumbleweed, Leap 42.3, SLE 12 SP3) but fail for a single version, openSuse Leap 15.0. I attached the output of the failing tests. The failure is related to CMP0083 and PIE. But I cannot spot any difference causing different test results. Could someone advice how to track down the reason for my issue? Bye, Christoph [ 683s] 356/495 Test #363: RunCMake.add_executable .......................... Passed 3.39 sec [ 683s] Start 369: RunCMake.cmake_minimum_required [ 683s] 357/495 Test #354: RunCMake.PositionIndependentCode .................***Failed 25.89 sec [ 683s] -- Conflict1 - PASSED [ 683s] -- Conflict2 - PASSED [ 683s] -- Conflict3 - PASSED [ 683s] -- Conflict4 - PASSED [ 683s] -- Conflict5 - PASSED [ 683s] -- Conflict6 - PASSED [ 683s] -- Debug - PASSED [ 683s] -- Genex1 - PASSED [ 683s] -- Genex2 - PASSED [ 683s] -- CheckPIESupported - PASSED [ 683s] -- PIE - PASSED [ 683s] -- PIE-pie_on - PASSED [ 683s] CMake Error at RunCMake.cmake:168 (message): [ 683s] PIE-pie_off - FAILED: [ 683s] [ 683s] Executable is NOT 'no PIE' (PIE). [ 683s] [ 683s] Command was: [ 683s] [ 683s] command> "/home/abuild/rpmbuild/BUILD/cmake-3.14.0/bin/cmake" "--build" "." "--config" "Release" "--target" "pie_off" [ 683s] [ 683s] Actual stdout: [ 683s] [ 683s] actual-out> Scanning dependencies of target pie_off [ 683s] actual-out> [ 50%] Building CXX object CMakeFiles/pie_off.dir/main.cpp.o [ 683s] actual-out> [100%] Linking CXX executable pie_off [ 683s] actual-out> [100%] Built target pie_off [ 683s] [ 683s] Actual stderr: [ 683s] [ 683s] actual-err> [ 683s] [ 683s] Call Stack (most recent call first): [ 683s] RunCMake.cmake:182 (run_cmake) [ 683s] PositionIndependentCode/RunCMakeTest.cmake:35 (run_cmake_command) [ 683s] PositionIndependentCode/RunCMakeTest.cmake:52 (run_cmake_target) [ 683s] [ 683s] [ 683s] -- CMP0083 - PASSED [ 683s] -- CMP0083-cmp0083_ref - PASSED [ 683s] CMake Error at RunCMake.cmake:168 (message): [ 683s] CMP0083-cmp0083_new - FAILED: [ 683s] [ 683s] CMP0083(NEW) do not produce expected executable. [ 683s] [ 683s] Command was: [ 683s] [ 683s] command> "/home/abuild/rpmbuild/BUILD/cmake-3.14.0/bin/cmake" "--build" "." "--config" "Release" "--target" "cmp0083_new" [ 683s] [ 683s] Actual stdout: [ 683s] [ 683s] actual-out> Scanning dependencies of target cmp0083_new_pie [ 683s] actual-out> [ 16%] Building CXX object CMakeFiles/cmp0083_new_pie.dir/main.cpp.o [ 683s] actual-out> [ 33%] Linking CXX executable cmp0083_new_pie [ 683s] actual-out> [ 33%] Built target cmp0083_new_pie [ 683s] actual-out> [ 66%] Built target cmp0083_ref [ 683s] actual-out> Scanning dependencies of target cmp0083_new_no_pie [ 683s] actual-out> [ 83%] Building CXX object CMakeFiles/cmp0083_new_no_pie.dir/main.cpp.o [ 683s] actual-out> [100%] Linking CXX executable cmp0083_new_no_pie [ 683s] actual-out> [100%] Built target cmp0083_new_no_pie [ 683s] actual-out> Scanning dependencies of target cmp0083_new [ 683s] actual-out> [100%] Built target cmp0083_new [ 683s] [ 683s] Actual stderr: [ 683s] [ 683s] actual-err> [ 683s] [ 683s] Call Stack (most recent call first): [ 683s] RunCMake.cmake:182 (run_cmake) [ 683s] PositionIndependentCode/RunCMakeTest.cmake:35 (run_cmake_command) [ 683s] PositionIndependentCode/RunCMakeTest.cmake:65 (run_cmake_target) [ 683s] [ 683s] [ 683s] -- CMP0083-cmp0083_old - PASSED [ 683s] [ 683s] Start 370: RunCMake.cmake_parse_arguments [ 683s] 358/495 Test #369: RunCMake.cmake_minimum_required .................. Passed 0.51 sec From Alan.W.Irwin1234 at gmail.com Tue Mar 19 21:21:11 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Tue, 19 Mar 2019 18:21:11 -0700 (PDT) Subject: [CMake] PIE-pie_off and CMP0083-cmp0083_new fail for openSuse Leap 15.0 In-Reply-To: References: Message-ID: On 2019-03-20 00:01+0100 Christoph Gr?ninger wrote: > Dear CMake, > while trying to update the RPMs for openSuse with the Open Build > service, I stumbled upon a strange problem. Following the same spec file > for all target plattforms, CMake is first built and then the tests are > executed. The tests pass for different types of openSuse versions > (Factory, Tumbleweed, Leap 42.3, SLE 12 SP3) but fail for a single > version, openSuse Leap 15.0. I attached the output of the failing tests. > The failure is related to CMP0083 and PIE. But I cannot spot any > difference causing different test results. > Could someone advice how to track down the reason for my issue? Hi Christoph: Just in case the trouble is simply due to a real CMake bug for some old version of CMake, what exact versions of CMake are you testing on each of your various "good" platforms compared to your "bad" platform, openSuse Leap 15.0? Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From foss at grueninger.de Wed Mar 20 06:44:42 2019 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Wed, 20 Mar 2019 11:44:42 +0100 Subject: [CMake] PIE-pie_off and CMP0083-cmp0083_new fail for openSuse Leap 15.0 In-Reply-To: References: Message-ID: <5fbe08bf-ff50-768f-5621-f5d2c961a833@grueninger.de> Hi Alan, thanks for you answer. Do you know how the open build service works? It sets up a fresh installation for each (openSuse) platform. Then CMake's sources are deflated, configure is called and the package is build, installed, tested and then packaged. So no other CMake version is involved beside CMake 3.14. So both good and bad platforms are from the same CMake source. They only differ in the versions of GCC, make, and so on. In the meantime I got some input from the openSuse community, indicating that Leap 15.0's GCC discrespects the pie/no-pie switch, cf. http://paste.opensuse.org/14067189 If an openSuse bug is confirmen, I let you know. Bye Christoph Am 20.03.19 um 02:21 schrieb Alan W. Irwin: > > Hi Christoph: > > Just in case the trouble is simply due to a real CMake bug for some > old version of CMake, what exact versions of CMake are you testing on > each of your various "good" platforms compared to your "bad" platform, > openSuse Leap 15.0? > > Alan > __________________________ > Alan W. Irwin -- Unfortunately, plots are notoriously hard to get right. Partly, the default settings of programs like gnuplot or Excel are to blame for this since these programs make it very convenient to create bad plots. -- Till Tantau, "The TikZ and PGF Packages" From marc.chevrier at gmail.com Wed Mar 20 07:27:31 2019 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Wed, 20 Mar 2019 12:27:31 +0100 Subject: [CMake] PIE-pie_off and CMP0083-cmp0083_new fail for openSuse Leap 15.0 In-Reply-To: <5fbe08bf-ff50-768f-5621-f5d2c961a833@grueninger.de> References: <5fbe08bf-ff50-768f-5621-f5d2c961a833@grueninger.de> Message-ID: <159be90a-220e-49f5-a6e2-985292904e48@Spark> clearly, from what shown on http://paste.opensuse.org/14067189, c++ compiler from OpenSuse Leap is buggy. Expected output from readelf for executable tests_1 is ? Elf file type is EXEC (Executable file)?? which is not the case. Option -no-pie is not taken into account. This explains the failures for some PIE tests. Le 20 mars 2019 ? 11:44 +0100, Christoph Gr?ninger , a ?crit : > Hi Alan, > thanks for you answer. Do you know how the open build service works? It > sets up a fresh installation for each (openSuse) platform. Then CMake's > sources are deflated, configure is called and the package is build, > installed, tested and then packaged. So no other CMake version is > involved beside CMake 3.14. So both good and bad platforms are from the > same CMake source. They only differ in the versions of GCC, make, and so on. > > In the meantime I got some input from the openSuse community, indicating > that Leap 15.0's GCC discrespects the pie/no-pie switch, cf. > http://paste.opensuse.org/14067189 > If an openSuse bug is confirmen, I let you know. > > Bye > Christoph > > > Am 20.03.19 um 02:21 schrieb Alan W. Irwin: > > > > Hi Christoph: > > > > Just in case the trouble is simply due to a real CMake bug for some > > old version of CMake, what exact versions of CMake are you testing on > > each of your various "good" platforms compared to your "bad" platform, > > openSuse Leap 15.0? > > > > Alan > > __________________________ > > Alan W. Irwin > > -- > Unfortunately, plots are notoriously hard to get right. Partly, the > default settings of programs like gnuplot or Excel are to blame for > this since these programs make it very convenient to create bad plots. > -- Till Tantau, "The TikZ and PGF Packages" > -- > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From foss at grueninger.de Wed Mar 20 11:01:35 2019 From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=c3=bcninger?=) Date: Wed, 20 Mar 2019 16:01:35 +0100 Subject: [CMake] PIE-pie_off and CMP0083-cmp0083_new fail for openSuse Leap 15.0 In-Reply-To: <159be90a-220e-49f5-a6e2-985292904e48@Spark> References: <5fbe08bf-ff50-768f-5621-f5d2c961a833@grueninger.de> <159be90a-220e-49f5-a6e2-985292904e48@Spark> Message-ID: <46ced1cb-bc10-fa4c-eb76-ceb667aca81e@grueninger.de> Hi Marc, thank you for having a look. openSuse confirmed it is a bug, cf. https://bugzilla.suse.com/show_bug.cgi?id=1096008 Sorry for the noise. Good to know, that packaging CMake reveal bugs. Bye Christoph Am 20.03.19 um 12:27 schrieb Marc CHEVRIER: > clearly, from what shown on http://paste.opensuse.org/14067189, c++ > compiler from OpenSuse Leap is buggy. > Expected output from readelf for executable tests_1 is ? Elf file type > is EXEC (Executable file)?? which is not the case. Option -no-pie is not > taken into account. From calebwherry at gmail.com Wed Mar 20 16:53:24 2019 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Wed, 20 Mar 2019 16:53:24 -0400 Subject: [CMake] CMake Project Generation Speedup In-Reply-To: References: Message-ID: Did anything ever come of this? I am in a similar boat: we have >800 targets on our full build (native C++, Managed C++, C#, Java, CUDA, etc) and the majority of the time for the configure/generate steps takes place in the generate step (>70%). I understand there is a lot of IO since the generate step has to write the project files and filters for each C++ project (the majority of our projects) for VS generators (what we use). I'm just looking to see if there is anything to look at or potentially speedup up the generate step besides "get a faster drive". Thanks! -Caleb On Thu, Nov 17, 2016 at 11:15 AM Damian wrote: > Hi all, > > We are still in the process of switching our large Make-based build to > CMake. One of the issues we're running into is the time it takes to reparse > and regenerate the CMake project (whether ninja, VS, or make) after > touching any CMake file. To give you an idea, we have about 1000 targets > and that takes a good 2 min for CMake to rerun. > > Are there any plans to speed this up? Maybe parallelize it in some way or > do a better job regenerating only what needs regenerating? Is there > anything we can do on our side to reduce our regeneration times? > > For example, if using a VS generator, each directory in the source that > has a CMakeLists.txt gets a .vcproj and .sln generated. Ideally, if I touch > one of those CMakeLists.txt, only that .sln/.vcproj would get regenerated. > > Thanks for any help. > -- > > 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 -- J. Caleb Wherry *Scientific Software Engineer* http://www.calebwherry.com +1 (615) 708-5651 calebwherry at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From calebwherry at gmail.com Wed Mar 20 16:57:11 2019 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Wed, 20 Mar 2019 16:57:11 -0400 Subject: [CMake] CMake Project Generation Speedup In-Reply-To: References: Message-ID: I was also surprised when "cmake --trace" gave 0 information related to the generate step. I assume this is expected behavior? Oh and: CMake: 3.13.4 Visual Studio 2017 15.9.9 Win7 -Caleb On Wed, Mar 20, 2019 at 4:53 PM J. Caleb Wherry wrote: > Did anything ever come of this? > > I am in a similar boat: we have >800 targets on our full build (native > C++, Managed C++, C#, Java, CUDA, etc) and the majority of the time for the > configure/generate steps takes place in the generate step (>70%). > > I understand there is a lot of IO since the generate step has to write the > project files and filters for each C++ project (the majority of our > projects) for VS generators (what we use). I'm just looking to see if there > is anything to look at or potentially speedup up the generate step besides > "get a faster drive". > > Thanks! > -Caleb > > On Thu, Nov 17, 2016 at 11:15 AM Damian wrote: > >> Hi all, >> >> We are still in the process of switching our large Make-based build to >> CMake. One of the issues we're running into is the time it takes to reparse >> and regenerate the CMake project (whether ninja, VS, or make) after >> touching any CMake file. To give you an idea, we have about 1000 targets >> and that takes a good 2 min for CMake to rerun. >> >> Are there any plans to speed this up? Maybe parallelize it in some way or >> do a better job regenerating only what needs regenerating? Is there >> anything we can do on our side to reduce our regeneration times? >> >> For example, if using a VS generator, each directory in the source that >> has a CMakeLists.txt gets a .vcproj and .sln generated. Ideally, if I touch >> one of those CMakeLists.txt, only that .sln/.vcproj would get regenerated. >> >> Thanks for any help. >> -- >> >> 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 > > > > -- > J. Caleb Wherry > *Scientific Software Engineer* > > > http://www.calebwherry.com > +1 (615) 708-5651 > calebwherry at gmail.com > -- J. Caleb Wherry *Scientific Software Engineer* http://www.calebwherry.com +1 (615) 708-5651 calebwherry at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Wed Mar 20 17:02:28 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Wed, 20 Mar 2019 17:02:28 -0400 Subject: [CMake] CMake Project Generation Speedup In-Reply-To: References: Message-ID: <1553115748.2839.0.camel@kitware.com> On Wed, 2019-03-20 at 16:57 -0400, J. Caleb Wherry wrote: > I was also surprised when "cmake --trace" gave 0 information related > to the generate step. I assume this is expected behavior? The purpose of --trace is to debug CMake scripts. No scripts get run during the generate step, so yes, this is expected. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From tachoknight at gmail.com Wed Mar 20 17:45:39 2019 From: tachoknight at gmail.com (Ron Olson) Date: Wed, 20 Mar 2019 16:45:39 -0500 Subject: [CMake] Strange issue with 3.14.0 and copying files Message-ID: <6E152B5B-0A36-4CBA-98F4-19892F06BABC@gmail.com> Hi all- As a way of introduction, I?m Ron, and I maintain Apple?s Swift programming language package for Fedora. I?ve been tracking down a build failure and I came across a weird issue using 3.14.0 that doesn?t seem to be a problem on 3.12.1. If you copy a file to the same location, it overwrites it with a zero byte file: [rolson at testn temp]$ cmake --version cmake version 3.14.0 CMake suite maintained and supported by Kitware (kitware.com/cmake). [rolson at testn temp]$ echo "hello world" > foo.txt [rolson at testn temp]$ ls -lah total 8.0K drwxrwxr-x. 2 rolson rolson 21 Mar 20 16:39 . drwx------. 9 rolson rolson 4.0K Mar 20 16:22 .. -rw-rw-r--. 1 rolson rolson 12 Mar 20 16:39 foo.txt [rolson at testn temp]$ cmake -E copy foo.txt . [rolson at testn temp]$ ls -lah total 4.0K drwxrwxr-x. 2 rolson rolson 21 Mar 20 16:39 . drwx------. 9 rolson rolson 4.0K Mar 20 16:22 .. -rw-rw-r--. 1 rolson rolson 0 Mar 20 16:39 foo.txt I haven?t been able to find any documentation about whether this is expected behavior or not; under 3.12.1 the result would be foo.txt would remain untouched. If it?s a bug, I?ll file a report, but wanted to make sure it is before I do so. Ron From kuba at mareimbrium.org Thu Mar 21 00:10:36 2019 From: kuba at mareimbrium.org (Kuba Ober) Date: Thu, 21 Mar 2019 00:10:36 -0400 Subject: [CMake] CMake Project Generation Speedup In-Reply-To: References: Message-ID: <51184E18-F25D-4A9C-A67F-A8CE7A73E1E6@mareimbrium.org> The best advice I had for myself: profile the code and tweak it. The last I looked, and that was a while ago, the generators could use a threaded write queue so that the file output would overlap with file generation. Those probably could be memory mapped files, too, to further minimize the overhead: writing to mapped pages that are dumped to disk via DMA (that?s how page flushes work) is cheaper than copying all the data in little chunks into a small buffer in the file output code, and then once again into the page that ends up flushed to disk. Never mind that the write latencies are on the hot path, where they don?t belong. If generators could be const-correct (not writing anywhere into the Makefile data structures), they could all be parallelized as well ? but I?m not sure whether that?s a minor hack or a major rework. Cheers, Kuba > 20 mars 2019 kl. 16:53 skrev J. Caleb Wherry : > > Did anything ever come of this? > > I am in a similar boat: we have >800 targets on our full build (native C++, Managed C++, C#, Java, CUDA, etc) and the majority of the time for the configure/generate steps takes place in the generate step (>70%). > > I understand there is a lot of IO since the generate step has to write the project files and filters for each C++ project (the majority of our projects) for VS generators (what we use). I'm just looking to see if there is anything to look at or potentially speedup up the generate step besides "get a faster drive". > > Thanks! > -Caleb > >> On Thu, Nov 17, 2016 at 11:15 AM Damian wrote: >> Hi all, >> >> We are still in the process of switching our large Make-based build to CMake. One of the issues we're running into is the time it takes to reparse and regenerate the CMake project (whether ninja, VS, or make) after touching any CMake file. To give you an idea, we have about 1000 targets and that takes a good 2 min for CMake to rerun. >> >> Are there any plans to speed this up? Maybe parallelize it in some way or do a better job regenerating only what needs regenerating? Is there anything we can do on our side to reduce our regeneration times? >> >> For example, if using a VS generator, each directory in the source that has a CMakeLists.txt gets a .vcproj and .sln generated. Ideally, if I touch one of those CMakeLists.txt, only that .sln/.vcproj would get regenerated. >> >> Thanks for any help. >> -- >> >> 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 > > > -- > J. Caleb Wherry > Scientific Software Engineer > > http://www.calebwherry.com > +1 (615) 708-5651 > calebwherry at 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, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Thu Mar 21 04:41:48 2019 From: gjasny at googlemail.com (Gregor Jasny) Date: Thu, 21 Mar 2019 09:41:48 +0100 Subject: [CMake] CMake Project Generation Speedup In-Reply-To: References: Message-ID: <690a9a33-68d0-b7e2-eecd-03476c171ce1@googlemail.com> Hello, On 17.11.16 17:15, Damian wrote: > We are still in the process of switching our large Make-based build to > CMake. One of the issues we're running into is the time it takes to > reparse and regenerate the CMake project (whether ninja, VS, or make) > after touching any CMake file. To give you an idea, we have about 1000 > targets and that takes a good 2 min for CMake to rerun. > > Are there any plans to speed this up? CMake VisualStudio and Xcode generator generates one solution / xcodeproj per project() commmand. Due to the shared vcxproj files this is not too expensive for Visual Studio. But for Xcode it is. You can disable that behavior by specifying -DCMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY=ON on the command line. Thanks, -Gregor From cristian.adam at gmail.com Thu Mar 21 06:16:37 2019 From: cristian.adam at gmail.com (Cristian Adam) Date: Thu, 21 Mar 2019 11:16:37 +0100 Subject: [CMake] CMake Project Generation Speedup In-Reply-To: References: Message-ID: Hi, CMake has for Visual Studio is a multi configuration generator. (Debug, Release, RelMinSize, RelWithDbgInformation). If you specify only one configuration you should cut the generation time to 1/4th. See https://cmake.org/cmake/help/latest/variable/CMAKE_CONFIGURATION_TYPES.html#variable:CMAKE_CONFIGURATION_TYPES Cheers, Cristian On Wed, Mar 20, 2019, 21:53 J. Caleb Wherry wrote: > Did anything ever come of this? > > I am in a similar boat: we have >800 targets on our full build (native > C++, Managed C++, C#, Java, CUDA, etc) and the majority of the time for the > configure/generate steps takes place in the generate step (>70%). > > I understand there is a lot of IO since the generate step has to write the > project files and filters for each C++ project (the majority of our > projects) for VS generators (what we use). I'm just looking to see if there > is anything to look at or potentially speedup up the generate step besides > "get a faster drive". > > Thanks! > -Caleb > > On Thu, Nov 17, 2016 at 11:15 AM Damian wrote: > >> Hi all, >> >> We are still in the process of switching our large Make-based build to >> CMake. One of the issues we're running into is the time it takes to reparse >> and regenerate the CMake project (whether ninja, VS, or make) after >> touching any CMake file. To give you an idea, we have about 1000 targets >> and that takes a good 2 min for CMake to rerun. >> >> Are there any plans to speed this up? Maybe parallelize it in some way or >> do a better job regenerating only what needs regenerating? Is there >> anything we can do on our side to reduce our regeneration times? >> >> For example, if using a VS generator, each directory in the source that >> has a CMakeLists.txt gets a .vcproj and .sln generated. Ideally, if I touch >> one of those CMakeLists.txt, only that .sln/.vcproj would get regenerated. >> >> Thanks for any help. >> -- >> >> 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 > > > > -- > J. Caleb Wherry > *Scientific Software Engineer* > > > http://www.calebwherry.com > +1 (615) 708-5651 > calebwherry at 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, 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Mar 21 20:38:23 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 21 Mar 2019 17:38:23 -0700 Subject: [CMake] CMake Project Generation Speedup In-Reply-To: References: Message-ID: A round of performance improvements to generate time was done as part of CMake 3.11 and that significantly helped. What would be helpful is a performance analysis run of CMake itself to determine if the issue is that we are IO bound ( and need to do multi-threaded writes ) or compute bound. While this information will be project dependent, it would be great to start getting samples from the community. On Wed, Mar 20, 2019 at 1:53 PM J. Caleb Wherry wrote: > > Did anything ever come of this? > > I am in a similar boat: we have >800 targets on our full build (native C++, Managed C++, C#, Java, CUDA, etc) and the majority of the time for the configure/generate steps takes place in the generate step (>70%). > > I understand there is a lot of IO since the generate step has to write the project files and filters for each C++ project (the majority of our projects) for VS generators (what we use). I'm just looking to see if there is anything to look at or potentially speedup up the generate step besides "get a faster drive". > > Thanks! > -Caleb > > On Thu, Nov 17, 2016 at 11:15 AM Damian wrote: >> >> Hi all, >> >> We are still in the process of switching our large Make-based build to CMake. One of the issues we're running into is the time it takes to reparse and regenerate the CMake project (whether ninja, VS, or make) after touching any CMake file. To give you an idea, we have about 1000 targets and that takes a good 2 min for CMake to rerun. >> >> Are there any plans to speed this up? Maybe parallelize it in some way or do a better job regenerating only what needs regenerating? Is there anything we can do on our side to reduce our regeneration times? >> >> For example, if using a VS generator, each directory in the source that has a CMakeLists.txt gets a .vcproj and .sln generated. Ideally, if I touch one of those CMakeLists.txt, only that .sln/.vcproj would get regenerated. >> >> Thanks for any help. >> -- >> >> 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 > > > > -- > J. Caleb Wherry > Scientific Software Engineer > > http://www.calebwherry.com > +1 (615) 708-5651 > calebwherry at 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, 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 From Steven.Cook at riotinto.com Thu Mar 21 23:17:22 2019 From: Steven.Cook at riotinto.com (Cook, Steven (G&I)) Date: Fri, 22 Mar 2019 03:17:22 +0000 Subject: [CMake] CPack/WiX shortcuts with custom arguments Message-ID: Hi, I'm attempting to transition from NSIS to WiX for our Windows installer and have been unable to find a way to create customised shortcuts with WiX (I would like to specify both the working directory and command line parameters). Some approaches I've tried are: * Specifying CPACK_PACKAGE_EXECUTABLES, and then using CPACK_WIX_PATCH_FILE to modify the shortcut. This approach doesn't work because the patching mechanism can only add new XML tags; it is unable to add or modify properties on existing tags. * Creating the shortcut myself via CPACK_WIX_EXTRA_SOURCES. This doesn't work because PROGRAM_MENU_FOLDER is not defined in directories.wxs unless cpack is creating shortcuts itself. And I can't define this directory myself because the patching mechanism doesn't allow modifications to the top level TARGETDIR directory. Ideas of things that might work but which are not ideal: * Create an unwanted shortcut with cpack and then define my own shortcuts with CPACK_WIX_EXTRA_SOURCES. But then there is an unwanted shortcut. * Create separate .bat files for each start menu item so that working directory and command line parameters are not required. Is there anything else I can try? Thanks Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Stewart at sig.com Fri Mar 22 06:55:27 2019 From: Robert.Stewart at sig.com (Stewart, Robert) Date: Fri, 22 Mar 2019 10:55:27 +0000 Subject: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS In-Reply-To: <31b0896761334faaa4f671e599e45ee9@msx.bala.susq.com> References: <31b0896761334faaa4f671e599e45ee9@msx.bala.susq.com> Message-ID: <61fb24ca2f11449a9341a9dfd20d2118@msx.bala.susq.com> On Wednesday, March 06, 2019 3:33 PM, I wrote: > > We've recently upgraded CMake from 2.8+ to 3.5+ (different versions on different platforms). In > so doing, our CMake invocation of CPack to create RPMs now fails and I'm hoping someone can help. > I have a spec file and I want to run rpmbuild -bb, but I can't figure out how to do it. > > We have been using a custom spec file all along, but I found information indicating that doing so > is (now?) considered a hack and that everything should be possible merely by setting CPACK_* > variables. Unfortunately, that's not the case. With the following %files entries, CPackRPM.cmake > chokes: > > %defattr(-, %{user}, %{group}, 0755) > %dir %{destination} > %dir %{versioned} > %dir %{foo} > %{foo}/*.sh > %attr(555, %{user}, %{group}) %{foo}/a > %dir %{bar} > %attr(544, %{user}, %{group}) %{bar}/b > %attr(444, %{user}, %{group}) %{bar}/*common > %{bar}/lib > > The result is that my attempt to port to the all-variable approach failed, so I'm setting > CPACK_RPM_USER_BINARY_SPECFILE to refer to my spec file as before. Unfortunately, when I do so, > CPackRPM.cmake doesn't set RPMBUILD_FLAGS, and that leads to rpmbuild doing nothing useful. The > issue is in the following code: > > # We should generate a USER spec file template: > # - either because the user asked for it : CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE > # - or the user did not provide one : NOT CPACK_RPM_USER_BINARY_SPECFILE > if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT CPACK_RPM_USER_BINARY_SPECFILE) > set(RPMBUILD_FLAGS "-bb") > > I tried just setting RPMBUILD_FLAGS to -bb in my CMakeLists.txt, where I include CPack, but that > isn't propagated to CPackRPM.cmake. I tried adding a custom target that invoked > "${CMAKE_CPACK_COMMAND} -D RPMBUILD_FLAGS=-bb", but that didn't work either. > > If the regex processing of the %files content were more robust, I wouldn't trip over the > RPMBUILD_FLAGS issue, but either CPACK_RPM_USER_BINARY_SPECFILE is supported or it isn't, and > since it is currently, it should be possible for me to set RPMBUILD_FLAGS. > > Ideas? Anyone? ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Mar 22 07:43:44 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 22 Mar 2019 12:43:44 +0100 Subject: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS In-Reply-To: <31b0896761334faaa4f671e599e45ee9@msx.bala.susq.com> References: <31b0896761334faaa4f671e599e45ee9@msx.bala.susq.com> Message-ID: Le mer. 6 mars 2019 ? 21:33, Stewart, Robert a ?crit : > We've recently upgraded CMake from 2.8+ to 3.5+ (different versions on > different platforms). In so doing, our CMake invocation of CPack to create > RPMs now fails and I'm hoping someone can help. I have a spec file and I > want to run rpmbuild -bb, but I can't figure out how to do it. > > We have been using a custom spec file all along, but I found information > indicating that doing so is (now?) considered a hack and that everything > should be possible merely by setting CPACK_* variables. Unfortunately, > that's not the case. Which CPACK_xxx variables did you use? CPACK_RPM_SPEC_MORE_DEFINE ? CPACK_RPM_USER_FILELIST ? > With the following %files entries, CPackRPM.cmake chokes: > > %defattr(-, %{user}, %{group}, 0755) > %dir %{destination} > %dir %{versioned} > %dir %{foo} > %{foo}/*.sh > %attr(555, %{user}, %{group}) %{foo}/a > %dir %{bar} > %attr(544, %{user}, %{group}) %{bar}/b > %attr(444, %{user}, %{group}) %{bar}/*common > %{bar}/lib > > The result is that my attempt to port to the all-variable approach failed, > so I'm setting CPACK_RPM_USER_BINARY_SPECFILE to refer to my spec file as > before. Unfortunately, when I do so, CPackRPM.cmake doesn't set > RPMBUILD_FLAGS, and that leads to rpmbuild doing nothing useful. The issue > is in the following code: > > # We should generate a USER spec file template: > # - either because the user asked for it : > CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE > # - or the user did not provide one : NOT > CPACK_RPM_USER_BINARY_SPECFILE > if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT > CPACK_RPM_USER_BINARY_SPECFILE) > set(RPMBUILD_FLAGS "-bb") > > I tried just setting RPMBUILD_FLAGS to -bb in my CMakeLists.txt, where I > include CPack, but that isn't propagated to CPackRPM.cmake. I tried adding > a custom target that invoked "${CMAKE_CPACK_COMMAND} -D > RPMBUILD_FLAGS=-bb", but that didn't work either. > You cannot add flags meant to be used at CPack time in your CMakeLists.txt because CMakeLists.txt is read when *cmake* runs not when *cpack* runs. See: https://github.com/dev-cafe/cmake-cookbook/tree/master/figures/cmake-times for the description of various times However you can use https://cmake.org/cmake/help/v3.12/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE for that purpose. If you specify (in your CMakeLists.txt) the name of a file as set(CPACK_PROJECT_CONFIG_FILE ${CMAKE_CURRENT_BINARY}/mycpack_config.cmake) then the 'mycpack_config.cmake' will be processed by CPack when it runs. You can find an example usage here: http://git.savannah.nongnu.org/cgit/certi.git/tree/CMakeLists.txt#n621 in this case the CERTICPackOptions.cmake.in (in the source tree) is first configure to CERTICPackOptions.cmake (in the build tree) then SET(CPACK_PROJECT_CONFIG_FILE "${CERTI_BINARY_DIR}/CERTICPackOptions.cmake") indicate that CPack should use it at "CPack-time". The process describing how "CPACK_PROJECT_CONFIG_FILE" is used is described at the beginning of : https://cmake.org/cmake/help/v3.12/module/CPack.html If the regex processing of the %files content were more robust, I wouldn't > trip over the RPMBUILD_FLAGS issue, Then may be you can file a patch for making those more robust? > but either CPACK_RPM_USER_BINARY_SPECFILE is supported or it isn't, and > since it is currently, it should be possible for me to set RPMBUILD_FLAGS. > > Ideas? 1) Use CPACK_RPM_USER_BINARY_SPECFILE and CPACK_PROJECT_CONFIG_FILE. 2) propose a patch for -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Mar 22 07:56:42 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 22 Mar 2019 12:56:42 +0100 Subject: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS In-Reply-To: <31b0896761334faaa4f671e599e45ee9@msx.bala.susq.com> References: <31b0896761334faaa4f671e599e45ee9@msx.bala.susq.com> Message-ID: Le mer. 6 mars 2019 ? 21:33, Stewart, Robert a ?crit : > We've recently upgraded CMake from 2.8+ to 3.5+ (different versions on > different platforms). In so doing, our CMake invocation of CPack to create > RPMs now fails and I'm hoping someone can help. I have a spec file and I > want to run rpmbuild -bb, but I can't figure out how to do it. > > > > The result is that my attempt to port to the all-variable approach failed, > so I'm setting CPACK_RPM_USER_BINARY_SPECFILE to refer to my spec file as > before. Unfortunately, when I do so, CPackRPM.cmake doesn't set > RPMBUILD_FLAGS, and that leads to rpmbuild doing nothing useful. The issue > is in the following code: > > # We should generate a USER spec file template: > # - either because the user asked for it : > CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE > # - or the user did not provide one : NOT > CPACK_RPM_USER_BINARY_SPECFILE > if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT > CPACK_RPM_USER_BINARY_SPECFILE) > set(RPMBUILD_FLAGS "-bb") > I missed that. Do you mean that even though you set(CPACK_RPM_USER_BINARY_SPECFILE /xxxx) CPackRPM does not process the spec file with rpmbuild -bb ? AFAIU from the source: "-bb" flags are always setup when binary RPM is built. https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Internal/CPack/CPackRPM.cmake#L1658 I am confused. Could restate the problem. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.wuttke at fz-juelich.de Fri Mar 22 09:53:26 2019 From: j.wuttke at fz-juelich.de (Joachim Wuttke) Date: Fri, 22 Mar 2019 14:53:26 +0100 Subject: [CMake] conflict between configure & build steps in gitlab-runner script for Windows: Debug or Release build directory not found Message-ID: A gitlab-runner configuration script .gitlab-ci.yml, for execution in the Powershell: === windows: tags: - windows stage: build script: - New-Item -ItemType "directory" -Confirm:$false -Force:$true -Name "build" - cd build - cmd.exe "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat" - cmake -G "Visual Studio 15 2017" -A x64 -T host=x64 -DCERF_CPP=ON -DLIB_MAN=OFF -DLIB_INSTALL=OFF -B. .. - cmake -j8 --build . --config Debug - ctest -j4 === results in === $ cd build $ cmd.exe "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat" Microsoft Windows [Version 10.0.17134.648] (c) 2018 Microsoft Corporation. All rights reserved. C:\gitlab-runner\builds\s-nngMTK\0\mlz\libcerf\build>$ cmake -G "Visual Studio 15 2017" -A x64 -T host=x64 -DCERF_CPP=ON -DLIB_MAN=OFF -DLIB_INSTALL=OFF -B. .. -- The CXX compiler identification is MSVC 19.16.27026.1 -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done Build C++ library libcerfcpp -- libcerf/lib: build library cerfcpp, CERF_CPP=ON, shared=ON -- Configuring done -- Generating done -- Build files have been written to: C:/gitlab-runner/builds/xxxxxxxx/libcerf/build $ cmake -j8 --build . --config Debug CMake Error: The source directory "C:/gitlab-runner/builds/xxxxxxxx/libcerf/build/Debug" does not exist. Specify --help for usage, or press the help button on the CMake GUI. ERROR: Job failed: exit status 1 === How to resolve this conflict between the configure step (cmake) and the build step (cmake --build)? The latter won't work without the option "--config Debug"; but if that option is given, then it looks for a nonexistent directory. The same problem occurs with "--config Release". /Joachim -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5110 bytes Desc: S/MIME Cryptographic Signature URL: From robert.maynard at kitware.com Fri Mar 22 11:34:47 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 22 Mar 2019 08:34:47 -0700 Subject: [CMake] Strange issue with 3.14.0 and copying files In-Reply-To: <6E152B5B-0A36-4CBA-98F4-19892F06BABC@gmail.com> References: <6E152B5B-0A36-4CBA-98F4-19892F06BABC@gmail.com> Message-ID: Just as a follow-up for the general community, this is a bug and can be tracked at: https://gitlab.kitware.com/cmake/cmake/issues/19075 On Wed, Mar 20, 2019 at 2:46 PM Ron Olson wrote: > > Hi all- > > As a way of introduction, I?m Ron, and I maintain Apple?s Swift > programming language package for Fedora. I?ve been tracking down a > build failure and I came across a weird issue using 3.14.0 that > doesn?t seem to be a problem on 3.12.1. If you copy a file to the same > location, it overwrites it with a zero byte file: > > [rolson at testn temp]$ cmake --version > cmake version 3.14.0 > > CMake suite maintained and supported by Kitware (kitware.com/cmake). > > [rolson at testn temp]$ echo "hello world" > foo.txt > > [rolson at testn temp]$ ls -lah > total 8.0K > drwxrwxr-x. 2 rolson rolson 21 Mar 20 16:39 . > drwx------. 9 rolson rolson 4.0K Mar 20 16:22 .. > -rw-rw-r--. 1 rolson rolson 12 Mar 20 16:39 foo.txt > > [rolson at testn temp]$ cmake -E copy foo.txt . > > [rolson at testn temp]$ ls -lah > total 4.0K > drwxrwxr-x. 2 rolson rolson 21 Mar 20 16:39 . > drwx------. 9 rolson rolson 4.0K Mar 20 16:22 .. > -rw-rw-r--. 1 rolson rolson 0 Mar 20 16:39 foo.txt > > I haven?t been able to find any documentation about whether this is > expected behavior or not; under 3.12.1 the result would be foo.txt would > remain untouched. > > If it?s a bug, I?ll file a report, but wanted to make sure it is > before I do so. > > Ron > > > > > > > > -- > > 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 From Robert.Stewart at sig.com Fri Mar 22 13:27:20 2019 From: Robert.Stewart at sig.com (Stewart, Robert) Date: Fri, 22 Mar 2019 17:27:20 +0000 Subject: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS In-Reply-To: References: <31b0896761334faaa4f671e599e45ee9@msx.bala.susq.com> Message-ID: <44930433d14a4b6a95c6d4643857f872@msx.bala.susq.com> I?m pretty certain that I did use CPACK_RPM_SPEC_MORE_DEFINE and CPACK_RPM_USER_FILELIST. CPACK_PROJECT_CONFIG_FILE might help. I?ll take a look. As for proposing a patch, I?m not certain how things are supposed to work yet, so that seems premature. Thanks for your thoughts. ___ Rob From: Eric Noulard [mailto:eric.noulard at gmail.com] Sent: Friday, March 22, 2019 7:44 AM To: Stewart, Robert Cc: cmake at cmake.org Subject: Re: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS Le mer. 6 mars 2019 ? 21:33, Stewart, Robert > a ?crit : We've recently upgraded CMake from 2.8+ to 3.5+ (different versions on different platforms). In so doing, our CMake invocation of CPack to create RPMs now fails and I'm hoping someone can help. I have a spec file and I want to run rpmbuild -bb, but I can't figure out how to do it. We have been using a custom spec file all along, but I found information indicating that doing so is (now?) considered a hack and that everything should be possible merely by setting CPACK_* variables. Unfortunately, that's not the case. Which CPACK_xxx variables did you use? CPACK_RPM_SPEC_MORE_DEFINE ? CPACK_RPM_USER_FILELIST ? With the following %files entries, CPackRPM.cmake chokes: %defattr(-, %{user}, %{group}, 0755) %dir %{destination} %dir %{versioned} %dir %{foo} %{foo}/*.sh %attr(555, %{user}, %{group}) %{foo}/a %dir %{bar} %attr(544, %{user}, %{group}) %{bar}/b %attr(444, %{user}, %{group}) %{bar}/*common %{bar}/lib The result is that my attempt to port to the all-variable approach failed, so I'm setting CPACK_RPM_USER_BINARY_SPECFILE to refer to my spec file as before. Unfortunately, when I do so, CPackRPM.cmake doesn't set RPMBUILD_FLAGS, and that leads to rpmbuild doing nothing useful. The issue is in the following code: # We should generate a USER spec file template: # - either because the user asked for it : CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE # - or the user did not provide one : NOT CPACK_RPM_USER_BINARY_SPECFILE if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT CPACK_RPM_USER_BINARY_SPECFILE) set(RPMBUILD_FLAGS "-bb") I tried just setting RPMBUILD_FLAGS to -bb in my CMakeLists.txt, where I include CPack, but that isn't propagated to CPackRPM.cmake. I tried adding a custom target that invoked "${CMAKE_CPACK_COMMAND} -D RPMBUILD_FLAGS=-bb", but that didn't work either. You cannot add flags meant to be used at CPack time in your CMakeLists.txt because CMakeLists.txt is read when *cmake* runs not when *cpack* runs. See: https://github.com/dev-cafe/cmake-cookbook/tree/master/figures/cmake-times for the description of various times However you can use https://cmake.org/cmake/help/v3.12/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE for that purpose. If you specify (in your CMakeLists.txt) the name of a file as set(CPACK_PROJECT_CONFIG_FILE ${CMAKE_CURRENT_BINARY}/mycpack_config.cmake) then the 'mycpack_config.cmake' will be processed by CPack when it runs. You can find an example usage here: http://git.savannah.nongnu.org/cgit/certi.git/tree/CMakeLists.txt#n621 in this case the CERTICPackOptions.cmake.in (in the source tree) is first configure to CERTICPackOptions.cmake (in the build tree) then SET(CPACK_PROJECT_CONFIG_FILE "${CERTI_BINARY_DIR}/CERTICPackOptions.cmake") indicate that CPack should use it at "CPack-time". The process describing how "CPACK_PROJECT_CONFIG_FILE" is used is described at the beginning of : https://cmake.org/cmake/help/v3.12/module/CPack.html If the regex processing of the %files content were more robust, I wouldn't trip over the RPMBUILD_FLAGS issue, Then may be you can file a patch for making those more robust? but either CPACK_RPM_USER_BINARY_SPECFILE is supported or it isn't, and since it is currently, it should be possible for me to set RPMBUILD_FLAGS. Ideas? 1) Use CPACK_RPM_USER_BINARY_SPECFILE and CPACK_PROJECT_CONFIG_FILE. 2) propose a patch for -- Eric ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Stewart at sig.com Fri Mar 22 13:30:53 2019 From: Robert.Stewart at sig.com (Stewart, Robert) Date: Fri, 22 Mar 2019 17:30:53 +0000 Subject: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS In-Reply-To: References: <31b0896761334faaa4f671e599e45ee9@msx.bala.susq.com> Message-ID: <61560e2aeebc464a9f9f610788070f1b@msx.bala.susq.com> Have a look at the code I quoted from CPackRPM.cmake: if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT CPACK_RPM_USER_BINARY_SPECFILE) set(RPMBUILD_FLAGS "-bb") If CPACK_RPM_USER_BINARY_SPECFILE is defined, then RPMBUILD_FLAGS is not set to -bb. ___ Rob From: Eric Noulard [mailto:eric.noulard at gmail.com] Sent: Friday, March 22, 2019 7:57 AM Le mer. 6 mars 2019 ? 21:33, Stewart, Robert > a ?crit : We've recently upgraded CMake from 2.8+ to 3.5+ (different versions on different platforms). In so doing, our CMake invocation of CPack to create RPMs now fails and I'm hoping someone can help. I have a spec file and I want to run rpmbuild -bb, but I can't figure out how to do it. The result is that my attempt to port to the all-variable approach failed, so I'm setting CPACK_RPM_USER_BINARY_SPECFILE to refer to my spec file as before. Unfortunately, when I do so, CPackRPM.cmake doesn't set RPMBUILD_FLAGS, and that leads to rpmbuild doing nothing useful. The issue is in the following code: # We should generate a USER spec file template: # - either because the user asked for it : CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE # - or the user did not provide one : NOT CPACK_RPM_USER_BINARY_SPECFILE if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT CPACK_RPM_USER_BINARY_SPECFILE) set(RPMBUILD_FLAGS "-bb") I missed that. Do you mean that even though you set(CPACK_RPM_USER_BINARY_SPECFILE /xxxx) CPackRPM does not process the spec file with rpmbuild -bb ? AFAIU from the source: "-bb" flags are always setup when binary RPM is built. https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Internal/CPack/CPackRPM.cmake#L1658 I am confused. Could restate the problem. -- Eric ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason.m.beach at gmail.com Fri Mar 22 22:58:08 2019 From: jason.m.beach at gmail.com (Jason Beach) Date: Fri, 22 Mar 2019 22:58:08 -0400 Subject: [CMake] Passing CMake Arguments to FetchContent Message-ID: I'm upgrading from cmake 3.5.1 and am trying to understand the new FetchContent command. So far I have: cmake_minimum_required(VERSION 3.14) project (json_test) include(FetchContent) set(JSON_BuildTests OFF) #if I try this I get a warning as it appears to be deprecated FetchContent_Declare( nlohmann_json_fc GIT_REPOSITORY https://github.com/nlohmann/json.git GIT_TAG v3.6.1 GIT_SHALLOW TRUE # CMAKE_ARGS -DJSON_BuildTests=OFF #doesn't work ) FetchContent_MakeAvailable(nlohmann_json_fc) add_executable(main src/main.cpp) target_link_libraries(main nlohmann_json::nlohmann_json) I first tried sending in the JSON_BuildTests=OFF with CMAKE_ARGS in the FetchContent_Declare command but that didn't work. On this post https://cmake.org/pipermail/cmake/2018-July/067804.html it appears this is because only the download portion of FetchContent_Declare is enabled with the intent to not do too much during configure time. How does specifying how the external project is configured fit that rationale? If I execute cmake -DJSON_BuildTests=OFF .. the argument successfully makes it through to the external project. I guess I'm trying to understand why it's ok to specify it on the command line but not permanently in the CMakeLists.txt, particularly if you have many libraries each potentially with their options that need to be configured. Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Mar 23 02:55:29 2019 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 23 Mar 2019 17:55:29 +1100 Subject: [CMake] Passing CMake Arguments to FetchContent In-Reply-To: References: Message-ID: On Sat, Mar 23, 2019 at 1:58 PM Jason Beach wrote: > I'm upgrading from cmake 3.5.1 and am trying to understand the new > FetchContent command. So far I have: > > cmake_minimum_required(VERSION 3.14) > project (json_test) > > include(FetchContent) > set(JSON_BuildTests OFF) #if I try this I get a warning as it appears to > be deprecated > > FetchContent_Declare( > nlohmann_json_fc > GIT_REPOSITORY https://github.com/nlohmann/json.git > GIT_TAG v3.6.1 > GIT_SHALLOW TRUE > # CMAKE_ARGS -DJSON_BuildTests=OFF #doesn't work > ) > FetchContent_MakeAvailable(nlohmann_json_fc) > add_executable(main src/main.cpp) > target_link_libraries(main nlohmann_json::nlohmann_json) > > > I first tried sending in the JSON_BuildTests=OFF with CMAKE_ARGS in the > FetchContent_Declare command but that didn't work. On this post > https://cmake.org/pipermail/cmake/2018-July/067804.html it appears this > is because only the download portion of FetchContent_Declare is enabled > with the intent to not do too much during configure time. How does > specifying how the external project is configured fit that rationale? If I > execute > > cmake -DJSON_BuildTests=OFF .. > > the argument successfully makes it through to the external project. I > guess I'm trying to understand why it's ok to specify it on the command > line but not permanently in the CMakeLists.txt, particularly if you have > many libraries each potentially with their options that need to be > configured. > The warning you are getting is due to the behavior of the option() command, which was changed in CMake 3.13. The first time you run CMake, the JSON_BuildTests variable is not in the cache. With CMake 3.12 and earlier, the option command will then ignore any non-cache variable of the same name and set the cache variable to the default value. This has the side-effect of also removing/updating the local variable, which means any non-cache variable you set before the call to option() will have no effect the first time you run CMake, but then it WILL have an effect for subsequent runs. This is unintuitive and easy to miss. In CMake 3.13, the behavior was changed to not create a cache variable if there was already a non-cache variable set. This is intuitively what developers typically expect, but it is only done if the CMP0077 policy is set to new. Inside the nlohmann/json project's CMakeLists.txt file, it uses cmake_minimum_required(VERSION 3.1), which means the CMP0077 policy is not set to NEW, hence the warning you are seeing. To prevent this problem in your case, you will need to set JSON_BuildTests as a cache variable in your example project rather than just a regular non-cache variable. Then the option() command in the nlohmann/json project sees that the cache variable has already been set and it does nothing instead of forcing it to have the default value on the first run. I typically handle this situation in my projects by setting such variables to an INTERNAL type where the main project is forcing the value and it won't be available to the developer to change (so you don't want to show it to them in the GUI, etc.). If you still want the developer to be able to override it, just put an option command with your own preferred default here instead. For your case, the modified example would be the following: cmake_minimum_required(VERSION 3.14) project (json_test) include(FetchContent) set(JSON_BuildTests OFF CACHE INTERNAL "") # Forces the value #option(JSON_BuildTests "" OFF) # Different default, but dev can still change it FetchContent_Declare( nlohmann_json_fc GIT_REPOSITORY https://github.com/nlohmann/json.git GIT_TAG v3.6.1 GIT_SHALLOW TRUE ) FetchContent_MakeAvailable(nlohmann_json_fc) add_executable(main src/main.cpp) target_link_libraries(main nlohmann_json::nlohmann_json) -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sat Mar 23 04:17:37 2019 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 23 Mar 2019 19:17:37 +1100 Subject: [CMake] conflict between configure & build steps in gitlab-runner script for Windows: Debug or Release build directory not found In-Reply-To: References: Message-ID: You have put -j8 before the --build option, but the --build option must be the first one. This ordering requirement is stated in the docs for the --build option in the "Build A Project" section. On Sat, Mar 23, 2019 at 1:00 AM Joachim Wuttke wrote: > A gitlab-runner configuration script .gitlab-ci.yml, for execution in the > Powershell: > > === > windows: > tags: > - windows > stage: build > script: > - New-Item -ItemType "directory" -Confirm:$false -Force:$true -Name > "build" > - cd build > - cmd.exe "C:\Program Files (x86)\Microsoft Visual > Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat" > - cmake -G "Visual Studio 15 2017" -A x64 -T host=x64 -DCERF_CPP=ON > -DLIB_MAN=OFF -DLIB_INSTALL=OFF -B. .. > - cmake -j8 --build . --config Debug > - ctest -j4 > === > > results in > > === > $ cd build > $ cmd.exe "C:\Program Files (x86)\Microsoft Visual > Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat" > Microsoft Windows [Version 10.0.17134.648] > (c) 2018 Microsoft Corporation. All rights reserved. > > C:\gitlab-runner\builds\s-nngMTK\0\mlz\libcerf\build>$ cmake -G "Visual > Studio 15 2017" -A x64 -T host=x64 -DCERF_CPP=ON -DLIB_MAN=OFF > -DLIB_INSTALL=OFF -B. .. > -- The CXX compiler identification is MSVC 19.16.27026.1 > -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe > -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual > Studio/2017/Community/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe -- > works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > Build C++ library libcerfcpp > -- libcerf/lib: build library cerfcpp, CERF_CPP=ON, shared=ON > -- Configuring done > -- Generating done > -- Build files have been written to: > C:/gitlab-runner/builds/xxxxxxxx/libcerf/build > $ cmake -j8 --build . --config Debug > CMake Error: The source directory > "C:/gitlab-runner/builds/xxxxxxxx/libcerf/build/Debug" does not exist. > Specify --help for usage, or press the help button on the CMake GUI. > > ERROR: Job failed: exit status 1 > === > > How to resolve this conflict between the configure step (cmake) and > the build step (cmake --build)? > > The latter won't work without the option "--config Debug"; > but if that option is given, then it looks for a nonexistent directory. > > The same problem occurs with "--config Release". > > /Joachim > > > -- > > 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 > -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason.m.beach at gmail.com Sat Mar 23 22:43:04 2019 From: jason.m.beach at gmail.com (Jason Beach) Date: Sat, 23 Mar 2019 22:43:04 -0400 Subject: [CMake] FetchContent or Export Targets Message-ID: Hi, As I've been learning CMake, it seems the best practice for a library is for it to export the targets it creates. There is also the relatively new command FetchContent. It seems that at least in part the FetchContent command obviates the need for exporting targets. I can see that for larger more permanent libraries exporting targets is still preferred so the library can be installed once and used by multiple projects on a developers workstation without having to install it on each project. At work we're a bunch of research engineers that happen to write a lot of software-- exporting targets still seems cumbersome and it seems not exporting targets and then just have users use FetchContent to pull in a library is not a bad idea. Are there other reasons /advantages of exporting targets? Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sun Mar 24 03:40:44 2019 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 24 Mar 2019 18:40:44 +1100 Subject: [CMake] FetchContent or Export Targets In-Reply-To: References: Message-ID: On Sun, Mar 24, 2019 at 1:43 PM Jason Beach wrote: > Hi, > As I've been learning CMake, it seems the best practice for a library is > for it to export the targets it creates. There is also the relatively new > command FetchContent. It seems that at least in part the FetchContent > command obviates the need for exporting targets. > > I can see that for larger more permanent libraries exporting targets is > still preferred so the library can be installed once and used by multiple > projects on a developers workstation without having to install it on each > project. > > At work we're a bunch of research engineers that happen to write a lot of > software-- exporting targets still seems cumbersome and it seems not > exporting targets and then just have users use FetchContent to pull in a > library is not a bad idea. > > Are there other reasons /advantages of exporting targets? > Exporting targets is a way to allow other projects to easily consume yours via find_package(). If you are 100% confident that no-one is ever going to use your project that way and will only ever build it from source directly (whether that be through FetchContent or some other method), then there's no benefit to exporting targets. As soon as there's a possibility that someone might want to build against an installed version of your project though, having the exported targets available makes for a significantly more convenient and more robust experience. It really comes down to whether in your case you can truly say no-one will ever want to use find_package() to bring your projects into theirs. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From dustyn at blasig.us Mon Mar 25 13:02:01 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Mon, 25 Mar 2019 12:02:01 -0500 Subject: [CMake] Parent component options passed to ExternalProject Message-ID: Hi All, I'm really struggling to use ExternalProject_Add() in our CMake project. Based on the documentation, I was expecting the simplest Git-based external project with all defaults to act just like using a Git submodule locked at a specific commit. include(ExternalProject)ExternalProject_Add(foobar GIT_REPOSITORY git at github.com:FooCo/FooBar.git GIT_TAG origin/release/1.2.3) The documentation states "The default configure command runs CMake with options based on the main project.", so I was expecting any options we pass to the owning project such as CMAKE_INSTALL_PREFIX and other variables would get propagated to the ExternalProject. However, that doesn't seem to be the case. Do I need to explicitly apply every variable through the "CMAKE_ARGS" options? If so, Also, unless I specify a custom CONFIGURE_COMMAND, I can't figure out how to make the configure step happen during the parent projects configure step. Should that be happening? If not, is there a simple way to force it to happen without having to duplicate everything the default options do? I'm seeing mixed results with online resources, along with many older examples that just don't work anymore. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Tue Mar 26 17:39:11 2019 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 27 Mar 2019 08:39:11 +1100 Subject: [CMake] Parent component options passed to ExternalProject In-Reply-To: References: Message-ID: On Tue, Mar 26, 2019 at 4:02 AM Dustyn Blasig wrote: > Hi All, > > I'm really struggling to use ExternalProject_Add() in our CMake project. > > Based on the documentation, I was expecting the simplest Git-based > external project with all defaults to act just like using a Git submodule > locked at a specific commit. > > include(ExternalProject)ExternalProject_Add(foobar GIT_REPOSITORY git at github.com:FooCo/FooBar.git GIT_TAG origin/release/1.2.3) > > The documentation states "The default configure command runs CMake with > options based on the main project.", so I was expecting any options we pass > to the owning project such as CMAKE_INSTALL_PREFIX and other variables > would get propagated to the ExternalProject. However, that doesn't seem to > be the case. Do I need to explicitly apply every variable through the > "CMAKE_ARGS" options? If so, > Some basic details are passed down to the external project, but I don't recall exactly which variables. I don't think there are a lot of them and I do tend to find that I need to pass down some vars in my own projects. You may have to dig into the ExternalProject module's source to get confirmation for yourself, possibly also look into what the external_process() command's implementation does as well. > Also, unless I specify a custom CONFIGURE_COMMAND, I can't figure out how > to make the configure step happen during the parent projects configure > step. Should that be happening? If not, is there a simple way to force it > to happen without having to duplicate everything the default options do? > I'm seeing mixed results with online resources, along with many older > examples that just don't work anymore. > The external project's configure step happens during the main project's build stage, just like every other step of ExternalProject_Add(). This will be the case whether you override the CONFIGURE_COMMAND or not. If you really need the configure step to occur during the main project's configure stage, then you have at least a couple of options: - Consider using the FetchContent module instead and bring the external project into your main build directly. If this suits your scenario, then I'd recommend this method. I use this a lot and it seems to be growing in popularity. It requires CMake 3.11 or later. - Go for a pure superbuild approach where your main project does nothing more than call various ExternalProject functions to tie together different external projects (i.e. your main project doesn't add any targets, etc. of its own). This will mean that even though the configure steps all occur during the main project's build step, you can control the dependencies between the different external projects' steps so that they can find what they need from each other (I'm guessing here that you want the external project's configure stage to run during your main project's build stage so that something later in your main project's configure stage can make use of something the external project's configure stage does). You will still have to explicitly specify a number of variables to be passed through to each external project's configure stage though, so maybe this doesn't solve the problem you are facing. -- Craig Scott Melbourne, Australia https://crascit.com Get the hand-book for every CMake user: Professional CMake: A Practical Guide -------------- next part -------------- An HTML attachment was scrubbed... URL: From badwaik.jayesh at gmail.com Tue Mar 26 22:09:14 2019 From: badwaik.jayesh at gmail.com (Jayesh Badwaik) Date: Wed, 27 Mar 2019 03:09:14 +0100 Subject: [CMake] Alternative to `add_compile_options` in Toolchain Files Message-ID: <2758153.vEts30yRdp@titan> Hi, In https://gitlab.kitware.com/cmake/cmake/issues/19074, it was mentioned that instead of `add_compile_options`, `CMAKE_CXX_FLAGS_INIT` should be used. An issue with this is that `CMAKE_CXX_FLAGS_INIT` flags are propogated to the linker as well, wherein, the linker warns about `[-Wunused-command-line- argument]` if those warnings are enabled. Is there an alternative to `CMAKE_CXX_FLAGS_INIT` which avoids these issues? Thanks -- Best Jayesh Badwaik https://jayeshbadwaik.github.io -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From cristian.adam at gmail.com Wed Mar 27 03:41:12 2019 From: cristian.adam at gmail.com (Cristian Adam) Date: Wed, 27 Mar 2019 08:41:12 +0100 Subject: [CMake] Alternative to `add_compile_options` in Toolchain Files In-Reply-To: <2758153.vEts30yRdp@titan> References: <2758153.vEts30yRdp@titan> Message-ID: Hi, If your CMake version is newer than 3.11 you can control what gets into the CMAKE__FLAGS_INIT flags with the technique from https://cristianadam.eu/20190223/modifying-the-default-cmake-build-types/ In your case you want to remove from the linker flags init the cxx compiler options. Cheers Cristian. On Wed, Mar 27, 2019, 03:10 Jayesh Badwaik wrote: > Hi, > > In https://gitlab.kitware.com/cmake/cmake/issues/19074, it was mentioned > that > instead of `add_compile_options`, `CMAKE_CXX_FLAGS_INIT` should be used. > An > issue with this is that `CMAKE_CXX_FLAGS_INIT` flags are propogated to the > linker as well, wherein, the linker warns about `[-Wunused-command-line- > argument]` if those warnings are enabled. > > Is there an alternative to `CMAKE_CXX_FLAGS_INIT` which avoids these > issues? > > Thanks > > -- > Best > Jayesh Badwaik > https://jayeshbadwaik.github.io > > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dustyn at blasig.us Wed Mar 27 13:40:01 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Wed, 27 Mar 2019 12:40:01 -0500 Subject: [CMake] Parent component options passed to ExternalProject In-Reply-To: References: Message-ID: Thanks for the help, I will give the FetchContent approach a shot and see how things go. I was actually in the process of trying to do a custom command using the built-in "cmake -E tar xvf" approach to roll a custom FetchContent that doesn't need such a new CMake, but I can't get it to work with zip files even though it seems like it should at this point. I'm hoping the fetch and include as subdirectory will be a more stable approach. On Tue, Mar 26, 2019 at 4:39 PM Craig Scott wrote: > > > On Tue, Mar 26, 2019 at 4:02 AM Dustyn Blasig wrote: > >> Hi All, >> >> I'm really struggling to use ExternalProject_Add() in our CMake project. >> >> Based on the documentation, I was expecting the simplest Git-based >> external project with all defaults to act just like using a Git submodule >> locked at a specific commit. >> >> include(ExternalProject)ExternalProject_Add(foobar GIT_REPOSITORY git at github.com:FooCo/FooBar.git GIT_TAG origin/release/1.2.3) >> >> The documentation states "The default configure command runs CMake with >> options based on the main project.", so I was expecting any options we pass >> to the owning project such as CMAKE_INSTALL_PREFIX and other variables >> would get propagated to the ExternalProject. However, that doesn't seem to >> be the case. Do I need to explicitly apply every variable through the >> "CMAKE_ARGS" options? If so, >> > > Some basic details are passed down to the external project, but I don't > recall exactly which variables. I don't think there are a lot of them and I > do tend to find that I need to pass down some vars in my own projects. You > may have to dig into the ExternalProject module's source to get > confirmation for yourself, possibly also look into what the > external_process() command's implementation does as well. > > > >> Also, unless I specify a custom CONFIGURE_COMMAND, I can't figure out how >> to make the configure step happen during the parent projects configure >> step. Should that be happening? If not, is there a simple way to force it >> to happen without having to duplicate everything the default options do? >> I'm seeing mixed results with online resources, along with many older >> examples that just don't work anymore. >> > > The external project's configure step happens during the main project's > build stage, just like every other step of ExternalProject_Add(). This will > be the case whether you override the CONFIGURE_COMMAND or not. If you > really need the configure step to occur during the main project's configure > stage, then you have at least a couple of options: > > - Consider using the FetchContent module instead and bring the > external project into your main build directly. If this suits your > scenario, then I'd recommend this method. I use this a lot and it seems to > be growing in popularity. It requires CMake 3.11 or later. > - Go for a pure superbuild approach where your main project does > nothing more than call various ExternalProject functions to tie together > different external projects (i.e. your main project doesn't add any > targets, etc. of its own). This will mean that even though the configure > steps all occur during the main project's build step, you can control the > dependencies between the different external projects' steps so that they > can find what they need from each other (I'm guessing here that you want > the external project's configure stage to run during your main project's > build stage so that something later in your main project's configure stage > can make use of something the external project's configure stage does). You > will still have to explicitly specify a number of variables to be passed > through to each external project's configure stage though, so maybe this > doesn't solve the problem you are facing. > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > > Get the hand-book for every CMake user: Professional CMake: A Practical > Guide > -------------- next part -------------- An HTML attachment was scrubbed... URL: From keller.steve at gmx.de Wed Mar 27 15:05:47 2019 From: keller.steve at gmx.de (Steve Keller) Date: Wed, 27 Mar 2019 20:05:47 +0100 Subject: [CMake] How can I automatically optionally build a submodule? In-Reply-To: References: Message-ID: "Albrecht Schlosser" wrote: > If you want yadda to be optional then don't use REQUIRED. > > find_package(yadda) > if (yadda_FOUND) > message(STATUS "found yadda, building bar ...") > > # add your code to build bar here > > endif () > > This should do what you want - unless I misunderstood your question. This will roughly do what I want, but I think it does not correctly express things. For the sub-project, yadda is not optional, and if I call cmake in that sub-project's directory, it should fail. What I think would be appropriate would be a command add_subdirectory_optional(...) or add_subdirectory_and_ignore_errors(...) or something similar. Steve From keller.steve at gmx.de Wed Mar 27 15:18:59 2019 From: keller.steve at gmx.de (Steve Keller) Date: Wed, 27 Mar 2019 20:18:59 +0100 Subject: [CMake] How can I automatically optionally build a submodule? In-Reply-To: <6ff3b6a2-5b8a-5b8f-b14f-426028a041c3@hogyros.de> References: <6ff3b6a2-5b8a-5b8f-b14f-426028a041c3@hogyros.de> Message-ID: "Simon Richter" wrote: > With my Debian Developer hat on: please also add a mechanism to manually > specify whether the optional component should be built. If the > dependency changes and suddenly a component goes missing without > triggering a build failure, that can be rather annoying for users. > > Without a package system, this also means that old files may stick > around after installation, so your program should be aware that > installed plugins could be built against an older API and weren't > updated during the last install run. I'd like to do that if I'd know how to achieve that using cmake. But I find cmake is much too large and is incapable of many things I'd expect from a build system tool. It also makes development ugly for the Unix accustomed developer, only to make things portable to Windows, which I don't want anyway. Currently, we have a shell script wrapper around cmake that does something like if [ ]; then BUILD_FOO=true else BUILD_FOO=false fi and in CMakeLists.txt set(BUILD_FOO "true" CACHE BOOL "description") ... if (BUILD_FOO) add_subdirectory(foo) endif() This is *ugly* but I don't know how to do this in cmake. Steve From Andreas-Naumann at gmx.net Wed Mar 27 15:45:30 2019 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Wed, 27 Mar 2019 20:45:30 +0100 Subject: [CMake] How can I automatically optionally build a submodule? In-Reply-To: References: Message-ID: <3f9b9d92-c560-2e09-c953-7744940c675a@gmx.net> For me, this sounds more like foo is an independent thing and not a subdirectory. In this case, I think about two solutions: ??? 1) Use a macro/function "check_yada", which sets a variable "yada_usable". If you extract this logic in an extra .cmake file, you can reuse it in your yada CMakelists.txt ??? 2) Use foo as an external project. But thats looks like a major change in the project structure. Am 27.03.19 um 20:05 schrieb Steve Keller: > "Albrecht Schlosser" wrote: > >> If you want yadda to be optional then don't use REQUIRED. >> >> find_package(yadda) >> if (yadda_FOUND) >> message(STATUS "found yadda, building bar ...") >> >> # add your code to build bar here >> >> endif () >> >> This should do what you want - unless I misunderstood your question. > This will roughly do what I want, but I think it does not correctly > express things. For the sub-project, yadda is not optional, and if I > call cmake in that sub-project's directory, it should fail. > > What I think would be appropriate would be a command > add_subdirectory_optional(...) or add_subdirectory_and_ignore_errors(...) > or something similar. > > Steve From scott at towel42.com Wed Mar 27 22:22:30 2019 From: scott at towel42.com (Scott Bloom) Date: Thu, 28 Mar 2019 02:22:30 +0000 Subject: [CMake] Install without building unittests Message-ID: I asked this a couple of years ago, and the answer was "no"... If you run tests, it doesn't automatically build tests... So why does an install? I would never release something into the wild with out running the tests... But, for developer builds, were we need to install all the packages in order to run the applications, sometimes I just want to test the GUI which requires an install of the core application into the correct location, without building the 1500+ (yes 1500) unittests, which can take 15-20 minutes to build on their own... Is there anyway to break the dependency?? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Wed Mar 27 22:24:02 2019 From: scott at towel42.com (Scott Bloom) Date: Thu, 28 Mar 2019 02:24:02 +0000 Subject: [CMake] Install without building unittests In-Reply-To: References: Message-ID: Note, Im running from inside visual studio... I do realize for a makefile based system, I can run make install from inside the executable's build directory From: CMake On Behalf Of Scott Bloom Sent: Wednesday, March 27, 2019 7:23 PM To: cmake at cmake.org Subject: [CMake] Install without building unittests I asked this a couple of years ago, and the answer was "no"... If you run tests, it doesn't automatically build tests... So why does an install? I would never release something into the wild with out running the tests... But, for developer builds, were we need to install all the packages in order to run the applications, sometimes I just want to test the GUI which requires an install of the core application into the correct location, without building the 1500+ (yes 1500) unittests, which can take 15-20 minutes to build on their own... Is there anyway to break the dependency?? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.wynne at mobotix.com Thu Mar 28 04:20:51 2019 From: daniel.wynne at mobotix.com (Daniel Wynne) Date: Thu, 28 Mar 2019 09:20:51 +0100 Subject: [CMake] Why do we need NVIDIA Nsight Tegrato create Visual Studio Android Projects? In-Reply-To: <3b23d9af-8c3d-aec7-324c-1307ca571cc1@mobotix.com> References: <96dd366e-1ae1-91e8-373d-7d2150ec6484@mobotix.com> <3b23d9af-8c3d-aec7-324c-1307ca571cc1@mobotix.com> Message-ID: <3391a8b7-020b-8549-6ebf-a4a2cb485d43@mobotix.com> A simple yes or no would be sufficient. Am 3/12/19 um 2:18 PM schrieb Daniel Wynne: > We would like to use Xamarin for our x-platform app-development with VS. > > Is any support for Xamarin planned in the near future? > > Am 11.03.2019 um 15:30 schrieb Daniel Wynne: >> Hi All! >> >> Short question: why do we need NVIDIA Nsight Tegra to setup a Visual >> Studio Android project? Despite of it being a helpful tool, the >> necessity for it to create the project file is unclear to me. >> >> Could you please enlighten me? >> >> Kind Regards >> >> Daniel >> -- MOBOTIX AG ? BeyondHumanVision ? www.mobotix.com Daniel Wynne Tel. +49 (0) 6302 9816-4124 Fax +49 (0) 6302 9816-190 Kaiserstrasse ? 67722 Langmeil ? Germany Vorstandsvorsitzender: Thomas Lausten Vorstandsmitglieder: Klaus Kiener, Hartmut Sprave Aufsichtsratsvorsitzender: Yuji Ichimura Registergericht: HRB Kaiserslautern 3724 From eric.noulard at gmail.com Thu Mar 28 07:48:05 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Thu, 28 Mar 2019 12:48:05 +0100 Subject: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS In-Reply-To: <61560e2aeebc464a9f9f610788070f1b@msx.bala.susq.com> References: <31b0896761334faaa4f671e599e45ee9@msx.bala.susq.com> <61560e2aeebc464a9f9f610788070f1b@msx.bala.susq.com> Message-ID: Le ven. 22 mars 2019 ? 18:30, Stewart, Robert a ?crit : > Have a look at the code I quoted from CPackRPM.cmake: > > if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT > CPACK_RPM_USER_BINARY_SPECFILE) > set(RPMBUILD_FLAGS "-bb") > > If CPACK_RPM_USER_BINARY_SPECFILE is defined, then RPMBUILD_FLAGS is *not* > set to -bb. > Sorry I missed your last answer. My link to up-to-date code: https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Internal/CPack/CPackRPM.cmake#L1658 shows that "-bb" is always set. This was fixed some time ago: https://gitlab.kitware.com/cmake/cmake/commit/574c81e28cef6737adc1619ce3b44b43bdcf308b CMake 3.8.0 and after should include this fix. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Thu Mar 28 10:48:05 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 28 Mar 2019 10:48:05 -0400 Subject: [CMake] Install without building unittests In-Reply-To: References: Message-ID: <1553784485.3145.0.camel@kitware.com> You could build CMake with -DBUILD_TESTING=OFF. This will skip the unit tests altogether. Kyle On Thu, 2019-03-28 at 02:24 +0000, Scott Bloom wrote: > Note, Im running from inside visual studio?? I do realize for a > makefile based system, I can run make install from inside the > executable?s build directory > ? > From: CMake On Behalf Of Scott Bloom > Sent: Wednesday, March 27, 2019 7:23 PM > To: cmake at cmake.org > Subject: [CMake] Install without building unittests > ? > I asked this a couple of years ago, and the answer was ?no?? > > If you run tests, it doesn?t automatically build tests?? So why does > an install? > ? > I would never release something into the wild with out running the > tests? > ? > But, for developer builds, were we need to install all the packages > in order to run the applications, sometimes I just want to test the > GUI which requires an install of the core application into the > correct location, without building the 1500+ (yes 1500) unittests, > which can take 15-20 minutes to build on their own? > ? > Is there anyway to break the dependency?? > > Scott > --? > > 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/op > ensource/opensource.html > > Follow this link to subscribe/unsubscribe: > https://cmake.org/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Thu Mar 28 11:07:15 2019 From: scott at towel42.com (Scott Bloom) Date: Thu, 28 Mar 2019 15:07:15 +0000 Subject: [CMake] Install without building unittests In-Reply-To: <1553784485.3145.0.camel@kitware.com> References: <1553784485.3145.0.camel@kitware.com> Message-ID: That is really not what we want.. We simply don?t want the Install target to have a dependency on the unittests. Essentially, the Install target should be have the same as the test target. If you to a make test, or from VS, on RUN_TESTS, RMB->Build, it doesn?t build the tests if they are out of date (or non-existant) Scott From: Kyle Edwards Sent: Thursday, March 28, 2019 7:48 AM To: Scott Bloom ; cmake at cmake.org Subject: Re: [CMake] Install without building unittests You could build CMake with -DBUILD_TESTING=OFF. This will skip the unit tests altogether. Kyle On Thu, 2019-03-28 at 02:24 +0000, Scott Bloom wrote: Note, Im running from inside visual studio? I do realize for a makefile based system, I can run make install from inside the executable?s build directory From: CMake > On Behalf Of Scott Bloom Sent: Wednesday, March 27, 2019 7:23 PM To: cmake at cmake.org Subject: [CMake] Install without building unittests I asked this a couple of years ago, and the answer was ?no?? If you run tests, it doesn?t automatically build tests? So why does an install? I would never release something into the wild with out running the tests? But, for developer builds, were we need to install all the packages in order to run the applications, sometimes I just want to test the GUI which requires an install of the core application into the correct location, without building the 1500+ (yes 1500) unittests, which can take 15-20 minutes to build on their own? Is there anyway to break the dependency?? Scott -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From frodak17 at gmail.com Thu Mar 28 13:03:15 2019 From: frodak17 at gmail.com (frodak17) Date: Thu, 28 Mar 2019 13:03:15 -0400 Subject: [CMake] Install without building unittests In-Reply-To: References: <1553784485.3145.0.camel@kitware.com> Message-ID: On Thu, Mar 28, 2019 at 11:07 AM Scott Bloom wrote: > That is really not what we want.. We simply don?t want the Install target > to have a dependency on the unittests. Essentially, the Install target > should be have the same as the test target. > > > > If you to a make test, or from VS, on RUN_TESTS, RMB->Build, it doesn?t > build the tests if they are out of date (or non-existant) > > > Scott > > > > I was under the impression that the global INSTALL target is only dependent on the ALL target unless you turn off the dependency. https://cmake.org/cmake/help/v3.14/variable/CMAKE_SKIP_INSTALL_ALL_DEPENDENCY.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Thu Mar 28 13:05:13 2019 From: scott at towel42.com (Scott Bloom) Date: Thu, 28 Mar 2019 17:05:13 +0000 Subject: [CMake] Install without building unittests In-Reply-To: References: <1553784485.3145.0.camel@kitware.com> Message-ID: This variable looks very interesting.. Ill play with it and see if it solves my problems ? THANKS!! Scott From: frodak17 Sent: Thursday, March 28, 2019 10:03 AM To: Scott Bloom Cc: Kyle Edwards ; cmake at cmake.org Subject: Re: [CMake] Install without building unittests On Thu, Mar 28, 2019 at 11:07 AM Scott Bloom > wrote: That is really not what we want.. We simply don?t want the Install target to have a dependency on the unittests. Essentially, the Install target should be have the same as the test target. If you to a make test, or from VS, on RUN_TESTS, RMB->Build, it doesn?t build the tests if they are out of date (or non-existant) Scott I was under the impression that the global INSTALL target is only dependent on the ALL target unless you turn off the dependency. https://cmake.org/cmake/help/v3.14/variable/CMAKE_SKIP_INSTALL_ALL_DEPENDENCY.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Thu Mar 28 13:20:23 2019 From: scott at towel42.com (Scott Bloom) Date: Thu, 28 Mar 2019 17:20:23 +0000 Subject: [CMake] Install without building unittests In-Reply-To: References: <1553784485.3145.0.camel@kitware.com> Message-ID: THANKS!!!! That was the exact variable I was looking for. Scott From: CMake On Behalf Of Scott Bloom Sent: Thursday, March 28, 2019 10:05 AM To: frodak17 Cc: cmake at cmake.org Subject: Re: [CMake] Install without building unittests This variable looks very interesting.. Ill play with it and see if it solves my problems ? THANKS!! Scott From: frodak17 > Sent: Thursday, March 28, 2019 10:03 AM To: Scott Bloom > Cc: Kyle Edwards >; cmake at cmake.org Subject: Re: [CMake] Install without building unittests On Thu, Mar 28, 2019 at 11:07 AM Scott Bloom > wrote: That is really not what we want.. We simply don?t want the Install target to have a dependency on the unittests. Essentially, the Install target should be have the same as the test target. If you to a make test, or from VS, on RUN_TESTS, RMB->Build, it doesn?t build the tests if they are out of date (or non-existant) Scott I was under the impression that the global INSTALL target is only dependent on the ALL target unless you turn off the dependency. https://cmake.org/cmake/help/v3.14/variable/CMAKE_SKIP_INSTALL_ALL_DEPENDENCY.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at towel42.com Thu Mar 28 13:22:03 2019 From: scott at towel42.com (Scott Bloom) Date: Thu, 28 Mar 2019 17:22:03 +0000 Subject: [CMake] Install without building unittests In-Reply-To: References: <1553784485.3145.0.camel@kitware.com> Message-ID: Just a note, for google later on? ? The default appears to have the variable unset, so it doesn?t show up in the list of variables in ccmake or the cmake-gui. I also added it to my system before any INSTALL command was called. I don?t know if that is necessary, but it does work SET( CMAKE_SKIP_INSTALL_ALL_DEPENDENCY TRUE ) Thanks again! Scott From: Scott Bloom Sent: Thursday, March 28, 2019 10:20 AM To: Scott Bloom ; frodak17 Cc: cmake at cmake.org Subject: RE: [CMake] Install without building unittests THANKS!!!! That was the exact variable I was looking for. Scott From: CMake > On Behalf Of Scott Bloom Sent: Thursday, March 28, 2019 10:05 AM To: frodak17 > Cc: cmake at cmake.org Subject: Re: [CMake] Install without building unittests This variable looks very interesting.. Ill play with it and see if it solves my problems ? THANKS!! Scott From: frodak17 > Sent: Thursday, March 28, 2019 10:03 AM To: Scott Bloom > Cc: Kyle Edwards >; cmake at cmake.org Subject: Re: [CMake] Install without building unittests On Thu, Mar 28, 2019 at 11:07 AM Scott Bloom > wrote: That is really not what we want.. We simply don?t want the Install target to have a dependency on the unittests. Essentially, the Install target should be have the same as the test target. If you to a make test, or from VS, on RUN_TESTS, RMB->Build, it doesn?t build the tests if they are out of date (or non-existant) Scott I was under the impression that the global INSTALL target is only dependent on the ALL target unless you turn off the dependency. https://cmake.org/cmake/help/v3.14/variable/CMAKE_SKIP_INSTALL_ALL_DEPENDENCY.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.W.Irwin1234 at gmail.com Thu Mar 28 13:28:10 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Thu, 28 Mar 2019 10:28:10 -0700 (PDT) Subject: [CMake] Install without building unittests In-Reply-To: References: Message-ID: On 2019-03-28 02:24-0000 Scott Bloom wrote: > Note, Im running from inside visual studio... I do realize for a makefile based system, I can run make install from inside the executable's build directory > > From: CMake On Behalf Of Scott Bloom > Sent: Wednesday, March 27, 2019 7:23 PM > To: cmake at cmake.org > Subject: [CMake] Install without building unittests > > I asked this a couple of years ago, and the answer was "no"... > > If you run tests, it doesn't automatically build tests... So why does an install? > > I would never release something into the wild with out running the tests... > > But, for developer builds, were we need to install all the packages in order to run the applications, sometimes I just want to test the GUI which requires an install of the core application into the correct location, without building the 1500+ (yes 1500) unittests, which can take 15-20 minutes to build on their own... > > Is there anyway to break the dependency?? The "install" target depends on the "all" target, and the "all" target depends on everything built with "add_executable". And I and presumably many other users of CMake would not be happy if the CMake developers decided to change these fundamental characteristics of CMake. However, I think you can straightforwardly achieve exactly what you want to do as follows: option(BUILD_UNIT_TESTS "Build unit tests?" OFF) if(BUILD_UNIT_TESTS) .... loop over add_executable for your various unit tests endif(BUILD_UNIT_TESTS) Of course, it is not as simple as that, and likely your builds of unit tests are scattered all over your build system, but the point is to protect all use of "add_executable" for those tests with an if block as above. Then you specify -DBUILD_UNIT_TESTS=ON cmake option if you actually do want to build your unit tests, but otherwise the default is not to build them (just like you apparently want). We have used a similar option over the years with the CMake-based build system for PLplot (in our case whether to build our standard examples in the build tree so we can test there in addition to our normal build and test of those examples in the installed examples tree). That method has worked well for us, and I think it would work well for your needs also. Alan __________________________ Alan W. Irwin Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From scott at towel42.com Thu Mar 28 13:30:35 2019 From: scott at towel42.com (Scott Bloom) Date: Thu, 28 Mar 2019 17:30:35 +0000 Subject: [CMake] Install without building unittests In-Reply-To: References: Message-ID: > Note, Im running from inside visual studio... I do realize for a > makefile based system, I can run make install from inside the > executable's build directory > > From: CMake On Behalf Of Scott Bloom > Sent: Wednesday, March 27, 2019 7:23 PM > To: cmake at cmake.org > Subject: [CMake] Install without building unittests > > I asked this a couple of years ago, and the answer was "no"... > > If you run tests, it doesn't automatically build tests... So why does an install? > > I would never release something into the wild with out running the tests... > > But, for developer builds, were we need to install all the packages in order to run the applications, sometimes I just want to test the GUI which requires an install of the core application into the correct location, without building the 1500+ (yes 1500) unittests, which can take 15-20 minutes to build on their own... > > Is there anyway to break the dependency?? The "install" target depends on the "all" target, and the "all" target depends on everything built with "add_executable". And I and presumably many other users of CMake would not be happy if the CMake developers decided to change these fundamental characteristics of CMake. However, I think you can straightforwardly achieve exactly what you want to do as follows: option(BUILD_UNIT_TESTS "Build unit tests?" OFF) if(BUILD_UNIT_TESTS) .... loop over add_executable for your various unit tests endif(BUILD_UNIT_TESTS) Of course, it is not as simple as that, and likely your builds of unit tests are scattered all over your build system, but the point is to protect all use of "add_executable" for those tests with an if block as above. Then you specify -DBUILD_UNIT_TESTS=ON cmake option if you actually do want to build your unit tests, but otherwise the default is not to build them (just like you apparently want). We have used a similar option over the years with the CMake-based build system for PLplot (in our case whether to build our standard examples in the build tree so we can test there in addition to our normal build and test of those examples in the installed examples tree). That method has worked well for us, and I think it would work well for your needs also. Alan __________________________ We have this exact style of setup... However, I want the Unit Tests as part of the project, I just don't want them built when running install.. I have no problem with them being built for " all" target... The variable CMAKE_SKIP_INSTALL_ALL_DEPENDENCY is what I was looking for.... Thanks Scott From jjwilke at sandia.gov Thu Mar 28 14:13:27 2019 From: jjwilke at sandia.gov (Wilke, Jeremiah J) Date: Thu, 28 Mar 2019 18:13:27 +0000 Subject: [CMake] De-duplication with generator expressions Message-ID: <8ECA24B9-4886-4CE5-B0E9-96B038030985@sandia.gov> I am passing several LLVM/Clang passes, which means I need arguments not de-duplicated: -Xtemplight -profiler -Xtemplight -ignore-system Otherwise I would get templight++ -Xtemplight -profiler -ignore-system which crashes. The SHELL: trick works in some cases. However, I also have scenarios where I need a generator expression so compiler flags only apply to C++ files: target_compile_options(${target} PUBLIC $<$:? The following works: target_compile_options(${target} PUBLIC $<$:SHELL:-Xtemplight -profiler -Xtemplight -ignore-system>) But then splitting around conditionals, the below does not and still does de-dup breaking the build: if (TEMPLIGHT_IGNORE_SYSTEM) target_compile_options(${target} PUBLIC $<$:SHELL:-Xtemplight -ignore-system>) endif() target_compile_options(${target} PUBLIC $<$:SHELL:-Xtemplight -profiler>) After searching for a bit, it would appear SHELL: can still not be used with generator expressions? Has anyone else encountered this and knows a workaround? No amount of searching or playing around with quotes got this to work. -Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.sutton at padtinc.com Thu Mar 28 14:12:23 2019 From: matt.sutton at padtinc.com (Matt Sutton) Date: Thu, 28 Mar 2019 18:12:23 +0000 Subject: [CMake] Fortran Compiler with Visual Studio Message-ID: Hello, I'm trying to configure a mixed language project (Fortran, CXX) with cmake 3.14 and I get the following cmake output: The Fortran compiler identification is Intel 17.0.5.20170817 The CXX compiler identification is MSVC 19.16.27027.1 CMake Error at CMakeLists.txt:9 (project): No CMAKE_FORTRAN_COMPILER could be found. I have been able to create a simple "hello world" Fortran project manually in Visual Studio, compile, link and run it. So, it seems the Fortran compiler integration is working. I'm not sure why CMake can correctly identify the Fortran compiler on my machine, but then complain about a Fortran compiler not being found? Any suggestions would be appreciated. Thanks, Matt [cid:image001.png at 01CF79BE.4008A810] We Make Innovation Work www.padtinc.com Matt Sutton, MSME Senior Engineer, Lead Software Developer matt.sutton at padtinc.com 480.813.4884 O 480.326.7940 M [cid:image004.jpg at 01D4E557.1DAA6A10] Arizona | California | Colorado | New Mexico | Texas | Utah CONFIDENTIALITY NOTICE: This e-mail message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Unless you are the intended recipient, you are hereby notified that copying, forwarding, printing or otherwise disseminating the information contained in or attached to this e-mail is strictly prohibited. If you are not the intended recipient, please notify the sender by telephone, and immediately and permanently delete and destroy all copies and printouts of this e-mail message and/or attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 8163 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 7787 bytes Desc: image004.jpg URL: From allen at huarp.harvard.edu Thu Mar 28 14:58:24 2019 From: allen at huarp.harvard.edu (Norton Allen) Date: Thu, 28 Mar 2019 14:58:24 -0400 Subject: [CMake] Generate and install a file Message-ID: <1d691057-b747-2dc7-9b39-2c357c509e19@huarp.harvard.edu> I have spent a few hours trying to solve what seems like a simple problem. I need to generate a file with some dependencies and install it. If I want cmake to figure out how to compile and link it, I can add_executable(mytarget mytarget.c) install(TARGETS mytarget DESTINATION bin) I also know that if I get cmake to configure a file, I can install it: configure_file ( ? ${CMAKE_CURRENT_SOURCE_DIR}/config.h.in ? ${CMAKE_CURRENT_BINARY_DIR}/config.h ) intall(FILES ${CMAKE_CURRENT_BINARY_DIR}/config.h ? DESTINATION include ) But what if I have a tool of my own that will generate the file? I know I can: add_custom_command( ? OUTPUT mygeneratedfile ? COMMAND mytool -o mygeneratedfile ? DEPENDS mysourcefile ) and this works well *provided* that mygeneratedfile is in turn a source file for another derivation, but I cannot follow that with: install(FILES mygeneratedfile DESTINATION bin) because mygeneratedfile is not a 'target', and I can't make it into a target with add_custom_target() because that's talking about something else entirely (commands that will be run unconditionally, not based on dependencies) Am I missing something? In my specific case, mytool actually creates an executable via it's own build system, but it could also be creating a script of some kind that needs to be installed. Of course in that case, I could possibly trick CMake by generating mygeneratedfile.in and using configure_file() with no substitutions (pretty dubious), but I can't do that with a binary file. Is this not possible? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Stewart at sig.com Thu Mar 28 15:11:02 2019 From: Robert.Stewart at sig.com (Stewart, Robert) Date: Thu, 28 Mar 2019 19:11:02 +0000 Subject: [CMake] Custom RPM build failing for want of RPMBUILD_FLAGS In-Reply-To: References: <31b0896761334faaa4f671e599e45ee9@msx.bala.susq.com> <61560e2aeebc464a9f9f610788070f1b@msx.bala.susq.com> Message-ID: From: Eric Noulard [mailto:eric.noulard at gmail.com] Sent: Thursday, March 28, 2019 7:48 AM Le ven. 22 mars 2019 ? 18:30, Stewart, Robert > a ?crit : Have a look at the code I quoted from CPackRPM.cmake: if(CPACK_RPM_GENERATE_USER_BINARY_SPECFILE_TEMPLATE OR NOT CPACK_RPM_USER_BINARY_SPECFILE) set(RPMBUILD_FLAGS "-bb") If CPACK_RPM_USER_BINARY_SPECFILE is defined, then RPMBUILD_FLAGS is not set to -bb. Sorry I missed your last answer. My link to up-to-date code: https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Internal/CPack/CPackRPM.cmake#L1658 shows that "-bb" is always set. This was fixed some time ago: https://gitlab.kitware.com/cmake/cmake/commit/574c81e28cef6737adc1619ce3b44b43bdcf308b CMake 3.8.0 and after should include this fix. I see that in my copy of 3.11 and not in 3.7.2, which is what I was using. Thanks! ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Thu Mar 28 15:11:49 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 28 Mar 2019 15:11:49 -0400 Subject: [CMake] Generate and install a file In-Reply-To: <1d691057-b747-2dc7-9b39-2c357c509e19@huarp.harvard.edu> References: <1d691057-b747-2dc7-9b39-2c357c509e19@huarp.harvard.edu> Message-ID: <1553800309.3145.3.camel@kitware.com> On Thu, 2019-03-28 at 14:58 -0400, Norton Allen wrote: > because mygeneratedfile is not a 'target', and I can't make it into a > target with add_custom_target() because that's talking about > something else entirely (commands that will be run unconditionally, > not based on dependencies) What exactly do you mean by "based on dependencies"? Do you mean that this file has dependencies on something else, or that something else has dependencies on it? Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From allen at huarp.harvard.edu Thu Mar 28 15:26:09 2019 From: allen at huarp.harvard.edu (Norton Allen) Date: Thu, 28 Mar 2019 15:26:09 -0400 Subject: [CMake] Generate and install a file In-Reply-To: <1553800309.3145.3.camel@kitware.com> References: <1d691057-b747-2dc7-9b39-2c357c509e19@huarp.harvard.edu> <1553800309.3145.3.camel@kitware.com> Message-ID: <84eca304-b7cb-2c6d-abf8-b23d3027b00c@huarp.harvard.edu> On 3/28/2019 3:11 PM, Kyle Edwards wrote: > On Thu, 2019-03-28 at 14:58 -0400, Norton Allen wrote: >> >> because mygeneratedfile is not a 'target', and I can't make it into a >> target with add_custom_target() because that's talking about >> something else entirely (commands that will be run unconditionally, >> not based on dependencies) >> > > What exactly do you mean by "based on dependencies"? Do you mean that > this file has dependencies on something else, or that something else > has dependencies on it? I mean this file depends on some source files--if the source files change, I want to rerun the generation step. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.sutton at padtinc.com Thu Mar 28 15:27:03 2019 From: matt.sutton at padtinc.com (Matt Sutton) Date: Thu, 28 Mar 2019 19:27:03 +0000 Subject: [CMake] Fortran Compiler with Visual Studio In-Reply-To: References: Message-ID: <38f0dd0acaee4c9d95e69e82cd79655d@ex0.padtinc.com> Sorry for the noise. It was a silly mistake on my part by using the language specified as FORTRAN not Fortran. Regards, Matt Matt Sutton Senior Engineer, Lead Software Developer PADT, Inc. www.padtinc.com 480.813.4884 matt.sutton at padtinc.com CONFIDENTIALITY NOTICE: This e-mail message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Unless you are the intended recipient, you are hereby notified that copying, forwarding, printing or otherwise disseminating the information contained in or attached to this e-mail is strictly prohibited. If you are not the intended recipient, please notify the sender by telephone, and immediately and permanently delete and destroy all copies and printouts of this e-mail message and/or attachments. From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Matt Sutton Sent: Thursday, March 28, 2019 11:12 AM To: cmake at cmake.org Subject: [CMake] Fortran Compiler with Visual Studio Hello, I'm trying to configure a mixed language project (Fortran, CXX) with cmake 3.14 and I get the following cmake output: The Fortran compiler identification is Intel 17.0.5.20170817 The CXX compiler identification is MSVC 19.16.27027.1 CMake Error at CMakeLists.txt:9 (project): No CMAKE_FORTRAN_COMPILER could be found. I have been able to create a simple "hello world" Fortran project manually in Visual Studio, compile, link and run it. So, it seems the Fortran compiler integration is working. I'm not sure why CMake can correctly identify the Fortran compiler on my machine, but then complain about a Fortran compiler not being found? Any suggestions would be appreciated. Thanks, Matt [cid:image001.png at 01CF79BE.4008A810] We Make Innovation Work www.padtinc.com Matt Sutton, MSME Senior Engineer, Lead Software Developer matt.sutton at padtinc.com 480.813.4884 O 480.326.7940 M [cid:image002.jpg at 01D4E561.8AE467C0] Arizona | California | Colorado | New Mexico | Texas | Utah CONFIDENTIALITY NOTICE: This e-mail message and any attachments are for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Unless you are the intended recipient, you are hereby notified that copying, forwarding, printing or otherwise disseminating the information contained in or attached to this e-mail is strictly prohibited. If you are not the intended recipient, please notify the sender by telephone, and immediately and permanently delete and destroy all copies and printouts of this e-mail message and/or attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 8163 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 7746 bytes Desc: image002.jpg URL: From kyle.edwards at kitware.com Thu Mar 28 15:33:06 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 28 Mar 2019 15:33:06 -0400 Subject: [CMake] Generate and install a file In-Reply-To: <84eca304-b7cb-2c6d-abf8-b23d3027b00c@huarp.harvard.edu> References: <1d691057-b747-2dc7-9b39-2c357c509e19@huarp.harvard.edu> <1553800309.3145.3.camel@kitware.com> <84eca304-b7cb-2c6d-abf8-b23d3027b00c@huarp.harvard.edu> Message-ID: <1553801586.3145.8.camel@kitware.com> On Thu, 2019-03-28 at 15:26 -0400, Norton Allen wrote: > On 3/28/2019 3:11 PM, Kyle Edwards wrote: > > On Thu, 2019-03-28 at 14:58 -0400, Norton Allen wrote: > > > because mygeneratedfile is not a 'target', and I can't make it > > > into a target with add_custom_target() because that's talking > > > about something else entirely (commands that will be run > > > unconditionally, not based on dependencies) > > What exactly do you mean by "based on dependencies"? Do you mean > > that this file has dependencies on something else, or that > > something else has dependencies on it? > I mean this file depends on some source files--if the source files > change, I want to rerun the generation step. Using the DEPENDS argument of add_custom_command() will do this. However, add_custom_command() on its own isn't enough to ensure that the file is generated before installation. You need to pair add_custom_command() with add_custom_target(). Example: add_custom_command( ? OUTPUT mygeneratedfile ? COMMAND mytool -o mygeneratedfile ? DEPENDS mysourcefile ) add_custom_target(mygeneratedtarget ? DEPENDS mygeneratedfile ) This is different from: add_custom_target(mygeneratedtarget ? COMMAND mytool -o mygeneratedfile ? BYPRODUCTS mygeneratedfile ? DEPENDS mysourcefile ) because it will only run mytool when it needs to (when mysourcefile has changed). Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From allen at huarp.harvard.edu Thu Mar 28 16:07:34 2019 From: allen at huarp.harvard.edu (Norton Allen) Date: Thu, 28 Mar 2019 16:07:34 -0400 Subject: [CMake] Generate and install a file In-Reply-To: <1553801586.3145.8.camel@kitware.com> References: <1d691057-b747-2dc7-9b39-2c357c509e19@huarp.harvard.edu> <1553800309.3145.3.camel@kitware.com> <84eca304-b7cb-2c6d-abf8-b23d3027b00c@huarp.harvard.edu> <1553801586.3145.8.camel@kitware.com> Message-ID: On 3/28/2019 3:33 PM, Kyle Edwards wrote: > Using the DEPENDS argument of add_custom_command() will do this. > However, add_custom_command() on its own isn't enough to ensure that > the file is generated before installation. You need to pair > add_custom_command() with add_custom_target(). Example: > > add_custom_command( > ? OUTPUT mygeneratedfile > ? COMMAND mytool -o mygeneratedfile > ? DEPENDS mysourcefile > ) > add_custom_target(mygeneratedtarget > ? DEPENDS mygeneratedfile > ) > > This is different from: > > add_custom_target(mygeneratedtarget > ? COMMAND mytool -o mygeneratedfile > ? BYPRODUCTS mygeneratedfile > ? DEPENDS mysourcefile > ) > > because it will only run mytool when it needs to (when mysourcefile > has changed). > Kyle, What you say makes sense, and I can even understand why add_custom_target might do that, but I cannot get this to actually work. Here is a minimal CMakeLists.txt. mysourcefile is just and empty file. I have these files in test/cmake, and I: cd test mkdir build-cmake cd build-cmake cmake ../cmake make and there is no sign of mygeneratedfile. I then try make install and I get: $ make install Install the project... -- Install configuration: "" CMake Error at cmake_install.cmake:31 (file): ? file INSTALL cannot find "/home/nort/test/build-cmake/mygeneratedfile". make: *** [Makefile:84: install] Error 1 Where is my mistake? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- cmake_minimum_required(VERSION 2.8.8) cmake_policy(SET CMP0048 NEW) project(table VERSION 2.0.0) add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/mygeneratedfile COMMAND touch mygeneratedfile DEPENDS mysourcefile ) add_custom_target(mygeneratedtarget DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/mygeneratedfile ) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/mygeneratedfile DESTINATION bin) From kyle.edwards at kitware.com Thu Mar 28 16:12:02 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 28 Mar 2019 16:12:02 -0400 Subject: [CMake] Generate and install a file In-Reply-To: References: <1d691057-b747-2dc7-9b39-2c357c509e19@huarp.harvard.edu> <1553800309.3145.3.camel@kitware.com> <84eca304-b7cb-2c6d-abf8-b23d3027b00c@huarp.harvard.edu> <1553801586.3145.8.camel@kitware.com> Message-ID: <1553803922.3145.10.camel@kitware.com> On Thu, 2019-03-28 at 16:07 -0400, Norton Allen wrote: > Kyle, > What you say makes sense, and I can even understand why > add_custom_target might do that, but I cannot get this to actually > work. Here is a minimal CMakeLists.txt. mysourcefile is just and > empty file. > I have these files in test/cmake, and I: > cd test > mkdir build-cmake > cd build-cmake > cmake ../cmake > make > and there is no sign of mygeneratedfile. I then try > make install > and I get: > $ make install > Install the project... > -- Install configuration: "" > CMake Error at cmake_install.cmake:31 (file): > ? file INSTALL cannot find "/home/nort/test/build- > cmake/mygeneratedfile". > > > make: *** [Makefile:84: install] Error 1 > Where is my mistake? One more thing: if you want the custom target to be built by "make" or "make all", you have to give it the ALL argument: add_custom_target(mygeneratedtarget ALL ? DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/mygeneratedfile ) Otherwise you can build the target with "make mygeneratedtarget". Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From allen at huarp.harvard.edu Thu Mar 28 16:38:33 2019 From: allen at huarp.harvard.edu (Norton Allen) Date: Thu, 28 Mar 2019 16:38:33 -0400 Subject: [CMake] Generate and install a file In-Reply-To: <1553803922.3145.10.camel@kitware.com> References: <1d691057-b747-2dc7-9b39-2c357c509e19@huarp.harvard.edu> <1553800309.3145.3.camel@kitware.com> <84eca304-b7cb-2c6d-abf8-b23d3027b00c@huarp.harvard.edu> <1553801586.3145.8.camel@kitware.com> <1553803922.3145.10.camel@kitware.com> Message-ID: On 3/28/2019 4:12 PM, Kyle Edwards wrote: > One more thing: if you want the custom target to be built by "make" or > "make all", you have to give it the ALL argument: > > add_custom_target(mygeneratedtarget ALL > DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/mygeneratedfile > ) > > Otherwise you can build the target with "make mygeneratedtarget". > OK! That does make a difference. I had focused on the add_custom_target documentation that indicated the rule was always considered out of date, and jumped to the conclusion that that meant it was always run. Thank you for sorting that out! What I find surprising is that 'make install' could not identify how to create mygeneratedfile. Is there some reason why 'mygeneratedfile' cannot be a target in its own right with needing to refer to this phony target to achieve the desired result? Related to that, I noticed in another thread the mention of 'CMAKE_SKIP_INSTALL_ALL_DEPENDENCY'. If that were set in this case, how could I indicate that install depends on mygeneratedtarget? (Admittedly, I'm having a hard time coming up with a case where this would apply, but I'm having trouble with the tenuous connection between the instruction to install mygeneratedfile and the rule that actually generates it.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Thu Mar 28 16:58:13 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 28 Mar 2019 16:58:13 -0400 Subject: [CMake] Generate and install a file In-Reply-To: References: <1d691057-b747-2dc7-9b39-2c357c509e19@huarp.harvard.edu> <1553800309.3145.3.camel@kitware.com> <84eca304-b7cb-2c6d-abf8-b23d3027b00c@huarp.harvard.edu> <1553801586.3145.8.camel@kitware.com> <1553803922.3145.10.camel@kitware.com> Message-ID: <1553806693.3145.14.camel@kitware.com> On Thu, 2019-03-28 at 16:38 -0400, Norton Allen wrote: > Related to that, I noticed in another thread the mention of > 'CMAKE_SKIP_INSTALL_ALL_DEPENDENCY'. If that were set in this case, > how could I indicate that install depends on mygeneratedtarget? There is no way to do this. C/C++ targets (executables and libraries) suffer from the same problem: if you set CMAKE_SKIP_INSTALL_ALL_DEPENDENCY and then run "make install" without running "make" first, the install rule will complain that it can't find the files (such as libfoo.a.) If you set CMAKE_SKIP_INSTALL_ALL_DEPENDENCY, you have to make sure the targets you want to install are built before running "make install". Kyle From neundorf at kde.org Thu Mar 28 16:56:14 2019 From: neundorf at kde.org (Alexander Neundorf) Date: Thu, 28 Mar 2019 21:56:14 +0100 Subject: [CMake] Install without building unittests In-Reply-To: References: Message-ID: <1910856.lyVlGjJt2n@linux-lma8> On 2019 M03 28, Thu 18:22:03 CET Scott Bloom wrote: > Just a note, for google later on? ? > > The default appears to have the variable unset, so it doesn?t show up in the > list of variables in ccmake or the cmake-gui. > I also added it to my system before any INSTALL command was called. I don?t > know if that is necessary, but it does work > SET( CMAKE_SKIP_INSTALL_ALL_DEPENDENCY TRUE ) I'm not sure how that applies to the MSVC generators, but when using Makefiles, you can do make install/fast which just installs without building. Alex From dustyn at blasig.us Fri Mar 29 11:58:14 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Fri, 29 Mar 2019 10:58:14 -0500 Subject: [CMake] CUDA Support Message-ID: Hi All, I can't find any documentation on the new-ish "native" CUDA support. I need to know all the variables that we can use, and (for instance) whether checking the CUDA version is now supported. When searching online, I'm always directed to the old FindCUDA pages which don't seem to match what is available with the native language support. Currently, I'm "hacking" my way through things by using both flows. I add CUDA as a language, use the found CUDA compiler to construct a CUDA_TOOLKIT_ROOT_DIR and then call find_package(CUDA) to get the old environment variables set up. Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry at parallel-computing.pro Fri Mar 29 12:28:07 2019 From: dmitry at parallel-computing.pro (Dmitry Mikushin) Date: Fri, 29 Mar 2019 20:28:07 +0400 Subject: [CMake] CUDA Support In-Reply-To: References: Message-ID: Hi, That was my confusion as well: to my understanding, we should not try to combine enable_language(CUDA) with find_package(CUDA). They do not work together, either use one or another. Kind regards, - Dmitry. ??, 29 ???. 2019 ?. ? 19:58, Dustyn Blasig : > Hi All, > > I can't find any documentation on the new-ish "native" CUDA support. I > need to know all the variables that we can use, and (for instance) whether > checking the CUDA version is now supported. When searching online, I'm > always directed to the old FindCUDA pages which don't seem to match what is > available with the native language support. > > Currently, I'm "hacking" my way through things by using both flows. I add > CUDA as a language, use the found CUDA compiler to construct a > CUDA_TOOLKIT_ROOT_DIR and then call find_package(CUDA) to get the old > environment variables set up. > > Cheers! > -- > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Mar 29 12:56:23 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 29 Mar 2019 12:56:23 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.14.1 available for download Message-ID: We are pleased to announce that CMake 3.14.1 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.14.1 since 3.14.0: Brad King (11): VS: Fix x64 host recognition by x86 cmake process find_program: Restore leading double slash on Windows network path Eclipse: Fix extra generator to not crash on interface libraries ARMCC: Fix identification of ARM compiler when it defines GNU macros Help: Clarify policy CMP0082 documentation Restore support for include_directories() in toolchain files CUDA: Tolerate square brackets in PROMPT environment variable cmake: Fix '-E copy foo .' to avoid clobbering file FindFontconfig: Convert module variables to camel case ParseImplicitIncludeInfo: Canonicalize implicit include dirs CMake 3.14.1 Cl?ment Rezvoy (1): CPackIFW: Add missing cpack_ifw_configure_component_group option processing Marc Chevrier (1): FindPython*: ensure correct architecture is selected. Sebastian Holtermann (1): Autogen: Do not treat hard-coded -I/usr/include exclusion as implicit include Sylvain Joubert (1): ctest_coverage: fix out-of-bounds index in Jacoco parser From dustyn at blasig.us Fri Mar 29 12:57:28 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Fri, 29 Mar 2019 11:57:28 -0500 Subject: [CMake] CUDA Support In-Reply-To: References: Message-ID: "we should not try to combine enable_language(CUDA) with find_package(CUDA). They do not work together, either use one or another." Absolutely, my goal is to move to the new built-in language support. I'm having trouble doing that because I can't find any documentation on it. For instance, what is the new equivalent CUDA_TOOLKIT_ROOT_DIR? Without find_package(CUDA), I don't see anything set that have the equivalent. Also, in some cases the CUDA include directory is added to targets, and in other cases it isn't, even if the target depends on source with .cu. What is the documented behavior for this? I'm sure there has to be a page somewhere on this, but going to page 4 on Google search didn't uncover anything, and the first 2 pages all point to various versions of FindCUDA : ) On Fri, Mar 29, 2019 at 11:28 AM Dmitry Mikushin < dmitry at parallel-computing.pro> wrote: > Hi, > > That was my confusion as well: to my understanding, we should not try to > combine enable_language(CUDA) with find_package(CUDA). They do not work > together, either use one or another. > > Kind regards, > - Dmitry. > > ??, 29 ???. 2019 ?. ? 19:58, Dustyn Blasig : > >> Hi All, >> >> I can't find any documentation on the new-ish "native" CUDA support. I >> need to know all the variables that we can use, and (for instance) whether >> checking the CUDA version is now supported. When searching online, I'm >> always directed to the old FindCUDA pages which don't seem to match what is >> available with the native language support. >> >> Currently, I'm "hacking" my way through things by using both flows. I add >> CUDA as a language, use the found CUDA compiler to construct a >> CUDA_TOOLKIT_ROOT_DIR and then call find_package(CUDA) to get the old >> environment variables set up. >> >> Cheers! >> -- >> >> 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julius.caro at gmail.com Sat Mar 30 08:45:07 2019 From: julius.caro at gmail.com (Luis Caro Campos) Date: Sat, 30 Mar 2019 12:45:07 +0000 Subject: [CMake] CUDA Support In-Reply-To: References: Message-ID: I believe the closest equivalent to settinga CUDA_TOOLKIT_ROOT_DIR when using enable_language(CUDA) is to set either the environment variable CUDACXX or the CMake cache entry CMAKE_CUDA_COMPILER to point to the location of the nvcc compiler. However I think there are still some "features" of FindCUDA that enable_language don't support, e.g. variables and/or import targets with locations, see https://gitlab.kitware.com/cmake/cmake/issues/17816 Kind regards, Luis On Fri, Mar 29, 2019 at 4:57 PM Dustyn Blasig wrote: > "we should not try to combine enable_language(CUDA) with > find_package(CUDA). They do not work together, either use one or another." > > Absolutely, my goal is to move to the new built-in language support. I'm > having trouble doing that because I can't find any documentation on it. For > instance, what is the new equivalent CUDA_TOOLKIT_ROOT_DIR? Without > find_package(CUDA), I don't see anything set that have the equivalent. > Also, in some cases the CUDA include directory is added to targets, and in > other cases it isn't, even if the target depends on source with .cu. What > is the documented behavior for this? > > I'm sure there has to be a page somewhere on this, but going to page 4 on > Google search didn't uncover anything, and the first 2 pages all point to > various versions of FindCUDA : ) > > On Fri, Mar 29, 2019 at 11:28 AM Dmitry Mikushin < > dmitry at parallel-computing.pro> wrote: > >> Hi, >> >> That was my confusion as well: to my understanding, we should not try to >> combine enable_language(CUDA) with find_package(CUDA). They do not work >> together, either use one or another. >> >> Kind regards, >> - Dmitry. >> >> ??, 29 ???. 2019 ?. ? 19:58, Dustyn Blasig : >> >>> Hi All, >>> >>> I can't find any documentation on the new-ish "native" CUDA support. I >>> need to know all the variables that we can use, and (for instance) whether >>> checking the CUDA version is now supported. When searching online, I'm >>> always directed to the old FindCUDA pages which don't seem to match what is >>> available with the native language support. >>> >>> Currently, I'm "hacking" my way through things by using both flows. I >>> add CUDA as a language, use the found CUDA compiler to construct a >>> CUDA_TOOLKIT_ROOT_DIR and then call find_package(CUDA) to get the old >>> environment variables set up. >>> >>> Cheers! >>> -- >>> >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cary at txcorp.com Sat Mar 30 16:07:25 2019 From: cary at txcorp.com (JR Cary) Date: Sat, 30 Mar 2019 14:07:25 -0600 Subject: [CMake] Does enable_language(CUDA) still have the problem with reconfiguring? In-Reply-To: References: Message-ID: <2c1c038a-9a70-8a69-8ab2-afc88050f8bd@txcorp.com> Re the thread below, Does the newer, enable_languagedo a better job of not having the repeated reconfigurations and full project rebuilds as described at https://cmake.org/pipermail/cmake/2011-January/042173.html and many times after? John On 3/30/19 6:45 AM, cmake-request at cmake.org wrote: > ----------------------------- > Message: 4 > Date: Sat, 30 Mar 2019 12:45:07 +0000 > From: Luis Caro Campos > > I believe the closest equivalent to settinga CUDA_TOOLKIT_ROOT_DIR when > using enable_language(CUDA) is to set either the environment variable > CUDACXX or the CMake cache entry CMAKE_CUDA_COMPILER to point to the > location of the nvcc compiler. > > However I think there are still some "features" of FindCUDA that > enable_language don't support, e.g. variables and/or import targets with > locations, see https://gitlab.kitware.com/cmake/cmake/issues/17816 > > Kind regards, > Luis > > On Fri, Mar 29, 2019 at 4:57 PM Dustyn Blasig wrote: > >> "we should not try to combine enable_language(CUDA) with >> find_package(CUDA). They do not work together, either use one or another." >> >> Absolutely, my goal is to move to the new built-in language support. I'm >> having trouble doing that because I can't find any documentation on it. For >> instance, what is the new equivalent CUDA_TOOLKIT_ROOT_DIR? Without >> find_package(CUDA), I don't see anything set that have the equivalent. >> Also, in some cases the CUDA include directory is added to targets, and in >> other cases it isn't, even if the target depends on source with .cu. What >> is the documented behavior for this? >> >> I'm sure there has to be a page somewhere on this, but going to page 4 on >> Google search didn't uncover anything, and the first 2 pages all point to >> various versions of FindCUDA : ) >> >> On Fri, Mar 29, 2019 at 11:28 AM Dmitry Mikushin < >> dmitry at parallel-computing.pro> wrote: >> >>> Hi, >>> >>> That was my confusion as well: to my understanding, we should not try to >>> combine enable_language(CUDA) with find_package(CUDA). They do not work >>> together, either use one or another. >>> >>> Kind regards, >>> - Dmitry. >>> >>> ??, 29 ???. 2019 ?. ? 19:58, Dustyn Blasig : >>> >>>> Hi All, >>>> >>>> I can't find any documentation on the new-ish "native" CUDA support. I >>>> need to know all the variables that we can use, and (for instance) whether >>>> checking the CUDA version is now supported. When searching online, I'm >>>> always directed to the old FindCUDA pages which don't seem to match what is >>>> available with the native language support. >>>> >>>> Currently, I'm "hacking" my way through things by using both flows. I >>>> add CUDA as a language, use the found CUDA compiler to construct a >>>> CUDA_TOOLKIT_ROOT_DIR and then call find_package(CUDA) to get the old >>>> environment variables set up. >>>> >>>> Cheers! >>>> From zbeekman at gmail.com Sun Mar 31 17:10:24 2019 From: zbeekman at gmail.com (Zaak Beekman) Date: Sun, 31 Mar 2019 17:10:24 -0400 Subject: [CMake] Querying targets for Fortran module files & module file installation advice Message-ID: Hi all, What's the best approach for handling cross-platform (i.e., MSVS, Mac, Linux) installation of Fortran module files associated with libraries? After searching the docs, I couldn't find any good and obvious way to handle installation of Fortran module files associated with library targets. These are compiler specific, and, perhaps a better approach might be to ship all executable code compiled into libraries and put inside submodules, and ship a free/open parent module with interface, type, class, constant, etc. definitions. But, at any rate, it would be nice if there were a better way to install Fortran module files besides something like: ``` set(CMAKE_Fortran_MODULE_DIRECTORY "${CMAKE_BINARY_DIR}/include") ... install(DIRECTORY ${CMAKE_Fortran_MODULE_DIRECTORY} DESTINATION ${CMAKE_INSTALL_INCLUDE_DIR}) ``` In particular, it is hard to know which .mod and .smod files will be produced ahead of time without parsing the source, or manually enumerating them. One can use the approach outlined above, but a few problems and drawbacks remain: 1. With IDEs like MSVS, I always seem to end up getting an additional directory installed under ${CMAKE_INSTALL_INCLUDE_DIR} with the name of the build configuration (e.g., `debug`) 2. Utility/test modules may have generic names (e.g. assertions.mod) that probably should not get installed and will very likely lead to name clashes with consuming projects 3. Lack of standard definition of module file format and Fortran ABI makes portability dicey, at least until ISO_Fortran_BINDING is widely available and adopted It would be great if there were a target property that could be queried for associated module and submodule files. In addition additional "it just works" logic around installing Fortran targets and how modules are handled would be really nice. This obviously isn't an easy/trivial question to answer, but being able to query targets for module file build artifacts would be a great starting point. In the mean time, I think my only acceptable options to handle IDEs like MSVS is to use the `SCRIPT` signature of `install()` where I can use `file(GLOB_RECURSE ...)` to find module files and strip out any build configuration specific directory structure. (Or at least adopt my own logic and conventions for this...) Any tips or advice would be very appreciated! Thanks, Zaak