From sebastian.mueller3 at zf.com Thu Aug 1 05:18:16 2019 From: sebastian.mueller3 at zf.com (sebastian.mueller3 at zf.com) Date: Thu, 1 Aug 2019 09:18:16 +0000 Subject: [CMake] FindPython3 Python_FIND_VIRTUALENV seems to be ignored Message-ID: <723308B8AE346144815E77DB91FA92E9345E3DB5@FRDS01516.emea.zf-world.com> Hi all, I've been trying to convince Cmake 15.1 to use the python installation in my virtual anaconda environment rather than the anaconda base installation. I'm using this to find python: set(Python3_FIND_VIRTUALENV "FIRST") find_package(Python3 3.6.8 EXACT COMPONENTS Development NumPy) First, I'm using Anaconda Prompt to execute the commands. I `activate testenv`, to activate my environment. When I then run `cmake .. -G "Visual Studio 14 2015 Win64"`, I get this output: -- Selecting Windows SDK version to target Windows 10.0.16299. -- The C compiler identification is MSVC 19.0.24215.1 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe - works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Found Git: C:/app/tools/Git/cmd/git.exe (found version "2.17.1.windows.2") -- Could NOT find Python3: Found unsuitable version "3.6.4", but required is exact version "3.6.8" (found C:/app/anaconda3/libs/python36.lib) -- Configuring done -- Generating done -- Build files have been written to: D:/src/project/vsbuild I would expect cmake rather to find the python in C:/app/anaconda3/envs/testenv/... since this is the active environment and according to the HINT I set it to be favored over other python installations (as documented in https://cmake.org/cmake/help/v3.15/module/FindPython3.html). Additional info: $ which python C:/app/anaconda3/envs/testenv/python.exe $ python -version Python 3.6.8 :: Anaconda, Inc. I'm working on Windows 10. Any ideas what is going wrong? Kind regards/Viele Gr??e Sebastian M?ller -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Thu Aug 1 08:02:21 2019 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Thu, 1 Aug 2019 14:02:21 +0200 Subject: [CMake] FindPython3 Python_FIND_VIRTUALENV seems to be ignored In-Reply-To: <723308B8AE346144815E77DB91FA92E9345E3DB5@FRDS01516.emea.zf-world.com> References: <723308B8AE346144815E77DB91FA92E9345E3DB5@FRDS01516.emea.zf-world.com> Message-ID: <06059165-d2fd-49a8-b356-e6301653753f@Spark> This is a bug already identified (see https://gitlab.kitware.com/cmake/cmake/issues/19525). I am currently working on a fix. Le 1 ao?t 2019 ? 11:33 +0200, sebastian.mueller3 at zf.com, a ?crit : > Hi all, > > I?ve been trying to convince Cmake 15.1 to use the python installation in my virtual anaconda environment rather than the anaconda base installation. > I?m using this to find python: > > set(Python3_FIND_VIRTUALENV "FIRST") > find_package(Python3 3.6.8 EXACT COMPONENTS Development NumPy) > > First, I?m using Anaconda Prompt to execute the commands. I `activate testenv`, to activate my environment. > When I then run `cmake .. -G "Visual Studio 14 2015 Win64"`, I get this output: > > -- Selecting Windows SDK version? to target Windows 10.0.16299. > -- The C compiler identification is MSVC 19.0.24215.1 > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe > -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe ? works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info ? done > -- Detecting C compile features > -- Detecting C compile features - done > -- Found Git: C:/app/tools/Git/cmd/git.exe (found version "2.17.1.windows.2") > -- Could NOT find Python3: Found unsuitable version "3.6.4", but required is exact version "3.6.8" (found C:/app/anaconda3/libs/python36.lib) > -- Configuring done > -- Generating done > -- Build files have been written to: D:/src/project/vsbuild > > I would expect cmake rather to find the python in C:/app/anaconda3/envs/testenv/? since this is the active environment and according to the > HINT I set it to be favored over other python installations (as documented in https://cmake.org/cmake/help/v3.15/module/FindPython3.html). > > Additional info: > $ which python > C:/app/anaconda3/envs/testenv/python.exe > $ python ?version > Python 3.6.8 :: Anaconda, Inc. > > I?m working on Windows 10. Any ideas what is going wrong? > > Kind regards/Viele Gr??e > Sebastian M?ller > > -- > > 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 julien.jomier at kitware.com Thu Aug 1 09:55:39 2019 From: julien.jomier at kitware.com (Julien Jomier) Date: Thu, 1 Aug 2019 15:55:39 +0200 Subject: [CMake] ANN: CMake Training in France Message-ID: Kitware will be holding a CMake training course on September 30, 2019 in Lyon, France. This one-day course will cover the best practices for CMake, CTest, CPack and CDash. Please visit our website for more information and registration details: https://training.kitware.fr/browse/215/modern-cmake Note that the course will be taught in English. If you have any questions, please email me directly. We are looking forward to seeing you in Lyon, Julien From guymac at gmail.com Thu Aug 1 14:35:24 2019 From: guymac at gmail.com (Guy McArthur) Date: Thu, 1 Aug 2019 11:35:24 -0700 Subject: [CMake] help needed with target_link_libraries and INTERFACE_INCLUDE_DIRECTORIES Message-ID: I am at my wit's end after 3 days struggling with this problem. I export a package with several targets. Those targets are in subdirectories (not sure if that matters). The exported config uses a namespace. In the generated file xyz-config.cmake, I see the following: # Create imported target xyz::ABC add_library(xyz::ABC SHARED IMPORTED) set_target_properties(xyz::ABC PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "C:/Users/myself/source/repos/xyz" INTERFACE_LINK_LIBRARIES "xyz::Strings;xyz::Utility" ) And that all looks fine. Now, in a project that depends on xyz::ABC I use find_package (which seems to work fine) and target_link_libraries(libTarget xyz::ABC other::Something++). However, the build process never emits the -I include statement for xyz::ABC, though it does for other::Something++. This is on MSVC17 btw. Please help, I have tried everything I can think of. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.osipov at siemens.com Fri Aug 2 09:34:30 2019 From: michael.osipov at siemens.com (Osipov, Michael) Date: Fri, 2 Aug 2019 15:34:30 +0200 Subject: [CMake] Applying (modern) CMake to an unsual source code structure Message-ID: Hi folks, we are migrating from a homegrown Makefile generator to CMake for a fairly large codebase in C and Fortran (77, 90) (100 000+ LoC) on HP-UX with the HP compilers. So I am confined to CMake 3.9. Here is the setup: Libs: less than 10 of those, all archive libraries. The output does not produce one .a file, but all objects will be installed and a subset of those objects are assembled into archive libraries. E.g, libfoo => libfoo_1.a, libfoo_2.a, etc. It may also happen that libfoo adds an object into an archive from libbar or uses a .c or .f file from another lib via symlink -- now svn:externals -- yes, no kidding. Applications: around 150 which may contain thousands lines of code in mostly Fortran. They may apply the same scheme, link external source code into src/ or use external objects. Though, they can also link against those archive libs, some also link against libcurl or libjansson dynamically. We have a very unusual/messy code organization I cannot and will not solve now because I am not owner/writer of the code, I take care of the platform and the code may be old 20, 30+ years. Granted, I have tried to list source files, compile, link. That succeeded, but the applications never ran properly until I have applied the old scheme. The old scheme was to plain list all required objects and link them in the order of appearance and that worked. Consider make variables BHx through BHn containing: > BH3=$(WORK_OBJ)/f1204w.bin \ > $(WORK_OBJ)/f1204x.bin \ > $(WORK_OBJ)/e1204d.bin \ > $(WORK_OBJ)/g1204b.bin \ > $(WORK_OBJ)/g1204v.bin \ > $(WORK_OBJ)/c1204g.bin \ > $(SM_OBJ_fest)/tdv700.bin \ > $(WORK_OBJ)/s1204q.bin \ > $(WORK_OBJ)/f1204v.bin \ > $(WORK_OBJ)/f1204y.bin \ > $(WORK_OBJ)/w1204b.bin \ > $(WORK_OBJ)/z1204a.bin \ > $(WORK_OBJ)/z1204b.bin \ > $(WORK_OBJ)/z1204c.bin \ > $(SGRAM_OBJ_fest)/mp411.bin \ > $(SGRAM_OBJ_fest)/mp411v.bin \ > $(SGRAM_OBJ_fest)/mp412.o \ > $(SGRAM_OBJ_fest)/mp413.bin \ > $(SGRAM_OBJ_fest)/mp413g.bin \ > $(SGRAM_OBJ_fest)/mp413s.bin > > BH4=$(SGRAM_OBJ_fest)/mp413v.bin \ > $(SGRAM_OBJ_fest)/mp415.bin \ > $(SGRAM_OBJ_fest)/mpmark.o \ > $(WORK_OBJ)/z1204f.bin \ > $(WORK_OBJ)/z1204g.bin \ > $(WORK_OBJ)/z1204d.bin \ > $(SGRAM_OBJ_fest)/mp414a.bin \ > $(SGRAM_OBJ_fest)/mp414.bin \ > $(WORK_OBJ)/e1204z.bin \ > $(WORK_OBJ)/r1204b.bin \ > $(SGRAM_OBJ_fest)/mp421.bin \ > $(SGRAM_OBJ_fest)/mp422g.bin \ > $(WORK_OBJ)/s1204l.bin \ > $(WORK_OBJ)/f1204s.bin \ > $(SBM_OBJ_fest)/sb_ar1102.bin \ > $(WORK_OBJ)/g1204z.bin \ > $(WORK_OBJ)/s1204z.bin \ > $(WORK_OBJ)/z1204h.bin \ > $(WORK_OBJ)/e1204w.bin \ > $(WORK_OBJ)/f1204t.bin WORK_OBJ refers to the current object dir of the application 'di1204' whereas SGRAM, SBM, etc. are libraries. Note that .bin has been previously selected for Fortran object files. Now linking together: > di1204.p: $(BH1) $(BH2) $(BH3) $(BH4) $(BH5) $(BH6) $(BH7) $(BH8) $(BH9) $(BH10) > $(LINKER) $(BH1) $(BH2) $(BH3) $(BH4) $(BH5) $(BH6) $(BH7) $(BH8) $(BH9) $(BH10) \ > $(LINKER_OPTIONS) $(USR_BIND_OPTIONS) -o $(WORK_BIN)/di1204.p To retain this order I applied the following approach in CMake: * Each breaking/grouping block is assinged a variable with source files and an object library: > set(DI1204_5_SRC > src/e1204z.f > src/r1204b.f > ) > add_library(di1204_5 OBJECT > ${DI1204_5_SRC} > ) * External objects are solved with IMPORTED and properties on these: > add_library(sm_5 OBJECT IMPORTED) > set_property(TARGET sm_5 PROPERTY IMPORTED_OBJECTS > ${CMAKE_INSTALL_PREFIX}/obj/libsm/tdv230.pc.c.o > ${CMAKE_INSTALL_PREFIX}/obj/libsm/tdv450.f.o > ${CMAKE_INSTALL_PREFIX}/obj/libsm/tdv452.f.o > ${CMAKE_INSTALL_PREFIX}/obj/libsm/tdv469.f.o > ) * Add these object collections with generator expressions in the order they appear to the executable: > add_executable(${PROJECT_NAME} > $ > $ > $ > $ > $ > $ > $ > $ >... omitted for brevity > $ > $ > > ) * Link this executable in order of appearance: > find_library(LIBSBM_1204 sbm_1204) > find_library(LIBSBM_1102 sbm_1102) > find_library(LIBSBM_1219 sbm_1219) > find_library(LIBSBM_3460 sbm_3460) > ... omitted for brevity > find_library(LIBSGRAM_GDS000 sgram_gds000) > find_library(LIBSM_IEC sm_iec) > find_library(LIBSM_READIN_O sm_readin_o) > find_library(LIBSBLM_3401 sblm_3401) > > set(LIBS > ${LIBSBM_1204} > ${LIBSBM_1102} > ${LIBSBM_1219} > ${LIBSBM_3460} > ${LIBSBM_3424} > ${LIBSBM_1512} > ${LIBSBM_3427} > ${LIBSBM_1236} > ${LIBSBM_1235} > ${LIBSBM_1510} > ${LIBSGRAM_GDS000} > ${LIBSM_IEC} > ${LIBSM_READIN_O} > ${LIBSBLM_3401} > ${LIBCLNTSH} > ${LIBCURL} > ${LIBJANSSON} > ) > target_link_libraries(${PROJECT_NAME} ${LIBS}) At the end, and by the static linking we have to do, I need to following to work: > install(TARGETS ${PROJECT_NAME} RUNTIME DESTINATION ${BIN_DIR}) (1) > install(FILES $ DESTINATION ${OBJ_DIR}) (2) > install(FILES ${SRC} DESTINATION ${SRC_DIR}/${PROJECT_NAME}) (3) > foreach(prog_lib_name ${PROG_LIB_NAMES}) (3) > install( > DIRECTORY ${CMAKE_INSTALL_PREFIX}/progs/${prog_lib_name}/src/ > DESTINATION ${SRC_DIR}/${prog_lib_name}) > endforeach() (1) Install the executable (2) Install all internal object files of this appliction for others to use (3) Install the source code of this application for the debugger (4) Install the source code of the statically linked libraries for this application for the debugger With that approach the applications run just like before on a new machine, but with CMake now. My question now is: * Is that a reasonable way to solve this in CMake? * Is there a yet better approach to this? Best regards, Michael From guymac at gmail.com Sat Aug 3 12:36:35 2019 From: guymac at gmail.com (guymac) Date: Sat, 3 Aug 2019 09:36:35 -0700 (MST) Subject: [CMake] help needed with target_link_libraries and INTERFACE_INCLUDE_DIRECTORIES In-Reply-To: References: Message-ID: <1564850195118-0.post@n2.nabble.com> Ok, I eventually figured it out. I was under the impression that the User Package Registry did something reasonable, like the build hash was a function of the OS/version/build type. But it's not; I don't know what it is. Hence, you can have multiple entries for a project in there, and they may not have the definitions you'd expect if your project is under development. -- Sent from: http://cmake.3232098.n2.nabble.com/ From mrdakeryas at gmail.com Mon Aug 5 16:56:26 2019 From: mrdakeryas at gmail.com (Dakeryas) Date: Mon, 5 Aug 2019 13:56:26 -0700 (MST) Subject: [CMake] Separating spaces are escaped by JOIN generator expression In-Reply-To: References: Message-ID: <1565038586964-0.post@n2.nabble.com> I am facing the exact same issue when when joining libraries from a target for some CMake function defined by the Cern ROOT library (ROOT_GENERATE_DICTIONARY in that case).I am defining a list:list(APPEND DICTIONARY_INCLUDES " -I$, -I>")which is then passed to the ROOT function. I can see from the build error that all the includes have a backslash appended, i.e.:... -I/home/user/lib1/include/\ -I/home/user/lib2/include/\ -I...The BUILD_INTERFACE vs INSTALL_INTERFACE is respected, everything seems to work aside from these nasty backlashes... If I save the command manually after seeing the error and perform a string replacement to remove the backlashes, I get the desired result.Is there any fix five years later? -- Sent from: http://cmake.3232098.n2.nabble.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.chevrier at gmail.com Mon Aug 5 17:26:48 2019 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Mon, 5 Aug 2019 23:26:48 +0200 Subject: [CMake] Separating spaces are escaped by JOIN generator expression In-Reply-To: <1565038586964-0.post@n2.nabble.com> References: <1565038586964-0.post@n2.nabble.com> Message-ID: <440554f8-2489-4fc4-80c9-6087c1572d52@Spark> If you want to define a list, try to use $ rather than a space to separate the items. This way, you will get a CMake list rather than a string: list(APPEND DICTIONARY_INCLUDES "-I$,$-I>") Le 5 ao?t 2019 ? 22:56 +0200, Dakeryas , a ?crit : > I am facing the exact same issue when when joining libraries from a target for some CMake function defined by the Cern ROOT library (ROOT_GENERATE_DICTIONARY in that case). I am defining a list: list(APPEND DICTIONARY_INCLUDES " -I$, -I>") which is then passed to the ROOT function. I can see from the build error that all the includes have a backslash appended, i.e.: ... -I/home/user/lib1/include/\ -I/home/user/lib2/include/\ -I... The BUILD_INTERFACE vs INSTALL_INTERFACE is respected, everything seems to work aside from these nasty backlashes... If I save the command manually after seeing the error and perform a string replacement to remove the backlashes, I get the desired result. Is there any fix five years later? > Sent from the CMake mailing list archive at Nabble.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 federico.kircheis at gmail.com Tue Aug 6 03:18:51 2019 From: federico.kircheis at gmail.com (Federico Kircheis) Date: Tue, 6 Aug 2019 09:18:51 +0200 Subject: [CMake] Running test from cmake on windows Message-ID: <6e5b2b63-4108-a2ef-35dc-d1d314c645fe@gmail.com> Hello, I'm having some trouble understanding how I can execute my test suite uniformly on all platforms. On GNU/Linux (with `make`), I can execute ---- cmake -S "$PROJDIR" -B "$BUILDDIR" -DCMAKE_BUILD_TYPE="$build_type" -DBUILD_TESTING=ON cmake --build "$BUILDDIR" cmake --build "$BUILDDIR" --config "$build_type" --target test -- ARGS="--progress" ---- (PROJDIR points to the project directory, BUILDDIR the build directory and build_type to Release, Debug and so on) If I try to execute on Windows (with msvc and msbuild) the same commands, I get following error: -- MSBUILD : error MSB1008: Only one project can be specified. Switch: ARGS=--progress -- Which is very misleading. Removing `-- ARGS="--progress"` from the invocation yields -- MSBUILD : error MSB1009: Project file does not exist. Switch: test.vcxproj -- Looking at the generated projects, I realized there is a "RUN_TESTS" target: ---- cmake -S "$PROJDIR" -B "$BUILDDIR" -DBUILD_TESTING=ON cmake --build "$BUILDDIR" cmake --build "$BUILDDIR" --config "$build_type" --target RUN_TESTS -- ARGS="--progress" ---- still yields -- MSBUILD : error MSB1008: Only one project can be specified. Switch: ARGS=--progress -- This time removing `-- ARGS="--progress"` finally runs the tests: ---- cmake -S "$PROJDIR" -B "$BUILDDIR" -DBUILD_TESTING=ON cmake --build "$BUILDDIR" cmake --build "$BUILDDIR" --config "$build_type" --target RUN_TESTS ---- So there are 2 questions, I'm unsure if those are bugs. 1) Is there a target that I can use on any platform for running the tests, or do I need to handle every platform/build-system differently? RUN_TESTS is not a valid target with `make`. 2) How can I pass `ARGS="--progress"` on windows. This parameter is accepted by `ctest` on windows too, so it should be valid. Regards, Federico From marc.chevrier at gmail.com Tue Aug 6 11:29:26 2019 From: marc.chevrier at gmail.com (Marc CHEVRIER) Date: Tue, 6 Aug 2019 17:29:26 +0200 Subject: [CMake] Separating spaces are escaped by JOIN generator expression In-Reply-To: References: <1565038586964-0.post@n2.nabble.com> <440554f8-2489-4fc4-80c9-6087c1572d52@Spark> Message-ID: This is the way to proceed... Le 6 ao?t 2019 ? 17:23 +0200, Unknown Unknown , a ?crit : > I am getting a further by combining your idea with a "add_custom_command" and using the "COMMAND_EXPAND_LISTS" trick I have just discovered. Essentially I have something like the following to get the desired results: > > list(APPEND DICTIONARY_INCLUDES "-I$,$-I>") > > add_custom_command( > ? ? OUTPUT ${DICTIONARY_SOURCE} > ? ? COMMAND rootcling -f ${DICTIONARY_SOURCE} > ? ? ? ? ? ? ? ? ? ? ? -rml lib${PROJECT_NAME}.so > ? ? ? ? ? ? ? ? ? ? ? -rmf lib${PROJECT_NAME}.rootmap > ? ? ? ? ? ? ? ? ? ? ? -s lib${PROJECT_NAME}.so > ? ? ? ? ? ? ? ? ? ? ? -inlineInputHeader > ? ? ? ? ? ? ? ? ? ? ? "${DICTIONARY_INCLUDES}" > ? ? ? ? ? ? ? ? ? ? ? -I${CMAKE_CURRENT_SOURCE_DIR} ${DICTIONARY_HEADERS} > ? ? ? ? ? ? ? ? ? ? ? ${CMAKE_CURRENT_SOURCE_DIR}/${DICTIONARY_LINKDEF} > ? ? DEPENDS? MyLibrary ${DICTIONARY_HEADERS} ${DICTIONARY_LINKDEF} > ? ? COMMAND_EXPAND_LISTS > ) > > > Le?mar. 6 ao?t 2019 ??02:56, Marc CHEVRIER a ?crit?: > > > Oops, I mean: $ To generate a semi-colon character (I.e. ??;?) > > > Le 6 ao?t 2019 ? 00:08 +0200, Unknown Unknown , a ?crit : > > > > Bonjour Marc, > > > > > > > > Thanks for the reply! Now I get: > > > > (add_custom_command): > > > > ? Error evaluating generator expression: > > > > > > > > ? ? $ > > > > > > > > ? Expression did not evaluate to a known generator expression > > > > > > > > I am really just trying to join the INTERFACE_INCLUDE_DIRECTORIES of my target with the "- I" compiler include flags... I have since noticed that I don't get a list indeed, and that: > > > > set(DICTIONARY_INCLUDES??" -I$, -I>") > > > > does the exact same thing, i.e. the Make/Ninja command is almost perfect if it were not for those backslashes coming out of nowhere at the end of each include path! > > > > > > > > > Le?lun. 5 ao?t 2019 ??17:26, Marc CHEVRIER a ?crit?: > > > > > > If you want to define a list, try to use $ rather than a space to separate the items. This way, you will get a CMake list rather than a string: list(APPEND DICTIONARY_INCLUDES "-I$,$-I>") > > > > > > Le 5 ao?t 2019 ? 22:56 +0200, Dakeryas , a ?crit : > > > > > > > I am facing the exact same issue when when joining libraries from a target for some CMake function defined by the Cern ROOT library (ROOT_GENERATE_DICTIONARY in that case). I am defining a list: list(APPEND DICTIONARY_INCLUDES " -I$, -I>") which is then passed to the ROOT function. I can see from the build error that all the includes have a backslash appended, i.e.: ... -I/home/user/lib1/include/\ -I/home/user/lib2/include/\ -I... The BUILD_INTERFACE vs INSTALL_INTERFACE is respected, everything seems to work aside from these nasty backlashes... If I save the command manually after seeing the error and perform a string replacement to remove the backlashes, I get the desired result. Is there any fix five years later? > > > > > > > Sent from the CMake mailing list archive at Nabble.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 M.Deij at marin.nl Wed Aug 7 14:10:17 2019 From: M.Deij at marin.nl (Deij-van Rijswijk, Menno) Date: Wed, 7 Aug 2019 18:10:17 +0000 Subject: [CMake] Fortran support for ninja Message-ID: <1565201417523.97330@marin.nl> Hello, Today I was trying to use the Ninja generator for CMake on a project containing Fortran and C++ source files. I got the error that ninja is not supported with CMake unless a special version of ninja is used that supports fortran. I got the source for this version from https://github.com/Kitware/ninja , built it and put the resulting binary in the PATH. I keep getting the error that ninja is not supported, and for some reason it insists that the ninja version is 1.7.2, while the version installed is 1.9.0. How is this supposed to work? What am I doing wrong? Thanks for your insight and taking time to help me out. All the best, Menno dr. ir. Menno A. Deij-van Rijswijk | Researcher | Research & Development MARIN | T +31 317 49 35 06 | M.Deij at marin.nl | www.marin.nl [LinkedIn] [YouTube] [Twitter] [Facebook] MARIN news: 25th HISWA International Symposium, November 12 & 13 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagecad4d1.PNG Type: image/png Size: 293 bytes Desc: imagecad4d1.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image88b16c.PNG Type: image/png Size: 331 bytes Desc: image88b16c.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image9c8966.PNG Type: image/png Size: 333 bytes Desc: image9c8966.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imageb2570b.PNG Type: image/png Size: 253 bytes Desc: imageb2570b.PNG URL: From kyle.edwards at kitware.com Wed Aug 7 15:13:03 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Wed, 07 Aug 2019 15:13:03 -0400 Subject: [CMake] Fortran support for ninja In-Reply-To: <1565201417523.97330@marin.nl> References: <1565201417523.97330@marin.nl> Message-ID: <1565205183.4274.1.camel@kitware.com> On Wed, 2019-08-07 at 18:10 +0000, Deij-van Rijswijk, Menno wrote: > Hello, > > Today I was trying to use the Ninja generator for?CMake on a project > containing Fortran and C++ source files. I got the error that ninja > is not supported with CMake unless a special?version of ninja is used > that supports fortran.? > > I got the source for this version from?https://github.com/Kitware/nin > ja , built it and put the resulting binary in the PATH. > > I keep getting the error that ninja is not supported, and for some > reason it insists that the ninja version is 1.7.2, while the version > installed is 1.9.0. It sounds like it's finding another Ninja installed elsewhere on the system. Please try the following to see which Ninja CMake is finding: $ grep CMAKE_MAKE_PROGRAM:FILEPATH= CMakeCache.txt Kyle From robert.maynard at kitware.com Wed Aug 7 16:30:00 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 7 Aug 2019 16:30:00 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.15.2 available for download Message-ID: We are pleased to announce that CMake 3.15.2 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.15.2 since 3.15.1: Brad King (8): Swift: Restore support for enabling with INTERFACE libraries VS: Fix mapping of `-Qspectre-` flag source_group: Fix regression in relative FILES clang: Restore support for clang-cl on non-Windows hosts fileapi: Fix codemodel target install destination for cross-dir rules clang: Work around toolchain file use of internal CMake variables Help: Add 3.15.2 release notes CMake 3.15.2 Claudio Fantacci (3): FindGLEW: Fix macOS library suffix selection FindGLEW: Add required OpenGL dependency in macOS FindGLEW: Fix typo in verbose log message Cristian Adam (1): find_package: Fix prefer-config mode to not fail on missing optional package From hzhou3 at clemson.edu Thu Aug 8 22:33:36 2019 From: hzhou3 at clemson.edu (Heng Zhou) Date: Thu, 8 Aug 2019 22:33:36 -0400 Subject: [CMake] How to use --build and --parallel? Message-ID: Hi, I want to build a project using all cores of the machine. After cmake .., I have tried cmake --build --parallel . and cmake --build . --parallel , but none of them works. So, what is the correct usage of --build and --parallel when using them together? I have read the documentation https://cmake.org/cmake/help/latest/manual/cmake.1.html#build-tool-mode but still could not figure out. Thanks for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Aug 9 00:25:21 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 9 Aug 2019 06:25:21 +0200 Subject: [CMake] How to use --build and --parallel? In-Reply-To: References: Message-ID: Le ven. 9 ao?t 2019 ? 04:40, Heng Zhou a ?crit : > Hi, > > I want to build a project using all cores of the machine. After cmake .., > I have tried > > cmake --build --parallel . > > and > > cmake --build . --parallel > > , but none of them works. So, what is the correct usage of --build and > --parallel when using them together? I have read the documentation > https://cmake.org/cmake/help/latest/manual/cmake.1.html#build-tool-mode > but still could not figure out. Thanks for your help. > Try providing a number of parallel job after the --parallel option. Depending on the native build tool used you won't get automatic number of parallel jobs. Which CMake generator are you using? > -- > > 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 eric.noulard at gmail.com Fri Aug 9 01:09:20 2019 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 9 Aug 2019 07:09:20 +0200 Subject: [CMake] How to use --build and --parallel? In-Reply-To: References: Message-ID: Le ven. 9 ao?t 2019 ? 06:44, Heng Zhou a ?crit : > I am working on ubuntu 16.04, so the generator is the default "Unix > Makefiles" which I did not specify. I don't think it is related to the lack > of the parallel job number (I added 4 but with the same error). I just > wanna confirm whether I wrote the syntax correctly. An example would > suffice. > this sequence works for me on Debian 9 and CMake 3.13.2: cd buildir cmake -G /path/to/srcdir cmake --build --parallel . What kind or error do you get when you do that? > On Fri, Aug 9, 2019 at 12:25 AM Eric Noulard > wrote: > >> >> >> Le ven. 9 ao?t 2019 ? 04:40, Heng Zhou a ?crit : >> >>> Hi, >>> >>> I want to build a project using all cores of the machine. After cmake >>> .., I have tried >>> >>> cmake --build --parallel . >>> >>> and >>> >>> cmake --build . --parallel >>> >>> , but none of them works. So, what is the correct usage of --build and >>> --parallel when using them together? I have read the documentation >>> https://cmake.org/cmake/help/latest/manual/cmake.1.html#build-tool-mode >>> but still could not figure out. Thanks for your help. >>> >> >> Try providing a number of parallel job after the --parallel option. >> Depending on the native build tool used you won't get automatic number of >> parallel jobs. >> Which CMake generator are you using? >> >>> -- >>> >>> 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 i.ivanov at trassir.com Fri Aug 9 08:34:22 2019 From: i.ivanov at trassir.com (=?UTF-8?B?0JjQs9C+0YDRjCDQmNCy0LDQvdC+0LI=?=) Date: Fri, 09 Aug 2019 15:34:22 +0300 Subject: [CMake] =?utf-8?q?Adjusting_CTest_Test=2Exml_results_for_Jenkins?= Message-ID: <1565354062.442283126@f338.i.mail.ru> We are using Jenkins and want it to parse CTest results. There is already a plugin for that, that takes Test.xml produced by `ctest -T Test` as an input. In `Test.xml` there are records like this: ???????? TEST-netutils /var/lib/jenkins/workspace/build/tech1utils /var/lib/jenkins/workspace/build/tech1utils/TEST-netutils /var/lib/jenkins/workspace/build/tech1utils/test-netutils-core2 We run `cmake --build; ctest` multiple times in different directories for x86+x64 and Debug+Release builds, which results in multiple `Test.xml` files. After aggregating them, Jenkins plugin outputs report like this: ?? projectroot.var.lib.jenkins.workspace.build: ?? ? tech1utils: ??? ?? TEST_netutils? 5.3 sec? Passed ??? ?? TEST_netutils? 5.1 sec? Passed ??? ?? TEST_netutils? 2.8 sec? Passed ??? ?? TEST_netutils? 2.9 sec? Passed which is kinda unreadable, you cannot immediately guess which test is which one. Turns out that if we replace the property in XML from `/var/lib/jenkins/workspace/build` to something like `build-32-debug`, the report becomes more readable: ?? projectroot.build-32-debug: ???? tech1utils: ??? ?? TEST_netutils? 5.3 sec? Passed ?? projectroot.build-64-debug: ?? ? tech1utils: ??? ?? TEST_netutils? 5.1 sec? Passed ?? ... Is it possible to feed to CTest some -Dparameters or ENV_VARS to provide needed values in Path, instead of writing a script to replace XML contents afterwards? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.thompson at nasa.gov Mon Aug 12 07:59:42 2019 From: matthew.thompson at nasa.gov (Thompson, Matt (GSFC-610.1)[SCIENCE SYSTEMS AND APPLICATIONS INC]) Date: Mon, 12 Aug 2019 11:59:42 +0000 Subject: [CMake] [EXTERNAL] Fortran support for ninja Message-ID: <477D7DA5-3500-45A8-BB7D-4AC2FD10322E@nasa.gov> Menno, I believe the issue is that Ninja doesn't yet support Fortran. Brad King's dyndep code was accepted in this pull: https://github.com/ninja-build/ninja/pull/1521 but that has not yet been released but I believe 1.10 is supposed to have it from what I've read on other issues. Until then, like many of us Fortran + Ninja users, I recommend going to: https://github.com/Kitware/ninja/releases and downloading a release there. Hopefully soon 1.10 will solve this. (That said, 1.8.2 to 1.9.0 took 700 days, so if that holds, 1.10 will be released on December 30, 2020...so keep the Kitware link around!) Matt -- Matt Thompson, SSAI, Ld Scientific Programmer/Analyst NASA GSFC, Global Modeling and Assimilation Office Code 610.1, 8800 Greenbelt Rd, Greenbelt, MD 20771 Phone: 301-614-6712 Fax: 301-614-6246 http://science.gsfc.nasa.gov/sed/bio/matthew.thompson From: CMake on behalf of "Deij-van Rijswijk, Menno" Date: Wednesday, August 7, 2019 at 2:56 PM To: "cmake at cmake.org" Subject: [EXTERNAL] [CMake] Fortran support for ninja Hello, Today I was trying to use the Ninja generator for CMake on a project containing Fortran and C++ source files. I got the error that ninja is not supported with CMake unless a special version of ninja is used that supports fortran. I got the source for this version from https://github.com/Kitware/ninja , built it and put the resulting binary in the PATH. I keep getting the error that ninja is not supported, and for some reason it insists that the ninja version is 1.7.2, while the version installed is 1.9.0. How is this supposed to work? What am I doing wrong? Thanks for your insight and taking time to help me out. All the best, Menno dr. ir. Menno A. Deij-van Rijswijk | Researcher | Research & Development MARIN | T +31 317 49 35 06 | M.Deij at marin.nl | www.marin.nl [LinkedIn] [YouTube] [Twitter] [Facebook] MARIN news: 25th HISWA International Symposium, November 12 & 13 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 294 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 332 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 334 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 254 bytes Desc: image004.png URL: From matthew.thompson at nasa.gov Mon Aug 12 08:09:52 2019 From: matthew.thompson at nasa.gov (Thompson, Matt (GSFC-610.1)[SCIENCE SYSTEMS AND APPLICATIONS INC]) Date: Mon, 12 Aug 2019 12:09:52 +0000 Subject: [CMake] [EXTERNAL] Fortran support for ninja Message-ID: <3D12AC6E-E4E1-4A3B-AF1B-C788A0E47B96@nasa.gov> Whoops. Apologies all. First, I didn't quite read the URL in Menno's message correctly because my new Office 365 work email munges URLs something fierce (think ~30 characters to ~300 characters). Glad he was using Kitware's! Second, apparently Office 365 is delaying messages from this list by about 5 days. This is going to be exciting. Ashamedly yours, Matt -- Matt Thompson, SSAI, Ld Scientific Programmer/Analyst NASA GSFC, Global Modeling and Assimilation Office Code 610.1, 8800 Greenbelt Rd, Greenbelt, MD 20771 Phone: 301-614-6712 Fax: 301-614-6246 http://science.gsfc.nasa.gov/sed/bio/matthew.thompson From: CMake on behalf of "Deij-van Rijswijk, Menno" Date: Wednesday, August 7, 2019 at 2:56 PM To: "cmake at cmake.org" Subject: [EXTERNAL] [CMake] Fortran support for ninja Hello, Today I was trying to use the Ninja generator for CMake on a project containing Fortran and C++ source files. I got the error that ninja is not supported with CMake unless a special version of ninja is used that supports fortran. I got the source for this version from https://github.com/Kitware/ninja , built it and put the resulting binary in the PATH. I keep getting the error that ninja is not supported, and for some reason it insists that the ninja version is 1.7.2, while the version installed is 1.9.0. How is this supposed to work? What am I doing wrong? Thanks for your insight and taking time to help me out. All the best, Menno dr. ir. Menno A. Deij-van Rijswijk | Researcher | Research & Development MARIN | T +31 317 49 35 06 | M.Deij at marin.nl | www.marin.nl [LinkedIn] [YouTube] [Twitter] [Facebook] MARIN news: 25th HISWA International Symposium, November 12 & 13 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 294 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 332 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 334 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 254 bytes Desc: image004.png URL: From johan556 at gmail.com Wed Aug 14 05:29:50 2019 From: johan556 at gmail.com (Johan Holmberg) Date: Wed, 14 Aug 2019 11:29:50 +0200 Subject: [CMake] Tree-like trace of add_subdirectory & include? Message-ID: Hi! I'm trying to understand a large project built with CMake, and think it would be very helpful to get a view of which CMake-file "calls" which other CMake-file. I'm interested in the chain of calls using "add_subdirectory" and "include". I have looked at the options "--debug-output" and "--trace", but they only give a "flat" view of the call graph. And reconstructing a tree-like representation from that info seems non-trivial to me. I'm hoping to get something like this (I hope the intended indentation can be seen): CMakeLists.txt .... MyMacros/Setup.cmake .... .... MyMacros/OtherStuff.cmake .... lib1/CMakeLists.txt .... lib2/CMakeLists.txt .... Misc/CMakeLists.txt .... .... prog_a/CMakeLists.txt .... .... prog_b/CMakeLists.txt .... foo/CMakeLists.txt Is there some way to accomplish this, or something similar? /Johan Holmberg -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.Deij at marin.nl Wed Aug 14 05:53:13 2019 From: M.Deij at marin.nl (Deij-van Rijswijk, Menno) Date: Wed, 14 Aug 2019 09:53:13 +0000 Subject: [CMake] Tree-like trace of add_subdirectory & include? Message-ID: <3bb4c62a76364defbf406e3da9d17af2@MAR190n2.marin.local> Hi Johan, Have you tried the trace mode of CMake? I got reasonably useful results with cmake [path] [options] --trace 2>&1 | grep subdirectory Gr, Menno From: CMake > On Behalf Of Johan Holmberg Sent: Wednesday, August 14, 2019 11:30 AM To: cmake at cmake.org Subject: [CMake] Tree-like trace of add_subdirectory & include? Hi! I'm trying to understand a large project built with CMake, and think it would be very helpful to get a view of which CMake-file "calls" which other CMake-file. I'm interested in the chain of calls using "add_subdirectory" and "include". I have looked at the options "--debug-output" and "--trace", but they only give a "flat" view of the call graph. And reconstructing a tree-like representation from that info seems non-trivial to me. I'm hoping to get something like this (I hope the intended indentation can be seen): CMakeLists.txt .... MyMacros/Setup.cmake .... .... MyMacros/OtherStuff.cmake .... lib1/CMakeLists.txt .... lib2/CMakeLists.txt .... Misc/CMakeLists.txt .... .... prog_a/CMakeLists.txt .... .... prog_b/CMakeLists.txt .... foo/CMakeLists.txt Is there some way to accomplish this, or something similar? /Johan Holmberg Help us improve the spam filter. If this message contains SPAM, click here to report. Thank you, MARIN Support Group dr. ir. Menno A. Deij-van Rijswijk | Researcher | Research & Development MARIN | T +31 317 49 35 06 | M.Deij at marin.nl | www.marin.nl [LinkedIn] [YouTube] [Twitter] [Facebook] MARIN news: Alternative fuels and power systems for support vessels -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image7e5eb8.PNG Type: image/png Size: 293 bytes Desc: image7e5eb8.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image0d3e9a.PNG Type: image/png Size: 331 bytes Desc: image0d3e9a.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: imagee0ea3e.PNG Type: image/png Size: 333 bytes Desc: imagee0ea3e.PNG URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image91d01a.PNG Type: image/png Size: 253 bytes Desc: image91d01a.PNG URL: From hong at topbug.net Thu Aug 15 20:49:33 2019 From: hong at topbug.net (Hong Xu) Date: Thu, 15 Aug 2019 17:49:33 -0700 Subject: [CMake] Ways to require CUDA arch minimum version? Message-ID: Is there a way to enforce a minimum CUDA arch version when finding CUDA? Hong From robert.maynard at kitware.com Fri Aug 16 10:41:33 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 16 Aug 2019 10:41:33 -0400 Subject: [CMake] Ways to require CUDA arch minimum version? In-Reply-To: References: Message-ID: Are you asking for a minimum CUDA SDK version or a restriction based on the hardware of the machine? We have no pre-built logic to enforce a minimum hardware component, as we want to support building CUDA on a machine without a GPU. As far as minimum CUDA SDK is concerned if you are doing it through find_package(CUDA) you would check the version after and error out if not high enough As farm as CUDA as a first class language, you can check the CMAKE_CUDA_COMPILER_VERSION and error out. On Thu, Aug 15, 2019 at 9:34 PM Hong Xu wrote: > > Is there a way to enforce a minimum CUDA arch version when finding CUDA? > Hong > > -- > > 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 hong at topbug.net Fri Aug 16 13:23:32 2019 From: hong at topbug.net (Hong Xu) Date: Fri, 16 Aug 2019 10:23:32 -0700 Subject: [CMake] Ways to require CUDA arch minimum version? In-Reply-To: References: Message-ID: Thanks, I am interested in enforcing minimum computing capacity (which translates to hardware restraint). If there is no such feature, would you be interested for such a feature? Hong On August 16, 2019 7:41:33 AM PDT, Robert Maynard wrote: >Are you asking for a minimum CUDA SDK version or a restriction based >on the hardware of the machine? > >We have no pre-built logic to enforce a minimum hardware component, as >we want to support building CUDA on a machine without a GPU. >As far as minimum CUDA SDK is concerned if you are doing it through >find_package(CUDA) you would check the version after and error out if >not high enough >As farm as CUDA as a first class language, you can check the >CMAKE_CUDA_COMPILER_VERSION and error out. > >On Thu, Aug 15, 2019 at 9:34 PM Hong Xu wrote: >> >> Is there a way to enforce a minimum CUDA arch version when finding >CUDA? >> Hong >> >> -- >> >> 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 mike.jackson at bluequartz.net Fri Aug 16 13:54:16 2019 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 16 Aug 2019 13:54:16 -0400 Subject: [CMake] How to specify VS2017 compilers when on VS2019 Message-ID: <98F40277-9A8F-4974-B0A5-F47C5608D28C@bluequartz.net> What are the values to the -T argument that are to be used so that I can use VS2019 but have the 2017 compilers? -- Mike Jackson -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Fri Aug 16 14:09:42 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Fri, 16 Aug 2019 14:09:42 -0400 Subject: [CMake] How to specify VS2017 compilers when on VS2019 In-Reply-To: <98F40277-9A8F-4974-B0A5-F47C5608D28C@bluequartz.net> References: <98F40277-9A8F-4974-B0A5-F47C5608D28C@bluequartz.net> Message-ID: <1565978982.17708.5.camel@kitware.com> On Fri, 2019-08-16 at 13:54 -0400, Michael Jackson wrote: > What are the values to the -T argument that are to be used so that I > can use VS2019 but have the 2017 compilers? Rather than using a -T argument, you want to set the CC environment variable or -DCMAKE_C_COMPILER on the command line (likewise for CXX and CMAKE_CXX_COMPILER.) Kyle From mike.jackson at bluequartz.net Fri Aug 16 14:19:27 2019 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Fri, 16 Aug 2019 14:19:27 -0400 Subject: [CMake] How to specify VS2017 compilers when on VS2019 In-Reply-To: <1565978982.17708.5.camel@kitware.com> References: <98F40277-9A8F-4974-B0A5-F47C5608D28C@bluequartz.net> <1565978982.17708.5.camel@kitware.com> Message-ID: Why can't I do -T v141? -- Mike Jackson ?On 8/16/19, 2:09 PM, "Kyle Edwards" wrote: On Fri, 2019-08-16 at 13:54 -0400, Michael Jackson wrote: > What are the values to the -T argument that are to be used so that I > can use VS2019 but have the 2017 compilers? Rather than using a -T argument, you want to set the CC environment variable or -DCMAKE_C_COMPILER on the command line (likewise for CXX and CMAKE_CXX_COMPILER.) Kyle From baradi09 at gmail.com Fri Aug 16 15:24:15 2019 From: baradi09 at gmail.com (=?UTF-8?Q?B=c3=a1lint_Aradi?=) Date: Fri, 16 Aug 2019 21:24:15 +0200 Subject: [CMake] ExternalProject install Message-ID: <7c0b0c41-ad65-5fe3-c515-931bb5f17482@gmail.com> Dear All, I try to understand the install logic for ExternalProjects. I added several CMake-based external projects to my main build, using the ExternalProject_Add() method. If I generate the build system and issue 'make install', the external projects install routines are also triggered. Is that the expected behaviour? (I have set INSTALL_COMMAND to "" in the ExternalProject_Add() call.) Is there a way, to switch this behaviour on or off? The only way I could achieve this was to put the CMakeLists.txt with the ExternalProject_Add() call into a subfolder and call that subfolder with add_subdirectory(.... EXCLUDE_FROM_ALL). But this is somewhat inconvinient, since I have to switch the installation on and off depending on a variable, so I have to add if(BUILD_API) add_subdirectory(...) else() add_subdirectory(... EXCLUDE_FROM_ALL) endif() branches for each subproject. Setting EXCLUDE_FROM_ALL TRUE or FALSE in ExternalProject_Add() routine did not help either. Any other suggestions? Thanks in advance. Best regards, B?lint -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From d3ck0r at gmail.com Fri Aug 16 17:19:18 2019 From: d3ck0r at gmail.com (J Decker) Date: Fri, 16 Aug 2019 14:19:18 -0700 Subject: [CMake] How to specify VS2017 compilers when on VS2019 In-Reply-To: References: <98F40277-9A8F-4974-B0A5-F47C5608D28C@bluequartz.net> <1565978982.17708.5.camel@kitware.com> Message-ID: can just specify the 2017 generator, 2019 will load an build it just fine. If 2017 is still opening when you double-click a solution, change your default handler for .sln files to 2019. Again, 2019 can build projects as is for 2017, 2015, etc... On Fri, Aug 16, 2019 at 11:19 AM Michael Jackson < mike.jackson at bluequartz.net> wrote: > Why can't I do -T v141? > > -- > Mike Jackson > > ?On 8/16/19, 2:09 PM, "Kyle Edwards" wrote: > > On Fri, 2019-08-16 at 13:54 -0400, Michael Jackson wrote: > > What are the values to the -T argument that are to be used so that I > > can use VS2019 but have the 2017 compilers? > > Rather than using a -T argument, you want to set the CC environment > variable or -DCMAKE_C_COMPILER on the command line (likewise for CXX > and CMAKE_CXX_COMPILER.) > > 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 dustyn at blasig.us Mon Aug 19 00:07:10 2019 From: dustyn at blasig.us (Dustyn Blasig) Date: Sun, 18 Aug 2019 23:07:10 -0500 Subject: [CMake] Install needed libraries from add_subdirectory(... EXCLUDE_FROM_ALL) Message-ID: Hi All, We have a build hierarchy of projects and generally we import needed projects into higher-level projects with EXLUDE_FROM_ALL so only dependency targets that are needed by the "uber" builds are built. However, if the subdirectory build produces shared libraries, we need those shared libraries to get installed with the uber project files. The documentation for EXCLUDE_FROM_ALL says the install behavior is undefined. However, I'm curious if there is a known "should work" workaround we can use, with the caveat we'll have to test things to make sure it works. I added all the transitive dependencies to the install rules in the owning package to make progress, but that will be tricky once each part needs to be truly installed by clients separately. Note, I'm stuck for now with supporting 3.12.4 as the minimum CMake requirement most likely. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From regev.ran at gmail.com Mon Aug 19 07:34:30 2019 From: regev.ran at gmail.com (Ran Regev) Date: Mon, 19 Aug 2019 14:34:30 +0300 Subject: [CMake] install externally supplied include and lib Message-ID: Hello, I have a very simple problem, which I don't find a solution for: I'm working with a company that once in a while sends me two directories, one with .h files and the second with a library in two forms, shared and static. say - X/include/* X/lib/libX.so X/lib/libX.a I would like to create a cmake project that just wrap this input and do this simple action: installs the headers and the library. When I'm fine with the 'install only' mode I would add XConfig.cmake, aliases and maybe more. But first I need to find a way to create the correct target and install it. Ran. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guymac at gmail.com Mon Aug 19 13:52:23 2019 From: guymac at gmail.com (Guy Mac) Date: Mon, 19 Aug 2019 10:52:23 -0700 Subject: [CMake] install externally supplied include and lib In-Reply-To: References: Message-ID: <6ce1ab66-2cef-0135-1350-8c357f11dc17@gmail.com> Ran, I did something like that with the following: cmake_minimum_required(VERSION 3.11) project(X) include(GNUInstallDirs) set(X_inc "${CMAKE_CURRENT_SOURCE_DIR}/include/") set(X_lib "${CMAKE_CURRENT_SOURCE_DIR}/lib/") install(DIRECTORY ${X_lib} DESTINATION ${CMAKE_INSTALL_LIBDIR} FILES_MATCHING PATTERN "libX*.*") install(DIRECTORY ${X_inc} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR} FILES_MATCHING PATTERN "*.h") -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeppeter at gmail.com Tue Aug 20 03:58:59 2019 From: jeppeter at gmail.com (wang jeppeter) Date: Tue, 20 Aug 2019 15:58:59 +0800 Subject: [CMake] howto compile cmake source code with visual studio 2019 on windows platform Message-ID: Hi: i have read from README.rst in the github.com/Kitware/cmake but i never find howto compile cmake source code with visual studio 2019 ,can somebody tell me howto ,thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Aug 20 10:36:00 2019 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 20 Aug 2019 10:36:00 -0400 Subject: [CMake] How to specify VS2017 compilers when on VS2019 In-Reply-To: References: <98F40277-9A8F-4974-B0A5-F47C5608D28C@bluequartz.net> <1565978982.17708.5.camel@kitware.com> Message-ID: You can use that method so you get the IDE features of VS2019 but the VS2017 compiler. On Fri, Aug 16, 2019 at 2:19 PM Michael Jackson wrote: > > Why can't I do -T v141? > > -- > Mike Jackson > > ?On 8/16/19, 2:09 PM, "Kyle Edwards" wrote: > > On Fri, 2019-08-16 at 13:54 -0400, Michael Jackson wrote: > > What are the values to the -T argument that are to be used so that I > > can use VS2019 but have the 2017 compilers? > > Rather than using a -T argument, you want to set the CC environment > variable or -DCMAKE_C_COMPILER on the command line (likewise for CXX > and CMAKE_CXX_COMPILER.) > > 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 From smitropoulos at edps.gr Wed Aug 21 05:16:39 2019 From: smitropoulos at edps.gr (Stefanos Mitropoulos) Date: Wed, 21 Aug 2019 12:16:39 +0300 Subject: [CMake] Using find_package with different build trees Message-ID: <241fde4d-2103-6395-c64e-8a15c15f4cc0@edps.gr> Hello all! I am trying to follow the modern cmake path and use the find_packages()/link libraries way. I am using a test scenario in which: LIB_B depends on LIB_A and EXEC_A depends on both. I was wondering how you could link EXEC_A to the debug lib version of LIB_B and the release version of LIB_A or vice versa. On LIB_A I am using set(CMAKE_DEBUG_POSTFIX "-debug") so my LIB_A is going to be LIB_A-debug when making the debug tree. I install them in /usr/local/lib and both reside there. For example let's say I have this line of code in LIB_A: |#ifdef Release printf("THIS IS RELEASE MODE"); #endif | This is going to differentiate LIB_A and LIB_A-debug. in EXEC_A I would use |find_package(LIBA REQUIRED) add_executable(EXEC_A main.cpp) target_link_libraries(EXEC_A PUBLIC LIBS::LIBA LIBS::LIBB) | assuming I have exported the libraries in the LIBS namespace. Is there any way to differentiate between library versions? EDIT: I am on Linux (centos) and using GCC 8. My CMake version is 3.14 -- Email Signature Stefanos Mitropoulos Developer Logo EDPS S.A. t: 30-210-8993660 e: smitropoulos at edps.gr www.edps.gr The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mojca at macports.org Wed Aug 21 07:57:40 2019 From: mojca at macports.org (Mojca Miklavec) Date: Wed, 21 Aug 2019 13:57:40 +0200 Subject: [CMake] Ways to require CUDA arch minimum version? In-Reply-To: References: Message-ID: On Fri, 16 Aug 2019 at 03:34, Hong Xu wrote: > > Is there a way to enforce a minimum CUDA arch version when finding CUDA? > Hong I don't know if the following is the correct advice, but I use the following code in my setup to enforce Pascal: string(APPEND CMAKE_CUDA_FLAGS " -gencode arch=compute_60,code=sm_60") else my code would not compile once I started using some newer directives. I believe that more archs would be needed in the string for better support of newer architectures, but just to get the starting point. I would have preferred if there was a better directive, similar to set(CMAKE_CXX_STANDARD 14) that can enable either C++14 or C++17 or later (depending on other components of the project) without actually harcoding c++14 and ending up with "-std=c++14 -std=c++20" in flags. For example something along the lines of set(CMAKE_CUDA_MIN_ARCH 60) Mojca From Alan.W.Irwin1234 at gmail.com Wed Aug 21 16:37:07 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Wed, 21 Aug 2019 13:37:07 -0700 (PDT) Subject: [CMake] Plan to deal with remaining D language support issues for PLplot Message-ID: Hi Ben: You know this already from our off-list discussion, but for other's here, the PLplot's ancient fork of the cmaked project works well for gdc, but is completely broken (doesn't even compile a test example) with dmd on my Linux (Debian Buster) platform. So I have been trying the [cmake-d](https://github.com/dcarp/cmake-d) project (suitably patched for PLplot needs) instead for our D language support. That support currently works well for gdc, and also *almost* works well for dmd (and probably ldc as well although I am concentrating on the dmd case at the moment). The remaining issues for cmake-d appear to be 1. # "D" version: set(CMAKE_LIBRARY_PATH_FLAG "-L-L") set(CMAKE_LINK_LIBRARY_FLAG "-L-l") for the dmd and also the ldc cases. This conflicts with support for our other languages on Linux which sets # "C" version set(CMAKE_LIBRARY_PATH_FLAG "-L") set(CMAKE_LINK_LIBRARY_FLAG "-l") 2. Libraries linked by full pathname cannot be linked properly by dmd and lcd (since they both need an "-L" prefix to such pathnames to pass those to the linker). I took a look at [another D support project that you recommended to me off list](https://github.com/trentforkert/cmake/) that project contained the following commit: Author: Ben Boeckel Date: Tue Apr 15 00:21:15 2014 -0400 linking: Support language-specific link flags Adds support for the following variables: * CMAKE__LINK_LIBRARY_FLAG * CMAKE__LINK_LIBRARY_FILE_FLAG * CMAKE__LINK_LIBRARY_SUFFIX * CMAKE__LINK_PATH_FLAG * CMAKE__LINK_PATH_TERMINATOR so that compilers with different flags can be used in the same build. M Help/manual/cmake-variables.7.rst A Help/variable/CMAKE_LANG_LIBRARY_PATH_FLAG.rst A Help/variable/CMAKE_LANG_LINK_LIBRARY_FILE_FLAG.rst A Help/variable/CMAKE_LANG_LINK_LIBRARY_FLAG.rst A Help/variable/CMAKE_LANG_LINK_LIBRARY_SUFFIX.rst M Source/cmComputeLinkInformation.cxx M Source/cmLocalGenerator.cxx It appears from those documentation files that this commit would help to solve both issues 1. and 2. above. Therefore, my planned next step is to rebase that commit on the upstream cmake master branch, and test that patched upstream result to see if those limited internal CMake changes allow fixing (with minor patching of cmake-d files) all remaining cmake-d issues for the PLplot use case. More later as the above plan unfolds.... 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.org); 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 Alan.W.Irwin1234 at gmail.com Wed Aug 21 22:17:39 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Wed, 21 Aug 2019 19:17:39 -0700 (PDT) Subject: [CMake] Plan to deal with remaining D language support issues for PLplot In-Reply-To: References: Message-ID: On 2019-08-21 13:37-0700 Alan W. Irwin wrote: > I took a look at [another D support project that you recommended to me > off list](https://github.com/trentforkert/cmake/) that project > contained the following commit: > > Author: Ben Boeckel > Date: Tue Apr 15 00:21:15 2014 -0400 [...] > [My] planned next step > is to rebase that commit on the upstream cmake master branch, and test > that patched upstream result to see if those limited internal CMake > changes allow fixing (with minor patching of cmake-d files) all > remaining cmake-d issues for the PLplot use case. Indeed, all issues in (patched) cmake-d have now been solved by this commit (now rebased to the cmake upstream cmake master branch which required some conflict resolution). The results for this patched upstream cmake for all of gdc, ldc, and dmd pass our stringent tests of our D examples (where we compare SVG plot file results for our ~30 D examples with corresponding results for the equivalent C examples) for our three major PLplot configurations (shared libraries + dynamic devices, shared libraries + nondynamic devices, and static libraries + nondynamic devices). In order for PLplot users other than me to be able to take advantage of these additional internal CMake capabilities for some future release of upstream CMake, I request you pull the attached commit (which is non-intrusive and rebased from your single commit above for the trentforkert version) into the appropriate branch of upstream cmake development. Please let me know if there are any technical issues with this pull request because it has been a long time since I have made such a request to CMake developers. 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.org); 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 __________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-linking-Support-language-specific-link-flags.patch.gz Type: application/x-gtar-compressed Size: 1777 bytes Desc: Upstream CMake pull request (in compressed git format-patch form) URL: From Alan.W.Irwin1234 at gmail.com Thu Aug 22 16:53:53 2019 From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin) Date: Thu, 22 Aug 2019 13:53:53 -0700 (PDT) Subject: [CMake] Plan to deal with remaining D language support issues for PLplot In-Reply-To: References: Message-ID: On 2019-08-21 19:17-0700 Alan W. Irwin wrote: > Please let me know if there are any technical issues with this > pull request because it has been a long time since I > have made such a request to CMake developers. I have now made this pull request available on the bug tracker, see . 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.org); 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 kkituyi at yahoo.com Fri Aug 23 10:19:50 2019 From: kkituyi at yahoo.com (kennedy kituyi) Date: Fri, 23 Aug 2019 17:19:50 +0300 Subject: [CMake] CMAKE+WIX RUN A PROGRAM AFTER INSTALL SUCCEEDS Message-ID: Hi how do I configure cpack in cmake to execute a custom command in the install directory. I want to install windows service that is packaged within my installer and extracted to specific install location. Thanks in advance Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sancelot at numalliance.com Wed Aug 28 05:39:05 2019 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Wed, 28 Aug 2019 11:39:05 +0200 Subject: [CMake] find_path / find_package hardcoded path Message-ID: <136a31c5-d7b0-772f-4f5b-9214b7a045f2@numalliance.com> Hi, using mingw32 with win10 , I can not manage to find jpeg libs . I tried setting JPEG_DIR, it fails. it also fails setting CMAKE_FIND_ROOT_PATH set(JPEG_DIR c:\\work\\WIN32DEPS\\jpegfolder) find_path(JPEG_INCLUDE_DIR jpeglib.h) fails find_package(JPEG ) fails what is the right way to specify the hardcoded path ? Regards, S.Ancelot -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Wed Aug 28 05:56:37 2019 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 28 Aug 2019 11:56:37 +0200 Subject: [CMake] find_path / find_package hardcoded path In-Reply-To: <136a31c5-d7b0-772f-4f5b-9214b7a045f2@numalliance.com> References: <136a31c5-d7b0-772f-4f5b-9214b7a045f2@numalliance.com> Message-ID: Am 2019-08-28 11:39, schrieb St?phane Ancelot: > Hi, > > using mingw32 with win10 , I can not manage to find jpeg libs . > > I tried setting JPEG_DIR, it fails. > > it also fails setting CMAKE_FIND_ROOT_PATH > > set(JPEG_DIR c:\\work\\WIN32DEPS\\jpegfolder) Use forward slashes. Don't do it in the CMakeLists.txt as it is something happening only on your system, so pass it on the command line, e.g. as cmake -D CMAKE_PREFIX_PATH=c:/work/win32deps/jpegfolder Eike -- From regev.ran at gmail.com Wed Aug 28 06:28:34 2019 From: regev.ran at gmail.com (Ran Regev) Date: Wed, 28 Aug 2019 13:28:34 +0300 Subject: [CMake] find_path / find_package hardcoded path In-Reply-To: References: <136a31c5-d7b0-772f-4f5b-9214b7a045f2@numalliance.com> Message-ID: I think you can also add "PATHS" or "HINTS" to find_package. Ran. On Wed, Aug 28, 2019 at 1:03 PM Rolf Eike Beer wrote: > Am 2019-08-28 11:39, schrieb St?phane Ancelot: > > Hi, > > > > using mingw32 with win10 , I can not manage to find jpeg libs . > > > > I tried setting JPEG_DIR, it fails. > > > > it also fails setting CMAKE_FIND_ROOT_PATH > > > > set(JPEG_DIR c:\\work\\WIN32DEPS\\jpegfolder) > > Use forward slashes. Don't do it in the CMakeLists.txt as it is > something happening only on your system, so pass it on the command line, > e.g. as > > cmake -D CMAKE_PREFIX_PATH=c:/work/win32deps/jpegfolder > > Eike > -- > -- > > 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 eike at sf-mail.de Wed Aug 28 06:45:02 2019 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 28 Aug 2019 12:45:02 +0200 Subject: [CMake] find_path / find_package hardcoded path In-Reply-To: References: <136a31c5-d7b0-772f-4f5b-9214b7a045f2@numalliance.com> Message-ID: <78fd828fe26689d3f006dec76fb3c7ad@sf-mail.de> Am 2019-08-28 12:28, schrieb Ran Regev: > I think you can also add "PATHS" or "HINTS" to find_package. Yes, but this has a different purpose. It's idea is to provide places to look at based on other things already found, things that would work independent of the machine. The plan here is to provide information about the local directories, and those should not end up in CMakeLists.txt as they are totally meaningless when switching to a different machine. One could use an initial cache file for this if this has to be done over and over again on the same machine, or add a shell alias (or a shell alias to the cache file, which is more flexible). Eike From Muthusamy.Deepan at in.bosch.com Thu Aug 29 01:51:35 2019 From: Muthusamy.Deepan at in.bosch.com (Deepan Muthusamy (RBEI/ESP-IS44)) Date: Thu, 29 Aug 2019 05:51:35 +0000 Subject: [CMake] cmake for GHS Message-ID: I want to compile c and c++ code in GHS compiler for renesas controller. For Mingw compiler, My code is compiling successfully. But I want to compile for GHS. I have compiler available at this path "C:/ghs/comp_201255_RH850". When generate, I gave option as "specify native compiler". C compiler : C:/ghs/comp_201255_RH850/ccrh850.exe C++ compiler: C:/ghs/comp_201255_RH850/cxrh850.exe I am getting the following error. Green Hills MULTI: -A not specified; defaulting to "arm" Green Hills MULTI: GHS_TARGET_PLATFORM not specified; defaulting to "integrity" Green Hills MULTI: -T not specified; defaulting to "C:/ghs/comp_201255_RH850" The C compiler identification is GHS The CXX compiler identification is GHS Check for working C compiler: C:/ghs/comp_201255_RH850/ccrh850.exe Check for working C compiler: C:/ghs/comp_201255_RH850/ccrh850.exe -- broken CMake Error at D:/e-bike/cmake-3.14.3-win64-x64/share/cmake-3.14/Modules/CMakeTestCCompiler.cmake:60 (message): The C compiler "C:/ghs/comp_201255_RH850/ccrh850.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeTmp Run Build Command(s):C:/ghs/comp_201255_RH850/gbuild.exe -top CMAKE_TRY_COMPILE.top.gpj cmTC_d9171.gpj Error: Could not read target file: arm_integrity.tgt CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:6 (project) Configuring incomplete, errors occurred! See also "D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeOutput.log". See also "D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeError.log". So How to configure GHS for CMAKE build. Please advice me in this, Thanks in advace Best regards, Muthusamy Deepan RBEI/ESP6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdk17 at ftml.net Thu Aug 29 08:14:34 2019 From: fdk17 at ftml.net (fdk17) Date: Thu, 29 Aug 2019 08:14:34 -0400 Subject: [CMake] cmake for GHS In-Reply-To: References: Message-ID: On Thu, Aug 29, 2019, at 1:51 AM, Deepan Muthusamy (RBEI/ESP-IS44) via CMake wrote: > I want to compile c and c++ code in GHS compiler for renesas controller. > > For Mingw compiler, My code is compiling successfully. But I want to compile for GHS. > > I have compiler available at this path "C:/ghs/comp_201255_RH850". > > When generate, I gave option as ?specify native compiler?. > C compiler : C:/ghs/comp_201255_RH850/ccrh850.exe > C++ compiler: C:/ghs/comp_201255_RH850/cxrh850.exe > > > I am getting the following error. > > > > Green Hills MULTI: -A not specified; defaulting to "arm" > Green Hills MULTI: GHS_TARGET_PLATFORM not specified; defaulting to "integrity" > Green Hills MULTI: -T not specified; defaulting to "C:/ghs/comp_201255_RH850" > The C compiler identification is GHS > The CXX compiler identification is GHS > Check for working C compiler: C:/ghs/comp_201255_RH850/ccrh850.exe > Check for working C compiler: C:/ghs/comp_201255_RH850/ccrh850.exe -- broken > CMake Error at D:/e-bike/cmake-3.14.3-win64-x64/share/cmake-3.14/Modules/CMakeTestCCompiler.cmake:60 (message): > The C compiler > > "C:/ghs/comp_201255_RH850/ccrh850.exe" > > is not able to compile a simple test program. > > It fails with the following output: > > Change Dir: D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeTmp > > Run Build Command(s):C:/ghs/comp_201255_RH850/gbuild.exe -top CMAKE_TRY_COMPILE.top.gpj cmTC_d9171.gpj > Error: Could not read target file: arm_integrity.tgt > > CMake will not be able to correctly generate this project. > Call Stack (most recent call first): > CMakeLists.txt:6 (project) > Configuring incomplete, errors occurred! > See also "D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeOutput.log". > See also "D:/e-bike/EbikeSource/src/Crc16/build/CMakeFiles/CMakeError.log". > > > > So How to configure GHS for CMAKE build. Please advice me in this, Thanks in advace > > > > > > Best regards, > > *Muthusamy Deepan > RBEI/ESP6 * https://cmake.org/cmake/help/v3.15/generator/Green%20Hills%20MULTI.html It sound's like you want to generate a GHS Multi project. The "CMAKE__COMPILER" variables are not used for compiling GHS Multi projects. The GHS build tool gbuild handles those kinds of details. You do need to set GHS_TARGET_PLATFORM and specify the target architecture so that a correct GHS Multi project for your target can be built. You can inspect the GHS example projects delivered to you as part of your GHS installation to determine those values. Usually its something like "arm" and "integrity", which is one of the reasons those were chosen as the default. I'd highly recommend reading the GHS manual and looking at the example projects to understand how a GHS Multi project works if you are not already familiar with it. -- F -------------- next part -------------- An HTML attachment was scrubbed... URL: From sancelot at numalliance.com Thu Aug 29 09:14:10 2019 From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=) Date: Thu, 29 Aug 2019 15:14:10 +0200 Subject: [CMake] using fetch_content imported modules and not system one Message-ID: <5f3eba72-db91-5a48-7cdb-3a315fda85e5@numalliance.com> hi, i used fetch_content to download bullet library , but I cant use it. FetchContent_Declare( ? bullet ? GIT_REPOSITORY https://github.com/bulletphysics/bullet3.git ? GIT_TAG??????? 2.88 ) FetchContent_GetProperties(bullet) if(NOT bullet_POPULATED) ? FetchContent_Populate(bullet) ? add_subdirectory(${bullet_SOURCE_DIR} ${bullet_BINARY_DIR}) endif() linking using bullet does not permit to find any include or lib file -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Thu Aug 29 13:27:19 2019 From: hex7c3 at gmail.com (hex) Date: Thu, 29 Aug 2019 18:27:19 +0100 Subject: [CMake] modify cmake build arguments Message-ID: <6cfae12a-b323-1ecc-abab-5af7e055b4f5@gmail.com> hello community, CMake builds a C project with /gcc -o target_name/. I have a compiler very similar to GCC and I am trying configure CMake C language for it. The compiler does not support the -o argument when linking objects. I wonder if there is a way to remove or modify this argument, maybe through one of the properties on targets? thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Thu Aug 29 14:52:56 2019 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Thu, 29 Aug 2019 14:52:56 -0400 Subject: [CMake] modify cmake build arguments In-Reply-To: <6cfae12a-b323-1ecc-abab-5af7e055b4f5@gmail.com> References: <6cfae12a-b323-1ecc-abab-5af7e055b4f5@gmail.com> Message-ID: <1567104776.751.15.camel@kitware.com> On Thu, 2019-08-29 at 18:27 +0100, hex wrote: > hello community, > > CMake builds a C project with gcc -o target_name. I have a compiler > very similar to GCC and I am trying configure CMake C language for > it. > > The compiler does not support the -o argument when linking objects. I > wonder if there is a way to remove or modify this argument, maybe > through one of the properties on targets? > > thank you Your best bet would be to modify the CMake source code to support your compiler. (Upstreaming your changes would be welcome.) As a matter of interest, what does it use instead of -o? Kyle From fdk17 at ftml.net Thu Aug 29 16:38:09 2019 From: fdk17 at ftml.net (fdk17) Date: Thu, 29 Aug 2019 16:38:09 -0400 Subject: [CMake] modify cmake build arguments In-Reply-To: <1567104776.751.15.camel@kitware.com> References: <6cfae12a-b323-1ecc-abab-5af7e055b4f5@gmail.com> <1567104776.751.15.camel@kitware.com> Message-ID: <5ed95f43-eb25-4ac4-86fb-dd72c1a791e4@www.fastmail.com> On Thu, Aug 29, 2019, at 2:52 PM, Kyle Edwards via CMake wrote: > On Thu, 2019-08-29 at 18:27 +0100, hex wrote: > > hello community, > > > > CMake builds a C project with gcc -o target_name. I have a compiler > > very similar to GCC and I am trying configure CMake C language for > > it. > > > > The compiler does not support the -o argument when linking objects. I > > wonder if there is a way to remove or modify this argument, maybe > > through one of the properties on targets? > > > > thank you > > Your best bet would be to modify the CMake source code to support your > compiler. (Upstreaming your changes would be welcome.) > > As a matter of interest, what does it use instead of -o? > > Kyle If you are using the Makefile generator then try: https://cmake.org/cmake/help/latest/variable/CMAKE_USER_MAKE_RULES_OVERRIDE.html You may then be able to provide the rules needed, refer to "Modules/CMakeCInformation.cmake". The way I understand it is that the rule templates are used by the Makefile generator. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Thu Aug 29 18:02:51 2019 From: craig.scott at crascit.com (Craig Scott) Date: Fri, 30 Aug 2019 08:02:51 +1000 Subject: [CMake] using fetch_content imported modules and not system one In-Reply-To: <5f3eba72-db91-5a48-7cdb-3a315fda85e5@numalliance.com> References: <5f3eba72-db91-5a48-7cdb-3a315fda85e5@numalliance.com> Message-ID: On Thu, Aug 29, 2019 at 11:14 PM St?phane Ancelot wrote: > hi, > > i used fetch_content to download bullet library , but I cant use it. > > FetchContent_Declare( > bullet > GIT_REPOSITORY https://github.com/bulletphysics/bullet3.git > GIT_TAG 2.88 > > ) > > FetchContent_GetProperties(bullet) > if(NOT bullet_POPULATED) > FetchContent_Populate(bullet) > add_subdirectory(${bullet_SOURCE_DIR} ${bullet_BINARY_DIR}) > endif() > > linking using bullet does not permit to find any include or lib file > Your FetchContent usage looks fine. I had a quick scan through the bullet project and it uses very old CMake patterns. In particular, it doesn't use any of the target-centered commands like target_include_directories(), etc. This means it doesn't define PUBLIC or INTERFACE properties on targets, which is why when you try to link to the bullet targets and include its headers, they aren't being found. Nothing is telling consumers of those libraries where to look. Ideally, the bullet project would update to more modern CMake practices, but that's not always a priority for projects that others manage. If you need to get this working for your build, you will have to manually add the missing header search paths and inter-library dependencies in your own project. You can still call target_include_directories() on the bullet targets from outside of the bullet source tree. You would do this immediately after the add_subdirectory() call, something like the following structure: if(NOT bullet_POPULATED) FetchContent_Populate(bullet) add_subdirectory(${bullet_SOURCE_DIR} ${bullet_BINARY_DIR} target_include_directories(Bullet3Common INTERFACE ${bullet_SOURCE_DIR}/src ${bullet_SOURCE_DIR}/src/Bullet3Common ... more as you work out what is needed ) endif() -- 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 doenges at mvtec.com Fri Aug 30 01:47:57 2019 From: doenges at mvtec.com (Eric Doenges) Date: Fri, 30 Aug 2019 07:47:57 +0200 Subject: [CMake] modify cmake build arguments In-Reply-To: <5ed95f43-eb25-4ac4-86fb-dd72c1a791e4@www.fastmail.com> References: <6cfae12a-b323-1ecc-abab-5af7e055b4f5@gmail.com> <1567104776.751.15.camel@kitware.com> <5ed95f43-eb25-4ac4-86fb-dd72c1a791e4@www.fastmail.com> Message-ID: <509c4819-db0f-6e5f-e972-d93412b59c2d@mvtec.com> An HTML attachment was scrubbed... URL: From fdk17 at ftml.net Fri Aug 30 05:28:10 2019 From: fdk17 at ftml.net (fdk17) Date: Fri, 30 Aug 2019 05:28:10 -0400 Subject: [CMake] modify cmake build arguments In-Reply-To: <509c4819-db0f-6e5f-e972-d93412b59c2d@mvtec.com> References: <6cfae12a-b323-1ecc-abab-5af7e055b4f5@gmail.com> <1567104776.751.15.camel@kitware.com> <5ed95f43-eb25-4ac4-86fb-dd72c1a791e4@www.fastmail.com> <509c4819-db0f-6e5f-e972-d93412b59c2d@mvtec.com> Message-ID: <98393c25-af5f-496d-a18d-8000ec1f3baf@www.fastmail.com> On Fri, Aug 30, 2019, at 1:47 AM, Eric Doenges wrote: > On 29.08.2019 22:38, fdk17 wrote: >> On Thu, Aug 29, 2019, at 2:52 PM, Kyle Edwards via CMake wrote: >>> On Thu, 2019-08-29 at 18:27 +0100, hex wrote: >>> > hello community, >>> > >>> > CMake builds a C project with gcc -o target_name. I have a compiler >>> > very similar to GCC and I am trying configure CMake C language for >>> > it. >>> > >>> > The compiler does not support the -o argument when linking objects. I >>> > wonder if there is a way to remove or modify this argument, maybe >>> > through one of the properties on targets? >>> > >>> > thank you >>> >>> Your best bet would be to modify the CMake source code to support your >>> compiler. (Upstreaming your changes would be welcome.) >>> >>> As a matter of interest, what does it use instead of -o? >>> >>> Kyle >> >> If you are using the Makefile generator then try: >> https://cmake.org/cmake/help/latest/variable/CMAKE_USER_MAKE_RULES_OVERRIDE.html >> You may then be able to provide the rules needed, refer to "Modules/CMakeCInformation.cmake". >> The way I understand it is that the rule templates are used by the Makefile generator. >> > The way I understand the documentation, CMAKE_USER_MAKE_RULES_OVERRIDE applies for all generators, not just the Makefile one. What you are apparently supposed to do is create a file that sets all the "rule variables" as required (in this case, CMAKE_C_COMPILE_OBJECT), and then include that file via CMAKE_USER_MAKE_RULES_OVERRIDE. I'm not sure if these 'rule variables' are documented anywhere - but you can look into "/share/cmake-/Modules/Compiler" for inspiration. Another good starting point would be "<...>/share/cmake-/Modules/CMakeCInformation.cmake". > > With kind regards, > Eric > > *Dr. Eric D?nges * > Senior Software Engineer > I could have been clearer about the use of CMAKE_USER_MAKE_RULES_OVERRIDE. It wasn't my intention to suggest that only the Makefile generator makes use of this variable. In a quick check I only saw the CMAKE_C_COMPILE_OBJECT rule being used by the Makefile (and maybe the Ninja) generator and I know that it isn't used by the GHS Multi generator. Which is why I mentioned the Makefile generator specifically in regards to changing a "-o" to something else. If you look at Modules/CMakeCInformation.cmake it will only define a rule if it hasn't already been previously set either by the definitions in the compiler / platform files that get included first and then by the override file. You won't need to define all the rules in the override file just the ones you care to change. Also not all of the rules that get defined applies to all of generators (such as CMAKE_C_COMPILE_OBJECT as already mentioned). A good example to follow is Modules/Compiler/TI-C.cmake to change a "-o" to something else. From TI-C.cmake: set(CMAKE_C_COMPILE_OBJECT " --compile_only --c_file= --output_file=") Then as suggested the override file could be the basis of a new compiler file that gets submitted upstream. -- F -------------- next part -------------- An HTML attachment was scrubbed... URL: From fdk17 at ftml.net Fri Aug 30 05:45:07 2019 From: fdk17 at ftml.net (fdk17) Date: Fri, 30 Aug 2019 05:45:07 -0400 Subject: [CMake] modify cmake build arguments In-Reply-To: <98393c25-af5f-496d-a18d-8000ec1f3baf@www.fastmail.com> References: <6cfae12a-b323-1ecc-abab-5af7e055b4f5@gmail.com> <1567104776.751.15.camel@kitware.com> <5ed95f43-eb25-4ac4-86fb-dd72c1a791e4@www.fastmail.com> <509c4819-db0f-6e5f-e972-d93412b59c2d@mvtec.com> <98393c25-af5f-496d-a18d-8000ec1f3baf@www.fastmail.com> Message-ID: <2cd70e38-0c7b-4a28-8fac-95f6904e2e23@www.fastmail.com> >>>> On Thu, 2019-08-29 at 18:27 +0100, hex wrote: >>>> > hello community, >>>> > >>>> > CMake builds a C project with gcc -o target_name. I have a compiler >>>> > very similar to GCC and I am trying configure CMake C language for >>>> > it. >>>> > >>>> > The compiler does not support the -o argument when linking objects. I >>>> > wonder if there is a way to remove or modify this argument, maybe >>>> > through one of the properties on targets? >>>> > >>>> > thank you >>>> >>>> Your best bet would be to modify the CMake source code to support your >>>> compiler. (Upstreaming your changes would be welcome.) >>>> >>>> As a matter of interest, what does it use instead of -o? >>>> >>>> Kyle >>> For linking objects it would be overriding CMAKE_C_LINK_EXECUTABLE: For example from the TI-C.cmake file: set(CMAKE_C_LINK_EXECUTABLE " --run_linker --output_file= --map_file=.map ") -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Fri Aug 30 06:15:19 2019 From: hex7c3 at gmail.com (hex) Date: Fri, 30 Aug 2019 11:15:19 +0100 Subject: [CMake] Fwd: modify cmake build arguments In-Reply-To: References: Message-ID: <0cd3c0e7-9642-39a7-887c-39186700ef2a@gmail.com> thank you this is exactly what I am looking for. It is working well. From the documentation: ?It is loaded after CMake?s builtin compiler and platform information modules have been loaded but before the information is used.? since CMakeCInformation.cmake: # compile a C file into an object file if(NOT CMAKE_C_COMPILE_OBJECT) ? set(CMAKE_C_COMPILE_OBJECT ??? " -o ?? -c ") endif() CMAKE_USER_MAKE_RULES_OVERRIDE_C must be set before the language is set, i.e. before any `enable_language()` or `project()` instruction. On 30/08/2019 06:47, Eric Doenges wrote: > > The way I understand the documentation, CMAKE_USER_MAKE_RULES_OVERRIDE > applies for all generators, not just the Makefile one. What you are > apparently supposed to do is create a file that sets all the "rule > variables" as required (in this case, CMAKE_C_COMPILE_OBJECT), and > then include that file via CMAKE_USER_MAKE_RULES_OVERRIDE. I'm not > sure if these 'rule variables' are documented anywhere - but you can > look into " installed>/share/cmake-/Modules/Compiler" for inspiration. > Another good starting point would be > "<...>/share/cmake-/Modules/CMakeCInformation.cmake". > > With kind regards, > Eric > > *Dr. Eric D?nges * > Senior Software Engineer > > MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany > doenges at mvtec.com | Tel: +49 89 457 695-0 | > www.mvtec.com > > Sign up for our MVTec Newsletter! > > Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt > Amtsgericht M?nchen HRB 114695 > > MVTec Software GmbH Logo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Fri Aug 30 06:16:24 2019 From: hex7c3 at gmail.com (hex) Date: Fri, 30 Aug 2019 11:16:24 +0100 Subject: [CMake] modify cmake build arguments In-Reply-To: <0cd3c0e7-9642-39a7-887c-39186700ef2a@gmail.com> References: <0cd3c0e7-9642-39a7-887c-39186700ef2a@gmail.com> Message-ID: <511a8be0-8952-725c-1802-40babdf8f801@gmail.com> thank you this is exactly what I am looking for. It is working well. From the documentation: ?It is loaded after CMake?s builtin compiler and platform information modules have been loaded but before the information is used.? since CMakeCInformation.cmake: # compile a C file into an object file if(NOT CMAKE_C_COMPILE_OBJECT) ? set(CMAKE_C_COMPILE_OBJECT ??? " -o ?? -c ") endif() CMAKE_USER_MAKE_RULES_OVERRIDE_C must be set before the language is set, i.e. before any `enable_language()` or `project()` instruction. On 30/08/2019 06:47, Eric Doenges wrote: > > The way I understand the documentation, CMAKE_USER_MAKE_RULES_OVERRIDE > applies for all generators, not just the Makefile one. What you are > apparently supposed to do is create a file that sets all the "rule > variables" as required (in this case, CMAKE_C_COMPILE_OBJECT), and > then include that file via CMAKE_USER_MAKE_RULES_OVERRIDE. I'm not > sure if these 'rule variables' are documented anywhere - but you can > look into " installed>/share/cmake-/Modules/Compiler" for inspiration. > Another good starting point would be > "<...>/share/cmake-/Modules/CMakeCInformation.cmake". > > With kind regards, > Eric > > *Dr. Eric D?nges * > Senior Software Engineer > > MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany > doenges at mvtec.com | Tel: +49 89 457 695-0 | > www.mvtec.com > > Sign up for our MVTec Newsletter! > > Gesch?ftsf?hrer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt > Amtsgericht M?nchen HRB 114695 > > MVTec Software GmbH Logo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hex7c3 at gmail.com Fri Aug 30 06:18:29 2019 From: hex7c3 at gmail.com (Hex) Date: Fri, 30 Aug 2019 03:18:29 -0700 (MST) Subject: [CMake] modify cmake build arguments In-Reply-To: <2cd70e38-0c7b-4a28-8fac-95f6904e2e23@www.fastmail.com> References: <6cfae12a-b323-1ecc-abab-5af7e055b4f5@gmail.com> <1567104776.751.15.camel@kitware.com> <5ed95f43-eb25-4ac4-86fb-dd72c1a791e4@www.fastmail.com> <509c4819-db0f-6e5f-e972-d93412b59c2d@mvtec.com> <98393c25-af5f-496d-a18d-8000ec1f3baf@www.fastmail.com> <2cd70e38-0c7b-4a28-8fac-95f6904e2e23@www.fastmail.com> Message-ID: <1567160309271-0.post@n2.nabble.com> thank you this is exactly what I am looking for. It is working well. >From the documentation: ?It is loaded after CMake?s builtin compiler and platform information modules have been loaded but before the information is used.? since CMakeCInformation.cmake: # compile a C file into an object file if(NOT CMAKE_C_COMPILE_OBJECT) set(CMAKE_C_COMPILE_OBJECT " -o -c ") endif() CMAKE_USER_MAKE_RULES_OVERRIDE_C must be set before the language is set, i.e. before any `enable_language()` or `project()` instruction. -- Sent from: http://cmake.3232098.n2.nabble.com/ From hex7c3 at gmail.com Fri Aug 30 07:41:27 2019 From: hex7c3 at gmail.com (hex) Date: Fri, 30 Aug 2019 12:41:27 +0100 Subject: [CMake] modify cmake build arguments In-Reply-To: <1567160309271-0.post@n2.nabble.com> References: <1567160309271-0.post@n2.nabble.com> Message-ID: I am still facing a problem: The build step is skipped only the link step is performed (I missed that in the beginning). It seems like the build step does not have any dependencies. This is because different file extension are used. I cannot set CMAKE_C_SOURCE_FILE_EXTENSIONS because I believe `project` redefines the variable. If I set it afterwards it does not take effect. For now it works if I change the source file extension. From hex7c3 at gmail.com Fri Aug 30 08:07:11 2019 From: hex7c3 at gmail.com (hex) Date: Fri, 30 Aug 2019 13:07:11 +0100 Subject: [CMake] modify cmake build arguments In-Reply-To: References: <1567160309271-0.post@n2.nabble.com> Message-ID: <59db9ead-eab4-c312-31fc-922bcb9a40c2@gmail.com> It does work after setting CMAKE_C_SOURCE_FILE_EXTENSIONS inside the override. It should be set in a CMakeDetermineCompiler file though. I'll add language support for it next. As a side note, wouldn't it be better to replace CMake/Modules/CMakeCCompiler.cmake.in: /set(CMAKE_C_SOURCE_FILE_EXTENSIONS c;m)/ with: /list(APPEND CMAKE_C_SOURCE_FILE_EXTENSIONS c;m )/ ? On 30/08/2019 12:41, hex wrote: > I am still facing a problem: The build step is skipped only the link > step is performed (I missed that in the beginning). It seems like the > build step does not have any dependencies. > > > This is because different file extension are used. I cannot set > CMAKE_C_SOURCE_FILE_EXTENSIONS because I believe `project` redefines > the variable. If I set it afterwards it does not take effect. For now > it works if I change the source file extension. > -------------- next part -------------- An HTML attachment was scrubbed... URL: