From bernhard.seckinger at gmx.de Thu Mar 2 04:12:39 2017 From: bernhard.seckinger at gmx.de (Bernhard Seckinger) Date: Thu, 2 Mar 2017 10:12:39 +0100 Subject: [CMake] -DCMAKE_BUILD_TYPE=Release breaks build process Message-ID: <20170302101239.c4e1c31584c7aaaa74a4cb57@gmx.de> Hi all, I'm relatively new to cmake and tried to use it for one of my projects. Meanwhile I've got a working version, but when I try to build with -DCMAKE_BUILD_TYPE=Release the linker complains about missing functions. I guess, that this happens, because all the files are compiled separately and -O3 removes some functions (or inlines them or whatever). When I compile manually using -O3, everything works, but in that case I do compilation of all files and linking in one stroke. I'm using cmake-d (1), a cmake extension to compile D-files. On my computer (debian, testing) cmake chooses gdc for compilation which is a D-frontend to gcc. I'm quite unsure how I should proceed to make it work. Although I read various tutorials and stuff about cmake I still feel not like having understood, what's going on behind the scenes. (What I'm missing is something like the autotools-guide (2) for cmake.) Maybe you can give me some ideas on how to proceed? Berni PS: And of course, if anyone would like to have a direct look at my project and give some comments on it, I'd be really happy. You can find it at github (3). PPS: I asked a similar question in the D-Forum, but got no answers there, probably because it's the wrong place to do so... (1) https://github.com/dcarp/cmake-d (2) http://freesoftwaremagazine.com/articles/autotools_a_guide_to_autoconf_automake_libtool/ (3) https://github.com/crocopaw/croco/tree/devel -- -- Meine R?tselwebseite: www.croco-puzzle.com From jan.hegewald at awi.de Thu Mar 2 05:57:48 2017 From: jan.hegewald at awi.de (=?utf-8?B?8J+QiyBKYW4gSGVnZXdhbGQ=?=) Date: Thu, 2 Mar 2017 11:57:48 +0100 Subject: [CMake] -DCMAKE_BUILD_TYPE=Release breaks build process In-Reply-To: <20170302101239.c4e1c31584c7aaaa74a4cb57@gmx.de> References: <20170302101239.c4e1c31584c7aaaa74a4cb57@gmx.de> Message-ID: Hi Berni, > On 2 Mar 2017, at 10:12, Bernhard Seckinger wrote: ... > but when I try to build with > -DCMAKE_BUILD_TYPE=Release the linker complains about missing functions. ... > Maybe you can give me some ideas on how to proceed? ... just a general idea as how to approach this: - make a clean cmake directory and try again, or at least remove the CMakeCache.txt - if you use the make generator, add -DCMAKE_VERBOSE_MAKEFILE=ON when calling cmake to know what exactly is being used during build HTH, Jan Hegewald From annulen at yandex.ru Thu Mar 2 06:35:45 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 02 Mar 2017 14:35:45 +0300 Subject: [CMake] -DCMAKE_BUILD_TYPE=Release breaks build process In-Reply-To: References: <20170302101239.c4e1c31584c7aaaa74a4cb57@gmx.de> Message-ID: <1781011488454545@web18o.yandex.ru> 02.03.2017, 13:58, "? Jan Hegewald" : > Hi Berni, > >> ?On 2 Mar 2017, at 10:12, Bernhard Seckinger wrote: > > ... >> ?but when I try to build with >> ?-DCMAKE_BUILD_TYPE=Release the linker complains about missing functions. > > ... >> ?Maybe you can give me some ideas on how to proceed? > > ... > > just a general idea as how to approach this: > - make a clean cmake directory and try again, or at least remove the CMakeCache.txt > - if you use the make generator, add -DCMAKE_VERBOSE_MAKEFILE=ON when calling cmake to know what exactly is being used during build This is not a good advice, better don't touch CMAKE_VERBOSE_MAKEFILE and use make VERBOSE=1 whenever you want to see details > > HTH, > Jan Hegewald > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin From bernhard.seckinger at gmx.de Thu Mar 2 07:01:46 2017 From: bernhard.seckinger at gmx.de (Bernhard Seckinger) Date: Thu, 2 Mar 2017 13:01:46 +0100 Subject: [CMake] -DCMAKE_BUILD_TYPE=Release breaks build process In-Reply-To: References: <20170302101239.c4e1c31584c7aaaa74a4cb57@gmx.de> Message-ID: <20170302130146.839497194aed6f815899438a@gmx.de> Hi Jan, > just a general idea as how to approach this: > - make a clean cmake directory and try again, or at least remove the > CMakeCache.txt I'm allready doing this all the time... :-) > - if you use the make generator, add -DCMAKE_VERBOSE_MAKEFILE=ON when > calling cmake to know what exactly is being used during build Basically it's (works) /usr/bin/gdc -I.. -fversion=slang -oCMakeFiles/starbattle.dir/__/puzzle -c /home/berni/Croco/Entwicklung/Croco/types/puzzle.d [...] /usr/bin/gdc CMakeFiles/starbattle.dir/starbattle CMakeFiles/starbattle.dir/starbattle_check_puzzle CMakeFiles/starbattle.dir/starbattle_check_solution CMakeFiles/starbattle.dir/__/puzzle CMakeFiles/starbattle.dir/__/puzzle_options CMakeFiles/starbattle.dir/__/puzzle_unittest CMakeFiles/starbattle.dir/__/spf_tools CMakeFiles/starbattle.dir/__/puzzle_io CMakeFiles/starbattle.dir/__/puzzle_timer CMakeFiles/starbattle.dir/__/slang -ostarbattle -L/usr/lib/gcc/x86_64-linux-gnu/6 ../libslang_wrapper.o.a -lslang -lc vs. (does not work) /usr/bin/gdc -O3 -fomit-frame-pointer -fweb -frelease -finline-functions -I.. -fversion=slang -oCMakeFiles/starbattle.dir/__/puzzle -c /home/berni/Croco/Entwicklung/Croco/types/puzzle.d [...] /usr/bin/gdc -O3 -fomit-frame-pointer -fweb -frelease -finline-functions CMakeFiles/starbattle.dir/starbattle CMakeFiles/starbattle.dir/starbattle_check_puzzle CMakeFiles/starbattle.dir/starbattle_check_solution CMakeFiles/starbattle.dir/__/puzzle CMakeFiles/starbattle.dir/__/puzzle_options CMakeFiles/starbattle.dir/__/puzzle_unittest CMakeFiles/starbattle.dir/__/spf_tools CMakeFiles/starbattle.dir/__/puzzle_io CMakeFiles/starbattle.dir/__/puzzle_timer CMakeFiles/starbattle.dir/__/slang -ostarbattle -L/usr/lib/gcc/x86_64-linux-gnu/6 ../libslang_wrapper.o.a -lslang -lc One can even remove "-fomit-frame-pointer -fweb -frelease -finline-functions" and set -O1 instead of -O3 to get the same result. And that's the output of the last call: CMakeFiles/starbattle.dir/starbattle_check_puzzle: In function `_DT256_D25starbattle_check_solution25Starbattle_Check_Solution16extract_solutionMFHAyaAyaZv': starbattle_check_puzzle.d: (.text._DT256_D25starbattle_check_solution25Starbattle_Check_Solution16extract_solutionMFHAyaAyaZv [_DT256_D25starbattle_check_solution25Starbattle_Check_Solution16extract_solutionMFHAyaAyaZv] +0x8e): undefined reference to `_D25starbattle_check_solution25Starbattle_Check_Solution16extract_solutionMFHAyaAyaZ12__dgliteral2MFNaNbNiNfZAxa' CMakeFiles/starbattle.dir/starbattle_check_puzzle: In function `_DT256_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZv': starbattle_check_puzzle.d: (.text._DT256_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZv [_DT256_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZv]+0x12): undefined reference to `_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZ12__dgliteral2MFNaNbNiNfZAya' starbattle_check_puzzle.d: (.text._DT256_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZv [_DT256_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZv]+0xbd): undefined reference to `_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZ12__dgliteral3MFNaNbNiNfZAya' CMakeFiles/starbattle.dir/starbattle_check_solution: In function `_DT96_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZv': starbattle_check_solution.d: (.text._DT96_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZv [_DT96_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZv]+0xf): undefined reference to `_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZ12__dgliteral2MFNaNbNiNfZAya' starbattle_check_solution.d: (.text._DT96_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZv [_DT96_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZv]+0xba): undefined reference to `_D10starbattle10Starbattle14extract_puzzleMFHAyaAyaZ12__dgliteral3MFNaNbNiNfZAya' collect2: error: ld returned 1 exit status Berni -- -- Meine R?tselwebseite: www.croco-puzzle.com From aishwaryaselvaraj1708 at gmail.com Thu Mar 2 07:07:48 2017 From: aishwaryaselvaraj1708 at gmail.com (aishwarya selvaraj) Date: Thu, 2 Mar 2017 16:37:48 +0430 Subject: [CMake] libsndfile in winodws Message-ID: Hi all , I was trying to build my .cpp file in windows in Windows platform (windows 10) using cmake . My .cpp file makes use of two external libraries 1)armadillo 2)libsnd file. I have written a corresponding cmakelist.txt to compile and obtain the binary . I was successful in doing so in Linux , when it come to Windows I obtain the following error . *3>Time Elapsed 00:00:02.062> Current branch master is up to date.2> No patch step for 'project_libsndfile'2> Performing autogen step for 'project_libsndfile'2> Performing configure step for 'project_libsndfile'2> 'C:\Users\computing7\Desktop\TSM_cmake\build\lib\libsndfile\src\project_libsndfile\configure' is not recognized as an internal or external command,2> operable program or batch file.2> 1>2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 9009.2> Done executing task "CustomBuild" -- FAILED.2> 1>2>Done building target "CustomBuild" in project "project_libsndfile.vcxproj" -- FAILED.2>2>Build FAILED.* PFA of the cmakelist.txt in case for clarifications. Why does this error come ? Is it possible to compile and build libsndfile in windows successfully ? -- Regards, Aishwarya Selvaraj -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- CMAKE_MINIMUM_REQUIRED(VERSION 2.8) PROJECT(TSM2) include(ExternalProject) MESSAGE(STATUS "Trying to install armadillo...") ExternalProject_Add(armadillo URL https://github.com/lsolanka/armadillo/archive/master.zip PREFIX ${CMAKE_CURRENT_BINARY_DIR}/armadillo_library CONFIGURE_COMMAND "" #--Build step----------------- BUILD_COMMAND "" #--Install step--------------- UPDATE_COMMAND "" # Skip annoying updates for every build INSTALL_COMMAND "" ) include_directories(${CMAKE_CURRENT_BINARY_DIR}/armadillo_library/src/armadillo/include) include(ExternalProject) MESSAGE(STATUS "Trying to install libsndfile...") ExternalProject_Add(project_libsndfile GIT_REPOSITORY https://github.com/erikd/libsndfile.git PREFIX lib/libsndfile CONFIGURE_COMMAND /configure BUILD_COMMAND make BUILD_IN_SOURCE 1 INSTALL_COMMAND echo Skipping install step for libsndfile ) ExternalProject_Add_Step(project_libsndfile autogen COMMAND /autogen.sh DEPENDEES update DEPENDERS configure ) ExternalProject_Get_Property(project_libsndfile BINARY_DIR) SET(libsndfile_lib_dir "${BINARY_DIR}/src/.libs") SET(libsndfile_inc_dir "${BINARY_DIR}/src") ADD_LIBRARY(libsndfile STATIC IMPORTED) SET_PROPERTY(TARGET libsndfile PROPERTY IMPORTED_LOCATION ${libsndfile_lib_dir}/libsndfile.a) SET(LIBSNDFILE_INCLUDE_PATH "${install_dir}/src/project_libsndfile-build/src/") INCLUDE_DIRECTORIES(include ${libsndfile_inc_dir}) ADD_EXECUTABLE(tsm ${PROJECT_SOURCE_DIR}/src/TSM_CODE_V3.cpp) TARGET_LINK_LIBRARIES(tsm ${ARMADILLO} libsndfile ) From dan at su-root.co.uk Thu Mar 2 07:38:23 2017 From: dan at su-root.co.uk (Dan Liew) Date: Thu, 2 Mar 2017 12:38:23 +0000 Subject: [CMake] libsndfile in winodws In-Reply-To: References: Message-ID: On 2 March 2017 at 12:07, aishwarya selvaraj wrote: > Hi all , > I was trying to build my .cpp file in windows in Windows platform (windows > 10) using cmake . > My .cpp file makes use of two external libraries 1)armadillo 2)libsnd file. > I have written a corresponding cmakelist.txt to compile and obtain the > binary . > I was successful in doing so in Linux , when it come to Windows I obtain the > following error . > > 3>Time Elapsed 00:00:02.06 > 2> Current branch master is up to date. > 2> No patch step for 'project_libsndfile' > 2> Performing autogen step for 'project_libsndfile' > 2> Performing configure step for 'project_libsndfile' > 2> > 'C:\Users\computing7\Desktop\TSM_cmake\build\lib\libsndfile\src\project_libsndfile\configure' > is not recognized as an internal or external command, > 2> operable program or batch file. Above is your clue. Your build could not run `configure`. Your problem is most likely in ``` ExternalProject_Add(project_libsndfile GIT_REPOSITORY https://github.com/erikd/libsndfile.git PREFIX lib/libsndfile CONFIGURE_COMMAND /configure BUILD_COMMAND make BUILD_IN_SOURCE 1 INSTALL_COMMAND echo Skipping install step for libsndfile ) ``` Running a `configure` script is not going to work on Windows out of the box because libsnd uses GNU autotools which is for made for UNIX like operating systems. You should try and figure out how (if it's even possible) to build libsnd on Windows. At glance at the GitHub page shows they have a CMake build system but the docs say it will likely only work on Linux. There are some commits that mention MINGW so maybe it might be possible to build using the MSYS environment. Good Luck. From aishwaryaselvaraj1708 at gmail.com Thu Mar 2 07:47:55 2017 From: aishwaryaselvaraj1708 at gmail.com (aishwarya selvaraj) Date: Thu, 2 Mar 2017 17:17:55 +0430 Subject: [CMake] libsndfile in winodws In-Reply-To: References: Message-ID: @Dan Liew Thanks for your feedback. Yes I was trying to proceed in that direction . Did you find any links which could be useful ? could you kindly share them ? Thanks On Thu, Mar 2, 2017 at 5:08 PM, Dan Liew wrote: > On 2 March 2017 at 12:07, aishwarya selvaraj > wrote: > > Hi all , > > I was trying to build my .cpp file in windows in Windows platform > (windows > > 10) using cmake . > > My .cpp file makes use of two external libraries 1)armadillo 2)libsnd > file. > > I have written a corresponding cmakelist.txt to compile and obtain the > > binary . > > I was successful in doing so in Linux , when it come to Windows I obtain > the > > following error . > > > > 3>Time Elapsed 00:00:02.06 > > 2> Current branch master is up to date. > > 2> No patch step for 'project_libsndfile' > > 2> Performing autogen step for 'project_libsndfile' > > 2> Performing configure step for 'project_libsndfile' > > 2> > > 'C:\Users\computing7\Desktop\TSM_cmake\build\lib\libsndfile\src\project_ > libsndfile\configure' > > is not recognized as an internal or external command, > > 2> operable program or batch file. > > Above is your clue. Your build could not run `configure`. Your problem > is most likely in > > ``` > ExternalProject_Add(project_libsndfile > GIT_REPOSITORY https://github.com/erikd/libsndfile.git > PREFIX lib/libsndfile > CONFIGURE_COMMAND /configure > BUILD_COMMAND make > BUILD_IN_SOURCE 1 > INSTALL_COMMAND echo Skipping install step for libsndfile > ) > ``` > > Running a `configure` script is not going to work on Windows out of > the box because libsnd uses GNU autotools which is for made for UNIX > like operating systems. You should try and figure out how (if it's > even possible) to build libsnd on Windows. At glance at the GitHub > page shows they have a CMake build system but the docs say it will > likely only work on Linux. There are some commits that mention MINGW > so maybe it might be possible to build using the MSYS environment. > > Good Luck. > -- Regards, Aishwarya Selvaraj -------------- next part -------------- An HTML attachment was scrubbed... URL: From dflogeras2 at gmail.com Thu Mar 2 08:14:15 2017 From: dflogeras2 at gmail.com (Dave Flogeras) Date: Thu, 2 Mar 2017 09:14:15 -0400 Subject: [CMake] libsndfile in winodws In-Reply-To: References: Message-ID: On Thu, Mar 2, 2017 at 8:47 AM, aishwarya selvaraj < aishwaryaselvaraj1708 at gmail.com> wrote: > @Dan Liew > Thanks for your feedback. > Yes I was trying to proceed in that direction . > Did you find any links which could be useful ? > could you kindly share them ? > Thanks > > Running a `configure` script is not going to work on Windows out of >> the box because libsnd uses GNU autotools which is for made for UNIX >> like operating systems. You should try and figure out how (if it's >> even possible) to build libsnd on Windows. At glance at the GitHub >> page shows they have a CMake build system but the docs say it will >> likely only work on Linux. There are some commits that mention MINGW >> so maybe it might be possible to build using the MSYS environment. >> >> Just my 0.02, but if I recall Eric doesn't (or didn't) support building directly on Windows. This may have changed since VS must now support more of C99 as part of C11. http://www.mega-nerd.com/libsndfile/win32.html It has always been my best practice to either use his provided binaries, or cross compile using mingw on Linux, then move the binary and headers over. Regards, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From dflogeras2 at gmail.com Thu Mar 2 08:15:37 2017 From: dflogeras2 at gmail.com (Dave Flogeras) Date: Thu, 2 Mar 2017 09:15:37 -0400 Subject: [CMake] libsndfile in winodws In-Reply-To: References: Message-ID: On Thu, Mar 2, 2017 at 9:14 AM, Dave Flogeras wrote: > > Just my 0.02, but if I recall Eric doesn't (or didn't) support building > directly on Windows. > > Pardon me, that should be Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Thu Mar 2 15:04:23 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 2 Mar 2017 12:04:23 -0800 (PST) Subject: [CMake] -DCMAKE_BUILD_TYPE=Release breaks build process In-Reply-To: <20170302130146.839497194aed6f815899438a@gmx.de> References: <20170302101239.c4e1c31584c7aaaa74a4cb57@gmx.de> <20170302130146.839497194aed6f815899438a@gmx.de> Message-ID: On 2017-03-02 13:01+0100 Bernhard Seckinger wrote: > Basically it's (works) > > /usr/bin/gdc -I.. -fversion=slang -oCMakeFiles/starbattle.dir/__/puzzle > -c /home/berni/Croco/Entwicklung/Croco/types/puzzle.d > [...] > /usr/bin/gdc CMakeFiles/starbattle.dir/starbattle > CMakeFiles/starbattle.dir/starbattle_check_puzzle > CMakeFiles/starbattle.dir/starbattle_check_solution > CMakeFiles/starbattle.dir/__/puzzle > CMakeFiles/starbattle.dir/__/puzzle_options > CMakeFiles/starbattle.dir/__/puzzle_unittest > CMakeFiles/starbattle.dir/__/spf_tools CMakeFiles/starbattle.dir/__/puzzle_io > CMakeFiles/starbattle.dir/__/puzzle_timer CMakeFiles/starbattle.dir/__/slang > -ostarbattle -L/usr/lib/gcc/x86_64-linux-gnu/6 ../libslang_wrapper.o.a > -lslang -lc > > vs. (does not work) > > /usr/bin/gdc -O3 -fomit-frame-pointer -fweb -frelease -finline-functions > -I.. -fversion=slang -oCMakeFiles/starbattle.dir/__/puzzle > -c /home/berni/Croco/Entwicklung/Croco/types/puzzle.d > [...] > /usr/bin/gdc -O3 -fomit-frame-pointer -fweb -frelease -finline-functions > CMakeFiles/starbattle.dir/starbattle > CMakeFiles/starbattle.dir/starbattle_check_puzzle > CMakeFiles/starbattle.dir/starbattle_check_solution > CMakeFiles/starbattle.dir/__/puzzle > CMakeFiles/starbattle.dir/__/puzzle_options > CMakeFiles/starbattle.dir/__/puzzle_unittest > CMakeFiles/starbattle.dir/__/spf_tools CMakeFiles/starbattle.dir/__/puzzle_io > CMakeFiles/starbattle.dir/__/puzzle_timer CMakeFiles/starbattle.dir/__/slang > -ostarbattle -L/usr/lib/gcc/x86_64-linux-gnu/6 ../libslang_wrapper.o.a > -lslang -lc > > One can even remove "-fomit-frame-pointer -fweb -frelease -finline-functions" > and set -O1 instead of -O3 to get the same result. Hi Bernhard: The problem is that CMake has no native support for gdc so several external projects have supplied that support. For example, PLplot (the project I am associated with) obtained our CMake support for gdc from CMakeD (by Selman Ulug and Tim Burrell) a decade ago, and we have been tweaking it ever since for just our own needs, but we have no interest in supporting CMakeD for others because the strong impression I have is that project has been superseded by other projects which we intend to move to eventually once we have evaluated them. It appears you are using https://github.com/dcarp/cmake-d for CMake gdc support which as far as I can tell (e.g., from the license which does not mention Ulug or Burrel) is completely different from CMakeD. Anyhow, you should contact the authors of cmake-d with your bug report and/or try other modern possibilities revealed by, say, a google search for the terms . My advice for putting together that bug report is to create the simplest standalone example of the problem that is possible (e.g., consiting of a CMakeLists.txt file that builds and installs a "hello, world" D application + D language source code for that application. Then after configuring that simple test project with -DCMAKE_BUILD_TYPE=Release, run "make VERBOSE=1" which tells you exactly the commands that were executed which lead to the linking error. Afterward replicate that last (gdc) command that generated the linker error by hand, and then start changing (by hand) the gdc options until you isolate the one that is causing the linker issue. Assuming you isolate the issue that way, then you have demonstrated a bug in your particular CMake support for gdc for the -DCMAKE_BUILD_TYPE=Release case which you should report to the authors of your CMake gdc support. That simple self-contained example will be a big help to them in replicating the issue and figuring it out. And if they are not responsive to your bug report, perhaps it is time to move to some other CMake gdc support project which is more responsive or which does not have the issue with -DCMAKE_BUILD_TYPE=Release that you have found with the cmake-d project. Good luck, and I would appreciate you sharing with me (and possibly this list) how it goes since I am interested in trying something different from a tweaked CMakeD for gdc language support in the CMake-based PLplot build system. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From lp.cordier at dynamixyz.com Fri Mar 3 08:28:52 2017 From: lp.cordier at dynamixyz.com (Louis-Paul CORDIER) Date: Fri, 3 Mar 2017 14:28:52 +0100 Subject: [CMake] Windows mapped network drive and 'if EXISTS' Message-ID: Hi, I'm trying to use the cmake 'if' statement with the EXISTS parameter, used for checking folder/file existence. In my project, I have a library stored on a network samba folder. On my Windows dev platform, I mapped a network drive (Windows 7 -> Computer -> Map network drive) on this share (the created network letter is Z:). Other program can access and work on this drive without any problems. When I try to do a if(EXISTS "Z:\"), it never jump into the if statement. Is it a bug? Best regards, LPC From nilsgladitz at gmail.com Fri Mar 3 09:23:37 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 3 Mar 2017 15:23:37 +0100 Subject: [CMake] Windows mapped network drive and 'if EXISTS' In-Reply-To: References: Message-ID: <0b0d08bd-639d-3aeb-5c1b-bfb01a803071@gmail.com> On 03/03/2017 02:28 PM, Louis-Paul CORDIER wrote: > > When I try to do a if(EXISTS "Z:\"), it never jump into the if statement. Try if(EXISTS "Z:\\") or if(EXISTS "Z:/"). Either works for me. if(EXISTS "Z:\") looks like it should have been a syntax error since the backslash starts an escape sequence [1]. Nils [1] https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#escape-sequences From lp.cordier at dynamixyz.com Fri Mar 3 09:43:10 2017 From: lp.cordier at dynamixyz.com (Louis-Paul CORDIER) Date: Fri, 3 Mar 2017 15:43:10 +0100 Subject: [CMake] Windows mapped network drive and 'if EXISTS' In-Reply-To: <0b0d08bd-639d-3aeb-5c1b-bfb01a803071@gmail.com> References: <0b0d08bd-639d-3aeb-5c1b-bfb01a803071@gmail.com> Message-ID: <6b0fea1a-5080-ef71-c6f3-7c5e83b1e6da@dynamixyz.com> Does not solve the issue here... I'm using the latest cmake release 3.7.2 Your Z is a mapped network drive, am I right? This behaviour is causing find_package to fail as well. Le 03/03/2017 ? 15:23, Nils Gladitz a ?crit : > On 03/03/2017 02:28 PM, Louis-Paul CORDIER wrote: > >> >> When I try to do a if(EXISTS "Z:\"), it never jump into the if >> statement. > > Try if(EXISTS "Z:\\") or if(EXISTS "Z:/"). > Either works for me. > > if(EXISTS "Z:\") looks like it should have been a syntax error since > the backslash starts an escape sequence [1]. > > Nils > > [1] > https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#escape-sequences > > > From lp.cordier at dynamixyz.com Fri Mar 3 09:54:38 2017 From: lp.cordier at dynamixyz.com (Louis-Paul CORDIER) Date: Fri, 3 Mar 2017 15:54:38 +0100 Subject: [CMake] Windows mapped network drive and 'if EXISTS' In-Reply-To: <6b0fea1a-5080-ef71-c6f3-7c5e83b1e6da@dynamixyz.com> References: <0b0d08bd-639d-3aeb-5c1b-bfb01a803071@gmail.com> <6b0fea1a-5080-ef71-c6f3-7c5e83b1e6da@dynamixyz.com> Message-ID: Hi again, Problem solved by rebooting Windows and the samba share. Thank you anyway! Le 03/03/2017 ? 15:43, Louis-Paul CORDIER a ?crit : > Does not solve the issue here... > I'm using the latest cmake release 3.7.2 > > Your Z is a mapped network drive, am I right? > > This behaviour is causing find_package to fail as well. > > Le 03/03/2017 ? 15:23, Nils Gladitz a ?crit : >> On 03/03/2017 02:28 PM, Louis-Paul CORDIER wrote: >> >>> >>> When I try to do a if(EXISTS "Z:\"), it never jump into the if >>> statement. >> >> Try if(EXISTS "Z:\\") or if(EXISTS "Z:/"). >> Either works for me. >> >> if(EXISTS "Z:\") looks like it should have been a syntax error since >> the backslash starts an escape sequence [1]. >> >> Nils >> >> [1] >> https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#escape-sequences >> >> >> > From bernhard.seckinger at gmx.de Fri Mar 3 10:14:48 2017 From: bernhard.seckinger at gmx.de (Bernhard Seckinger) Date: Fri, 3 Mar 2017 16:14:48 +0100 Subject: [CMake] -DCMAKE_BUILD_TYPE=Release breaks build process In-Reply-To: References: <20170302101239.c4e1c31584c7aaaa74a4cb57@gmx.de> <20170302130146.839497194aed6f815899438a@gmx.de> Message-ID: <20170303161448.4f2c9ad63d547844a2240e0e@gmx.de> > My advice for putting together that bug report is to create the > simplest standalone example of the problem that is possible (e.g., > consiting of a CMakeLists.txt file that builds and installs a "hello, > world" D application + D language source code for that application. After one mornings work I've got such a small example. And surprisingly it's a bug in gdc and has nothing to do with neither cmake nor cmake-d. I filed a bug report for gdc. :-) Thanks for your help. Berni -- -- Meine R?tselwebseite: www.croco-puzzle.com From robert.maynard at kitware.com Fri Mar 3 10:39:18 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 3 Mar 2017 10:39:18 -0500 Subject: [CMake] [ANNOUNCE] CMake 3.8.0-rc2 now ready for testing! Message-ID: I am proud to announce the second CMake 3.8 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.8 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.8/release/3.8.html Some of the more significant changes in CMake 3.8 are: * CMake now supports "CSharp" (C#) as a first-class language. It is currently supported by the Visual Studio Generators for VS 2010 and above. * CMake now supports "CUDA" as a first-class language. It is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". CMake 3.8 Release Notes *********************** Changes made since CMake 3.7 include the following. New Features ============ Languages --------- C# ~~ * CMake learned to support "CSharp" (C#) as a first-class language that can be enabled via the "project()" and "enable_language()" commands. It is currently supported by the Visual Studio Generators for VS 2010 and above. C# assemblies and programs can be added just like common C++ targets using the "add_library()" and "add_executable()" commands. References between C# targets in the same source tree may be specified by "target_link_libraries()" like for C++. References to system or 3rd-party assemblies may be specified by the target properties "VS_DOTNET_REFERENCE_" and "VS_DOTNET_REFERENCES". * More fine tuning of C# targets may be done using target and source file properties. Specifically the target properties related to Visual Studio ("VS_*") are worth a look (for setting toolset versions, root namespaces, assembly icons, ...). CUDA ~~~~ * CMake learned to support "CUDA" as a first-class language that can be enabled via the "project()" and "enable_language()" commands. * "CUDA" is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The NVIDIA CUDA Toolkit compiler ("nvcc") is supported. C & C++ ~~~~~~~ * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The "Compile Features" functionality is now aware of the availability of C99 in gcc since version 3.4. Platforms --------- * A new minimal platform file for "Fuchsia" was added. Generators ---------- * The "CodeBlocks" extra generator may now be used to generate with "NMake Makefiles JOM". * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned the option "COMMAND_EXPAND_LISTS" which causes lists in the "COMMAND" argument to be expanded, including lists created by generator expressions. * The "execute_process()" command gained an "ENCODING" option to specify on Windows which encoding is used for output from child process. * The "math(EXPR)" command gained support for unary "+" and "-" operators. * The "source_group()" command gained "TREE" and "PREFIX" options to add groups following source tree directory structure. * The "string(TIMESTAMP)" command learned to treat "%%" as a way to encode plain "%". * The "string(TIMESTAMP)" command will now honor the "SOURCE_DATE_EPOCH" environment variable and use its value instead of the current time. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". Variables --------- * A "CMAKE_CODELITE_USE_TARGETS" variable was added to tell the "CodeLite" extra generator to change the generated project to have target-centric organization. The "build", "rebuild", and "clean" operations within "CodeLite" then work on a selected target rather than the whole workspace. (Note that the "Ninja" clean operation on a target includes its dependencies, though.) * The "CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS" variable was added to tell the "Sublime Text 2" extra generator to place specified environment variables in the generated ".sublime-project". * The "CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE" variable was added to tell the "Sublime Text 2" extra generator whether to exclude the build tree from the ".sublime-project" when it is inside the source tree. * A "CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD" variable was added to tell Visual Studio Generators for VS 2010 and above to include the "PACKAGE" target in the default build, similar to the existing "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" variable for the "INSTALL" target. Properties ---------- * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * The "FRAMEWORK" target property may now also be applied to static libraries on Apple targets. It will result in a proper Framework but with a static library inside. * Imported Interface Libraries learned new "IMPORTED_LIBNAME" and "IMPORTED_LIBNAME_" target properties to specify a link library name since interface libraries do not build their own library files. * A "_CPPLINT" target property and supporting "CMAKE__CPPLINT" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run the "cpplint" style checker along with the compiler for "C" and "CXX" languages. * A "MANUALLY_ADDED_DEPENDENCIES" target property has been added. It provides a read-only list of dependencies that have been added with the "add_dependencies()" command. * The "MAP_IMPORTED_CONFIG_" target property learned to interpret empty list elements as referring to the configuration-less imported location specified by "IMPORTED_LOCATION". * The "NO_SYSTEM_FROM_IMPORTED" target property is now supported on Imported Interface Libraries. * New source file properties "SKIP_AUTOMOC", "SKIP_AUTOUIC", "SKIP_AUTORCC", and "SKIP_AUTOGEN" were added to allow source files to be excluded from processing by "AUTOMOC", "AUTOUIC", and "AUTORCC" target properties. * A "VS_COPY_TO_OUT_DIR" source file property was added to tell Visual Studio Generators for VS 2010 and above whether or not a file should e copied to the output directory. * A "VS_DEBUGGER_WORKING_DIRECTORY" target property was added to tell Visual Studio Generators for VS 2010 and above what debugger working directory should be set for the target. * A "VS_DOTNET_REFERENCES_COPY_LOCAL" target property was added to specify whether to copy referenced assemblies to the output directory. * A "VS_DOTNET_REFERENCE_" target property was added to tell Visual Studio Generators for VS 2010 and above to add a .NET reference with a given hint path. * A "VS_INCLUDE_IN_VSIX" source file property was added to tell Visual Studio Generators for VS 2010 and above whether to include the file in a Visual Studio extension package. * A "VS_RESOURCE_GENERATOR" source file property was added to give Visual Studio Generators for VS 2010 and above a setting for the resource generator ("C#" only). * A "VS_USER_PROPS" target property was added to tell Visual Studio Generators for VS 2010 and above to use a custom MSBuild user ".props" file. * A "XCODE_EMIT_EFFECTIVE_PLATFORM_NAME" global property was added to tell the "Xcode" generator whether to emit the "EFFECTIVE_PLATFORM_NAME" variable. This is useful when building with multiple SDKs like "macosx" and "iphoneos" in parallel. * New "XCODE_PRODUCT_TYPE" and "XCODE_EXPLICIT_FILE_TYPE" target properties were created to tell the "Xcode" generator to use custom values of the corresponding attributes for a target in the generated Xcode project. Modules ------- * A "CSharpUtilities" module was added to aid parameterization of Visual Studio C# targets. It provides functions to allow automated setting of source file properties to support Windows Forms, WPF/XAML or other technologies as needed. * The "ExternalData" module learned to support multiple content links for one data file using different hashes, e.g. "img.png.sha256" and "img.png.sha1". This allows objects to be fetched from sources indexed by different hash algorithms. * The "ExternalProject" module gained the "GIT_PROGRESS" option to force Git to show progress when cloning repositories. * The "ExternalProject" module gained a "GIT_CONFIG" option to pass " --config" options to Git when cloning repositories. * The "FeatureSummary" module "feature_summary()" command now accepts a new "QUIET_ON_EMPTY" option that suppresses the output when the list of packages that belong to the selected category is empty. * The "FeatureSummary" module "add_feature_info()" command now accepts lists of dependencies for deciding whether a feature is enabled or not. * The package types accepted by the "FeatureSummary" module can now be tweaked by changing the "FeatureSummary_PKG_TYPES", "FeatureSummary_REQUIRED_PKG_TYPES" and "FeatureSummary_DEFAULT_PKG_TYPE" global properties. * The "FindOpenGL" module now provides imported targets "OpenGL::GL" and "OpenGL::GLU" when the libraries are found. * The "UseSWIG" module gained a "swig_add_library" command to give more flexibility over the old "swig_add_module" command. * The "UseSWIG" module "swig_add_source_to_module" command learned a new "SWIG_OUTFILE_DIR" option to control the output file location ("swig -o"). * The "WriteCompilerDetectionHeader" module gained the "ALLOW_UNKNOWN_COMPILERS" and "ALLOW_UNKNOWN_COMPILER_VERSIONS" options that allow creation of headers that will work also with unknown or old compilers by simply assuming they do not support any of the requested features. CTest ----- * The "ctest_memcheck()" command gained a "DEFECT_COUNT " option to capture the number of memory defects detected. * The "ctest_memcheck()" command learned to read the location of suppressions files for sanitizers from the "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable. * The "ctest_memcheck()" command learned to support "LeakSanitizer" independently from "AddressSanitizer". * The "ctest_update()" command "CDASH_UPLOAD" signature was taught to honor the "RETRY_COUNT", "RETRY_DELAY", and "QUIET" options. CPack ----- * The "CPackIFWConfigureFile" module was added to define a new "cpack_ifw_configure_file()" command to configure file templates prepared in QtIFW/SDK/Creator style. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "DEFAULT", "VIRTUAL", "FORCED_INSTALLATION", "REQUIRES_ADMIN_RIGHTS", "DISPLAY_NAME", "UPDATE_TEXT", "DESCRIPTION", "RELEASE_DATE", "AUTO_DEPEND_ON" and "TRANSLATIONS" options to more specific configuration. * The "CPackIFW" module "cpack_ifw_configure_component()" command gained a new "DEPENDENCIES" alias for "DEPENDS" option. * The "CPackIFW" module "cpack_ifw_configure_component_group()" command gained a new "DEPENDS" option. The "DEPENDENCIES" alias also added. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands "PRIORITY" option now is deprecated and will be removed in a future version of CMake. Please use new "SORTING_PRIORITY" option instead. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_WATERMARK", "CPACK_IFW_PACKAGE_BANNER", "CPACK_IFW_PACKAGE_BACKGROUND", "CPACK_IFW_PACKAGE_WIZARD_STYLE", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT", and "CPACK_IFW_PACKAGE_TITLE_COLOR" variables to customize a QtIFW installer look. * The "CPackProductBuild" module gained options to sign packages. See the variables "CPACK_PRODUCTBUILD_IDENTITY_NAME", "CPACK_PRODUCTBUILD_KEYCHAIN_PATH", "CPACK_PKGBUILD_IDENTITY_NAME", and "CPACK_PKGBUILD_KEYCHAIN_PATH". * The "CPackRPM" module learned to omit tags that are not supported by provided "rpmbuild" tool. If unsupported tags are set they are ignored and a developer warning is printed out. * The "CPackRPM" module learned to generate main component package which forces generation of a rpm for defined component without component suffix in filename and package name. See "CPACK_RPM_MAIN_COMPONENT" variable. * The "CPackRPM" module learned to generate a single "debuginfo" package on demand even if components packaging is used. See "CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE" variable. * The "CPackRPM" module learned to support multiple directives per file when using "CPACK_RPM_USER_FILELIST" variable. Other ----- * CMake functionality using cryptographic hashes now supports SHA-3 algorithms. * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". Deprecated and Removed Features =============================== * The "FeatureSummary" module commands "set_package_info()", "set_feature_info()", "print_enabled_features()", and "print_disabled_features()" are now deprecated. * The "UseSWIG" module "swig_add_module" command is now deprecated in favor of "swig_add_library". Other Changes ============= * If a command specified by the "_CLANG_TIDY" target property returns non-zero at build time this is now treated as an error instead of silently ignored. * The "ctest_memcheck()" command no longer automatically adds "leak_check=1" to the options used by "AddressSanitizer". The default behavior of "AddressSanitizer" is to run *LeakSanitizer* to check leaks unless "leak_check=0". * The "ctest_memcheck()" command was fixed to correctly append extra sanitizer options read from the "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable to the environment variables used internally by the sanitizers. * The "FeatureSummary" module "set_package_properties()" command no longer forces the package type to "OPTIONAL" when the type is not explicitly set. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * Calls to the "FindPkgConfig" module "pkg_check_modules()" command following a successful call learned to re-evaluate the cached values for a given prefix after changes to the parameters to the command for that prefix. * When using "AUTOMOC" or "AUTOUIC", generated "moc_*", "*.moc" and "ui_*" are placed in the "/_autogen/include" directory which is automatically added to the target's "INCLUDE_DIRECTORIES". It is therefore not necessary anymore to have "CMAKE_CURRENT_BINARY_DIR" in the target's "INCLUDE_DIRECTORIES". * The "Sublime Text 2" generator no longer runs the native build command (e.g. "ninja" or "make") with verbose build output enabled. * The "try_compile()" command source file signature now honors the "CMAKE_WARN_DEPRECATED" variable value in the generated test project. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". ---------------------------------------------------------------------------- Changes made since CMake 3.8.0-rc1: Ben Boeckel (1): FindGTK2: handle old libsigc++ versions Bjoern Thiel (1): FindCUDA: Fix PTX selection with multiple architectures Brad Davis (1): FindVulkan: Update for LunarG SDK import library location on Windows Brad King (32): Utilities/Sphinx: Port qthelp css workaround to Sphinx 1.4 Help: Fix cmake code block warnings produced by Sphinx 1.4 Help: Improve execute_process ENCODING option documentation execute_process: Restore no-decoding default behavior clang-format.bash: Format CUDA source files too Modules: Run clang-format on CUDA code Tests: Run clang-format on CUDA code Tests: Add case for CUDA with C but not C++ CUDA: Link to standard system libraries when linking as CUDA CUDA: Do not use non-existent -Os flag for nvcc CUDA: Fix test cases to not override CUDA flags CUDA: Fix default compiler flags on Windows ctest_update: Fix svn log and external loading FindHDF5: Restore HDF5__INCLUDE_DIR advanced cache entry mark FindHDF5: Fix search for language-specific header file Windows: Fix inconsistent behavior on changes to case of path to cmake CUDA: Fix boolean interpretation of CUDA_SEPARABLE_COMPILATION ExternalProject: Clarify documented role of `INSTALL_DIR` VS2017: If Win 8.1 SDK is not available, use Win 10 SDK Define a custom Git attribute to mark source files as generated Define a custom Git attribute to mark sources using our C style clang-format.bash: Use Git attributes to mark files for formatting VS: Fix .vcxproj indentation Revert "Ninja: Use full path for all source files" Fix COMPILE_PDB_NAME when used on an OBJECT library ExternalProject: Run `git checkout` with `--` to clarify arguments cmFindLibraryCommand: Refactor AddArchitecturePath logic find_library: Skip 'lib => lib' searches if one symlinks the other cmOrderDirectories: Factor out implicit directory check cmOrderDirectories: Consider symlinks when checking implicit directories Tests: Add case for RPATH exclusion of symlinks to implicit directories CMake 3.8.0-rc2 Gregor Jasny (1): Utilities/Sphinx: Port cmake extension to Sphinx 1.4 Kitsu (1): FindJNI: Add jvm paths for Arch Linux Michael Maltese (1): Help: Clarify 'make-style' variable references in cmake-language(7) Michael St?rmer (3): VS: add VS_CSHARP_ sourcefile property VS: add CSharpUtilities module VS: add test for VS_CSHARP_* source file property Orion Poplawski (1): KWIML: Add -Wno-format-security to tolerate -Werror=format-security Robert Maynard (1): CUDA: Detect the toolkit include directories Sebastian Holtermann (1): Autogen: Fix headers not skipped Wilfried Goesgens (1): ExternalProject: Clarify documented role of `INSTALL_COMMAND` From mdrahos at aurisrobotics.com Fri Mar 3 12:23:20 2017 From: mdrahos at aurisrobotics.com (Miroslav Drahos) Date: Fri, 3 Mar 2017 17:23:20 +0000 Subject: [CMake] Error from GenerateExportHeader.cmake (configure_file) Message-ID: Hi, I am getting errors emanating from GenerateExportHeader.cmake and hope someone has any pointers on this. The error: CMake Error at /usr/share/cmake-3.5/Modules/GenerateExportHeader.cmake:362 (configure_file): ? configure_file Problem configuring file Call Stack (most recent call first): ? /usr/share/cmake-3.5/Modules/GenerateExportHeader.cmake:378 (_do_generate_export_header) ? /slave/workspace/build-1.7.0/aurissw/Main/CMake/AsrCreateLibraryMacro.cmake:161 (generate_export_header) The relevant portion of the custom AsrCreateLibraryMacro.cmake is pretty standard, according to cmake docs: unset(exportMacro) string(TOUPPER ${TARGET} exportMacro) set(exportMacro "${exportMacro}_DLLSPEC") set(exportHeader ${TARGET}_export.h) generate_export_header(${TARGET} BASE_NAME ${TARGET} EXPORT_MACRO_NAME ${exportMacro} EXPORT_FILE_NAME ${exportHeader} ) where TARGET is always set to a valid string (library name). The error is not consistent among machines -- on some machines this error is never seen, on others, it consistently fails. All of these machines run a pretty standard Linux distribution (most of them Ubuntu 16.04), and use the same cmake 3.5.1. Here is the system version that we are using: Linux version 4.4.0-36-generic (buildd at lcy01-01) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2) ) #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 We have a machine with the exact same system version that builds fine and a machine that cmake consistently fails. Has anyone experienced a similar error? Any clues on what may be the problem? Thank you tons, Miro -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Fri Mar 3 12:49:36 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Fri, 3 Mar 2017 09:49:36 -0800 Subject: [CMake] Error from GenerateExportHeader.cmake (configure_file) In-Reply-To: References: Message-ID: > On Mar 3, 2017, at 9:23 AM, Miroslav Drahos wrote: > > Hi, > I am getting errors emanating from GenerateExportHeader.cmake and hope someone has any pointers on this. The error: > > CMake Error at /usr/share/cmake-3.5/Modules/GenerateExportHeader.cmake:362 (configure_file): > ? configure_file Problem configuring file > Call Stack (most recent call first): > ? /usr/share/cmake-3.5/Modules/GenerateExportHeader.cmake:378 (_do_generate_export_header) > ? /slave/workspace/build-1.7.0/aurissw/Main/CMake/AsrCreateLibraryMacro.cmake:161 (generate_export_header) > > The relevant portion of the custom AsrCreateLibraryMacro.cmake is pretty standard, according to cmake docs: > > unset(exportMacro) > string(TOUPPER ${TARGET} exportMacro) > set(exportMacro "${exportMacro}_DLLSPEC") > set(exportHeader ${TARGET}_export.h) > generate_export_header(${TARGET} > BASE_NAME ${TARGET} > EXPORT_MACRO_NAME ${exportMacro} > EXPORT_FILE_NAME ${exportHeader} > ) > > where TARGET is always set to a valid string (library name). > > The error is not consistent among machines -- on some machines this error is never seen, on others, it consistently fails. All of these machines run a pretty standard Linux distribution (most of them Ubuntu 16.04), and use the same cmake 3.5.1. > > Here is the system version that we are using: > Linux version 4.4.0-36-generic (buildd at lcy01-01) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2) ) #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 > We have a machine with the exact same system version that builds fine and a machine that cmake consistently fails. > > Has anyone experienced a similar error? Any clues on what may be the problem? > Thank you tons, > Miro This might just be a filesystem error when writing the configured header file. I would try message() printing the value of ${exportHeader} and ${CMAKE_CURRENT_BINARY_DIR} before calling GEH to make sure the filepath looks valid and writeable. -Mike From irwin at beluga.phys.uvic.ca Fri Mar 3 16:22:37 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 3 Mar 2017 13:22:37 -0800 (PST) Subject: [CMake] -DCMAKE_BUILD_TYPE=Release breaks build process In-Reply-To: <20170303161448.4f2c9ad63d547844a2240e0e@gmx.de> References: <20170302101239.c4e1c31584c7aaaa74a4cb57@gmx.de> <20170302130146.839497194aed6f815899438a@gmx.de> <20170303161448.4f2c9ad63d547844a2240e0e@gmx.de> Message-ID: On 2017-03-03 16:14+0100 Bernhard Seckinger wrote: >> My advice for putting together that bug report is to create the >> simplest standalone example of the problem that is possible (e.g., >> consiting of a CMakeLists.txt file that builds and installs a "hello, >> world" D application + D language source code for that application. > > After one mornings work I've got such a small example. And surprisingly it's a > bug in gdc and has nothing to do with neither cmake nor cmake-d. I filed a bug > report for gdc. :-) > > Thanks for your help. Hi Berni: You are welcome. And for the others here, Berni's general result (making a simple example of what appear to be CMake problems often yields important new insights) is quite typical with CMake in my experience. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From bernhard.seckinger at gmx.de Mon Mar 6 07:43:57 2017 From: bernhard.seckinger at gmx.de (Bernhard Seckinger) Date: Mon, 6 Mar 2017 13:43:57 +0100 Subject: [CMake] Adding a link? Message-ID: <20170306134357.b2cb9d500b6730afe0245ca5@gmx.de> Hi all, I've got a project where meanwhile everything works, using cmake, but a tiny detail. I've got a frontend which consists of several php files. I copy them into a subfolder of share/ with the install command. Now I need a symlink from bin/croco to share/croco/main.php that is, after installing everything else "ln -s share/croco/main.php bin/croco" should be executed. I know, that symlinks are not available in some other OSs, but for the time being, I only need a solution, that works using linux. What I found so far is: add_custom_command(OUTPUT bin/croco COMMAND ln -s share/croco/main.php bin/croco DEPENDS share/croco/main.php) But that seems to be ignored by "make install". Can you help me? Thanks, Berni -- -- Meine R?tselwebseite: www.croco-puzzle.com From rleigh at codelibre.net Mon Mar 6 08:49:31 2017 From: rleigh at codelibre.net (Roger Leigh) Date: Mon, 6 Mar 2017 13:49:31 +0000 Subject: [CMake] Adding a link? In-Reply-To: <20170306134357.b2cb9d500b6730afe0245ca5@gmx.de> References: <20170306134357.b2cb9d500b6730afe0245ca5@gmx.de> Message-ID: On 06/03/2017 12:43, Bernhard Seckinger wrote: > Hi all, > > I've got a project where meanwhile everything works, using cmake, but a tiny > detail. I've got a frontend which consists of several php files. I copy them > into a subfolder of share/ with the install command. Now I need a symlink from > bin/croco to share/croco/main.php that is, after installing everything else "ln > -s share/croco/main.php bin/croco" should be executed. > > I know, that symlinks are not available in some other OSs, but for the time > being, I only need a solution, that works using linux. > > What I found so far is: > > add_custom_command(OUTPUT bin/croco > COMMAND ln -s share/croco/main.php bin/croco > DEPENDS share/croco/main.php) > > But that seems to be ignored by "make install". Can you help me? bzip2 example (from https://github.com/ome/ome-cmake-superbuild/blob/master/packages/bzip2/patches/cmake.diff#L163) # Copy or symlink bunzip2 and bzcat to bzip2 if (WIN32) install(CODE "configure_file(\"${CMAKE_INSTALL_FULL_BINDIR}/bzip2.exe\" \"${CMAKE_INSTALL_FULL_BINDIR}/bunzip2.exe\" COPYONLY)" COMPONENT "runtime") install(CODE "configure_file(\"${CMAKE_INSTALL_FULL_BINDIR}/bzip2.exe\" \"${CMAKE_INSTALL_FULL_BINDIR}/bzcat.exe\" COPYONLY)" COMPONENT "runtime") else() install(CODE "execute_process(COMMAND \"${CMAKE_COMMAND}\" -E create_symlink bzip2 \"\$ENV{DESTDIR}${CMAKE_INSTALL_FULL_BINDIR}/bunzip2\")" COMPONENT "runtime") install(CODE "execute_process(COMMAND \"${CMAKE_COMMAND}\" -E create_symlink bzip2 \"\$ENV{DESTDIR}${CMAKE_INSTALL_FULL_BINDIR}/bzcat\")" COMPONENT "runtime") endif() Hope that's useful as an example, Roger From bernhard.seckinger at gmx.de Mon Mar 6 11:08:18 2017 From: bernhard.seckinger at gmx.de (Bernhard Seckinger) Date: Mon, 6 Mar 2017 17:08:18 +0100 Subject: [CMake] Adding a link? In-Reply-To: References: <20170306134357.b2cb9d500b6730afe0245ca5@gmx.de> Message-ID: <20170306170818.0fd387fbe55ffa600677e696@gmx.de> Hi Roger, > install(CODE "execute_process(COMMAND \"${CMAKE_COMMAND}\" -E > create_symlink bzip2 > \"\$ENV{DESTDIR}${CMAKE_INSTALL_FULL_BINDIR}/bunzip2\")" > COMPONENT "runtime") Hi thanks, that works when I add install(DIRECTORY DESTINATION ${CMAKE_INSTALL_PREFIX}/bin) somewhere before. :-) Cheers, Berni -- -- Meine R?tselwebseite: www.croco-puzzle.com From aishwaryaselvaraj1708 at gmail.com Tue Mar 7 04:19:11 2017 From: aishwaryaselvaraj1708 at gmail.com (aishwarya selvaraj) Date: Tue, 7 Mar 2017 14:49:11 +0530 Subject: [CMake] libsndfile in windows Message-ID: ?Hi all , I'm trying to compile a .cpp code of mine using cmake file in all the three platforms. I have successfully completed it in Linux software . when I started to do it in windows I read across multiple documents which mention that ?libsnd file cannot be built on windows using visual studio , instead its possible using MINGW , but there was support documents for the same . Has anyone already done something similiar . Could you please provide some knowledge? -- Regards, Aishwarya Selvaraj -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonka3100 at gmail.com Tue Mar 7 04:25:39 2017 From: tonka3100 at gmail.com (tonka tonka) Date: Tue, 7 Mar 2017 10:25:39 +0100 Subject: [CMake] CPack WIX - disable feature by default Message-ID: Hello, I?ve create an installer with cpack and WIX (cpack ?G WIX). Everything works fine, but I have one big problem. I have 2 features, which are created by cpack(wix). My Problem: I want to deactivate the CM_C_dev feature by default (CPACK_WIX seems to ignore my set(CPACK_COMPONENT_DEV_DISABLED ON) ). The user should be able to activate it if he/she wants that. I know how I can do it with WIX itself (handmade), but I have big troubles to inject that into the cpack_wix flow. I have to add Level=?2? to the Feature with the Id=?CM_C_DEV? like or add a property (as value) like DISABLE_FEATUREA I?ve tried the CPACK_WIX_PATCH function, but I?m only able to add something to the ProductRoot feature (ID=?ProductFeature?) via But not into the subfeature CM_C_dev Does anybody know how I can do that (or maybe another way)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From winfried_mb2 at xmsnet.nl Tue Mar 7 09:32:27 2017 From: winfried_mb2 at xmsnet.nl (Winfried) Date: Tue, 07 Mar 2017 15:32:27 +0100 Subject: [CMake] =?utf-8?q?CMAKE=5FCXX=5FSTANDARD=5FREQUIRED_not_working_i?= =?utf-8?q?n_helloworld?= Message-ID: <4496b6b1a2b629125f15d44a18a520c0@xmsnet.nl> I am trying to let cmake exit with an error when the c++ compiler doesn't support at least the C++14 standard. According to the cmake documentation this should be possible with variables CMAKE_CXX_STANDARD and CMAKE_CXX_STANDARD_REQUIRED. However when I compile the simple helloworld example below with g++ 4.8 (which has no C++14 support), cmake supplies the option -std=c++1y to g++ and compilation fails. I expected CMake to stop during configure with an error. Can anybody see what I am doing wrong ? Thanks in advance, Winfried file main.cpp : #include #include using namespace std::string_literals; int main(int, char **) { std::cout << "Hello "s + "world!" << std::endl; return 0; } file CMakeLists.txt : project(reqstd_test) cmake_minimum_required(VERSION 3.7) set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) add_executable(hello main.cpp) cmake output: wdobbe at linux-wdobbe:/data/generated/cmake_std_req/build> cmake .. -- The C compiler identification is GNU 4.8.5 -- The CXX compiler identification is GNU 4.8.5 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Configuring done -- Generating done -- Build files have been written to: /data/generated/cmake_std_req/build wdobbe at linux-wdobbe:/data/generated/cmake_std_req/build> make output: wdobbe at linux-wdobbe:/data/generated/cmake_std_req/build> make VERBOSE=Y /home/wdobbe/install/cmake-3.8.0-rc2-Linux-x86_64/bin/cmake -H/data/generated/cmake_std_req -B/data/generated/cmake_std_req/build --check-build-system CMakeFiles/Makefile.cmake 0 [ 50%] Building CXX object CMakeFiles/hello.dir/main.cpp.o /usr/bin/c++ -std=c++1y -o CMakeFiles/hello.dir/main.cpp.o -c /data/generated/cmake_std_req/main.cpp /data/generated/cmake_std_req/main.cpp:4:22: error: ?string_literals? is not a namespace-name using namespace std::string_literals; ^ /data/generated/cmake_std_req/main.cpp:4:37: error: expected namespace-name before ?;? token using namespace std::string_literals; ^ /data/generated/cmake_std_req/main.cpp: In function ?int main(int, char**)?: /data/generated/cmake_std_req/main.cpp:8:18: error: unable to find string literal operator ?operator"" s? std::cout << "Hello "s + "world!" << std::endl; ^ CMakeFiles/hello.dir/build.make:62: recipe for target 'CMakeFiles/hello.dir/main.cpp.o' failed make[2]: *** [CMakeFiles/hello.dir/main.cpp.o] Error 1 make[2]: Leaving directory '/data/generated/cmake_std_req/build' CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/hello.dir/all' failed make[1]: *** [CMakeFiles/hello.dir/all] Error 2 make[1]: Leaving directory '/data/generated/cmake_std_req/build' Makefile:83: recipe for target 'all' failed make: *** [all] Error 2 From robert.maynard at kitware.com Tue Mar 7 10:34:00 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 7 Mar 2017 10:34:00 -0500 Subject: [CMake] CMAKE_CXX_STANDARD_REQUIRED not working in helloworld In-Reply-To: <4496b6b1a2b629125f15d44a18a520c0@xmsnet.nl> References: <4496b6b1a2b629125f15d44a18a520c0@xmsnet.nl> Message-ID: The issue is that GCC 4.8 c++1y does offer support for some c++14 features ( https://gcc.gnu.org/projects/cxx-status.html#cxx14 ) and therefore that is why you getting a compile time failure. You could try using target_compile_features instead but it only verifies language level features and is not aware of standard library features such as std::string_literals. On Tue, Mar 7, 2017 at 9:32 AM, Winfried wrote: > I am trying to let cmake exit with an error when the c++ compiler doesn't > support at least the C++14 standard. > According to the cmake documentation this should be possible with variables > CMAKE_CXX_STANDARD and CMAKE_CXX_STANDARD_REQUIRED. > > However when I compile the simple helloworld example below with g++ 4.8 > (which has no C++14 support), cmake supplies the option -std=c++1y to g++ > and compilation fails. > I expected CMake to stop during configure with an error. > > Can anybody see what I am doing wrong ? > > Thanks in advance, > Winfried > > > file main.cpp : > > #include > #include > > using namespace std::string_literals; > > int main(int, char **) > { > std::cout << "Hello "s + "world!" << std::endl; > return 0; > } > > > > file CMakeLists.txt : > > project(reqstd_test) > cmake_minimum_required(VERSION 3.7) > > set(CMAKE_CXX_STANDARD 14) > set(CMAKE_CXX_STANDARD_REQUIRED ON) > set(CMAKE_CXX_EXTENSIONS OFF) > > add_executable(hello main.cpp) > > > cmake output: > wdobbe at linux-wdobbe:/data/generated/cmake_std_req/build> cmake .. > -- The C compiler identification is GNU 4.8.5 > -- The CXX compiler identification is GNU 4.8.5 > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Check for working CXX compiler: /usr/bin/c++ > -- Check for working CXX compiler: /usr/bin/c++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- Configuring done > -- Generating done > -- Build files have been written to: /data/generated/cmake_std_req/build > wdobbe at linux-wdobbe:/data/generated/cmake_std_req/build> > > > make output: > wdobbe at linux-wdobbe:/data/generated/cmake_std_req/build> make VERBOSE=Y > /home/wdobbe/install/cmake-3.8.0-rc2-Linux-x86_64/bin/cmake > -H/data/generated/cmake_std_req -B/data/generated/cmake_std_req/build > --check-build-system CMakeFiles/Makefile.cmake 0 > > [ 50%] Building CXX object CMakeFiles/hello.dir/main.cpp.o > /usr/bin/c++ -std=c++1y -o CMakeFiles/hello.dir/main.cpp.o -c > /data/generated/cmake_std_req/main.cpp > /data/generated/cmake_std_req/main.cpp:4:22: error: ?string_literals? is not > a namespace-name > using namespace std::string_literals; > ^ > /data/generated/cmake_std_req/main.cpp:4:37: error: expected namespace-name > before ?;? token > using namespace std::string_literals; > ^ > /data/generated/cmake_std_req/main.cpp: In function ?int main(int, char**)?: > /data/generated/cmake_std_req/main.cpp:8:18: error: unable to find string > literal operator ?operator"" s? > std::cout << "Hello "s + "world!" << std::endl; > ^ > CMakeFiles/hello.dir/build.make:62: recipe for target > 'CMakeFiles/hello.dir/main.cpp.o' failed > make[2]: *** [CMakeFiles/hello.dir/main.cpp.o] Error 1 > make[2]: Leaving directory '/data/generated/cmake_std_req/build' > CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/hello.dir/all' failed > make[1]: *** [CMakeFiles/hello.dir/all] Error 2 > make[1]: Leaving directory '/data/generated/cmake_std_req/build' > Makefile:83: recipe for target 'all' failed > make: *** [all] Error 2 > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From kgt at lanl.gov Tue Mar 7 11:02:39 2017 From: kgt at lanl.gov (Thompson, KT) Date: Tue, 7 Mar 2017 16:02:39 +0000 Subject: [CMake] Problem with VS2017 and CMakeGNUtoMS_lib.bat.in (cmake-3.8-rc2) Message-ID: <7f365a1b4888466a915cab8fbb09043a@EXG13-P-MBX09.win.lanl.gov> Hi, I use the CMakeAddFortranSubdirectory feature in one of my projects. This appears to be broken under Visual Studio 2017 Community Edition RC because CMake\share\cmake-3.8\Modules\Platform\GNUtoMS_lib.bat.in generates a batch file that contains: call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars32.bat" and this batch function changes the current working directory to %USERPROFILE%/Source (unlike earlier versions) . Has anyone else seen this? I have fixed the issue by replacing the cmake provided GNUtoMS_lib.bat.in with @echo off set CWD=%CD% call "@CMAKE_GNUtoMS_BAT@" cd /d %CWD% lib /machine:"@CMAKE_GNUtoMS_ARCH@" %* I'm not sure if CMake needs to make this change more permanent or if this is a bug in VS2017. -kt ----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From winfried_mb2 at xmsnet.nl Tue Mar 7 11:57:09 2017 From: winfried_mb2 at xmsnet.nl (Winfried) Date: Tue, 07 Mar 2017 17:57:09 +0100 Subject: [CMake] =?utf-8?q?CMAKE=5FCXX=5FSTANDARD=5FREQUIRED_not_working_i?= =?utf-8?q?n_helloworld?= In-Reply-To: References: <4496b6b1a2b629125f15d44a18a520c0@xmsnet.nl> Message-ID: <0ef679c2ae7e91cad708039a901c44e7@xmsnet.nl> Robert Maynard schreef op 07.03.2017 16:34: > The issue is that GCC 4.8 c++1y does offer support for some c++14 > features ( https://gcc.gnu.org/projects/cxx-status.html#cxx14 ) and > therefore that is why you getting a compile time failure. You could > try using target_compile_features instead but it only verifies > language level features and is not aware of standard library features > such as std::string_literals. > Thanks for the clarification. I already tried setting the CXX_STANDARD and CXX_STANDARD_REQUIRED target compile features directly, but that gives the same result. I will add an extra check for gcc >= 4.9. From michele.portolan at grenoble-inp.fr Tue Mar 7 11:56:49 2017 From: michele.portolan at grenoble-inp.fr (Michele Portolan) Date: Tue, 7 Mar 2017 17:56:49 +0100 Subject: [CMake] Link to local glibc Message-ID: <2579a434-f182-e158-2d4d-babdf4551439@grenoble-inp.fr> Hello, I build on a Ubuntu machine (kernel 4.4.0-64-generic), but I need my program to be executed on an old Cento 5.8 (kernel 2.6.18). I tried compiling with "-static" to have static linking, but when I try to execute I get "ERROR: Kernel too old!" I therefore locally compiled a glibc with support for kernel 2.6.18 ... but how can I have Cmake use it instead of the system one? Thanks, Michele From loose at astron.nl Tue Mar 7 13:53:44 2017 From: loose at astron.nl (Marcel Loose) Date: Tue, 7 Mar 2017 19:53:44 +0100 Subject: [CMake] Link to local glibc In-Reply-To: <2579a434-f182-e158-2d4d-babdf4551439@grenoble-inp.fr> References: <2579a434-f182-e158-2d4d-babdf4551439@grenoble-inp.fr> Message-ID: <4f1c218d-69ae-b194-c6a8-7ef71790d113@astron.nl> Hi Michele, This could become a painful exercise. You basically have two options: 1) Treat it as a cross-compilation project, or 2) Create a virtual machine running CentOS 5.8 and do the build there. If I were you, I would go for the second option. Cheers, Marcel. Op 07-03-17 om 17:56 schreef Michele Portolan: > Hello, > > I build on a Ubuntu machine (kernel 4.4.0-64-generic), but I need my > program to be executed on an old Cento 5.8 (kernel 2.6.18). I tried > compiling with "-static" to have static linking, but when I try to > execute I get "ERROR: Kernel too old!" > > I therefore locally compiled a glibc with support for kernel 2.6.18 ... > but how can I have Cmake use it instead of the system one? > > Thanks, > > > Michele > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From chuck.atkins at kitware.com Tue Mar 7 16:33:59 2017 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Tue, 7 Mar 2017 16:33:59 -0500 Subject: [CMake] Link to local glibc In-Reply-To: <4f1c218d-69ae-b194-c6a8-7ef71790d113@astron.nl> References: <2579a434-f182-e158-2d4d-babdf4551439@grenoble-inp.fr> <4f1c218d-69ae-b194-c6a8-7ef71790d113@astron.nl> Message-ID: If you're using a newer Ubuntu environment, I'd suggest using a CentOS 5 docker container. Either that or the VM. - Chuck On Tue, Mar 7, 2017 at 1:53 PM, Marcel Loose wrote: > Hi Michele, > > This could become a painful exercise. You basically have two options: > 1) Treat it as a cross-compilation project, or > 2) Create a virtual machine running CentOS 5.8 and do the build there. > If I were you, I would go for the second option. > > Cheers, > Marcel. > > Op 07-03-17 om 17:56 schreef Michele Portolan: > > Hello, > > > > I build on a Ubuntu machine (kernel 4.4.0-64-generic), but I need my > > program to be executed on an old Cento 5.8 (kernel 2.6.18). I tried > > compiling with "-static" to have static linking, but when I try to > > execute I get "ERROR: Kernel too old!" > > > > I therefore locally compiled a glibc with support for kernel 2.6.18 ... > > but how can I have Cmake use it instead of the system one? > > > > Thanks, > > > > > > Michele > > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele.portolan at grenoble-inp.fr Wed Mar 8 02:48:31 2017 From: michele.portolan at grenoble-inp.fr (Michele Portolan) Date: Wed, 8 Mar 2017 08:48:31 +0100 Subject: [CMake] Link to local glibc In-Reply-To: References: <2579a434-f182-e158-2d4d-babdf4551439@grenoble-inp.fr> <4f1c218d-69ae-b194-c6a8-7ef71790d113@astron.nl> Message-ID: I'll try and see if I can compile a gcc 4.9.3 chain on the CentOS 5 machine (I need C++11). The docker container looks interesting but I haven't used it yet: does it need some specific install on the target machine? I don't have any install rights on the Cento 5.11 machine.... Thanks, Michele Le 07/03/2017 ? 22:33, Chuck Atkins a ?crit : > If you're using a newer Ubuntu environment, I'd suggest using a CentOS > 5 docker container. Either that or the VM. > > - Chuck > > On Tue, Mar 7, 2017 at 1:53 PM, Marcel Loose > wrote: > > Hi Michele, > > This could become a painful exercise. You basically have two options: > 1) Treat it as a cross-compilation project, or > 2) Create a virtual machine running CentOS 5.8 and do the build there. > If I were you, I would go for the second option. > > Cheers, > Marcel. > > Op 07-03-17 om 17:56 schreef Michele Portolan: > > Hello, > > > > I build on a Ubuntu machine (kernel 4.4.0-64-generic), but I need my > > program to be executed on an old Cento 5.8 (kernel 2.6.18). I tried > > compiling with "-static" to have static linking, but when I try to > > execute I get "ERROR: Kernel too old!" > > > > I therefore locally compiled a glibc with support for kernel > 2.6.18 ... > > but how can I have Cmake use it instead of the system one? > > > > Thanks, > > > > > > Michele > > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > Kitware offers various services to support the CMake community. > For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard.seckinger at gmx.de Wed Mar 8 04:00:19 2017 From: bernhard.seckinger at gmx.de (Bernhard Seckinger) Date: Wed, 8 Mar 2017 10:00:19 +0100 Subject: [CMake] CPACK, generating deb packages: md5sums and wrong directory permissons Message-ID: <20170308100019.2479418fcedb6cfa63744258@gmx.de> Hi all, I'm using cpack to generate a debian package. There are two things that look like bugs in cpack to me (although it might also be, that I got something wrong): a) Files, that I install with install(FILES ...) get the wrong name in the md5sum section. Names should be e.g. "usr/bin/croco", but are "/path/to/build/directory/_CPack_Packages/Linux/DEB/croco-0.1.1-Linux/usr/bin/croco". Not only, that the md5sums cannot be checked automatically, but also my build path is exposed in the deb package. b) Directory permissions of automatically created directories are set to 770 instead of 755 which is standard. This includes even directories, that are part of the ${CMAKE_INSTALL_PREFIX}. For everything else I could add an install(DIRECTORY ... DIRECTORY_PERMISSIONS) although I think, that even this should not be necessary. Is it me, who's doing something wrong or should I file a bug report somewhere? Berni -- -- Meine R?tselwebseite: www.croco-puzzle.com From domen.vrankar at gmail.com Wed Mar 8 04:27:26 2017 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 8 Mar 2017 10:27:26 +0100 Subject: [CMake] CPACK, generating deb packages: md5sums and wrong directory permissons In-Reply-To: <20170308100019.2479418fcedb6cfa63744258@gmx.de> References: <20170308100019.2479418fcedb6cfa63744258@gmx.de> Message-ID: 2017-03-08 10:00 GMT+01:00 Bernhard Seckinger : > Hi all, > > I'm using cpack to generate a debian package. There are two things that > look > like bugs in cpack to me (although it might also be, that I got something > wrong): > > a) Files, that I install with install(FILES ...) get the wrong name in the > md5sum section. Names should be e.g. "usr/bin/croco", but are > "/path/to/build/directory/_CPack_Packages/Linux/DEB/ > croco-0.1.1-Linux/usr/bin/croco". > Not only, that the md5sums cannot be checked automatically, but also my > build > path is exposed in the deb package. > This was already reported and the fix should be part of CMake 3.8. > b) Directory permissions of automatically created directories are set to > 770 > instead of 755 which is standard. This includes even directories, that are > part of the ${CMAKE_INSTALL_PREFIX}. For everything else I could add an > install(DIRECTORY ... DIRECTORY_PERMISSIONS) although I think, that even > this > should not be necessary. > This came up in the past and if I recall correctly the only workaround was the install(DIRECTORY ... DIRECTORY_PERMISSIONS) that you mentioned. Please file a bug report for this one. Thanks, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard.seckinger at gmx.de Wed Mar 8 10:23:41 2017 From: bernhard.seckinger at gmx.de (Bernhard Seckinger) Date: Wed, 8 Mar 2017 16:23:41 +0100 Subject: [CMake] CPACK, generating deb packages: md5sums and wrong directory permissons In-Reply-To: References: <20170308100019.2479418fcedb6cfa63744258@gmx.de> Message-ID: <20170308162341.5c56c51b0c2a4491fed84f55@gmx.de> Hi Domen, > This came up in the past and if I recall correctly the only workaround was > the install(DIRECTORY ... DIRECTORY_PERMISSIONS) that you mentioned. Please > file a bug report for this one. Where is the best place to do so? Berni -- -- Meine R?tselwebseite: www.croco-puzzle.com From domen.vrankar at gmail.com Wed Mar 8 10:37:01 2017 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Wed, 8 Mar 2017 16:37:01 +0100 Subject: [CMake] CPACK, generating deb packages: md5sums and wrong directory permissons In-Reply-To: <20170308162341.5c56c51b0c2a4491fed84f55@gmx.de> References: <20170308100019.2479418fcedb6cfa63744258@gmx.de> <20170308162341.5c56c51b0c2a4491fed84f55@gmx.de> Message-ID: 2017-03-08 16:23 GMT+01:00 Bernhard Seckinger : > Hi Domen, > > > This came up in the past and if I recall correctly the only workaround > was > > the install(DIRECTORY ... DIRECTORY_PERMISSIONS) that you mentioned. > Please > > file a bug report for this one. > > Where is the best place to do so? > https://gitlab.kitware.com/users/sign_in Thanks, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Wed Mar 8 11:57:50 2017 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Wed, 8 Mar 2017 11:57:50 -0500 Subject: [CMake] Link to local glibc In-Reply-To: References: <2579a434-f182-e158-2d4d-babdf4551439@grenoble-inp.fr> <4f1c218d-69ae-b194-c6a8-7ef71790d113@astron.nl> Message-ID: > > I'll try and see if I can compile a gcc 4.9.3 chain on the CentOS 5 > machine (I need C++11). > I'd suggest using the devtollset repo from https://people.centos.org/tru/devtools/devtools.repo > The docker container looks interesting but I haven't used it yet: does it > need some specific install on the target machine? I don't have any install > rights on the Cento 5.11 machine.... > I think you misunderstand. I meant to use a docker container on your Ubuntu machine running CentOS 5 as a development environment. That way you can use your Ubuntu workstation to build in a CentOS 5 environment. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.doucet at inria.fr Thu Mar 9 17:41:03 2017 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Thu, 9 Mar 2017 23:41:03 +0100 (CET) Subject: [CMake] Missing 'undefined dynamic_lookup' flag In-Reply-To: <506662378.1170459.1489098354104.JavaMail.zimbra@inria.fr> Message-ID: <1030213491.1172477.1489099263657.JavaMail.zimbra@inria.fr> Hello, I am trying to find a portable way of generating modules with CMake. Here is a toy CMake script: ------------------------------- CMAKE_MINIMUM_REQUIRED(VERSION 2.8) PROJECT(dlopen_example CXX) ADD_EXECUTABLE(main main.cpp print_ref.cpp) TARGET_LINK_LIBRARIES(main dl) ADD_LIBRARY(module MODULE module.cpp) ------------------------------- This script works fine with g++ on Linux Ubuntu. However, I get an error message with clang on Mac OSX: ---------------------------- Undefined symbols for architecture x86_64: "print_ref()", referenced from: _module in module.cpp.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [libmodule.so] Error 1 make[1]: *** [CMakeFiles/module.dir/all] Error 2 make: *** [all] Error 2 ---------------------------- I found a solution to this problem by adding the 'undefined dynamic_lookup' flag : SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -undefined dynamic_lookup") But, I am surprised that the MODULE option of ADD_LIBRARY does not handle such a flag. Is there a portable solution to this problem with CMake? Best regards, C?dric Doucet -------------- next part -------------- An HTML attachment was scrubbed... URL: From cedric.doucet at inria.fr Thu Mar 9 18:31:20 2017 From: cedric.doucet at inria.fr (Cedric Doucet) Date: Fri, 10 Mar 2017 00:31:20 +0100 (CET) Subject: [CMake] Missing 'undefined dynamic_lookup' flag In-Reply-To: <1030213491.1172477.1489099263657.JavaMail.zimbra@inria.fr> References: <1030213491.1172477.1489099263657.JavaMail.zimbra@inria.fr> Message-ID: <249802461.1175850.1489102280298.JavaMail.zimbra@inria.fr> Actually, I should not modify CMAKE_CXX_COMPILER_FLAGS. It seems that the problem comes from the variable CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS which only contains ' -bundle -Wl,-headerpad_max_install_names' but not ' -undefined dynamic_lookup'. How to overcome this problem? ----- Mail original ----- > De: "Cedric Doucet" > ?: cmake at cmake.org > Envoy?: Jeudi 9 Mars 2017 23:41:03 > Objet: Missing 'undefined dynamic_lookup' flag > Hello, > I am trying to find a portable way of generating modules with CMake. > Here is a toy CMake script: > ------------------------------- > CMAKE_MINIMUM_REQUIRED(VERSION 2.8) > PROJECT(dlopen_example CXX) > ADD_EXECUTABLE(main main.cpp print_ref.cpp) > TARGET_LINK_LIBRARIES(main dl) > ADD_LIBRARY(module MODULE module.cpp) > ------------------------------- > This script works fine with g++ on Linux Ubuntu. > However, I get an error message with clang on Mac OSX: > ---------------------------- > Undefined symbols for architecture x86_64: > "print_ref()", referenced from: > _module in module.cpp.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make[2]: *** [libmodule.so] Error 1 > make[1]: *** [CMakeFiles/module.dir/all] Error 2 > make: *** [all] Error 2 > ---------------------------- > I found a solution to this problem by adding the 'undefined dynamic_lookup' > flag : > SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -undefined dynamic_lookup") > But, I am surprised that the MODULE option of ADD_LIBRARY does not handle > such a flag. > Is there a portable solution to this problem with CMake? > Best regards, > C?dric Doucet -------------- next part -------------- An HTML attachment was scrubbed... URL: From tenorsax at gmail.com Fri Mar 10 11:47:02 2017 From: tenorsax at gmail.com (TT) Date: Fri, 10 Mar 2017 09:47:02 -0700 (MST) Subject: [CMake] CMake with VS2015 C++ Build Tools and missing ucrtbased.dll In-Reply-To: <578232FB.8040804@codelibre.net> References: <578232FB.8040804@codelibre.net> Message-ID: <1489164422279-7595151.post@n2.nabble.com> I'm having the same problem with "missing" ucrtbased.dll even though it is present in all the platforms under C:\Program Files (x86)\Windows Kits\10\bin\ I have tried reinstalling the Windows SDK and the Microsoft C++ Build Tools (2015). Here are some related links with no solutions: 1) https://social.msdn.microsoft.com/Forums/en-US/25a64cd8-1482-4cc4-9dbb-3a420c7a31be/visual-c-build-tools-doesnt-install-ucrtbaseddll?forum=vssetup - I can't reinstall Visual Studio, because I never installed it, only the aforementioned Build Tools. 2) http://stackoverflow.com/questions/33743493/why-visual-studio-2015-cant-run-exe-file-ucrtbased-dll/41970093 - This one says "This problem is from VS 2015 silently failing to copy ucrtbased.dll (debug) and ucrtbase.dll (release) into the appropriate system folders.." Here is a recent answer that seems to be getting at the root cause of the problem: http://stackoverflow.com/a/35466136/3066295 Which links to this, https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ Which has a comment part way down that says "When debugging on machines that do not have the Windows SDK installed, we would recommend copying the debug Universal CRT (ucrtbased.dll) app-locally with your app, or copying it to the system directory yourself." So the solution seems to be install either the Windows SDK (10 not just 8.1 as I have) or copy the ucrtbased.dll to C:\Windows\System32 -- View this message in context: http://cmake.3232098.n2.nabble.com/CMake-with-VS2015-C-Build-Tools-and-missing-ucrtbased-dll-tp7593931p7595151.html Sent from the CMake mailing list archive at Nabble.com. From d3ck0r at gmail.com Fri Mar 10 12:02:18 2017 From: d3ck0r at gmail.com (J Decker) Date: Fri, 10 Mar 2017 09:02:18 -0800 Subject: [CMake] CMake with VS2015 C++ Build Tools and missing ucrtbased.dll In-Reply-To: <1489164422279-7595151.post@n2.nabble.com> References: <578232FB.8040804@codelibre.net> <1489164422279-7595151.post@n2.nabble.com> Message-ID: or copy ucrtbased.dll into your program directory... ucrtbaseD.dll is the debug version, and is only installed with the compilers, and not just the windows kits(?). On Fri, Mar 10, 2017 at 8:47 AM, TT wrote: > I'm having the same problem with "missing" ucrtbased.dll even though it is > present in all the platforms under C:\Program Files (x86)\Windows > Kits\10\bin\ > > I have tried reinstalling the Windows SDK and the Microsoft C++ Build Tools > (2015). > > Here are some related links with no solutions: > > 1) > https://social.msdn.microsoft.com/Forums/en-US/25a64cd8- > 1482-4cc4-9dbb-3a420c7a31be/visual-c-build-tools-doesnt- > install-ucrtbaseddll?forum=vssetup > - I can't reinstall Visual Studio, because I never installed it, only the > aforementioned Build Tools. > > 2) > http://stackoverflow.com/questions/33743493/why-visual- > studio-2015-cant-run-exe-file-ucrtbased-dll/41970093 > - This one says "This problem is from VS 2015 silently failing to copy > ucrtbased.dll (debug) and ucrtbase.dll (release) into the appropriate > system > folders.." > > Here is a recent answer that seems to be getting at the root cause of the > problem: > http://stackoverflow.com/a/35466136/3066295 > > Which links to this, > https://blogs.msdn.microsoft.com/vcblog/2015/03/03/ > introducing-the-universal-crt/ > > Which has a comment part way down that says "When debugging on machines > that > do not have the Windows SDK installed, we would recommend copying the debug > Universal CRT (ucrtbased.dll) app-locally with your app, or copying it to > the system directory yourself." > > So the solution seems to be install either the Windows SDK (10 not just 8.1 > as I have) or copy the ucrtbased.dll to C:\Windows\System32 > > > > -- > View this message in context: http://cmake.3232098.n2. > nabble.com/CMake-with-VS2015-C-Build-Tools-and-missing-ucrtbased-dll- > tp7593931p7595151.html > 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: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rleigh at codelibre.net Fri Mar 10 12:30:22 2017 From: rleigh at codelibre.net (Roger Leigh) Date: Fri, 10 Mar 2017 17:30:22 +0000 Subject: [CMake] CMake with VS2015 C++ Build Tools and missing ucrtbased.dll In-Reply-To: <1489164422279-7595151.post@n2.nabble.com> References: <578232FB.8040804@codelibre.net> <1489164422279-7595151.post@n2.nabble.com> Message-ID: On 10/03/2017 16:47, TT wrote: > I'm having the same problem with "missing" ucrtbased.dll even though it is > present in all the platforms under C:\Program Files (x86)\Windows > Kits\10\bin\ > > I have tried reinstalling the Windows SDK and the Microsoft C++ Build Tools > (2015). From Andrew Pardoe: "It turns out that the Build Tools SKU only installs the universal CRT for developers on Windows 10. We should have had it install on all OS. We'll fix this in the next release." From a private reply from this thread: https://www.reddit.com/r/cpp/comments/4r8n41/what_are_some_reasons_why_visual_studio_seems_so/d51sh2f/?context=3 It's a bit broken. The 2017 version seems OK though. Regards, Roger From ford at squareup.com Fri Mar 10 13:21:01 2017 From: ford at squareup.com (Ford Peprah) Date: Fri, 10 Mar 2017 10:21:01 -0800 Subject: [CMake] [CTest] Using rerun-failed when tests pass the first time Message-ID: Hey all, My team is using CMake as our build system, and we're also using CTest for our unit tests. We wanted to speed up running tests by only running the tests that failed previously or when the binary file had changed. While trying to use '--rerun-failed', we noticed that all our tests were being run on subsequent ctest invocations, even though they had all passed on the previous step. After looking into it, we saw that the file 'LastTestsFailed.log' was not being created. We tried making a simple empty one, but that didn't change anything. We then changed one of our tests to fail, then tried running 'ctest' with '--rerun-failed' again, and on the subsequent run it only re-ran that failed test. We reverted that test back to normal, and now '--rerun-failed' only runs that test, which makes sense based on the documentation. Is this by design? We expected that if all our tests never failed on the first invocation, that subsequent runs would not cause those tests to re-run unless the binary had changed. The behaviour also seems inconsistent, since if you add an entry into an empty 'LastTestsFailed.log' for a non-existant test, then subsequent test runs will not run any of your tests. I've given steps below on how to reproduce the issue with the attached demo. Version: ctest version 3.7.2 Steps to Reproduce: 1. Copy over the sources. 2. Make a build directory, change to that build directory. 3. Run 'cmake ..', 'make', then followed by 'ctest --rerun-failed'; all tests should run. 4. Run 'ctest --rerun-failed' again; all tests should run. 5. Open up the 'CMakeLists.txt' you copied in the earlier step, uncomment the division test. 6. Run 'cmake ..', 'make', then followed by 'ctest --rerun-failed'; all tests should run. 7. Run 'ctest --rerun-failed' again; only the 'division' test should run. 8. Open up the 'CMakeLists.txt' you copied in the earlier step, comment the division test. 9. Run 'cmake ..', 'make', then followed by 'ctest --rerun-failed'; should output "No tests were found!!!" Expected Behaviour: 1. If no 'LastTestsFailed.log' exists, should create one; if no tests failed, then this file should be empty. 2. On subsequent runs, if a 'LastTestsFailed.log' exists, but is empty, then no tests should be run. Attached is the example code (example.zip) MD5 (example.zip) = 786c191c767f3865b1fc307efe022076 Cheers, Ford -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: example.zip Type: application/zip Size: 1708 bytes Desc: not available URL: From a.neundorf-work at gmx.net Fri Mar 10 16:46:21 2017 From: a.neundorf-work at gmx.net (Alexander Neundorf) Date: Fri, 10 Mar 2017 22:46:21 +0100 Subject: [CMake] cdash/ctest question In-Reply-To: <50320452A334BD42A5EC72BAD21450993DDCE4B5@MBX110.d.ethz.ch> References: <8703684.uaWUrAkQri@tuxedo.neundorf.net> <50320452A334BD42A5EC72BAD21450993DDCE4B5@MBX110.d.ethz.ch> Message-ID: <8324694.F0YGN0Frr8@linux-l7nd> Hi John, On 2016 M01 19, Tue 07:55:27 CET Biddiscombe, John A. wrote: > Alex > > Thank you for this information. I shall test this out right away. so, did it work out ? Alex From kim.walisch at gmail.com Sat Mar 11 05:42:29 2017 From: kim.walisch at gmail.com (Kim Walisch) Date: Sat, 11 Mar 2017 11:42:29 +0100 Subject: [CMake] cmake treat warnings as errors Message-ID: Hi, Obviously the return code of cmake is 1 if any error occurs. For integration testing I would like the return code of cmake to be 1 as well if any warning occurs (during configuration). Is there an option for this? From gjasny at googlemail.com Sun Mar 12 13:45:44 2017 From: gjasny at googlemail.com (Gregor Jasny) Date: Sun, 12 Mar 2017 18:45:44 +0100 Subject: [CMake] Missing 'undefined dynamic_lookup' flag In-Reply-To: <249802461.1175850.1489102280298.JavaMail.zimbra@inria.fr> References: <1030213491.1172477.1489099263657.JavaMail.zimbra@inria.fr> <249802461.1175850.1489102280298.JavaMail.zimbra@inria.fr> Message-ID: <7e1e7c98-6292-48e4-bd8e-683147216e6e@googlemail.com> Hello, On 3/10/17 12:31 AM, Cedric Doucet wrote: > Actually, I should not modify CMAKE_CXX_COMPILER_FLAGS. > It seems that the problem comes from the variable CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS which only contains ' -bundle -Wl,-headerpad_max_install_names' but not ' -undefined dynamic_lookup'. Please try: TARGET_LINK_LIBRARIES(main "-undefined dynamic_lookup") Thanks, Gregor From gjasny at googlemail.com Sun Mar 12 13:49:17 2017 From: gjasny at googlemail.com (Gregor Jasny) Date: Sun, 12 Mar 2017 18:49:17 +0100 Subject: [CMake] Missing 'undefined dynamic_lookup' flag In-Reply-To: <7e1e7c98-6292-48e4-bd8e-683147216e6e@googlemail.com> References: <1030213491.1172477.1489099263657.JavaMail.zimbra@inria.fr> <249802461.1175850.1489102280298.JavaMail.zimbra@inria.fr> <7e1e7c98-6292-48e4-bd8e-683147216e6e@googlemail.com> Message-ID: <98ddd2a0-059d-c86c-2690-bf9bb1d82b18@googlemail.com> On 3/12/17 6:45 PM, Gregor Jasny wrote: > On 3/10/17 12:31 AM, Cedric Doucet wrote: >> Actually, I should not modify CMAKE_CXX_COMPILER_FLAGS. >> It seems that the problem comes from the variable CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS which only contains ' -bundle -Wl,-headerpad_max_install_names' but not ' -undefined dynamic_lookup'. > > Please try: > > TARGET_LINK_LIBRARIES(main "-undefined dynamic_lookup") Meh. main should have been module. You could also try to add it to CMAKE_SHARED_LINKER_FLAGS. Thanks, Gregor From michele.portolan at grenoble-inp.fr Mon Mar 13 08:02:41 2017 From: michele.portolan at grenoble-inp.fr (Michele Portolan) Date: Mon, 13 Mar 2017 13:02:41 +0100 Subject: [CMake] Link to local glibc In-Reply-To: References: <2579a434-f182-e158-2d4d-babdf4551439@grenoble-inp.fr> <4f1c218d-69ae-b194-c6a8-7ef71790d113@astron.nl> Message-ID: At the end of the day, here is what I did: 1) create a development Centos 5.5 machine 2) on the dev machine, I compiled gcc 4.9.3 from sources, installed it locally and updated the build system (cmake, etc..) with only local builds, if possible from source. By exploiting LD_LIBRARY_PATH, I link to the glibc et al. in the gcc 4.9.3 installation path 3) I run Cmake on the dev machine, to obtain the executables and libraries 4) I prepare a distribution with the Cmake-built exe and libs, and in case of dynamic linking, the dependecies found by ldd 5) I unpack the distribution on my target Cento0S 5.5 machine and run the execs, if needed using LD_LIBRARY_PATH for the local libs Quite the workaround, but it works better than manually handling all glibc dependencies! Michele On 08/03/17 17:57, Chuck Atkins wrote: > > I'll try and see if I can compile a gcc 4.9.3 chain on the CentOS > 5 machine (I need C++11). > > I'd suggest using the devtollset repo from > https://people.centos.org/tru/devtools/devtools.repo > > The docker container looks interesting but I haven't used it yet: > does it need some specific install on the target machine? I don't > have any install rights on the Cento 5.11 machine.... > > > I think you misunderstand. I meant to use a docker container on your > Ubuntu machine running CentOS 5 as a development environment. That > way you can use your Ubuntu workstation to build in a CentOS 5 > environment. > > - Chuck > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rianquinn at gmail.com Mon Mar 13 12:09:39 2017 From: rianquinn at gmail.com (Rian Quinn) Date: Mon, 13 Mar 2017 10:09:39 -0600 Subject: [CMake] Download more then one repo prior to build_command Message-ID: Below is my current cmake script for building libc++. There are several things about this script I would like to cleanup, but the really big one is fact that I have to download libcxx and libcxxabi twice. This is because libcxx, libcxxabi and llvm have a circular dependency (each relies on the other), so all three repos need to be downloaded before libcxxabi can be built, and then finally libcxx. Any thoughts on ways I can remove the extra download? I tried setting DOWNLOAD_COMMAND ??, and then setting SOURCE_DIR to the previously downloaded location, but cmake complains about the fact that the directory is empty (because it has not been downloaded during the configure step). Thanks, - Rian ---------------------------------------------------------------------------------------------------------------------------------------------------------------- # cmake -DCMAKE_TOOLCHAIN_FILE=~/bfprefix/cmake/CMakeToolchain_VMM.txt -DDISABLE_WARNINGS=on .. cmake_minimum_required(VERSION 3.4) project(bfsysroot C CXX) if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT) set(CMAKE_INSTALL_PREFIX "$ENV{HOME}/bfprefix" CACHE PATH "default install path" FORCE) endif() include("${CMAKE_INSTALL_PREFIX}/cmake/CMakeGlobal_Project.txt") # ------------------------------------------------------------------------------ # Newlib # ------------------------------------------------------------------------------ list(APPEND NEWLIB_ARGS "--prefix=${CMAKE_INSTALL_PREFIX}/sysroots/" "--target=${BAREFLANK_TARGET}" "--disable-libgloss" "--disable-multilib" "--disable-newlib-supplied-syscalls" "--enable-newlib-multithread" "--enable-newlib-iconv" "CC_FOR_TARGET=${CMAKE_C_COMPILER}" "CXX_FOR_TARGET=${CMAKE_CXX_COMPILER}" ) ExternalProject_Add( newlib PREFIX ${CMAKE_BINARY_DIR}/newlib GIT_REPOSITORY https://github.com/Bareflank/newlib.git GIT_TAG newlib-2.5.0-v1.2 CONFIGURE_COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/newlib/configure "${NEWLIB_ARGS}" CFLAGS_FOR_TARGET=${CMAKE_C_FLAGS} BUILD_COMMAND make INSTALL_COMMAND make install LOG_CONFIGURE 1 LOG_BUILD 1 LOG_INSTALL 1 ) # ------------------------------------------------------------------------------ # Unwind # ------------------------------------------------------------------------------ list(APPEND BFUNWIND_CMAKE_ARGS "-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}" "-DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE}" ) ExternalProject_Add( bfunwind PREFIX ${CMAKE_BINARY_DIR}/bfunwind GIT_REPOSITORY https://github.com/Bareflank/bfunwind.git CMAKE_ARGS ${BFUNWIND_CMAKE_ARGS} DEPENDS newlib ) # ------------------------------------------------------------------------------ # Download LLVM # ------------------------------------------------------------------------------ ExternalProject_Add( download_llvm PREFIX ${CMAKE_BINARY_DIR}/download_llvm DOWNLOAD_COMMAND git clone --depth 1 -b release_39 https://github.com/llvm-mirror/llvm.git download_llvm CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND "" ) # ------------------------------------------------------------------------------ # Download Libcxxabi # ------------------------------------------------------------------------------ ExternalProject_Add( download_libcxxabi PREFIX ${CMAKE_BINARY_DIR}/download_libcxxabi DOWNLOAD_COMMAND git clone --depth 1 -b libcxxabi-39-v1 https://github.com/Bareflank/libcxxabi.git download_libcxxabi CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND "" ) # ------------------------------------------------------------------------------ # Download Libcxx # ------------------------------------------------------------------------------ ExternalProject_Add( download_libcxx PREFIX ${CMAKE_BINARY_DIR}/download_libcxx DOWNLOAD_COMMAND git clone --depth 1 -b libcxx-39-v1 https://github.com/Bareflank/libcxx.git download_libcxx CONFIGURE_COMMAND "" BUILD_COMMAND "" INSTALL_COMMAND "" ) # ------------------------------------------------------------------------------ # Libcxxabi # ------------------------------------------------------------------------------ list(APPEND LIBCXXABI_CMAKE_ARGS "-DCMAKE_INSTALL_PREFIX=${BAREFLANK_SYSROOT_PATH}" "-DLLVM_PATH=${CMAKE_BINARY_DIR}/download_llvm/src/download_llvm" "-DLIBCXXABI_LIBCXX_PATH=${CMAKE_BINARY_DIR}/download_libcxx/src/download_libcxx" "-DLIBCXXABI_SYSROOT=${BAREFLANK_SYSROOT_PATH}" "-DLIBCXXABI_HAS_PTHREAD_API=ON" "-DLLVM_ENABLE_LIBCXX=ON" "-DCMAKE_SYSTEM_NAME=${CMAKE_SYSTEM_NAME}" "-DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}" "-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}" "-DCMAKE_AR=${CMAKE_AR}" "-DCMAKE_C_FLAGS=${CMAKE_C_FLAGS}" "-DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}" ) ExternalProject_Add( libcxxabi PREFIX ${CMAKE_BINARY_DIR}/libcxxabi DOWNLOAD_COMMAND git clone --depth 1 -b libcxxabi-39-v1 https://github.com/Bareflank/libcxxabi.git CMAKE_ARGS ${LIBCXXABI_CMAKE_ARGS} DEPENDS bfunwind download_llvm download_libcxx download_libcxxabi ) # ------------------------------------------------------------------------------ # Libcxx # ------------------------------------------------------------------------------ list(APPEND LIBCXX_CMAKE_ARGS "-DCMAKE_INSTALL_PREFIX=${BAREFLANK_SYSROOT_PATH}" "-DLLVM_PATH=${CMAKE_BINARY_DIR}/download_llvm/src/download_llvm" "-DLIBCXX_CXX_ABI=libcxxabi" "-DLIBCXX_CXX_ABI_INCLUDE_PATHS=${CMAKE_BINARY_DIR}/download_libcxxabi/src/download_libcxxabi/include/" "-DLIBCXX_SYSROOT=${BAREFLANK_SYSROOT_PATH}" "-DLIBCXX_HAS_PTHREAD_API=ON" "-DLIBCXX_ENABLE_EXPERIMENTAL_LIBRARY=OFF" "-DCMAKE_SYSTEM_NAME=${CMAKE_SYSTEM_NAME}" "-DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}" "-DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}" "-DCMAKE_AR=${CMAKE_AR}" "-DCMAKE_C_FLAGS=${CMAKE_C_FLAGS}" "-DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}" ) ExternalProject_Add( libcxx PREFIX ${CMAKE_BINARY_DIR}/libcxx DOWNLOAD_COMMAND git clone --depth 1 -b libcxx-39-v1 https://github.com/Bareflank/libcxx.git CMAKE_ARGS ${LIBCXX_CMAKE_ARGS} DEPENDS bfunwind download_llvm download_libcxx download_libcxxabi libcxxabi ) From afuller at teradici.com Mon Mar 13 13:50:16 2017 From: afuller at teradici.com (Andrew Fuller) Date: Mon, 13 Mar 2017 17:50:16 +0000 Subject: [CMake] Clarifying PUBLIC_HEADER property and non-FRAMEWORK / STATIC / INTERFACE libraries Message-ID: I'm finding the PUBLIC_HEADER target property to be quite convenient for clarity's sake. Specifically it spells out quite unambiguously that "hey, these are the headers I want to be published" while at the same time providing locality to the export details with "PUBLIC_HEADER DESTINATION foo" and "INCLUDES DESTINATION foo". Less code by not needing a separate "install( FILES ? )" stanza is a bonus. The documentation for the PUBLIC_HEADER property seems to stress (framework) shared libraries. I'm left wondering if I'm abusing PUBLIC_HEADER by using it on static libraries as well. Am I going to get bit down the road by doing this, or is this use perfectly acceptable? Assuming it's fine to use on static libraries, then how about interface libraries? I see there have been previous discussions on the mailing list about whether more properties should be whitelisted for interface targets, but I didn't see PUBLIC_HEADER brought up. Updating the interface includes directory using the "INCLUDES DESTINATION foo" when exporting an interface library already works, so it would be very nice to be able to leverage PUBLIC_HEADER at the same time. Again, for clarity/consistency/less code. Is there a technical limitation, or is it just a matter of adding public_header to the whitelist? For now I've just got an extra "install( FILES ? )" stanza. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From houssen at ipgp.fr Mon Mar 13 14:33:32 2017 From: houssen at ipgp.fr (houssen) Date: Mon, 13 Mar 2017 19:33:32 +0100 Subject: [CMake] =?utf-8?q?CHECK=5FINCLUDE=5FFILE=5FCXX_with_built_from_so?= =?utf-8?q?urce_compiler?= Message-ID: <4fdd9fcf173330b891fd9024d150ffd7@imap.ipgp.fr> Hello, I do NOT use /usr/bin/g++ that is installed in the system (long story - don't ask why). I compiled gcc from source and installed it in /my/path/local/bin/g++. Now I need to check for tuple with CHECK_INCLUDE_FILE_CXX : it fails ! Still failing if: 1. I export CPLUS_INCLUDE_PATH to point at /my/path/local/include/c++/x.y.z (I checked: tuple is here) 2. set this before calling CHECK_INCLUDE_FILE_CXX : SET ( CMAKE_REQUIRED_FLAGS "-I$ENV{CPLUS_INCLUDE_PATH}" ) SET ( CMAKE_REQUIRED_INCLUDES "$ENV{CPLUS_INCLUDE_PATH}" ) What is wrong ? Franck From houssen at ipgp.fr Mon Mar 13 14:36:11 2017 From: houssen at ipgp.fr (houssen) Date: Mon, 13 Mar 2017 19:36:11 +0100 Subject: [CMake] =?utf-8?q?CHECK=5FINCLUDE=5FFILE=5FCXX_with_built_from_so?= =?utf-8?q?urce_compiler?= In-Reply-To: <4fdd9fcf173330b891fd9024d150ffd7@imap.ipgp.fr> References: <4fdd9fcf173330b891fd9024d150ffd7@imap.ipgp.fr> Message-ID: <67faaf0206b90f2152b73b4b3db415f4@imap.ipgp.fr> Forgot to mention: ~> cmake --version cmake version 3.5.0 Le 2017-03-13 19:33, houssen a ?crit?: > Hello, > > I do NOT use /usr/bin/g++ that is installed in the system (long story > - don't ask why). > I compiled gcc from source and installed it in > /my/path/local/bin/g++. > > Now I need to check for tuple with CHECK_INCLUDE_FILE_CXX : it fails > ! > > Still failing if: > 1. I export CPLUS_INCLUDE_PATH to point at > /my/path/local/include/c++/x.y.z (I checked: tuple is here) > 2. set this before calling CHECK_INCLUDE_FILE_CXX : > SET ( CMAKE_REQUIRED_FLAGS "-I$ENV{CPLUS_INCLUDE_PATH}" ) > SET ( CMAKE_REQUIRED_INCLUDES "$ENV{CPLUS_INCLUDE_PATH}" ) > > What is wrong ? > > Franck From mikelojkovic at gmail.com Wed Mar 15 02:51:37 2017 From: mikelojkovic at gmail.com (mike lojkovic) Date: Tue, 14 Mar 2017 23:51:37 -0700 Subject: [CMake] Is it possible to patch a make project with CMakeLists.txt, through external_project_add? Message-ID: So, I'm trying to get my project to work on Windows, as well as Linux. Currently, everything compiles fine on Linux. I've gotten it to compile in the past on Windows, but since then have reinstalled Windows, and forgotten the precise steps needed to manually setup Lua, so CMake can find it. So, I assume just add Lua to my project with ExternalProject_Add, but they use make and the makefil is configured for Linux. The two options I have are either patch their makefile to build correctly through cygwin, (I'm just worried this might lead to issues with producing a binary requiring cygwin) or add a CMakeLists.txt file and patch it in after the download ends. How would I go about adding custom CMakeLists.txt file to their project after the download finishes? From houssen at ipgp.fr Wed Mar 15 05:12:44 2017 From: houssen at ipgp.fr (houssen) Date: Wed, 15 Mar 2017 10:12:44 +0100 Subject: [CMake] =?utf-8?q?CHECK=5FINCLUDE=5FFILE=5FCXX_with_built_from_so?= =?utf-8?q?urce_compiler?= In-Reply-To: <67faaf0206b90f2152b73b4b3db415f4@imap.ipgp.fr> References: <4fdd9fcf173330b891fd9024d150ffd7@imap.ipgp.fr> <67faaf0206b90f2152b73b4b3db415f4@imap.ipgp.fr> Message-ID: <375742e125701efb5b9ef818334697da@imap.ipgp.fr> For the record, the solution is (try_compile needs this option): SET(CMAKE_REQUIRED_FLAGS "-std=c++11") Is there a way to get this flag whatever the compiler to do this ? [SET_TARGET_PROPERTIES(myTarget PROPERTIES CXX_STANDARD 11) seems to be relevant only for target - flags are not available] Franck Le 2017-03-13 19:36, houssen a ?crit?: > Forgot to mention: > > ~> cmake --version > cmake version 3.5.0 > > > Le 2017-03-13 19:33, houssen a ?crit?: >> Hello, >> >> I do NOT use /usr/bin/g++ that is installed in the system (long >> story >> - don't ask why). >> I compiled gcc from source and installed it in >> /my/path/local/bin/g++. >> >> Now I need to check for tuple with CHECK_INCLUDE_FILE_CXX : it fails >> ! >> >> Still failing if: >> 1. I export CPLUS_INCLUDE_PATH to point at >> /my/path/local/include/c++/x.y.z (I checked: tuple is here) >> 2. set this before calling CHECK_INCLUDE_FILE_CXX : >> SET ( CMAKE_REQUIRED_FLAGS "-I$ENV{CPLUS_INCLUDE_PATH}" ) >> SET ( CMAKE_REQUIRED_INCLUDES "$ENV{CPLUS_INCLUDE_PATH}" ) >> >> What is wrong ? >> >> Franck > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From nick.henderson at gmail.com Wed Mar 15 20:22:14 2017 From: nick.henderson at gmail.com (Nick Henderson) Date: Wed, 15 Mar 2017 17:22:14 -0700 (MST) Subject: [CMake] Question regarding CUDA support in CMake 3.8.0-rc2 Message-ID: <1489623734705-7595171.post@n2.nabble.com> Hello! I am testing out the CUDA support in CMake 3.8.0-rc2. When running `make VERBOSE=1` in the build directory, I get a warning generated related to the GPU architecture flags for nvcc: ``` [ 80%] Linking CUDA device code /home/nwh/git/foobar/build/exec/CMakeFiles/exec.dir/cmake_device_link.o cd /home/nwh/git/foobar/build/exec && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/exec.dir/dlink.txt --verbose=1 /usr/local/cuda/bin/nvcc -Xcompiler=-fPIC -shared -dlink CMakeFiles/exec.dir/exec.cc.o -o CMakeFiles/exec.dir/cmake_device_link.o ../libfoobar.a nvcc warning : The 'compute_20', 'sm_20', and 'sm_21' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning). ``` I don't get the warning when the executable source is being compiled because an up-to-date architecture is specified: ``` [ 60%] Building CUDA object exec/CMakeFiles/exec.dir/exec.cc.o cd /home/nwh/git/foobar/build/exec && /usr/local/cuda/bin/nvcc -I/home/nwh/git/foobar -arch compute_30 -std=c++11 -x cu -c /home/nwh/git/foobar/exec/exec.cc -o CMakeFiles/exec.dir/exec.cc.o ``` Link to sample project: https://github.com/nwh/foobar Questions: * Is this a problem? * What is the purpose of cmake_device_link.o? Thanks, Nick -- View this message in context: http://cmake.3232098.n2.nabble.com/Question-regarding-CUDA-support-in-CMake-3-8-0-rc2-tp7595171.html Sent from the CMake mailing list archive at Nabble.com. From robert.maynard at kitware.com Thu Mar 16 10:37:11 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 16 Mar 2017 10:37:11 -0400 Subject: [CMake] CHECK_INCLUDE_FILE_CXX with built from source compiler In-Reply-To: <375742e125701efb5b9ef818334697da@imap.ipgp.fr> References: <4fdd9fcf173330b891fd9024d150ffd7@imap.ipgp.fr> <67faaf0206b90f2152b73b4b3db415f4@imap.ipgp.fr> <375742e125701efb5b9ef818334697da@imap.ipgp.fr> Message-ID: This is a known issue that will be resolved in CMake 3.8 ( https://cmake.org/cmake/help/v3.8/policy/CMP0067.html#policy:CMP0067 ) On Wed, Mar 15, 2017 at 5:12 AM, houssen wrote: > For the record, the solution is (try_compile needs this option): > SET(CMAKE_REQUIRED_FLAGS "-std=c++11") > > Is there a way to get this flag whatever the compiler to do this ? > [SET_TARGET_PROPERTIES(myTarget PROPERTIES CXX_STANDARD 11) seems to be > relevant only for target - flags are not available] > > Franck > > > Le 2017-03-13 19:36, houssen a ?crit : >> >> Forgot to mention: >> >> ~> cmake --version >> cmake version 3.5.0 >> >> >> Le 2017-03-13 19:33, houssen a ?crit : >>> >>> Hello, >>> >>> I do NOT use /usr/bin/g++ that is installed in the system (long story >>> - don't ask why). >>> I compiled gcc from source and installed it in /my/path/local/bin/g++. >>> >>> Now I need to check for tuple with CHECK_INCLUDE_FILE_CXX : it fails ! >>> >>> Still failing if: >>> 1. I export CPLUS_INCLUDE_PATH to point at >>> /my/path/local/include/c++/x.y.z (I checked: tuple is here) >>> 2. set this before calling CHECK_INCLUDE_FILE_CXX : >>> SET ( CMAKE_REQUIRED_FLAGS "-I$ENV{CPLUS_INCLUDE_PATH}" ) >>> SET ( CMAKE_REQUIRED_INCLUDES "$ENV{CPLUS_INCLUDE_PATH}" ) >>> >>> What is wrong ? >>> >>> Franck >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For >> more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From robert.maynard at kitware.com Thu Mar 16 11:01:39 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 16 Mar 2017 11:01:39 -0400 Subject: [CMake] Question regarding CUDA support in CMake 3.8.0-rc2 In-Reply-To: <1489623734705-7595171.post@n2.nabble.com> References: <1489623734705-7595171.post@n2.nabble.com> Message-ID: Hi, The purpose of the cmake_device_link.o is to resolve device side symbols when doing separable compilation. We do this device linking step for all CUDA enabled targets as it makes the internal CMake to logic significantly easier ( no need to propagate another property through the graph, etc ). Updating CMake to only do device linking where needed is theoretical possible, but opens up a new question on consistency [1]. What you have pointed out is actually two issues. The first is that target_compile_options by design does not propagate any flags to the linker, which is a design decision made by CMake. The second being that for CUDA arch/code flags in general need to be passed to both the compiler and the linker. So currently CUDA projects should specify arch/code flags through CMAKE_CUDA_FLAGS/CMAKE_CUDA_FLAGS_ to have them propagate to the linker. [1] - If we only do device linking for targets that need separable compilation, we introduce a split in CUDA targets where some are satisfied by add_compile_options, and others require CMAKE_CUDA_FLAGS/CMAKE_CUDA_FLAGS_. To complicate this situation you can't provide -arch/code in both as that will generally result in a collection of invalid flags. On Wed, Mar 15, 2017 at 8:22 PM, Nick Henderson wrote: > Hello! > > I am testing out the CUDA support in CMake 3.8.0-rc2. > > When running `make VERBOSE=1` in the build directory, I get a warning > generated related to the GPU architecture flags for nvcc: > > ``` > [ 80%] Linking CUDA device code > /home/nwh/git/foobar/build/exec/CMakeFiles/exec.dir/cmake_device_link.o > cd /home/nwh/git/foobar/build/exec && /usr/local/bin/cmake -E > cmake_link_script CMakeFiles/exec.dir/dlink.txt --verbose=1 > /usr/local/cuda/bin/nvcc -Xcompiler=-fPIC -shared -dlink > CMakeFiles/exec.dir/exec.cc.o -o CMakeFiles/exec.dir/cmake_device_link.o > ../libfoobar.a > nvcc warning : The 'compute_20', 'sm_20', and 'sm_21' architectures are > deprecated, and may be removed in a future release (Use > -Wno-deprecated-gpu-targets to suppress warning). > ``` > > I don't get the warning when the executable source is being compiled because > an up-to-date architecture is specified: > > ``` > [ 60%] Building CUDA object exec/CMakeFiles/exec.dir/exec.cc.o > cd /home/nwh/git/foobar/build/exec && /usr/local/cuda/bin/nvcc > -I/home/nwh/git/foobar -arch compute_30 -std=c++11 -x cu -c > /home/nwh/git/foobar/exec/exec.cc -o CMakeFiles/exec.dir/exec.cc.o > ``` > > Link to sample project: https://github.com/nwh/foobar > > Questions: > > * Is this a problem? > * What is the purpose of cmake_device_link.o? > > Thanks, > Nick > > > > -- > View this message in context: http://cmake.3232098.n2.nabble.com/Question-regarding-CUDA-support-in-CMake-3-8-0-rc2-tp7595171.html > 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: > http://public.kitware.com/mailman/listinfo/cmake From nick.henderson at gmail.com Thu Mar 16 13:58:22 2017 From: nick.henderson at gmail.com (Nick Henderson) Date: Thu, 16 Mar 2017 10:58:22 -0700 (MST) Subject: [CMake] Question regarding CUDA support in CMake 3.8.0-rc2 In-Reply-To: References: <1489623734705-7595171.post@n2.nabble.com> Message-ID: <1489687102703-7595174.post@n2.nabble.com> Thank you! Setting: set(CMAKE_CUDA_FLAGS "-arch compute_30 ${CMAKE_CUDA_FLAGS}") did the trick. Is there any documentation or example projects related to the new CUDA support? CUDA support is great to have and will simplify my build system! Thank you. -- View this message in context: http://cmake.3232098.n2.nabble.com/Question-regarding-CUDA-support-in-CMake-3-8-0-rc2-tp7595171p7595174.html Sent from the CMake mailing list archive at Nabble.com. From andrew.amaclean at gmail.com Thu Mar 16 18:24:47 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 17 Mar 2017 09:24:47 +1100 Subject: [CMake] Building using Qt 5.8 and VS2017. Message-ID: At present the builds will fail. I have posted a report on the Qt forum: https://forum.qt.io/topic/77260/errors-when-building-cmake-and-vtk In the interim here is a temporary fix: The problem relates to the Qt macro: **Q_DECL_CONSTEXPR** If it is commented out in lines 593 to 714 of *qalgorithms.h* then the builds work for CMake and VTK and any other Qt build using VS2017. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wesley.hoke at gmail.com Thu Mar 16 20:23:54 2017 From: wesley.hoke at gmail.com (Wesley Smith) Date: Thu, 16 Mar 2017 17:23:54 -0700 Subject: [CMake] C# Language Detection Errors in 3.8.0-rc2 Message-ID: I'm trying to test out the C# features added to 3.8.0. A few things: + I couldn't find any documentation as to what the language name for CSHARP was in the enable_language documentation page + When I tried enable_language(CSHARP), I got some errors CMake Error at CMakeLists.txt:4 (enable_language): No CMAKE_CSHARP_COMPILER could be found. In the error log, I see: The CSharp compiler identification could not be found in "/build_/CMakeFiles/3.8.0-rc2/CompilerIdCSharp/CompilerIdCSharp.csproj" When I open this project, it compiles and runs just fine. I'm not sure why it's giving an error. Any thoughts? thanks, wes -------------- next part -------------- An HTML attachment was scrubbed... URL: From houssen at ipgp.fr Fri Mar 17 04:20:26 2017 From: houssen at ipgp.fr (houssen) Date: Fri, 17 Mar 2017 09:20:26 +0100 Subject: [CMake] =?utf-8?q?CHECK=5FINCLUDE=5FFILE=5FCXX_with_built_from_so?= =?utf-8?q?urce_compiler?= In-Reply-To: References: <4fdd9fcf173330b891fd9024d150ffd7@imap.ipgp.fr> <67faaf0206b90f2152b73b4b3db415f4@imap.ipgp.fr> <375742e125701efb5b9ef818334697da@imap.ipgp.fr> Message-ID: <0f4866f5e5d4488e2557030bb2a788b0@imap.ipgp.fr> OK, thanks ! Franck Le 2017-03-16 15:37, Robert Maynard a ?crit?: > This is a known issue that will be resolved in CMake 3.8 ( > https://cmake.org/cmake/help/v3.8/policy/CMP0067.html#policy:CMP0067 > ) > > On Wed, Mar 15, 2017 at 5:12 AM, houssen wrote: >> For the record, the solution is (try_compile needs this option): >> SET(CMAKE_REQUIRED_FLAGS "-std=c++11") >> >> Is there a way to get this flag whatever the compiler to do this ? >> [SET_TARGET_PROPERTIES(myTarget PROPERTIES CXX_STANDARD 11) seems to >> be >> relevant only for target - flags are not available] >> >> Franck >> >> >> Le 2017-03-13 19:36, houssen a ?crit : >>> >>> Forgot to mention: >>> >>> ~> cmake --version >>> cmake version 3.5.0 >>> >>> >>> Le 2017-03-13 19:33, houssen a ?crit : >>>> >>>> Hello, >>>> >>>> I do NOT use /usr/bin/g++ that is installed in the system (long >>>> story >>>> - don't ask why). >>>> I compiled gcc from source and installed it in >>>> /my/path/local/bin/g++. >>>> >>>> Now I need to check for tuple with CHECK_INCLUDE_FILE_CXX : it >>>> fails ! >>>> >>>> Still failing if: >>>> 1. I export CPLUS_INCLUDE_PATH to point at >>>> /my/path/local/include/c++/x.y.z (I checked: tuple is here) >>>> 2. set this before calling CHECK_INCLUDE_FILE_CXX : >>>> SET ( CMAKE_REQUIRED_FLAGS "-I$ENV{CPLUS_INCLUDE_PATH}" ) >>>> SET ( CMAKE_REQUIRED_INCLUDES "$ENV{CPLUS_INCLUDE_PATH}" ) >>>> >>>> What is wrong ? >>>> >>>> Franck >>> >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For >>> more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >> >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For >> more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake From robert.maynard at kitware.com Fri Mar 17 14:03:49 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 17 Mar 2017 14:03:49 -0400 Subject: [CMake] Question regarding CUDA support in CMake 3.8.0-rc2 In-Reply-To: <1489687102703-7595174.post@n2.nabble.com> References: <1489623734705-7595171.post@n2.nabble.com> <1489687102703-7595174.post@n2.nabble.com> Message-ID: A good starting spot would be the tests in CMake itself for CUDA support: https://gitlab.kitware.com/cmake/cmake/tree/master/Tests/Cuda https://gitlab.kitware.com/cmake/cmake/tree/master/Tests/CudaOnly On Thu, Mar 16, 2017 at 1:58 PM, Nick Henderson wrote: > Thank you! > > Setting: > > set(CMAKE_CUDA_FLAGS "-arch compute_30 ${CMAKE_CUDA_FLAGS}") > > did the trick. > > Is there any documentation or example projects related to the new CUDA > support? > > CUDA support is great to have and will simplify my build system! Thank you. > > > > -- > View this message in context: http://cmake.3232098.n2.nabble.com/Question-regarding-CUDA-support-in-CMake-3-8-0-rc2-tp7595171p7595174.html > 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: > http://public.kitware.com/mailman/listinfo/cmake From csiga.biga at aol.com Sat Mar 18 11:16:10 2017 From: csiga.biga at aol.com (csiga.biga at aol.com) Date: Sat, 18 Mar 2017 16:16:10 +0100 Subject: [CMake] add_custom_target and add_custom_command Message-ID: Hi! Apologies for the noobish question, but even a seasoned CMake user can get lost from time to time. I want to demonstrate the feasability of automating an article creation proces with CMake. Ultimately I want to issue commands as such on the CLI: make app make data make plot make article These commands would: compile a C/C++ application (no problem) invoke that app with some args (provided by CMake) to create a data file (only if the app or the args have changed) invoke a gnuplot script on the data file to create a plot (only if the the data file or the plotting script have changed) invoke latex to create a document that references the plot (only if either the latex file or the plot changed) Because any of the steps may take fairly lone, I would like each pass to do something only if any of the preceding steps are out of date. I sort of got lost in the custom_target and custom_command functions and how and when to use them to setup a chain of custom tool invocation that have well defined input and output files. Could someone show a real simple demo? Help is much appreciated. Cheers, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamwolf at feelslikeburning.com Sat Mar 18 15:51:33 2017 From: adamwolf at feelslikeburning.com (Adam Wolf) Date: Sat, 18 Mar 2017 14:51:33 -0500 Subject: [CMake] Embedding Python in macOS bundle Message-ID: Hi folks! I work on a relatively large cross-platform project which uses CMake. Currently, the macOS version uses the system Python. I'm working on embedding a Python inside the bundle. I compiled Python with --enable-framework, stored it in my home directory and aimed CMake at it. I added a few directories to the dirs parameter of fixup_bundle, but fixup_bundle doesn't seem to be pulling it in. -- Analyzing app='/Users/wolf/wnl/kicad/kicadmacbuilder/silly/bin/kicad.app/Contents/MacOS/kicad' -- bundle='/Users/wolf/wnl/kicad/kicadmacbuilder/silly/bin/kicad.app' -- executable='/Users/wolf/wnl/kicad/kicadmacbuilder/silly/bin/kicad.app/Contents/MacOS/kicad' -- valid='1' -- executable file 1: /Users/wolf/wnl/kicad/kicadmacbuilder/silly/bin/kicad.app/Contents/MacOS/dxf2idf -- executable file 2: /Users/wolf/wnl/kicad/kicadmacbuilder/silly/bin/kicad.app/Contents/MacOS/idf2vrml -- executable file 3: /Users/wolf/wnl/kicad/kicadmacbuilder/silly/bin/kicad.app/Contents/MacOS/idfcyl -- executable file 4: /Users/wolf/wnl/kicad/kicadmacbuilder/silly/bin/kicad.app/Contents/MacOS/idfrect -- executable file 5: /Users/wolf/wnl/kicad/kicadmacbuilder/silly/bin/kicad.app/Contents/MacOS/kicad -- executable file 6: /Users/wolf/wnl/kicad/kicadmacbuilder/silly/bin/kicad.app/Contents/MacOS/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python -- verified='0' -- info='external prerequisites found: f='/Users/wolf/wnl/kicad/kicadmacbuilder/silly/bin/kicad.app/Contents/MacOS/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python' external_prereqs='/Users/wolf/wnl/kicad/kicadmacbuilder/silly/python-build//Python.framework/Versions/2.7/Python' ' -- CMake Error at /usr/local/Cellar/cmake/3.6.3/share/cmake/Modules/BundleUtilities.cmake:1053 (message): error: verify_app failed Call Stack (most recent call first): /usr/local/Cellar/cmake/3.6.3/share/cmake/Modules/BundleUtilities.cmake:912 (verify_app) kicad/cmake_install.cmake:91 (fixup_bundle) cmake_install.cmake:69 (include) I tried setting BU_COPY_FULL_FRAMEWORK_CONTENTS, mostly for giggles, and I had similar issues. Anyone have any thoughts or suggestions? Am I barking up the wrong tree with --enable-framework? Anyone have any examples or projects that have pulled in Python using CMake and fixup_bundle? Thanks! Adam Wolf From ggarra13 at gmail.com Sun Mar 19 14:13:57 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Sun, 19 Mar 2017 15:13:57 -0300 Subject: [CMake] Desktop icon not safe (missing +x ) on cmake deb file Message-ID: Hi, I had a program which I compile with cmake. This program was on an NTFS partition with permissions: defaults. This meant all files were owned by root with 777 permissions. This worked fine but it was not secure and created problems with the postrm/posinst scripts. Recently I tried changing my fstab to mount the partition with user and permissions,like: UUID=98222A3D222A20AC /media/gga/Datos ntfs-3g auto,users,permissions,exec 0 0 Now, when I package my application into a deb file, it works. I get: -rw-r--r-- 1 gga gga 24M mar 19 14:55 mrViewer-v3.5.4-Linux-64.deb However upon installation of the deb file under root, I get an icon in the desktop that is not executable. The desktop file that gets created from a desktop.in config file, which has permissions like: -rwxrwxrwx 1 gga root 1,2K feb 21 12:14 mrViewer.desktop.in and the resulting .desktop file has permissions like: -rwxrwxrwx 1 gga root 1,2K mar 14 09:36 mrViewer-v3.5.4.desktop So it should be executable and it should get installed with same permissions. However, this does not work. I am at a loss on what to try. Any help is appreciated. -- Gonzalo Garramu?o From ggarra13 at gmail.com Sun Mar 19 15:41:30 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Sun, 19 Mar 2017 16:41:30 -0300 Subject: [CMake] Desktop icon not safe (missing +x ) on cmake deb file In-Reply-To: References: Message-ID: <5a229b9c-6ecb-11f8-6b75-4f3d4184d88d@gmail.com> El 19/03/2017 a las 15:13, Gonzalo Garramu?o escribi?: > Hi, > > I had a program which I compile with cmake. This program was on an > NTFS partition with permissions: defaults. This meant all files were > owned by root with 777 permissions. This worked fine but it was not > secure and created problems with the postrm/posinst scripts. > > Recently I tried changing my fstab to mount the partition with user > and permissions,like: > > UUID=98222A3D222A20AC /media/gga/Datos ntfs-3g > auto,users,permissions,exec 0 0 > > Now, when I package my application into a deb file, it works. I get: > > -rw-r--r-- 1 gga gga 24M mar 19 14:55 mrViewer-v3.5.4-Linux-64.deb > I figured it out. For reference, I had to change the fstab file to: UUID=98222A3D222A20AC /media/gga/Datos ntfs-3g auto,users,permissions,exec,uid=1000,gid=1000,umask=022 0 0 -- Gonzalo Garramu?o From post at hendrik-sattler.de Sun Mar 19 15:51:12 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sun, 19 Mar 2017 20:51:12 +0100 Subject: [CMake] Desktop icon not safe (missing +x ) on cmake deb file In-Reply-To: <5a229b9c-6ecb-11f8-6b75-4f3d4184d88d@gmail.com> References: <5a229b9c-6ecb-11f8-6b75-4f3d4184d88d@gmail.com> Message-ID: <556AC353-F248-4987-A4C9-AF2D61A1114C@hendrik-sattler.de> Hi, Desktop files and icons do not need any execute permissions. They are only data files. The executable that the desktop file points to must be executable, though. To mount the NTFS partition as a user, use either pmount or your desktop mount utility. OTOH, you make your life unusual hard by using NTFS on Linux for more than pure data storage. HS Am 19. M?rz 2017 20:41:30 MEZ schrieb "Gonzalo Garramu?o" : > > >El 19/03/2017 a las 15:13, Gonzalo Garramu?o escribi?: >> Hi, >> >> I had a program which I compile with cmake. This program was on an >> NTFS partition with permissions: defaults. This meant all files were > >> owned by root with 777 permissions. This worked fine but it was not > >> secure and created problems with the postrm/posinst scripts. >> >> Recently I tried changing my fstab to mount the partition with user >> and permissions,like: >> >> UUID=98222A3D222A20AC /media/gga/Datos ntfs-3g >> auto,users,permissions,exec 0 0 >> >> Now, when I package my application into a deb file, it works. I get: >> >> -rw-r--r-- 1 gga gga 24M mar 19 14:55 mrViewer-v3.5.4-Linux-64.deb >> >I figured it out. For reference, I had to change the fstab file to: > >UUID=98222A3D222A20AC /media/gga/Datos ntfs-3g >auto,users,permissions,exec,uid=1000,gid=1000,umask=022 0 0 -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From doublef.mobile at gmail.com Mon Mar 20 06:57:09 2017 From: doublef.mobile at gmail.com (Sergey Zakharchenko) Date: Mon, 20 Mar 2017 13:57:09 +0300 Subject: [CMake] Multiple ELSE() clauses Message-ID: Hello, I've just noticed that CMake doesn't forbid multiple ELSE() (not just ELSEIF()) clauses, and proceeds without warnings. IF(1) ELSE() ELSE() ENDIF() Is this expected? Best regards, -- DoubleF From eike at sf-mail.de Mon Mar 20 07:06:16 2017 From: eike at sf-mail.de (Rolf Eike Beer) Date: Mon, 20 Mar 2017 12:06:16 +0100 Subject: [CMake] Multiple ELSE() clauses In-Reply-To: References: Message-ID: Am 2017-03-20 11:57, schrieb Sergey Zakharchenko: > Hello, > > I've just noticed that CMake doesn't forbid multiple ELSE() (not just > ELSEIF()) clauses, and proceeds without warnings. > > IF(1) > ELSE() > ELSE() > ENDIF() > > Is this expected? https://gitlab.kitware.com/cmake/cmake/issues/14335 -- From doublef.mobile at gmail.com Mon Mar 20 07:09:48 2017 From: doublef.mobile at gmail.com (Sergey Zakharchenko) Date: Mon, 20 Mar 2017 14:09:48 +0300 Subject: [CMake] Multiple ELSE() clauses In-Reply-To: References: Message-ID: Rolf, 2017-03-20 14:06 GMT+03:00 Rolf Eike Beer : > https://gitlab.kitware.com/cmake/cmake/issues/14335 Since the issue is marked "easy" and it's over 3 years old, I assume nobody cares? OK then. Best regards, -- DoubleF From gjasny at googlemail.com Mon Mar 20 12:33:45 2017 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 20 Mar 2017 17:33:45 +0100 Subject: [CMake] Multiple ELSE() clauses In-Reply-To: References: Message-ID: Hello, On 20/03/2017 12:09, Sergey Zakharchenko wrote: > Rolf, > > 2017-03-20 14:06 GMT+03:00 Rolf Eike Beer : >> https://gitlab.kitware.com/cmake/cmake/issues/14335 > > Since the issue is marked "easy" and it's over 3 years old, I assume > nobody cares? OK then. I can try to fix it. I hope we don't need a new policy for that. Thanks, Gregor From norbert.lange at andritz.com Mon Mar 20 14:17:48 2017 From: norbert.lange at andritz.com (Lange Norbert) Date: Mon, 20 Mar 2017 18:17:48 +0000 Subject: [CMake] CMake and IAR: Assembly files silently ignored Message-ID: <99BAB48E90E86D42AD41F0BCE3225AEB013FA6DF4A@GRZSMS582.andritz.com> Hello, I am trying to write CMakelists for a Project originally developed in IAR Studio, the startup code is in assembly. Using gcc this works nicely (Linux and Windows), but when using the IAR Compiler the Assembly files aren`t built at all. The files are just ignored and the executable is linked without them. The CMake Version is 3.7.1. Is there a bug tracker for CMake? I can create a small project to reproduce the issue if required. I set the compiler with env variables, lie this: set CC=%ProgramFiles(x86)%\IAR Systems\Embedded Workbench 8.0\arm\bin\iccarm.exe set CXX=%CC% set CXXFLAGS=--c++ "%ProgramFiles%\CMake\bin\cmake.exe" -G "MinGW Makefiles" Cortex Kind regards, Norbert Lange Kind regards Norbert Lange AT-DES ANDRITZ HYDRO GmbH Eibesbrunnergasse 20 1120 Wien, Austria *Phone.: +43 50805 56684 * * <> ##################################################################################### This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank You. ##################################################################################### -------------- next part -------------- An HTML attachment was scrubbed... URL: From micha.hergarden at gmail.com Mon Mar 20 16:19:05 2017 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Mon, 20 Mar 2017 21:19:05 +0100 Subject: [CMake] Is it possible to patch a make project with CMakeLists.txt, through external_project_add? In-Reply-To: References: Message-ID: <3557c4c5-6b37-a1e0-1f8d-61a474e93aa1@gmail.com> Hello Mike, The externalproject_add command has an option that might do what you want: https://cmake.org/cmake/help/v3.8/module/ExternalProject.html See: |PATCH_COMMAND ...| Command to patch downloaded source Regards, Micha On 15-03-17 07:51, mike lojkovic wrote: > So, I'm trying to get my project to work on Windows, as well as Linux. > Currently, everything compiles fine on Linux. I've gotten it to > compile in the past on Windows, but since then have reinstalled > Windows, and forgotten the precise steps needed to manually setup Lua, > so CMake can find it. So, I assume just add Lua to my project with > ExternalProject_Add, but they use make and the makefil is configured > for Linux. > > The two options I have are either patch their makefile to build > correctly through cygwin, (I'm just worried this might lead to issues > with producing a binary requiring cygwin) or add a CMakeLists.txt file > and patch it in after the download ends. How would I go about adding > custom CMakeLists.txt file to their project after the download > finishes? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 525 bytes Desc: OpenPGP digital signature URL: From gjasny at googlemail.com Mon Mar 20 17:42:00 2017 From: gjasny at googlemail.com (Gregor Jasny) Date: Mon, 20 Mar 2017 22:42:00 +0100 Subject: [CMake] Multiple ELSE() clauses In-Reply-To: References: Message-ID: <553086c1-25e4-bdc3-bc98-00360b587d1f@googlemail.com> On 3/20/17 12:09 PM, Sergey Zakharchenko wrote: > Rolf, > > 2017-03-20 14:06 GMT+03:00 Rolf Eike Beer : >> https://gitlab.kitware.com/cmake/cmake/issues/14335 > > Since the issue is marked "easy" and it's over 3 years old, I assume > nobody cares? OK then. https://gitlab.kitware.com/cmake/cmake/merge_requests/594 From aishwaryaselvaraj1708 at gmail.com Tue Mar 21 01:27:42 2017 From: aishwaryaselvaraj1708 at gmail.com (aishwarya selvaraj) Date: Tue, 21 Mar 2017 10:57:42 +0530 Subject: [CMake] libsndfile in windows Message-ID: Hello , To compile my code which uses libsndfile library on windows , i used the cross compiling on linux for windows following the instructions in this : https://github.com/erikd/libsndfile I have cmake_build.sh file . I'm very new to all this , So Could anyone please guide me on what to do next . ?I'd be really grateful .? -- Regards, Aishwarya Selvaraj -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.zarl-zierl at jku.at Tue Mar 21 05:38:06 2017 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Tue, 21 Mar 2017 10:38:06 +0100 Subject: [CMake] libsndfile in windows In-Reply-To: References: Message-ID: <1603983.gT13zEFmXz@ersa> Hi, On Dienstag, 21. M?rz 2017 10:57:42 CET aishwarya selvaraj wrote: > I'm very new to all this , So Could anyone please guide me on what to do > next . Did you try asking on the libsndfile mailing list? They are more likely to know about the issue you're dealing with. Try here: http://www.mega-nerd.com/libsndfile/lists.html Cheers, Johannes From aishwaryaselvaraj1708 at gmail.com Tue Mar 21 05:54:13 2017 From: aishwaryaselvaraj1708 at gmail.com (aishwarya selvaraj) Date: Tue, 21 Mar 2017 15:24:13 +0530 Subject: [CMake] libsndfile in windows In-Reply-To: <1603983.gT13zEFmXz@ersa> References: <1603983.gT13zEFmXz@ersa> Message-ID: I did .but there was no response . I had written cmakelists.txt to compile and build . I was able to successfully built it in linux , but in windows I was not able to do it . Do you have nay leads on that ? On Tue, Mar 21, 2017 at 3:08 PM, Johannes Zarl-Zierl < johannes.zarl-zierl at jku.at> wrote: > Hi, > > On Dienstag, 21. M?rz 2017 10:57:42 CET aishwarya selvaraj wrote: > > I'm very new to all this , So Could anyone please guide me on what to do > > next . > > Did you try asking on the libsndfile mailing list? They are more likely to > know > about the issue you're dealing with. > > Try here: > http://www.mega-nerd.com/libsndfile/lists.html > > Cheers, > Johannes > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Regards, Aishwarya Selvaraj -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.zarl-zierl at jku.at Tue Mar 21 09:22:44 2017 From: johannes.zarl-zierl at jku.at (Johannes Zarl-Zierl) Date: Tue, 21 Mar 2017 14:22:44 +0100 Subject: [CMake] libsndfile in windows In-Reply-To: References: <1603983.gT13zEFmXz@ersa> Message-ID: <1563689.JSajj0P2Km@ersa> On Dienstag, 21. M?rz 2017 15:24:13 CET you wrote: > > Did you try asking on the libsndfile mailing list? > I did .but there was no response . Ok then. > I had written cmakelists.txt to compile and build . > I was able to successfully built it in linux , but in windows I was not > able to do it . > Do you have nay leads on that ? Reading the description that you linked to, I see that they have only done a partial port to cmake and still require autotools. If you want to compile on other platforms you'll need to get rid of those non-portable parts. I would probably look at any pull requests and issues for that repository and look for cmake-related reports. Maybe someone else is already fixing the issues? Otherwise, you can try porting the non-portable parts yourself and ask on this list if you have problems in your cmake code. Cheers, Johannes From python152 at gmail.com Wed Mar 22 09:52:17 2017 From: python152 at gmail.com (Oliver) Date: Wed, 22 Mar 2017 09:52:17 -0400 Subject: [CMake] can't locate library with find_library Message-ID: hi all, I am running cmake 3 using EPEL install on RHEL 7. I also have installed "gflags", $rpm -ql gflags /usr/bin/gflags_completions.sh /usr/lib64/libgflags.so.2.1 /usr/lib64/libgflags_nothreads.so.2.1 /usr/share/doc/gflags-2.1.1 /usr/share/doc/gflags-2.1.1/AUTHORS.txt /usr/share/doc/gflags-2.1.1/COPYING.txt /usr/share/doc/gflags-2.1.1/ChangeLog.txt /usr/share/doc/gflags-2.1.1/README.txt but my check fails: # glags find_library(GFLAGS_LIB NAMES gflags PATHS /usr/lib64 /usr/lib /usr/local/lib) if (NOT GFLAGS_LIB) message(STATUS "gflags is not present, you can still control logging through env settings") message(STATUS " GLOG_logtostderr=1 ./your_application") else() message(STATUS "gflags is present, you can controll logging through command line:") message(STATUS " ./your_application --logtostderr=1") endif() what did I do wrong? thx. -- Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Wed Mar 22 10:08:32 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 22 Mar 2017 15:08:32 +0100 Subject: [CMake] can't locate library with find_library In-Reply-To: References: Message-ID: <4ae1efb9-c9b9-0b87-0f43-db5374023cdf@gmail.com> On 22.03.2017 14:52, Oliver wrote: > hi all, > > I am running cmake 3 using EPEL install on RHEL 7. I also have > installed "gflags", > > > > $rpm -ql gflags > /usr/bin/gflags_completions.sh > /usr/lib64/libgflags.so.2.1 > /usr/lib64/libgflags_nothreads.so.2.1 > /usr/share/doc/gflags-2.1.1 > /usr/share/doc/gflags-2.1.1/AUTHORS.txt > /usr/share/doc/gflags-2.1.1/COPYING.txt > /usr/share/doc/gflags-2.1.1/ChangeLog.txt > /usr/share/doc/gflags-2.1.1/README.txt > Did you also install the corresponding development package e.g. "gflags-devel"? Nils From python152 at gmail.com Wed Mar 22 10:13:00 2017 From: python152 at gmail.com (Oliver) Date: Wed, 22 Mar 2017 10:13:00 -0400 Subject: [CMake] can't locate library with find_library In-Reply-To: <4ae1efb9-c9b9-0b87-0f43-db5374023cdf@gmail.com> References: <4ae1efb9-c9b9-0b87-0f43-db5374023cdf@gmail.com> Message-ID: oh, no, silly me, I didn't. that fixed the problem. thx Feiyi On Wed, Mar 22, 2017 at 10:08 AM, Nils Gladitz wrote: > On 22.03.2017 14:52, Oliver wrote: > >> hi all, >> >> I am running cmake 3 using EPEL install on RHEL 7. I also have installed >> "gflags", >> >> >> >> $rpm -ql gflags >> /usr/bin/gflags_completions.sh >> /usr/lib64/libgflags.so.2.1 >> /usr/lib64/libgflags_nothreads.so.2.1 >> /usr/share/doc/gflags-2.1.1 >> /usr/share/doc/gflags-2.1.1/AUTHORS.txt >> /usr/share/doc/gflags-2.1.1/COPYING.txt >> /usr/share/doc/gflags-2.1.1/ChangeLog.txt >> /usr/share/doc/gflags-2.1.1/README.txt >> >> > Did you also install the corresponding development package e.g. > "gflags-devel"? > > Nils > -- Oliver -------------- next part -------------- An HTML attachment was scrubbed... URL: From hng.email at gmail.com Wed Mar 22 17:07:34 2017 From: hng.email at gmail.com (Hom Nath Gharti) Date: Wed, 22 Mar 2017 17:07:34 -0400 Subject: [CMake] Include file in the Makefile Message-ID: Dear all, I use PETSc in my package and I need to use the following line in my GNU Makefile: include ${PETSC_DIR}/lib/petsc/conf/variables What is the equivalent command for CMakeLists.txt for this? Thanks for your help. Thanks, HNG From aishwaryaselvaraj1708 at gmail.com Thu Mar 23 08:07:53 2017 From: aishwaryaselvaraj1708 at gmail.com (aishwarya selvaraj) Date: Thu, 23 Mar 2017 17:37:53 +0530 Subject: [CMake] libsndfile in windows In-Reply-To: <1563689.JSajj0P2Km@ersa> References: <1603983.gT13zEFmXz@ersa> <1563689.JSajj0P2Km@ersa> Message-ID: @Johannes Zarl-Zierl PFA . I found this link and tried how its mentioned in it . I was not able to successfully build it using this . Probably you could go though this and we could discuss. On Tue, Mar 21, 2017 at 6:52 PM, Johannes Zarl-Zierl < johannes.zarl-zierl at jku.at> wrote: > On Dienstag, 21. M?rz 2017 15:24:13 CET you wrote: > > > Did you try asking on the libsndfile mailing list? > > I did .but there was no response . > > Ok then. > > > I had written cmakelists.txt to compile and build . > > I was able to successfully built it in linux , but in windows I was not > > able to do it . > > Do you have nay leads on that ? > > Reading the description that you linked to, I see that they have only done > a > partial port to cmake and still require autotools. If you want to compile > on > other platforms you'll need to get rid of those non-portable parts. > > I would probably look at any pull requests and issues for that repository > and > look for cmake-related reports. Maybe someone else is already fixing the > issues? > > Otherwise, you can try porting the non-portable parts yourself and ask on > this > list if you have problems in your cmake code. > > Cheers, > Johannes > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Regards, Aishwarya Selvaraj -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From wesley.hoke at gmail.com Thu Mar 23 10:32:28 2017 From: wesley.hoke at gmail.com (Wesley Smith) Date: Thu, 23 Mar 2017 07:32:28 -0700 Subject: [CMake] C# Language Detection Errors in 3.8.0-rc2 In-Reply-To: References: Message-ID: Eventually I figured out the answer to this question after stepping through the CMake project code. DO: enable_language(CSharp) DONT: enable_language(CSHARP) Unlike C, CXX, FORTRAN, etc. CSharp is not an abbreviation requiring capitalization of all letters. Case matters. On Thu, Mar 16, 2017 at 5:23 PM, Wesley Smith wrote: > I'm trying to test out the C# features added to 3.8.0. A few things: > > + I couldn't find any documentation as to what the language name for > CSHARP was in the enable_language documentation page > > + When I tried enable_language(CSHARP), I got some errors > > CMake Error at CMakeLists.txt:4 (enable_language): > No CMAKE_CSHARP_COMPILER could be found. > > In the error log, I see: > > The CSharp compiler identification could not be found in > "/build_/CMakeFiles/3.8.0-rc2/CompilerIdCSharp/ > CompilerIdCSharp.csproj" > > When I open this project, it compiles and runs just fine. I'm not sure > why it's giving an error. Any thoughts? > > thanks, > wes > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mellery451 at gmail.com Thu Mar 23 12:59:12 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Thu, 23 Mar 2017 09:59:12 -0700 Subject: [CMake] Include file in the Makefile In-Reply-To: References: Message-ID: > On Mar 22, 2017, at 2:07 PM, Hom Nath Gharti wrote: > > Dear all, > > I use PETSc in my package and I need to use the following line in my > GNU Makefile: > > include ${PETSC_DIR}/lib/petsc/conf/variables > > What is the equivalent command for CMakeLists.txt for this? > > Thanks for your help. > > Thanks, > HNG > -- The typical way to use an installed library is via find_package, which requires either a pkgspec or a find module. It looks like someone has already written a find module: https://github.com/jedbrown/cmake-modules/blob/master/FindPETSc.cmake so, you can do something like: * fork/or submodule this repo above * append to CMAKE_MODULE_PATH in your CMakeLists.txt file to add the path to this module above. * call find_package(PETSc) * use the variables that are documented in the finder to set your include_directories and target_link_libraries. If you are certain the env variable PETSC_DIR is always going to be set (as above), then you can simply build paths based on that variable and pass them to include_directories and target_link_libraries, but the finders also do a better job of dealing with various build environments, etc. HTH, Mike Ellery From hng.email at gmail.com Thu Mar 23 13:33:31 2017 From: hng.email at gmail.com (Hom Nath Gharti) Date: Thu, 23 Mar 2017 13:33:31 -0400 Subject: [CMake] Include file in the Makefile In-Reply-To: References: Message-ID: Thanks, Mike! HNG On Thu, Mar 23, 2017 at 12:59 PM, Michael Ellery wrote: > >> On Mar 22, 2017, at 2:07 PM, Hom Nath Gharti wrote: >> >> Dear all, >> >> I use PETSc in my package and I need to use the following line in my >> GNU Makefile: >> >> include ${PETSC_DIR}/lib/petsc/conf/variables >> >> What is the equivalent command for CMakeLists.txt for this? >> >> Thanks for your help. >> >> Thanks, >> HNG >> -- > > The typical way to use an installed library is via find_package, which requires either a pkgspec or a find module. It looks like someone has already written a find module: > > https://github.com/jedbrown/cmake-modules/blob/master/FindPETSc.cmake > > so, you can do something like: > > * fork/or submodule this repo above > * append to CMAKE_MODULE_PATH in your CMakeLists.txt file to add the path to this module above. > * call find_package(PETSc) > * use the variables that are documented in the finder to set your include_directories and target_link_libraries. > > If you are certain the env variable PETSC_DIR is always going to be set (as above), then you can simply build paths based on that variable and pass them to include_directories and target_link_libraries, but the finders also do a better job of dealing with various build environments, etc. > > HTH, > Mike Ellery From rcdailey.lists at gmail.com Thu Mar 23 16:03:38 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 23 Mar 2017 15:03:38 -0500 Subject: [CMake] Trying to get android toolchain setup for Crystax Message-ID: So I'm having no luck getting the Crystax NDK setup using built-in android support in CMake 3.8. I have the following toolchain file: set( CMAKE_SYSTEM_NAME Android ) set( CMAKE_SYSTEM_VERSION ${ANDROID_API} ) # set( CMAKE_ANDROID_NDK $ENV{ANDROID_NDK} ) set( CMAKE_ANDROID_NDK "E:/android/crystax-ndk-10.3.2-stable" ) #set( CMAKE_ANDROID_API ${ANDROID_API} ) set( CMAKE_ANDROID_ARCH_ABI ${ANDROID_ABI} ) set( CMAKE_ANDROID_STL_TYPE ${ANDROID_STL} ) set( CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION ${ANDROID_TOOLCHAIN_VERSION} ) if( CMAKE_ANDROID_ARCH_ABI MATCHES "armeabi" ) set( CMAKE_ANDROID_ARM_MODE ON ) set( CMAKE_ANDROID_ARM_NEON OFF ) endif() The logs output as follows: -- Android: Targeting API '15' with architecture 'arm', ABI 'armeabi-v7a', and processor 'armv7-a' -- Android: Selected GCC toolchain 'arm-linux-androideabi-4.9' -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Error at CMakeLists.txt:10 (project): The CMAKE_C_COMPILER: E:/android/crystax-ndk-10.3.2-stable/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe is not a full path to an existing compiler tool. The problem is the path to the toolchain it is trying to find is actually: "E:\android\crystax-ndk-10.3.2-stable\toolchains\arm-linux-androideabi-4.9\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe" The one difference is that the path has "windows" in it instead of "windows-x86_64". I installed the 32-bit version of Crystax NDK, not the 64 bit one (not sure if that makes a difference, but my native android code will not build with 64-bit compiler anyway). How can I make it properly calculate the path? I tried setting this but it did not change the behavior: set( CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG windows ) From rcdailey.lists at gmail.com Thu Mar 23 16:14:11 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 23 Mar 2017 15:14:11 -0500 Subject: [CMake] Trying to get android toolchain setup for Crystax In-Reply-To: References: Message-ID: Sorry I guess it would help if I showed where the ANDROID_ variables are being defined: cmake .. -G"Ninja" -DCMAKE_BUILD_TYPE="Release" -DCMAKE_TOOLCHAIN_FILE="crystax.toolchain.cmake" -DBUILD_TESTING=OFF -DANDROID_API=15 -DANDROID_TOOLCHAIN_NAME=arm-linux-androideabi-4.9 -DANDROID_ABI=armeabi-v7a -DANDROID_TOOLCHAIN_VERSION=4.9 -DANDROID_STL=gnustl_static On Thu, Mar 23, 2017 at 3:03 PM, Robert Dailey wrote: > So I'm having no luck getting the Crystax NDK setup using built-in > android support in CMake 3.8. > > I have the following toolchain file: > > set( CMAKE_SYSTEM_NAME Android ) > set( CMAKE_SYSTEM_VERSION ${ANDROID_API} ) > > # set( CMAKE_ANDROID_NDK $ENV{ANDROID_NDK} ) > set( CMAKE_ANDROID_NDK "E:/android/crystax-ndk-10.3.2-stable" ) > #set( CMAKE_ANDROID_API ${ANDROID_API} ) > set( CMAKE_ANDROID_ARCH_ABI ${ANDROID_ABI} ) > set( CMAKE_ANDROID_STL_TYPE ${ANDROID_STL} ) > set( CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION ${ANDROID_TOOLCHAIN_VERSION} ) > > if( CMAKE_ANDROID_ARCH_ABI MATCHES "armeabi" ) > set( CMAKE_ANDROID_ARM_MODE ON ) > set( CMAKE_ANDROID_ARM_NEON OFF ) > endif() > > > The logs output as follows: > > > -- Android: Targeting API '15' with architecture 'arm', ABI > 'armeabi-v7a', and processor 'armv7-a' > -- Android: Selected GCC toolchain 'arm-linux-androideabi-4.9' > -- The C compiler identification is unknown > -- The CXX compiler identification is unknown > CMake Error at CMakeLists.txt:10 (project): > The CMAKE_C_COMPILER: > > E:/android/crystax-ndk-10.3.2-stable/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe > > is not a full path to an existing compiler tool. > > > The problem is the path to the toolchain it is trying to find is actually: > > > "E:\android\crystax-ndk-10.3.2-stable\toolchains\arm-linux-androideabi-4.9\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe" > > The one difference is that the path has "windows" in it instead of > "windows-x86_64". I installed the 32-bit version of Crystax NDK, not > the 64 bit one (not sure if that makes a difference, but my native > android code will not build with 64-bit compiler anyway). > > How can I make it properly calculate the path? I tried setting this > but it did not change the behavior: > > set( CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG windows ) From rcdailey.lists at gmail.com Thu Mar 23 16:22:48 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 23 Mar 2017 15:22:48 -0500 Subject: [CMake] Trying to get android toolchain setup for Crystax In-Reply-To: References: Message-ID: Update: Using the x86_64 version of the Crystax NDK worked. Meaning, the directory name aligned with what CMake was expecting. However, the question now is: Why didn't changing CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG work? On Thu, Mar 23, 2017 at 3:14 PM, Robert Dailey wrote: > Sorry I guess it would help if I showed where the ANDROID_ variables > are being defined: > > cmake .. -G"Ninja" -DCMAKE_BUILD_TYPE="Release" > -DCMAKE_TOOLCHAIN_FILE="crystax.toolchain.cmake" > -DBUILD_TESTING=OFF -DANDROID_API=15 > -DANDROID_TOOLCHAIN_NAME=arm-linux-androideabi-4.9 > -DANDROID_ABI=armeabi-v7a -DANDROID_TOOLCHAIN_VERSION=4.9 > -DANDROID_STL=gnustl_static > > On Thu, Mar 23, 2017 at 3:03 PM, Robert Dailey wrote: >> So I'm having no luck getting the Crystax NDK setup using built-in >> android support in CMake 3.8. >> >> I have the following toolchain file: >> >> set( CMAKE_SYSTEM_NAME Android ) >> set( CMAKE_SYSTEM_VERSION ${ANDROID_API} ) >> >> # set( CMAKE_ANDROID_NDK $ENV{ANDROID_NDK} ) >> set( CMAKE_ANDROID_NDK "E:/android/crystax-ndk-10.3.2-stable" ) >> #set( CMAKE_ANDROID_API ${ANDROID_API} ) >> set( CMAKE_ANDROID_ARCH_ABI ${ANDROID_ABI} ) >> set( CMAKE_ANDROID_STL_TYPE ${ANDROID_STL} ) >> set( CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION ${ANDROID_TOOLCHAIN_VERSION} ) >> >> if( CMAKE_ANDROID_ARCH_ABI MATCHES "armeabi" ) >> set( CMAKE_ANDROID_ARM_MODE ON ) >> set( CMAKE_ANDROID_ARM_NEON OFF ) >> endif() >> >> >> The logs output as follows: >> >> >> -- Android: Targeting API '15' with architecture 'arm', ABI >> 'armeabi-v7a', and processor 'armv7-a' >> -- Android: Selected GCC toolchain 'arm-linux-androideabi-4.9' >> -- The C compiler identification is unknown >> -- The CXX compiler identification is unknown >> CMake Error at CMakeLists.txt:10 (project): >> The CMAKE_C_COMPILER: >> >> E:/android/crystax-ndk-10.3.2-stable/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe >> >> is not a full path to an existing compiler tool. >> >> >> The problem is the path to the toolchain it is trying to find is actually: >> >> >> "E:\android\crystax-ndk-10.3.2-stable\toolchains\arm-linux-androideabi-4.9\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe" >> >> The one difference is that the path has "windows" in it instead of >> "windows-x86_64". I installed the 32-bit version of Crystax NDK, not >> the 64 bit one (not sure if that makes a difference, but my native >> android code will not build with 64-bit compiler anyway). >> >> How can I make it properly calculate the path? I tried setting this >> but it did not change the behavior: >> >> set( CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG windows ) From rcdailey.lists at gmail.com Thu Mar 23 16:42:16 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 23 Mar 2017 15:42:16 -0500 Subject: [CMake] Trying to get android toolchain setup for Crystax In-Reply-To: References: Message-ID: Sorry last email: Assuming I get past the host tag issue, the next one is that the test program is unable to compile because: error: cannot find -lcrystax Somehow, somewhere the linker is expecting this library. I do not see it in the output from CMake when the build fails. I do know the file is located here: ${CMAKE_ANDROID_NDK}/sources/crystax/libs/${ANDROID_ABI} Is there a way I can add this to the linker search path from the toolchain file? Or is there a better way? On Thu, Mar 23, 2017 at 3:22 PM, Robert Dailey wrote: > Update: > > Using the x86_64 version of the Crystax NDK worked. Meaning, the > directory name aligned with what CMake was expecting. However, the > question now is: Why didn't changing > CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG work? > > On Thu, Mar 23, 2017 at 3:14 PM, Robert Dailey wrote: >> Sorry I guess it would help if I showed where the ANDROID_ variables >> are being defined: >> >> cmake .. -G"Ninja" -DCMAKE_BUILD_TYPE="Release" >> -DCMAKE_TOOLCHAIN_FILE="crystax.toolchain.cmake" >> -DBUILD_TESTING=OFF -DANDROID_API=15 >> -DANDROID_TOOLCHAIN_NAME=arm-linux-androideabi-4.9 >> -DANDROID_ABI=armeabi-v7a -DANDROID_TOOLCHAIN_VERSION=4.9 >> -DANDROID_STL=gnustl_static >> >> On Thu, Mar 23, 2017 at 3:03 PM, Robert Dailey wrote: >>> So I'm having no luck getting the Crystax NDK setup using built-in >>> android support in CMake 3.8. >>> >>> I have the following toolchain file: >>> >>> set( CMAKE_SYSTEM_NAME Android ) >>> set( CMAKE_SYSTEM_VERSION ${ANDROID_API} ) >>> >>> # set( CMAKE_ANDROID_NDK $ENV{ANDROID_NDK} ) >>> set( CMAKE_ANDROID_NDK "E:/android/crystax-ndk-10.3.2-stable" ) >>> #set( CMAKE_ANDROID_API ${ANDROID_API} ) >>> set( CMAKE_ANDROID_ARCH_ABI ${ANDROID_ABI} ) >>> set( CMAKE_ANDROID_STL_TYPE ${ANDROID_STL} ) >>> set( CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION ${ANDROID_TOOLCHAIN_VERSION} ) >>> >>> if( CMAKE_ANDROID_ARCH_ABI MATCHES "armeabi" ) >>> set( CMAKE_ANDROID_ARM_MODE ON ) >>> set( CMAKE_ANDROID_ARM_NEON OFF ) >>> endif() >>> >>> >>> The logs output as follows: >>> >>> >>> -- Android: Targeting API '15' with architecture 'arm', ABI >>> 'armeabi-v7a', and processor 'armv7-a' >>> -- Android: Selected GCC toolchain 'arm-linux-androideabi-4.9' >>> -- The C compiler identification is unknown >>> -- The CXX compiler identification is unknown >>> CMake Error at CMakeLists.txt:10 (project): >>> The CMAKE_C_COMPILER: >>> >>> E:/android/crystax-ndk-10.3.2-stable/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-gcc.exe >>> >>> is not a full path to an existing compiler tool. >>> >>> >>> The problem is the path to the toolchain it is trying to find is actually: >>> >>> >>> "E:\android\crystax-ndk-10.3.2-stable\toolchains\arm-linux-androideabi-4.9\prebuilt\windows\bin\arm-linux-androideabi-gcc.exe" >>> >>> The one difference is that the path has "windows" in it instead of >>> "windows-x86_64". I installed the 32-bit version of Crystax NDK, not >>> the 64 bit one (not sure if that makes a difference, but my native >>> android code will not build with 64-bit compiler anyway). >>> >>> How can I make it properly calculate the path? I tried setting this >>> but it did not change the behavior: >>> >>> set( CMAKE_ANDROID_NDK_TOOLCHAIN_HOST_TAG windows ) From eric.noulard at gmail.com Fri Mar 24 06:04:28 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 24 Mar 2017 11:04:28 +0100 Subject: [CMake] Is it possible to run ctest outside build tree? Message-ID: Is possible to run ctest outside the builld tree and how? typical use is when I have an out of source build I may be in the source tree and want to run tests without manually going to build tree. i.e. I currently do: ninja -C /my/build/tree is there a similar way to do that with ctest (other than creating my own script, shell alias etc...)? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Mar 24 06:50:54 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 24 Mar 2017 11:50:54 +0100 Subject: [CMake] Running test who have two labels? Message-ID: Hi there, I'm playing with ctest LABELS and I wanted to know whether if it is possible to run the set of tests which have 2 labels ? I manage to have all tests which have **either** L1 or L2: ctest -L "L1|L2" but how can I write a proper command line for both L1 and L2 ? apparently ctest -L "L1" -L "L2" only takes into account the last -L argument. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Mar 24 07:30:22 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 24 Mar 2017 12:30:22 +0100 Subject: [CMake] Running test who have two labels? In-Reply-To: References: Message-ID: On 03/24/2017 11:50 AM, Eric Noulard wrote: > Hi there, > > I'm playing with ctest LABELS and I wanted to know whether if it is > possible > to run the set of tests which have 2 labels ? > > I manage to have all tests which have **either** L1 or L2: > > ctest -L "L1|L2" > > but how can I write a proper command line for both L1 and L2 ? > > apparently > > ctest -L "L1" -L "L2" > > only takes into account the last -L argument. > I don't think it is possible currently. To a degree you might be able to work around it by creating additional labels that combine the existing ones e.g. "L1", "L2", "L1-L2". I was pondering trying to implement test filtering based on the condition evaluator CMake uses for if()/while() at some point (cmConditionEvaluator.cxx). e.g. --run-tests-if "L1 IN_LIST TEST_LABELS AND L2 IN_LIST TEST_LABELS" Nils From eric.noulard at gmail.com Fri Mar 24 08:08:20 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 24 Mar 2017 13:08:20 +0100 Subject: [CMake] Running test who have two labels? In-Reply-To: References: Message-ID: 2017-03-24 12:30 GMT+01:00 Nils Gladitz : > On 03/24/2017 11:50 AM, Eric Noulard wrote: > > Hi there, >> >> I'm playing with ctest LABELS and I wanted to know whether if it is >> possible >> to run the set of tests which have 2 labels ? >> >> I manage to have all tests which have **either** L1 or L2: >> >> ctest -L "L1|L2" >> >> but how can I write a proper command line for both L1 and L2 ? >> >> apparently >> >> ctest -L "L1" -L "L2" >> >> only takes into account the last -L argument. >> >> > I don't think it is possible currently. > To a degree you might be able to work around it by creating additional > labels that combine the existing ones e.g. "L1", "L2", "L1-L2". > Yes of course. I do test name mangling but I was hoping for more "classifying" feature with labels and was expecting a simple OR and AND operation with labels. This is not the case. > > I was pondering trying to implement test filtering based on the condition > evaluator CMake uses for if()/while() at some point > (cmConditionEvaluator.cxx). > e.g. --run-tests-if "L1 IN_LIST TEST_LABELS AND L2 IN_LIST TEST_LABELS" It could have been nice but may be overkill my needs. A repetable ANDing -L or -LE will do the job. That said since test filtering is regex-based I simply rediscovered that ANDing or negating regex is not easy. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Fri Mar 24 09:04:06 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 24 Mar 2017 14:04:06 +0100 Subject: [CMake] VS Code generator? Message-ID: Is there any plan to create/support a VS Code ( https://code.visualstudio.com/) generator? Since Visual Studio Code seems to be able to open Visual Studio Solution is it possible to have a working Visual Studio Generator on Linux? Any information/experience about using VS Code with CMake on Linux would be great. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Mar 24 09:28:07 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 24 Mar 2017 14:28:07 +0100 Subject: [CMake] VS Code generator? In-Reply-To: References: Message-ID: <63d96a22-8fa1-ec82-f8d3-d7b141dc0532@gmail.com> On 03/24/2017 02:04 PM, Eric Noulard wrote: > Is there any plan to create/support a VS Code > (https://code.visualstudio.com/) generator? > > Since Visual Studio Code seems to be able to open Visual Studio > Solution is it possible to have a working Visual Studio Generator on > Linux? > > Any information/experience about using VS Code with CMake on Linux > would be great. Did you see https://marketplace.visualstudio.com/items?itemName=vector-of-bool.cmake-tools ? Might have more potential with the noted CMake Server support than CMake generated IDE files. Nils From csiga.biga at aol.com Fri Mar 24 10:53:03 2017 From: csiga.biga at aol.com (csiga.biga at aol.com) Date: Fri, 24 Mar 2017 15:53:03 +0100 Subject: [CMake] VS Code generator? In-Reply-To: <63d96a22-8fa1-ec82-f8d3-d7b141dc0532@gmail.com> References: <63d96a22-8fa1-ec82-f8d3-d7b141dc0532@gmail.com> Message-ID: I agree and not at the same time. CMake Tools is an awesome extension, but C++ development in VS Code still feel second rate due to the fact, that the C++ language services extension (most notably the Microsoft extension) does not know about CMake Tools and one manually has to populate CppSettings.json file with include files for instance, as well as the actual location of the executables if one wishes to debug targets. All this info is available in the JSON generated by CMake Tools by invoking cmake in server mode, but the two extensions would have to meet in the middle. There are discussions about this on their respective Github issues trackers, but there is major radio silence from the MS dev team. Felad?: Nils Gladitz Elk?ldve: 2017. m?rcius 24., p?ntek 14:28 C?mzett: Eric Noulard; CMake Mailinglist T?rgy: Re: [CMake] VS Code generator? On 03/24/2017 02:04 PM, Eric Noulard wrote: > Is there any plan to create/support a VS Code > (https://code.visualstudio.com/) generator? > > Since Visual Studio Code seems to be able to open Visual Studio > Solution is it possible to have a working Visual Studio Generator on > Linux? > > Any information/experience about using VS Code with CMake on Linux > would be great. Did you see https://marketplace.visualstudio.com/items?itemName=vector-of-bool.cmake-tools ? Might have more potential with the noted CMake Server support than CMake generated IDE files. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Fri Mar 24 13:43:55 2017 From: DLRdave at aol.com (David Cole) Date: Fri, 24 Mar 2017 13:43:55 -0400 Subject: [CMake] Is it possible to run ctest outside build tree? In-Reply-To: References: Message-ID: This code: https://github.com/Kitware/CMake/blob/master/Source/ctest.cxx#L139-L157 shows ctest will look for a CTestTestfile.cmake or DartTestfile.txt file in the current working directory as soon as it starts. Except in the case of processing a "--launch" directive, in which case, it dispatches that in the code just above there. So. I think you have not much choice other than to propose adding a new command line argument for such purpose, or wrapping existing ctest with your own script or program of some sort. HTH, David C. On Fri, Mar 24, 2017 at 6:04 AM, Eric Noulard wrote: > Is possible to run ctest outside the builld tree and how? > typical use is when I have an out of source build I may be in the source > tree > and want to run tests without manually going to build tree. > > i.e. I currently do: > > ninja -C /my/build/tree > > is there a similar way to do that with ctest (other than creating my own > script, shell alias etc...)? > > -- > Eric > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From robert.maynard at kitware.com Fri Mar 24 14:04:52 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 24 Mar 2017 14:04:52 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.8.0-rc3 now ready for testing! Message-ID: I am proud to announce the third CMake 3.8 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.8 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.8/release/3.8.html Some of the more significant changes in CMake 3.8 are: * CMake now supports "CSharp" (C#) as a first-class language. It is currently supported by the Visual Studio Generators for VS 2010 and above. * CMake now supports "CUDA" as a first-class language. It is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". CMake 3.8 Release Notes *********************** Changes made since CMake 3.7 include the following. New Features ============ Languages --------- C# ~~ * CMake learned to support "CSharp" (C#) as a first-class language that can be enabled via the "project()" and "enable_language()" commands. It is currently supported by the Visual Studio Generators for VS 2010 and above. C# assemblies and programs can be added just like common C++ targets using the "add_library()" and "add_executable()" commands. References between C# targets in the same source tree may be specified by "target_link_libraries()" like for C++. References to system or 3rd-party assemblies may be specified by the target properties "VS_DOTNET_REFERENCE_" and "VS_DOTNET_REFERENCES". * More fine tuning of C# targets may be done using target and source file properties. Specifically the target properties related to Visual Studio ("VS_*") are worth a look (for setting toolset versions, root namespaces, assembly icons, ...). CUDA ~~~~ * CMake learned to support "CUDA" as a first-class language that can be enabled via the "project()" and "enable_language()" commands. * "CUDA" is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The NVIDIA CUDA Toolkit compiler ("nvcc") is supported. C & C++ ~~~~~~~ * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The "Compile Features" functionality is now aware of the availability of C99 in gcc since version 3.4. Platforms --------- * A new minimal platform file for "Fuchsia" was added. Generators ---------- * The "CodeBlocks" extra generator may now be used to generate with "NMake Makefiles JOM". * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned the option "COMMAND_EXPAND_LISTS" which causes lists in the "COMMAND" argument to be expanded, including lists created by generator expressions. * The "execute_process()" command gained an "ENCODING" option to specify on Windows which encoding is used for output from child process. * The "math(EXPR)" command gained support for unary "+" and "-" operators. * The "source_group()" command gained "TREE" and "PREFIX" options to add groups following source tree directory structure. * The "string(TIMESTAMP)" command learned to treat "%%" as a way to encode plain "%". * The "string(TIMESTAMP)" command will now honor the "SOURCE_DATE_EPOCH" environment variable and use its value instead of the current time. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". Variables --------- * A "CMAKE_CODELITE_USE_TARGETS" variable was added to tell the "CodeLite" extra generator to change the generated project to have target-centric organization. The "build", "rebuild", and "clean" operations within "CodeLite" then work on a selected target rather than the whole workspace. (Note that the "Ninja" clean operation on a target includes its dependencies, though.) * The "CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS" variable was added to tell the "Sublime Text 2" extra generator to place specified environment variables in the generated ".sublime-project". * The "CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE" variable was added to tell the "Sublime Text 2" extra generator whether to exclude the build tree from the ".sublime-project" when it is inside the source tree. * A "CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD" variable was added to tell Visual Studio Generators for VS 2010 and above to include the "PACKAGE" target in the default build, similar to the existing "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" variable for the "INSTALL" target. Properties ---------- * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * The "FRAMEWORK" target property may now also be applied to static libraries on Apple targets. It will result in a proper Framework but with a static library inside. * Imported Interface Libraries learned new "IMPORTED_LIBNAME" and "IMPORTED_LIBNAME_" target properties to specify a link library name since interface libraries do not build their own library files. * A "_CPPLINT" target property and supporting "CMAKE__CPPLINT" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run the "cpplint" style checker along with the compiler for "C" and "CXX" languages. * A "MANUALLY_ADDED_DEPENDENCIES" target property has been added. It provides a read-only list of dependencies that have been added with the "add_dependencies()" command. * The "MAP_IMPORTED_CONFIG_" target property learned to interpret empty list elements as referring to the configuration-less imported location specified by "IMPORTED_LOCATION". * The "NO_SYSTEM_FROM_IMPORTED" target property is now supported on Imported Interface Libraries. * New source file properties "SKIP_AUTOMOC", "SKIP_AUTOUIC", "SKIP_AUTORCC", and "SKIP_AUTOGEN" were added to allow source files to be excluded from processing by "AUTOMOC", "AUTOUIC", and "AUTORCC" target properties. * A "VS_COPY_TO_OUT_DIR" source file property was added to tell Visual Studio Generators for VS 2010 and above whether or not a file should e copied to the output directory. * A "VS_DEBUGGER_WORKING_DIRECTORY" target property was added to tell Visual Studio Generators for VS 2010 and above what debugger working directory should be set for the target. * A "VS_DOTNET_REFERENCES_COPY_LOCAL" target property was added to specify whether to copy referenced assemblies to the output directory. * A "VS_DOTNET_REFERENCE_" target property was added to tell Visual Studio Generators for VS 2010 and above to add a .NET reference with a given hint path. * A "VS_INCLUDE_IN_VSIX" source file property was added to tell Visual Studio Generators for VS 2010 and above whether to include the file in a Visual Studio extension package. * A "VS_RESOURCE_GENERATOR" source file property was added to give Visual Studio Generators for VS 2010 and above a setting for the resource generator ("C#" only). * A "VS_USER_PROPS" target property was added to tell Visual Studio Generators for VS 2010 and above to use a custom MSBuild user ".props" file. * A "XCODE_EMIT_EFFECTIVE_PLATFORM_NAME" global property was added to tell the "Xcode" generator whether to emit the "EFFECTIVE_PLATFORM_NAME" variable. This is useful when building with multiple SDKs like "macosx" and "iphoneos" in parallel. * New "XCODE_PRODUCT_TYPE" and "XCODE_EXPLICIT_FILE_TYPE" target properties were created to tell the "Xcode" generator to use custom values of the corresponding attributes for a target in the generated Xcode project. Modules ------- * A "CSharpUtilities" module was added to aid parameterization of Visual Studio C# targets. It provides functions to allow automated setting of source file properties to support Windows Forms, WPF/XAML or other technologies as needed. * The "ExternalData" module learned to support multiple content links for one data file using different hashes, e.g. "img.png.sha256" and "img.png.sha1". This allows objects to be fetched from sources indexed by different hash algorithms. * The "ExternalProject" module gained the "GIT_PROGRESS" option to force Git to show progress when cloning repositories. * The "ExternalProject" module gained a "GIT_CONFIG" option to pass " --config" options to Git when cloning repositories. * The "FeatureSummary" module "feature_summary()" command now accepts a new "QUIET_ON_EMPTY" option that suppresses the output when the list of packages that belong to the selected category is empty. * The "FeatureSummary" module "add_feature_info()" command now accepts lists of dependencies for deciding whether a feature is enabled or not. * The package types accepted by the "FeatureSummary" module can now be tweaked by changing the "FeatureSummary_PKG_TYPES", "FeatureSummary_REQUIRED_PKG_TYPES" and "FeatureSummary_DEFAULT_PKG_TYPE" global properties. * The "FindOpenGL" module now provides imported targets "OpenGL::GL" and "OpenGL::GLU" when the libraries are found. * The "UseSWIG" module gained a "swig_add_library" command to give more flexibility over the old "swig_add_module" command. * The "UseSWIG" module "swig_add_source_to_module" command learned a new "SWIG_OUTFILE_DIR" option to control the output file location ("swig -o"). * The "WriteCompilerDetectionHeader" module gained the "ALLOW_UNKNOWN_COMPILERS" and "ALLOW_UNKNOWN_COMPILER_VERSIONS" options that allow creation of headers that will work also with unknown or old compilers by simply assuming they do not support any of the requested features. CTest ----- * The "ctest_memcheck()" command gained a "DEFECT_COUNT " option to capture the number of memory defects detected. * The "ctest_memcheck()" command learned to read the location of suppressions files for sanitizers from the "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable. * The "ctest_memcheck()" command learned to support "LeakSanitizer" independently from "AddressSanitizer". * The "ctest_update()" command "CDASH_UPLOAD" signature was taught to honor the "RETRY_COUNT", "RETRY_DELAY", and "QUIET" options. CPack ----- * The "CPackIFWConfigureFile" module was added to define a new "cpack_ifw_configure_file()" command to configure file templates prepared in QtIFW/SDK/Creator style. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "DEFAULT", "VIRTUAL", "FORCED_INSTALLATION", "REQUIRES_ADMIN_RIGHTS", "DISPLAY_NAME", "UPDATE_TEXT", "DESCRIPTION", "RELEASE_DATE", "AUTO_DEPEND_ON" and "TRANSLATIONS" options to more specific configuration. * The "CPackIFW" module "cpack_ifw_configure_component()" command gained a new "DEPENDENCIES" alias for "DEPENDS" option. * The "CPackIFW" module "cpack_ifw_configure_component_group()" command gained a new "DEPENDS" option. The "DEPENDENCIES" alias also added. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands "PRIORITY" option now is deprecated and will be removed in a future version of CMake. Please use new "SORTING_PRIORITY" option instead. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_WATERMARK", "CPACK_IFW_PACKAGE_BANNER", "CPACK_IFW_PACKAGE_BACKGROUND", "CPACK_IFW_PACKAGE_WIZARD_STYLE", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT", and "CPACK_IFW_PACKAGE_TITLE_COLOR" variables to customize a QtIFW installer look. * The "CPackProductBuild" module gained options to sign packages. See the variables "CPACK_PRODUCTBUILD_IDENTITY_NAME", "CPACK_PRODUCTBUILD_KEYCHAIN_PATH", "CPACK_PKGBUILD_IDENTITY_NAME", and "CPACK_PKGBUILD_KEYCHAIN_PATH". * The "CPackRPM" module learned to omit tags that are not supported by provided "rpmbuild" tool. If unsupported tags are set they are ignored and a developer warning is printed out. * The "CPackRPM" module learned to generate main component package which forces generation of a rpm for defined component without component suffix in filename and package name. See "CPACK_RPM_MAIN_COMPONENT" variable. * The "CPackRPM" module learned to generate a single "debuginfo" package on demand even if components packaging is used. See "CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE" variable. * The "CPackRPM" module learned to support multiple directives per file when using "CPACK_RPM_USER_FILELIST" variable. Other ----- * CMake functionality using cryptographic hashes now supports SHA-3 algorithms. * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". Deprecated and Removed Features =============================== * The "FeatureSummary" module commands "set_package_info()", "set_feature_info()", "print_enabled_features()", and "print_disabled_features()" are now deprecated. * The "UseSWIG" module "swig_add_module" command is now deprecated in favor of "swig_add_library". Other Changes ============= * If a command specified by the "_CLANG_TIDY" target property returns non-zero at build time this is now treated as an error instead of silently ignored. * The "ctest_memcheck()" command no longer automatically adds "leak_check=1" to the options used by "AddressSanitizer". The default behavior of "AddressSanitizer" is to run *LeakSanitizer* to check leaks unless "leak_check=0". * The "ctest_memcheck()" command was fixed to correctly append extra sanitizer options read from the "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable to the environment variables used internally by the sanitizers. * The "FeatureSummary" module "set_package_properties()" command no longer forces the package type to "OPTIONAL" when the type is not explicitly set. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * Calls to the "FindPkgConfig" module "pkg_check_modules()" command following a successful call learned to re-evaluate the cached values for a given prefix after changes to the parameters to the command for that prefix. * When using "AUTOMOC" or "AUTOUIC", generated "moc_*", "*.moc" and "ui_*" are placed in the "/_autogen/include" directory which is automatically added to the target's "INCLUDE_DIRECTORIES". It is therefore not necessary anymore to have "CMAKE_CURRENT_BINARY_DIR" in the target's "INCLUDE_DIRECTORIES". * The "Sublime Text 2" generator no longer runs the native build command (e.g. "ninja" or "make") with verbose build output enabled. * The "try_compile()" command source file signature now honors the "CMAKE_WARN_DEPRECATED" variable value in the generated test project. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". ---------------------------------------------------------------------------- Changes made since CMake 3.8.0-rc2: Ben Boeckel (1): FindHDF5: fix quoting Brad King (22): Revert "Remove CTestTestfile.cmake when BUILD_TESTING is OFF" FindGit: Avoid finding VS 2017 non-general Git installation Help: Fix typo in CMAKE_VS_PLATFORM_TOOLSET_HOST_ARCHITECTURE libarchive: backport rc4 crypto requirement update FindHDF5: Improve HDF5_ROOT variable documentation FindHDF5: Add option to skip finding package configuration file Ninja: Fix Fortran `include` dependency on generated file FindwxWidgets: Use `MSVC_VERSION` instead of `MSVC##` FindwxWidgets: Add support for VS 2017 v141 toolset MSVC: Exclude future cl 20+ from MSVC14 variable Help: Clarify MSVC14 docs w.r.t. VS 2017 v141 toolset Help: Document preference of `MSVC_VERSION` over `MSVC##` InstallRequiredSystemLibraries: Use `MSVC_VERSION` instead of `MSVC##` InstallRequiredSystemLibraries: Refactor to avoid macros InstallRequiredSystemLibraries: Drop version from variable names FindBoost: Avoid mentioning discouraged `MSVC##`` variable FindGTK2: Use `MSVC_VERSION` instead of `MSVC##` FindRuby: Use `MSVC_VERSION` instead of `MSVC##` InstallRequiredSystemLibraries: Split VS IDE and DLL versions InstallRequiredSystemLibraries: Split MFC redist dir variable InstallRequiredSystemLibraries: Add support for VS 2017 CMake 3.8.0-rc3 Daniel Black (1): CPack/RPM: fix error message associated with source path length Domen Vrankar (1): CPack/RPM: fix cpack_rpm_debugsymbol_check parameter Gregor Jasny (1): FindBLAS/LAPACK: Format documentation Kris Thielemans (1): FindHDF5: Restore `-D` in HDF5_DEFINITIONS Mateusz ?oskot (2): FindBoost: Add support for 1.64 FindBoost: Update support for 1.64 Matth?us G. Chajdas (1): FindVulkan: Fix for SDK versions < 1.0.42 on 32-bit Windows Michael St?rmer (2): VS: Do not treat custom targets as CSharp targets CSharpUtilities: Fix documentation Robert Maynard (1): CUDA: Disable support for using response files. Tobias Hunger (1): server-mode: Make CMAKE_HOME_DIRECTORY more reliable Wojciech Mamrak (1): Help: Update MSVC_VERSION for Visual Studio 2017 From eric.noulard at gmail.com Fri Mar 24 15:11:14 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Fri, 24 Mar 2017 20:11:14 +0100 Subject: [CMake] Is it possible to run ctest outside build tree? In-Reply-To: References: Message-ID: Hi David, Thank you for you for checking the code. Would you think adding such a command line option would be acceptable upstream? Le 24 mars 2017 18:43, "David Cole" a ?crit : This code: https://github.com/Kitware/CMake/blob/master/Source/ctest.cxx#L139-L157 shows ctest will look for a CTestTestfile.cmake or DartTestfile.txt file in the current working directory as soon as it starts. Except in the case of processing a "--launch" directive, in which case, it dispatches that in the code just above there. So. I think you have not much choice other than to propose adding a new command line argument for such purpose, or wrapping existing ctest with your own script or program of some sort. HTH, David C. On Fri, Mar 24, 2017 at 6:04 AM, Eric Noulard wrote: > Is possible to run ctest outside the builld tree and how? > typical use is when I have an out of source build I may be in the source > tree > and want to run tests without manually going to build tree. > > i.e. I currently do: > > ninja -C /my/build/tree > > is there a similar way to do that with ctest (other than creating my own > script, shell alias etc...)? > > -- > Eric > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Fri Mar 24 15:25:18 2017 From: DLRdave at aol.com (David Cole) Date: Fri, 24 Mar 2017 15:25:18 -0400 Subject: [CMake] Is it possible to run ctest outside build tree? In-Reply-To: References: Message-ID: If the implementation is "run ctest in this build tree" and it effectively simply does a "pushd $build_tree", runs, and then "popd", then I don't see why anybody would object to it. Although, a script wrapper would be completely trivial, and work with existing ctest. D On Fri, Mar 24, 2017 at 3:11 PM, Eric Noulard wrote: > Hi David, > Thank you for you for checking the code. Would you think adding such a > command line option would be acceptable upstream? > > Le 24 mars 2017 18:43, "David Cole" a ?crit : > > This code: > > https://github.com/Kitware/CMake/blob/master/Source/ctest.cxx#L139-L157 > > shows ctest will look for a CTestTestfile.cmake or DartTestfile.txt > file in the current working directory as soon as it starts. Except in > the case of processing a "--launch" directive, in which case, it > dispatches that in the code just above there. > > So. I think you have not much choice other than to propose adding a > new command line argument for such purpose, or wrapping existing ctest > with your own script or program of some sort. > > > HTH, > David C. > > > > > On Fri, Mar 24, 2017 at 6:04 AM, Eric Noulard > wrote: >> Is possible to run ctest outside the builld tree and how? >> typical use is when I have an out of source build I may be in the source >> tree >> and want to run tests without manually going to build tree. >> >> i.e. I currently do: >> >> ninja -C /my/build/tree >> >> is there a similar way to do that with ctest (other than creating my own >> script, shell alias etc...)? >> >> -- >> Eric >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > From DLRdave at aol.com Fri Mar 24 16:17:26 2017 From: DLRdave at aol.com (David Cole) Date: Fri, 24 Mar 2017 16:17:26 -0400 Subject: [CMake] Running test who have two labels? In-Reply-To: References: Message-ID: Here's a bash script wrapper you could use with existing ctest. Save it out to a file named ctest-two-labels.sh and then call it with bash on Mac or Linux: label1=$1 label2=$2 if [ -z "$label1" ]; then echo "script takes two label arguments as input, missing arg 1" exit 1 fi if [ -z "$label2" ]; then echo "script takes two label arguments as input, missing arg 2" exit 2 fi tmpfile=./ctest-two-labels-sh-tmp.txt testlistFile=./ctest-two-labels-sh-testlist.txt testnumsFile=./ctest-two-labels-sh-testnums.txt ctest -L "^($label1)$" -N > "$tmpfile" ctest -L "^($label2)$" -N >> "$tmpfile" cat "$tmpfile" | grep " Test #" | sort | uniq -d > "$testlistFile" cat "$testlistFile" | awk -F "#" '{ print $2; }' | awk -F ":" '{ print $1; }' > "$testnumsFile" testnums=$(cat "$testnumsFile" | paste -s -d, -) #echo Tests with both labels $label1 and $label2: #cat "$testlistFile" # #echo Just the test numbers: #cat "$testnumsFile" # #echo The test numbers, assembled into a ctest -I string to run just those numbered tests: #echo $testnums echo Running command line: echo "" echo " ctest -I \"0,0,0,$testnums\" -N" echo "" echo Run it without the -N to actually execute the tests... echo "" ctest -I "0,0,0,$testnums" -N It's a "back of the envelope / proof of concept" script. Polish it up and make it nice if the approach seems reasonable to you. HTH, David C. On Fri, Mar 24, 2017 at 8:08 AM, Eric Noulard wrote: > > > 2017-03-24 12:30 GMT+01:00 Nils Gladitz : >> >> On 03/24/2017 11:50 AM, Eric Noulard wrote: >> >>> Hi there, >>> >>> I'm playing with ctest LABELS and I wanted to know whether if it is >>> possible >>> to run the set of tests which have 2 labels ? >>> >>> I manage to have all tests which have **either** L1 or L2: >>> >>> ctest -L "L1|L2" >>> >>> but how can I write a proper command line for both L1 and L2 ? >>> >>> apparently >>> >>> ctest -L "L1" -L "L2" >>> >>> only takes into account the last -L argument. >>> >> >> I don't think it is possible currently. >> To a degree you might be able to work around it by creating additional >> labels that combine the existing ones e.g. "L1", "L2", "L1-L2". > > > Yes of course. > I do test name mangling but I was hoping for more "classifying" feature with > labels and was expecting a simple > OR and AND operation with labels. This is not the case. > > >> >> >> I was pondering trying to implement test filtering based on the condition >> evaluator CMake uses for if()/while() at some point >> (cmConditionEvaluator.cxx). >> e.g. --run-tests-if "L1 IN_LIST TEST_LABELS AND L2 IN_LIST TEST_LABELS" > > > It could have been nice but may be overkill my needs. > A repetable ANDing -L or -LE will do the job. > > That said since test filtering is regex-based I simply rediscovered that > ANDing or negating regex is not easy. > > -- > Eric > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From kipade at 163.com Sat Mar 25 00:58:41 2017 From: kipade at 163.com (kipade) Date: Sat, 25 Mar 2017 12:58:41 +0800 (CST) Subject: [CMake] How to exclude linking from add_subdirectory? Message-ID: <56ba0a7c.24a4.15b03d4aebf.Coremail.kipade@163.com> In my cmake project, there are some subdirectories within it, and some of them have to build as completed static or shared libraries. 1. The top project is executable 2. a subdirectory is a shared project, which also have some subdirectoy compile as static libraries which of course should ONLY link into their parent shared library I add link options to linking the shared library produced by its subdirectory(which linked as a shared library), but I found the all sub-static library with the shared library project(the subdirectory) also double linked into the top executable project. Of course I only want to link the shared library. How to resolve such problem for the top CMakeLists.txt? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Sat Mar 25 05:06:24 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Sat, 25 Mar 2017 10:06:24 +0100 Subject: [CMake] How to exclude linking from add_subdirectory? In-Reply-To: <56ba0a7c.24a4.15b03d4aebf.Coremail.kipade@163.com> References: <56ba0a7c.24a4.15b03d4aebf.Coremail.kipade@163.com> Message-ID: You should check the options PUBLIC, PRIVATE, of the target_link_librairies. See: https://cmake.org/cmake/help/v3.7/command/target_link_libraries.html transitive linking is achieved through PUBLIC or INTERFACE whereas PRIVATE does not propagate. AFAIU your shared lib should PRIVATEly target_link_librairies to your shared lib. Moreover the way you describe it suggest that your static libs may well be OBJECT libraries: https://cmake.org/cmake/help/v3.7/command/add_library.html#object-libraries Next time, posting some excerpt of your CMakeLists.txt would make it easier to answer with example. Eric Le 25 mars 2017 6:14 AM, "kipade" a ?crit : > In my cmake project, there are some subdirectories within it, and some of > them have to build as completed > static or shared libraries. > 1. The top project is executable > 2. a subdirectory is a shared project, which also have some subdirectoy > compile as static libraries which > of course should ONLY link into their parent shared library > I add link options to linking the shared library produced by its > subdirectory(which linked as a shared library), > but I found the all sub-static library with the shared library project(the > subdirectory) also double linked into > the top executable project. Of course I only want to link the shared > library. How to resolve such problem > for the top CMakeLists.txt? > > > > > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Sat Mar 25 16:05:53 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Sat, 25 Mar 2017 21:05:53 +0100 Subject: [CMake] Running test who have two labels? In-Reply-To: References: Message-ID: 2017-03-24 21:17 GMT+01:00 David Cole : > Here's a bash script wrapper you could use with existing ctest. Save > it out to a file named ctest-two-labels.sh and then call it with bash > on Mac or Linux: > > > label1=$1 > label2=$2 > > if [ -z "$label1" ]; then > echo "script takes two label arguments as input, missing arg 1" > exit 1 > fi > > if [ -z "$label2" ]; then > echo "script takes two label arguments as input, missing arg 2" > exit 2 > fi > > tmpfile=./ctest-two-labels-sh-tmp.txt > testlistFile=./ctest-two-labels-sh-testlist.txt > testnumsFile=./ctest-two-labels-sh-testnums.txt > > ctest -L "^($label1)$" -N > "$tmpfile" > ctest -L "^($label2)$" -N >> "$tmpfile" > > cat "$tmpfile" | grep " Test #" | sort | uniq -d > "$testlistFile" > Strange enough I got the very same idea to dump and "uniqify" the list I want. > > cat "$testlistFile" | awk -F "#" '{ print $2; }' | awk -F ":" '{ print > $1; }' > "$testnumsFile" > > testnums=$(cat "$testnumsFile" | paste -s -d, -) > > #echo Tests with both labels $label1 and $label2: > #cat "$testlistFile" > # > #echo Just the test numbers: > #cat "$testnumsFile" > # > #echo The test numbers, assembled into a ctest -I string to run just > those numbered tests: > #echo $testnums > > echo Running command line: > echo "" > echo " ctest -I \"0,0,0,$testnums\" -N" > echo "" > echo Run it without the -N to actually execute the tests... > echo "" > > ctest -I "0,0,0,$testnums" -N > > It's a "back of the envelope / proof of concept" script. Polish it up > and make it nice if the approach seems reasonable to you. > The approach is reasonable. I was simply afraid that dump + filtering of tests and/or labels wouldn't be efficient with 600++ tests. That said it's working. Thank you very much for the proof of concept. I guess that may be dumping whole tests names (with ctest -N ) and labels (with --print-labels) would make it simple for me to craft a script to easily select tests subset with a ctest wrapper. It would even be simpler if ctest could dump all tests with associated labels. I'll think about it. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dvir.Yitzchaki at ceva-dsp.com Sun Mar 26 04:13:53 2017 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Sun, 26 Mar 2017 08:13:53 +0000 Subject: [CMake] Is it possible to run ctest outside build tree? In-Reply-To: References: Message-ID: <5106163058994147a43b97927bcbb132@ceva-dsp.com> How about cmake --build /my/build/tree --target test Regards, Dvir From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Eric Noulard Sent: Friday, March 24, 2017 13:04 To: CMake Mailinglist Subject: [CMake] Is it possible to run ctest outside build tree? Is possible to run ctest outside the builld tree and how? typical use is when I have an out of source build I may be in the source tree and want to run tests without manually going to build tree. i.e. I currently do: ninja -C /my/build/tree is there a similar way to do that with ctest (other than creating my own script, shell alias etc...)? -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Sun Mar 26 04:29:19 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Sun, 26 Mar 2017 10:29:19 +0200 Subject: [CMake] Is it possible to run ctest outside build tree? In-Reply-To: <5106163058994147a43b97927bcbb132@ceva-dsp.com> References: <5106163058994147a43b97927bcbb132@ceva-dsp.com> Message-ID: This works but it is not possible to pass filtering argument (-L or -R) to ctest this way. Le 26 mars 2017 10:13, "Dvir Yitzchaki" a ?crit : > How about > > > > cmake --build /my/build/tree --target test > > > > Regards, > > Dvir > > > > *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Eric Noulard > *Sent:* Friday, March 24, 2017 13:04 > *To:* CMake Mailinglist > *Subject:* [CMake] Is it possible to run ctest outside build tree? > > > > Is possible to run ctest outside the builld tree and how? > > typical use is when I have an out of source build I may be in the source > tree > > and want to run tests without manually going to build tree. > > > > i.e. I currently do: > > > > ninja -C /my/build/tree > > > > is there a similar way to do that with ctest (other than creating my own > script, shell alias etc...)? > > > > -- > > Eric > -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Sun Mar 26 04:51:59 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sun, 26 Mar 2017 19:51:59 +1100 Subject: [CMake] Is it possible to run ctest outside build tree? In-Reply-To: References: <5106163058994147a43b97927bcbb132@ceva-dsp.com> Message-ID: Not sure if this is the sort of thing you are looking for, but you can use the cmake -E chdir command as a way to run an arbitrary command from another directory without having to create any extra scripts, perform shell logic, etc. For example: cmake -E chdir /my/build/tree ctest .... On Sun, Mar 26, 2017 at 7:29 PM, Eric Noulard wrote: > This works but it is not possible to pass filtering argument (-L or -R) to > ctest this way. > > Le 26 mars 2017 10:13, "Dvir Yitzchaki" a > ?crit : > >> How about >> >> >> >> cmake --build /my/build/tree --target test >> >> >> >> Regards, >> >> Dvir >> >> >> >> *From:* CMake [mailto:cmake-bounces at cmake.org] *On Behalf Of *Eric >> Noulard >> *Sent:* Friday, March 24, 2017 13:04 >> *To:* CMake Mailinglist >> *Subject:* [CMake] Is it possible to run ctest outside build tree? >> >> >> >> Is possible to run ctest outside the builld tree and how? >> >> typical use is when I have an out of source build I may be in the source >> tree >> >> and want to run tests without manually going to build tree. >> >> >> >> i.e. I currently do: >> >> >> >> ninja -C /my/build/tree >> >> >> >> is there a similar way to do that with ctest (other than creating my own >> script, shell alias etc...)? >> >> >> >> -- >> >> Eric >> > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From harpywar at gmail.com Sun Mar 26 05:01:33 2017 From: harpywar at gmail.com (HarpyWar) Date: Sun, 26 Mar 2017 12:01:33 +0300 Subject: [CMake] Visual Studio 2017 could not be found if installed in non-default location Message-ID: *CMake could not find Visual Studio 2017 and stops with error:* -- The CXX compiler identification is unknown Initially Visual Studio Community was installed in path: E:\Microsoft But actually part of files are also located in default installation path: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community The files tree from both these directories https://forums.pvpgn.pro/misc.php?action=pan_download&item=17&download=1 Output from vswhere.exe shows that Visual Studio is installed on disk C:\ (https://github.com/Microsoft/vswhere) Visual Studio Locator, version 1.0.58Copyright (C) Microsoft Corporation. All rights reserved. instanceId: 3a7dda28 installDate: 23.11.2016 installationName: VisualStudio/15.0.0+26228.9 installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community installationVersion: 15.0.26228.9 displayName: Visual Studio Community 2017 description: ?????????? ??????????????????? ??????????????? ????? ?????????? ??? ????????, ????????????? ??????? ? ???????? ????? ? ?????????????? ????????????? enginePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\a pp\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service channelId: VisualStudio.15.Release channelPath: C:\Users\User\AppData\Local\Microsoft\VisualStudio\Packages\_Channe ls\4CB340F5\catalog.json channelUri: https://aka.ms/vs/15/release/channel -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Mar 27 09:04:24 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 27 Mar 2017 09:04:24 -0400 Subject: [CMake] Visual Studio 2017 could not be found if installed in non-default location In-Reply-To: References: Message-ID: Hi, Which version of CMake are you using? On Sun, Mar 26, 2017 at 5:01 AM, HarpyWar wrote: > CMake could not find Visual Studio 2017 and stops with error: > -- The CXX compiler identification is unknown > > > Initially Visual Studio Community was installed in path: > E:\Microsoft > But actually part of files are also located in default installation path: > > C:\Program Files (x86)\Microsoft Visual Studio\2017\Community > > The files tree from both these directories > https://forums.pvpgn.pro/misc.php?action=pan_download&item=17&download=1 > > > Output from vswhere.exe shows that Visual Studio is installed on disk C:\ > (https://github.com/Microsoft/vswhere) > > Visual Studio Locator, version 1.0.58 > Copyright (C) Microsoft Corporation. All rights reserved. > > instanceId: 3a7dda28 > installDate: 23.11.2016 > installationName: VisualStudio/15.0.0+26228.9 > installationPath: C:\Program Files (x86)\Microsoft Visual > Studio\2017\Community > installationVersion: 15.0.26228.9 > displayName: Visual Studio Community 2017 > description: ?????????? ??????????????????? ??????????????? ????? ?????????? > ??? > ????????, ????????????? ??????? ? ???????? ????? ? ?????????????? > ????????????? > > enginePath: C:\Program Files (x86)\Microsoft Visual > Studio\Installer\resources\a > pp\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service > channelId: VisualStudio.15.Release > channelPath: > C:\Users\User\AppData\Local\Microsoft\VisualStudio\Packages\_Channe > ls\4CB340F5\catalog.json > channelUri: https://aka.ms/vs/15/release/channel > > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From harpywar at gmail.com Mon Mar 27 09:12:00 2017 From: harpywar at gmail.com (HarpyWar) Date: Mon, 27 Mar 2017 16:12:00 +0300 Subject: [CMake] Visual Studio 2017 could not be found if installed in non-default location In-Reply-To: References: Message-ID: The latest version cmake-3.8.0-rc3-win32-x86.zip On Mon, Mar 27, 2017 at 4:04 PM, Robert Maynard wrote: > Hi, > > Which version of CMake are you using? > > On Sun, Mar 26, 2017 at 5:01 AM, HarpyWar wrote: > > CMake could not find Visual Studio 2017 and stops with error: > > -- The CXX compiler identification is unknown > > > > > > Initially Visual Studio Community was installed in path: > > E:\Microsoft > > But actually part of files are also located in default installation path: > > > > C:\Program Files (x86)\Microsoft Visual Studio\2017\Community > > > > The files tree from both these directories > > https://forums.pvpgn.pro/misc.php?action=pan_download&item=17&download=1 > > > > > > Output from vswhere.exe shows that Visual Studio is installed on disk C:\ > > (https://github.com/Microsoft/vswhere) > > > > Visual Studio Locator, version 1.0.58 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > instanceId: 3a7dda28 > > installDate: 23.11.2016 > > installationName: VisualStudio/15.0.0+26228.9 > > installationPath: C:\Program Files (x86)\Microsoft Visual > > Studio\2017\Community > > installationVersion: 15.0.26228.9 > > displayName: Visual Studio Community 2017 > > description: ?????????? ??????????????????? ??????????????? ????? > ?????????? > > ??? > > ????????, ????????????? ??????? ? ???????? ????? ? ?????????????? > > ????????????? > > > > enginePath: C:\Program Files (x86)\Microsoft Visual > > Studio\Installer\resources\a > > pp\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service > > channelId: VisualStudio.15.Release > > channelPath: > > C:\Users\User\AppData\Local\Microsoft\VisualStudio\Packages\_Channe > > ls\4CB340F5\catalog.json > > channelUri: https://aka.ms/vs/15/release/channel > > > > > > > > > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruce.r.stephens at gmail.com Mon Mar 27 09:31:39 2017 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Mon, 27 Mar 2017 14:31:39 +0100 Subject: [CMake] Handling generated headers Message-ID: I have a build with two or three tools that generate headers and source files. Getting the source files compiled is easy enough: when they're mentioned as source files (in add_library or add_executable) the custom rule gets triggered. But that doesn't seem to be true for header files included by non-generated source files, presumably because CMake's not looking at those files, but rather Ninja is (presumably other generators will behave similarly). If the (generated) header changes then anything using the source file gets rebuilt (as expected), but the first build seems not to necessarily succeed (depending on accidents of when the generated files are produced). Concretely, suppose I have an XML file compat.xml with a custom rule to generate messages/Compat.h, and some source files which include that header (which does not exist to begin with), I'd like a compile of any of those source files to depend on messages/Compat.h such that it'll be generated if necessary. That doesn't seem to happen automatically using the Ninja generator. Is that expected, or have I messed something up? For the moment I'm assuming it's as expected and have a workaround: a simple Python script that scans source files and creates a deps.cmake with calls to add_file_dependencies. (Fortunately all the generated headers have simple patterns so accurately determining them is straightforward.) Unfortunately there are also (non-generated) header files which include these headers and that seems harder to handle. Calling add_file_dependencies on header files doesn't seem to work. It's not a showstopper: I can just explicitly add some dependencies. And later, we'll probably split out some of these things so they'll be separate builds. It seems a bit annoying, though. Am I missing some better way to handle this? From robert.maynard at kitware.com Mon Mar 27 09:35:32 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 27 Mar 2017 09:35:32 -0400 Subject: [CMake] Visual Studio 2017 could not be found if installed in non-default location In-Reply-To: References: Message-ID: I just installed the Visual Studio Community 2017 edition into my D drive and verified that both the 32bit and 64bit compiler was found correctly. The C compiler identification is MSVC 19.10.25017.0 The CXX compiler identification is MSVC 19.10.25017.0 Check for working C compiler: D:/Work/VisualStudo2017/VC/Tools/MSVC/14.10.25017/bin/HostX86/x64/cl.exe Check for working C compiler: D:/Work/VisualStudo2017/VC/Tools/MSVC/14.10.25017/bin/HostX86/x64/cl.exe -- works Detecting C compiler ABI info Detecting C compiler ABI info - done Check for working CXX compiler: D:/Work/VisualStudo2017/VC/Tools/MSVC/14.10.25017/bin/HostX86/x64/cl.exe Check for working CXX compiler: D:/Work/VisualStudo2017/VC/Tools/MSVC/14.10.25017/bin/HostX86/x64/cl.exe -- works So the real question is how did your compiler end up in the C drive and not the alternative drive like mine. Do you run the visual studio installer multiple times? On Mon, Mar 27, 2017 at 9:12 AM, HarpyWar wrote: > The latest version cmake-3.8.0-rc3-win32-x86.zip > > On Mon, Mar 27, 2017 at 4:04 PM, Robert Maynard > wrote: >> >> Hi, >> >> Which version of CMake are you using? >> >> On Sun, Mar 26, 2017 at 5:01 AM, HarpyWar wrote: >> > CMake could not find Visual Studio 2017 and stops with error: >> > -- The CXX compiler identification is unknown >> > >> > >> > Initially Visual Studio Community was installed in path: >> > E:\Microsoft >> > But actually part of files are also located in default installation >> > path: >> > >> > C:\Program Files (x86)\Microsoft Visual Studio\2017\Community >> > >> > The files tree from both these directories >> > https://forums.pvpgn.pro/misc.php?action=pan_download&item=17&download=1 >> > >> > >> > Output from vswhere.exe shows that Visual Studio is installed on disk >> > C:\ >> > (https://github.com/Microsoft/vswhere) >> > >> > Visual Studio Locator, version 1.0.58 >> > Copyright (C) Microsoft Corporation. All rights reserved. >> > >> > instanceId: 3a7dda28 >> > installDate: 23.11.2016 >> > installationName: VisualStudio/15.0.0+26228.9 >> > installationPath: C:\Program Files (x86)\Microsoft Visual >> > Studio\2017\Community >> > installationVersion: 15.0.26228.9 >> > displayName: Visual Studio Community 2017 >> > description: ?????????? ??????????????????? ??????????????? ????? >> > ?????????? >> > ??? >> > ????????, ????????????? ??????? ? ???????? ????? ? ?????????????? >> > ????????????? >> > >> > enginePath: C:\Program Files (x86)\Microsoft Visual >> > Studio\Installer\resources\a >> > pp\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service >> > channelId: VisualStudio.15.Release >> > channelPath: >> > C:\Users\User\AppData\Local\Microsoft\VisualStudio\Packages\_Channe >> > ls\4CB340F5\catalog.json >> > channelUri: https://aka.ms/vs/15/release/channel >> > >> > >> > >> > >> > -- >> > >> > Powered by www.kitware.com >> > >> > Please keep messages on-topic and check the CMake FAQ at: >> > http://www.cmake.org/Wiki/CMake_FAQ >> > >> > Kitware offers various services to support the CMake community. For more >> > information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/cmake > > From nilsgladitz at gmail.com Mon Mar 27 09:46:12 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 27 Mar 2017 15:46:12 +0200 Subject: [CMake] Visual Studio 2017 could not be found if installed in non-default location In-Reply-To: References: Message-ID: On 03/26/2017 11:01 AM, HarpyWar wrote: > Output from vswhere.exe shows that Visual Studio is installed on disk C:\ > (https://github.com/Microsoft/vswhere) Perhaps also try: vswhere -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -requires Microsoft.VisualStudio.Component.Windows10SDK I think those are the default components CMake might expect when looking for compatible installations. Nils From brad.king at kitware.com Mon Mar 27 09:47:16 2017 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Mar 2017 09:47:16 -0400 Subject: [CMake] Visual Studio 2017 could not be found if installed in non-default location In-Reply-To: References: Message-ID: On 03/27/2017 09:35 AM, Robert Maynard wrote: > So the real question is how did your compiler end up in the C drive > and not the alternative drive like mine. Do you run the visual studio > installer multiple times? Did you have any of the VS 15 preview versions installed previously? For reference, VS 2017 does not have any registry entries. Instead the VS installer tool provides a COM interface that applications must use to ask for the location(s) of VS installations. We do this in cmVSSetupHelper [1]. -Brad [1] https://gitlab.kitware.com/cmake/cmake/blob/v3.8.0-rc3/Source/cmVSSetupHelper.cxx From mellery451 at gmail.com Mon Mar 27 11:08:50 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Mon, 27 Mar 2017 08:08:50 -0700 Subject: [CMake] Handling generated headers In-Reply-To: References: Message-ID: <4DF5AFDD-E2CA-4D50-AD06-E9F4A5349991@gmail.com> > On Mar 27, 2017, at 6:31 AM, Bruce Stephens wrote: > > I have a build with two or three tools that generate headers and > source files. Getting the source files compiled is easy enough: when > they're mentioned as source files (in add_library or add_executable) > the custom rule gets triggered. > > But that doesn't seem to be true for header files included by > non-generated source files, presumably because CMake's not looking at > those files, but rather Ninja is (presumably other generators will > behave similarly). If the (generated) header changes then anything > using > the source file gets rebuilt (as expected), but the first build seems > not to necessarily succeed (depending on accidents of when the > generated files are produced). > > Concretely, suppose I have an XML file compat.xml with a custom rule > to generate messages/Compat.h, and some source files which include > that header (which does not exist to begin with), I'd like a compile > of any of those source files to depend on messages/Compat.h such that > it'll be generated if necessary. > > That doesn't seem to happen automatically using the Ninja generator. > Is that expected, or have I messed something up? > > For the moment I'm assuming it's as expected and have a workaround: a > simple Python script that scans source files and creates a deps.cmake > with calls > to add_file_dependencies. (Fortunately all the generated headers have > simple patterns so accurately determining them is straightforward.) > > Unfortunately there are also (non-generated) header files which > include these headers and that seems harder to handle. > Calling add_file_dependencies on header files doesn't seem to work. > > It's not a showstopper: I can just explicitly add some dependencies. > And later, we'll probably split out some of these things so they'll > be separate builds. It seems a bit annoying, though. Am I missing some > better way to handle this? > -- it?s not clear from your message ? are you using add_custom_command() to create the rule that generates the header from the XML? If you get all of the parameters right to that command (like OUTPUT, DEPENDS, BYPRODUCTS..), then I would expect this to work and the header should get generated before any other source that needs it. In some cases you might need to explicitly specify that a target depends on that header, but if at least ONE thing depends on the header, the the add_custom_command rule should get executed. You might also try running CMAKE with ?trace and generating a verbose makefile if you are still not seeing your custom command running when it should. -Mike Ellery From bruce.r.stephens at gmail.com Mon Mar 27 17:57:36 2017 From: bruce.r.stephens at gmail.com (Bruce Stephens) Date: Mon, 27 Mar 2017 22:57:36 +0100 Subject: [CMake] Handling generated headers In-Reply-To: <4DF5AFDD-E2CA-4D50-AD06-E9F4A5349991@gmail.com> References: <4DF5AFDD-E2CA-4D50-AD06-E9F4A5349991@gmail.com> Message-ID: Yes, that's the idea: I have custom commands (created with add_custom_command) listing the headers in OUTPUT. And there are source files which #include such headers. I'd like it so that compiling such a source file would cause the header to be generated. Concretely, with a CMakeLists.txt like the attached, with the obvious main.c (also attached), I'd like "ninja exe" to work. I find that it does not. After "ninja build-incl" (or "ninja incl.h") then "ninja exe" will work. And then after removing incl.h, "ninja exe" will recreate incl.h and then rebuild exe. (Presumably ninja is caching some dependency information, likely in its .ninja_deps file.) But correct recompilation (while obviously desirable) doesn't seem sufficient; I want the first build to work too. (I'm also not sure why the add_custom_target is required, but it does seem to be. Presumably without it CMake can't see why the custom command might be used.) In most cases I have a natural place where I need the things to be built, so the custom target can have ALL DEPENDS (rather than.the DEPENDS in the example). However, in some cases in parallel builds I still end up with (sometimes) source files not compiling because the needed headers haven't been generated. As I say, so far this is OK: I can just generated dependencies explicitly in a pre-CMake step. But handling cases where main.c includes some source header which includes this generated incl.h seems not easily doable. If I'm not missing something silly and all this is expected behaviour (as it appears to be) it's not a disaster. We can add a few explicit dependencies and get things to work. But maybe I'm missing something and this should work more smoothly. On Mon, Mar 27, 2017 at 4:08 PM, Michael Ellery wrote: > >> On Mar 27, 2017, at 6:31 AM, Bruce Stephens wrote: >> >> I have a build with two or three tools that generate headers and >> source files. Getting the source files compiled is easy enough: when >> they're mentioned as source files (in add_library or add_executable) >> the custom rule gets triggered. >> >> But that doesn't seem to be true for header files included by >> non-generated source files, presumably because CMake's not looking at >> those files, but rather Ninja is (presumably other generators will >> behave similarly). If the (generated) header changes then anything >> using >> the source file gets rebuilt (as expected), but the first build seems >> not to necessarily succeed (depending on accidents of when the >> generated files are produced). >> >> Concretely, suppose I have an XML file compat.xml with a custom rule >> to generate messages/Compat.h, and some source files which include >> that header (which does not exist to begin with), I'd like a compile >> of any of those source files to depend on messages/Compat.h such that >> it'll be generated if necessary. >> >> That doesn't seem to happen automatically using the Ninja generator. >> Is that expected, or have I messed something up? >> >> For the moment I'm assuming it's as expected and have a workaround: a >> simple Python script that scans source files and creates a deps.cmake >> with calls >> to add_file_dependencies. (Fortunately all the generated headers have >> simple patterns so accurately determining them is straightforward.) >> >> Unfortunately there are also (non-generated) header files which >> include these headers and that seems harder to handle. >> Calling add_file_dependencies on header files doesn't seem to work. >> >> It's not a showstopper: I can just explicitly add some dependencies. >> And later, we'll probably split out some of these things so they'll >> be separate builds. It seems a bit annoying, though. Am I missing some >> better way to handle this? >> -- > > > it?s not clear from your message ? are you using add_custom_command() to create the rule that generates the header from the XML? If you get all of the parameters right to that command (like OUTPUT, DEPENDS, BYPRODUCTS..), then I would expect this to work and the header should get generated before any other source that needs it. In some cases you might need to explicitly specify that a target depends on that header, but if at least ONE thing depends on the header, the the add_custom_command rule should get executed. You might also try running CMAKE with ?trace and generating a verbose makefile if you are still not seeing your custom command running when it should. > > -Mike Ellery -------------- next part -------------- cmake_minimum_required(VERSION 3.7) add_executable(exe main.c) target_include_directories(exe PUBLIC ${CMAKE_CURRENT_BINARY_DIR}) add_custom_command(OUTPUT incl.h COMMAND ${CMAKE_COMMAND} -E touch incl.h) add_custom_target(build-incl DEPENDS incl.h) -------------- next part -------------- A non-text attachment was scrubbed... Name: main.c Type: text/x-csrc Size: 32 bytes Desc: not available URL: From mellery451 at gmail.com Mon Mar 27 18:37:08 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Mon, 27 Mar 2017 15:37:08 -0700 Subject: [CMake] Handling generated headers In-Reply-To: References: <4DF5AFDD-E2CA-4D50-AD06-E9F4A5349991@gmail.com> Message-ID: <5099AE86-6188-4807-B28B-DC5EA4BA187A@gmail.com> > On Mar 27, 2017, at 2:57 PM, Bruce Stephens wrote: > > Yes, that's the idea: I have custom commands (created with > add_custom_command) listing the headers in OUTPUT. > > And there are source files which #include such headers. > > I'd like it so that compiling such a source file would cause the > header to be generated. > > Concretely, with a CMakeLists.txt like the attached, with the obvious > main.c (also attached), I'd like "ninja exe" to work. > > I find that it does not. > > After "ninja build-incl" (or "ninja incl.h") then "ninja exe" will > work. And then after removing incl.h, > "ninja exe" will recreate incl.h and then rebuild exe. (Presumably > ninja is caching some dependency information, likely > in its .ninja_deps file.) But correct recompilation (while obviously > desirable) doesn't seem sufficient; I want the first > build to work too. > > (I'm also not sure why the add_custom_target is required, but it does > seem to be. Presumably without it CMake > can't see why the custom command might be used.) > > In most cases I have a natural place where I need the things to be > built, so the custom target can have ALL DEPENDS > (rather than.the DEPENDS in the example). However, in some cases in > parallel builds I still end up with (sometimes) > source files not compiling because the needed headers haven't been generated. > > As I say, so far this is OK: I can just generated dependencies > explicitly in a pre-CMake step. But handling cases where > main.c includes some source header which includes this generated > incl.h seems not easily doable. > > If I'm not missing something silly and all this is expected behaviour > (as it appears to be) it's not a disaster. We can add > a few explicit dependencies and get things to work. But maybe I'm > missing something and this should work more > smoothly. > > > On Mon, Mar 27, 2017 at 4:08 PM, Michael Ellery wrote: > Doing this worked for me: ???? add_executable(exe main.c ${CMAKE_CURRENT_BINARY_DIR}/incl.h) target_include_directories(exe PUBLIC ${CMAKE_CURRENT_BINARY_DIR}) add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/incl.h COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_CURRENT_BINARY_DIR}/incl.h) ???? ..in other words, I used the binary dir as the output location of the generated file and then I explicitly added the header file to the sources list. Yeah, it would be nice if header reps auto detection worked in this case, but it seems like it does not, so you form the dependency relationship explicitly I guess. -Mike From michele.portolan at grenoble-inp.fr Tue Mar 28 06:17:16 2017 From: michele.portolan at grenoble-inp.fr (Michele Portolan) Date: Tue, 28 Mar 2017 12:17:16 +0200 Subject: [CMake] Toggle Absolute paths in Eclipse Generator Message-ID: <3510d11a-cccd-f010-e931-2713dc8dfb81@grenoble-inp.fr> Hello, I am trying to use the Eclipse Generator to create a project to be exported to Eclipse. Everything works fine, but when I look at the generated .cproject and .project I see that all paths are absolute, like for instance: -E chdir "/home/portolan/my_project/Optional_Libs/eclipse_build/Server" "/usr/bin/cmake" -P "CMakeFiles/ATE_Loopback_Server.dir/cmake_clean.cmake" This is not really good because I would like to copy my project to another machine where I do not have /home/portolan/. So I have two questions: Can I ask cmake to - generate relative paths instead of absolute? - copy the sources locally to the Eclipse project, rather than use the external ones? Thanks, Michele From mateusz at loskot.net Tue Mar 28 07:22:14 2017 From: mateusz at loskot.net (Mateusz Loskot) Date: Tue, 28 Mar 2017 13:22:14 +0200 Subject: [CMake] Add BUILD_SHARED_LIBS as an option Message-ID: Hi, The docs [1] say: "This variable [BUILD_SHARED_LIBS] is often added to projects as an option()" [1] https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html Does that literally mean adding the option this way? option(BUILD_SHARED_LIBS "Build shared library" OFF) Or, adding an extra level of indirection via custom option: option(XXX_BUILD_SHARED "Build shared library" OFF) if (XXX_BUILD_SHARED) set(BUILD_SHARED_LIBS ON) endif() I do realise it's question about docs pedantism, but I'd like to get that cleared once for good :) I'm trying to cut number of custom options and I'm never certain how I can actually re/ab-use the standard CMake settings. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From eric.noulard at gmail.com Tue Mar 28 08:18:40 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 28 Mar 2017 14:18:40 +0200 Subject: [CMake] Toggle Absolute paths in Eclipse Generator In-Reply-To: <3510d11a-cccd-f010-e931-2713dc8dfb81@grenoble-inp.fr> References: <3510d11a-cccd-f010-e931-2713dc8dfb81@grenoble-inp.fr> Message-ID: Hi Michele, If you look into CMake ML history you'll find many discussions concerning the ABSOLUTE vs RELATIVE path for generated build systems. CMake had once an option for trying that, the support has been removed: https://cmake.org/cmake/help/v3.7/variable/CMAKE_USE_RELATIVE_PATHS.html So basically you cannot ask generate relative paths. See: https://cmake.org/Wiki/CMake_FAQ#Why_does_CMake_use_full_paths.2C_or_can_I_copy_my_build_tree.3F 2017-03-28 12:17 GMT+02:00 Michele Portolan < michele.portolan at grenoble-inp.fr>: > Hello, > > I am trying to use the Eclipse Generator to create a project to be > exported to Eclipse. Everything works fine, but when I look at the > generated .cproject and .project I see that all paths are absolute, like > for instance: > > -E chdir "/home/portolan/my_project/Opt > ional_Libs/eclipse_build/Server" "/usr/bin/cmake" -P > "CMakeFiles/ATE_Loopback_Server.dir/cmake_clean.cmake" > > > This is not really good because I would like to copy my project to another > machine where I do not have /home/portolan/. > > So I have two questions: Can I ask cmake to > > - generate relative paths instead of absolute? > > - copy the sources locally to the Eclipse project, rather than use the > external ones? > > > Thanks, > > > Michele > > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From harpywar at gmail.com Tue Mar 28 09:17:32 2017 From: harpywar at gmail.com (HarpyWar) Date: Tue, 28 Mar 2017 16:17:32 +0300 Subject: [CMake] Visual Studio 2017 could not be found if installed in non-default location In-Reply-To: References: Message-ID: I did some tests on different Windows versions in virtual machines. On a fresh Windows 10 (and installed Visual Studio 2017 Community) cmake works fine and a compiler is found. But on earlier versions: Windows 7, Windows 8.1, Windows Server 2012 - cmake always fails with error "The CXX compiler identification is unknown" So, the problem is not in different installation path, but in wrong method to find a compiler in earlier Windows. Nils Gladitz, the command, which you proposed, return nothing, even on a machine where a compiler found: vswhere -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -requires Microsoft.VisualStudio.Component.Windows10SDK On Mon, Mar 27, 2017 at 4:47 PM, Brad King wrote: > On 03/27/2017 09:35 AM, Robert Maynard wrote: > > So the real question is how did your compiler end up in the C drive > > and not the alternative drive like mine. Do you run the visual studio > > installer multiple times? > > Did you have any of the VS 15 preview versions installed previously? > > For reference, VS 2017 does not have any registry entries. Instead > the VS installer tool provides a COM interface that applications must > use to ask for the location(s) of VS installations. We do this in > cmVSSetupHelper [1]. > > -Brad > > > [1] https://gitlab.kitware.com/cmake/cmake/blob/v3.8.0-rc3/Sourc > e/cmVSSetupHelper.cxx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Mar 28 09:40:45 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 28 Mar 2017 15:40:45 +0200 Subject: [CMake] Visual Studio 2017 could not be found if installed in non-default location In-Reply-To: References: Message-ID: On 03/28/2017 03:17 PM, HarpyWar wrote: > Nils Gladitz, the command, which you proposed, return nothing, even on > a machine where a compiler found: > vswhere -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 > -requires Microsoft.VisualStudio.Component.Windows10SDK For me it lists my "Visual Studio Community 2017" installation (on Windows 10). If CMake works nonetheless perhaps you've got "Microsoft.VisualStudio.Component.Windows81SDK" instead of "Microsoft.VisualStudio.Compone nt.Windows10SDK" (which I think CMake falls back on). And on the systems where it doesn't work perhaps you've got neither? Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From harpywar at gmail.com Tue Mar 28 09:57:19 2017 From: harpywar at gmail.com (HarpyWar) Date: Tue, 28 Mar 2017 16:57:19 +0300 Subject: [CMake] Visual Studio 2017 could not be found if installed in non-default location In-Reply-To: References: Message-ID: "Microsoft.VisualStudio.Component.Windows81SDK" could not not be found anywhere. A component "Microsoft.VisualStudio.Component.Windows10SDK.14393" exists on Windows 10 x64 (just found about it here https://docs.microsoft.com/en- us/visualstudio/install/workload-component-id-vs-community) This component also exists on a virtual machine with Windows 8.1 x86 where cmake can not find the compiler. vswhere -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -requires Microsoft.VisualStudio.Component.Windows10SDK.14393 Visual Studio Locator, version 1.0.58 Copyright (C) Microsoft Corporation. All rights reserved. instanceId: 874fee78 installDate: 3/28/2017 installationName: VisualStudio/15.0.0+26228.9 installationPath: C:\Program Files\Microsoft Visual Studio\2017\Community installationVersion: 15.0.26228.9 displayName: Visual Studio Community 2017 description: Free, fully-featured IDE for students, open-source and individual d evelopers enginePath: C:\Program Files\Microsoft Visual Studio\Installer\resources\app \Ser viceHub\Services\Microsoft.VisualStudio.Setup.Service channelId: VisualStudio.15.Release channelPath: C:\Users\Anton\AppData\Local\Microsoft\VisualStudio\Packages \_Chann els\4CB340F5\catalog.json channelUri: https://aka.ms/vs/15/release/channel On Tue, Mar 28, 2017 at 4:40 PM, Nils Gladitz wrote: > On 03/28/2017 03:17 PM, HarpyWar wrote: > > Nils Gladitz, the command, which you proposed, return nothing, even on a > machine where a compiler found: > vswhere -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 > -requires Microsoft.VisualStudio.Component.Windows10SDK > > > For me it lists my "Visual Studio Community 2017" installation (on Windows > 10). > > If CMake works nonetheless perhaps you've got > "Microsoft.VisualStudio.Component.Windows81SDK" instead of > "Microsoft.VisualStudio.Compone > nt.Windows10SDK" (which I think CMake falls back on). > > And on the systems where it doesn't work perhaps you've got neither? > > Nils > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Tue Mar 28 11:01:45 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 28 Mar 2017 17:01:45 +0200 Subject: [CMake] Visual Studio 2017 could not be found if installed in non-default location In-Reply-To: References: Message-ID: <1d1314ac-e535-46e7-4ac1-3200de1dabde@gmail.com> On 03/28/2017 03:57 PM, HarpyWar wrote: > "Microsoft.VisualStudio.Component.Windows81SDK" could not not be found > anywhere. > > A component "Microsoft.VisualStudio.Component.Windows10SDK.14393" > exists on Windows 10 x64 (just found about it here > https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-community > ) > > This component also exists on a virtual machine with Windows 8.1 x86 > where cmake can not find the compiler. > > vswhere -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 > -requires Microsoft.VisualStudio.Component.Windows10SDK.14393 > Visual Studio Locator, version 1.0.58 > Copyright (C) Microsoft Corporation. All rights reserved. https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmVSSetupHelper.cxx#L115 also seems to expect / accept those version suffixes. Beyond that I can't think of anything other than debugging into cmVSSetupHelper.cxx. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexis.jeandet at member.fsf.org Tue Mar 28 15:57:48 2017 From: alexis.jeandet at member.fsf.org (Jeandet Alexis) Date: Tue, 28 Mar 2017 21:57:48 +0200 Subject: [CMake] Unknown generator output with CMake Message-ID: <1490731068.15625.11.camel@lpp.polytechnique.fr> Hi, I play with CMake on PythonQt build. I faced a chalenge: PythonQt is composed of: 1)The generator which wrap Qt api(parses Qt sources to produce cpp/python wrappers) 2)The Lib (main engine) 3)The wrappers generated by 1) The chalenge was to build in this order: 1) build generator 2) generate from generator wrappers? 3) build Lib 4) build wrappers My issue was to build wrappers from generator output since I can't predict how many files it will produce. And what I understood is that Glob can only be used at config time and I cant use *.cpp as sources. So my basic solution was to build generator and call it at config time using ExternalProject and execute_process: https://github.com/jeandet/PythonQt/blob/cmake-clean/cmake/generated_cp p.cmake Then build src and wrapper normally. I'm a CMake beginner but I feel that this solution is ugly and it slows down config time. Did I miss something?? Best regards, Alexis. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Tue Mar 28 17:24:43 2017 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 29 Mar 2017 08:24:43 +1100 Subject: [CMake] Unknown generator output with CMake In-Reply-To: <1490731068.15625.11.camel@lpp.polytechnique.fr> References: <1490731068.15625.11.camel@lpp.polytechnique.fr> Message-ID: I have a very similar situation at work to yours. We build a generator which produces source files, but we don't know the set of source files that will be produced until after the generator has been run. The solution that is working for us is documented here: http://stackoverflow.com/a/36084786/1938798 It's a little more involved than you probably want, but we've been using it for close to a year now and it is serving us well. On Wed, Mar 29, 2017 at 6:57 AM, Jeandet Alexis < alexis.jeandet at member.fsf.org> wrote: > Hi, > > I play with CMake on PythonQt build. I faced a chalenge: > > PythonQt is composed of: > 1)The generator which wrap Qt api(parses Qt sources to produce cpp/python > wrappers) > 2)The Lib (main engine) > 3)The wrappers generated by 1) > > The chalenge was to build in this order: > 1) build generator > 2) generate from generator wrappers > 3) build Lib > 4) build wrappers > > My issue was to build wrappers from generator output since I can't predict > how many files it will produce. And what I understood is that Glob can only > be used at config time and I cant use *.cpp as sources. > > So my basic solution was to build generator and call it at config time > using ExternalProject and execute_process: > https://github.com/jeandet/PythonQt/blob/cmake-clean/ > cmake/generated_cpp.cmake > Then build src and wrapper normally. > I'm a CMake beginner but I feel that this solution is ugly and it slows > down config time. > > Did I miss something? > > Best regards, > Alexis. > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Wagner at neuberger.net Wed Mar 29 03:10:05 2017 From: Martin.Wagner at neuberger.net (Wagner Martin) Date: Wed, 29 Mar 2017 07:10:05 +0000 Subject: [CMake] gnu-arm-embedded toolchain and CMAKE_FORCE_C_COMPILER Message-ID: <56E920142ED81D4FBE3260E4B9D1DB3E97C43620@ROTSRV13.Neuberger.local> Hi @all, In recent CMake versions I get a deprecated message for using the cmake_force_xxx_compiler() function inside my toolchain file. After searching, I found that there are two threads on the CMake list, one https://cmake.org/pipermail/cmake/2016-February/062773.html just ending without a solution and referencing to https://cmake.org/pipermail/cmake-developers/2016-February/027888.html which also doesn?t really tell me how this is supposed to work in my case. From those threads, I was able to modify my toolchain file: - replaced force_compiler function with regular set(CMAKE... - added line set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) as linking needs a linker script. However, it fails with the following output: exit.c:(.text.exit+0x1a): undefined reference to `_exit' collect2: error: ld returned 1 exit status which to me indicates that CMake ignores the STATIC_LIBRARY flag and tries linking. Has anyone successfully modified their toolchain file to correctly detect the gnu-arm-embedded toolchain? Thanks for your help! Regards, Martin Terminal output: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- The C compiler identification is GNU 6.2.1 -- The CXX compiler identification is GNU 6.2.1 -- Check for working C compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc CMake Error at /home/user/workspace/project/buildsupport/toolchains/toolchain_stm32f303xB_freertos.cmake:37 (include): include could not find load file: /home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/CMakeTmp/buildsupport/toolchains/toolchain_arm-cortex-m4f.cmake Call Stack (most recent call first): /home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/3.7.2/CMakeSystem.cmake:6 (include) /home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/CMakeTmp/CMakeLists.txt:2 (project) CMake Error: Internal CMake error, TryCompile configure of cmake failed -- Check for working C compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc -- broken CMake Error at /usr/share/cmake-3.7/Modules/CMakeTestCCompiler.cmake:51 (message): The C compiler "/opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc" is not able to compile a simple test program. It fails with the following output: -- Configuring incomplete, errors occurred! See also "/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/CMakeOutput.log". See also "/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/CMakeError.log". CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:17 (project) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CMakeOutput.log The target system is: Generic - - arm-freertos-eabi The host system is: Linux - 4.9.0-1-amd64 - x86_64 Compiling the C compiler identification source file "CMakeCCompilerId.c" succeeded. Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc Build flags: ;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL; Id flags: -c The output was: 0 Compilation of the C compiler identification source "CMakeCCompilerId.c" produced "CMakeCCompilerId.o" The C compiler identification is GNU, found in "/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/3.7.2/CompilerIdC/CMakeCCompilerId.o" Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" succeeded. Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-g++ Build flags: ;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL; Id flags: -c The output was: 0 Compilation of the CXX compiler identification source "CMakeCXXCompilerId.cpp" produced "CMakeCXXCompilerId.o" The CXX compiler identification is GNU, found in "/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/3.7.2/CompilerIdCXX/CMakeCXXCompilerId.o" Compiling the C compiler identification source file "CMakeCCompilerId.c" succeeded. Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc Build flags: ;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL; Id flags: -c The output was: 0 Compilation of the C compiler identification source "CMakeCCompilerId.c" produced "CMakeCCompilerId.o" The C compiler identification is GNU, found in "/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/3.7.2/CompilerIdC/CMakeCCompilerId.o" Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" succeeded. Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-g++ Build flags: ;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL; Id flags: -c The output was: 0 Compilation of the CXX compiler identification source "CMakeCXXCompilerId.cpp" produced "CMakeCXXCompilerId.o" The CXX compiler identification is GNU, found in "/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/3.7.2/CompilerIdCXX/CMakeCXXCompilerId.o" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CMakeError.log Compiling the C compiler identification source file "CMakeCCompilerId.c" failed. Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc Build flags: ;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL; Id flags: The output was: 1 /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/../lib/gcc/arm-freertos-eabi/6.2.1/../../../../arm-freertos-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc_nano.a(lib_a-exit.o): In function `exit': exit.c:(.text.exit+0x1a): undefined reference to `_exit' collect2: error: ld returned 1 exit status Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed. Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-g++ Build flags: ;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL; Id flags: The output was: 1 /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/../lib/gcc/arm-freertos-eabi/6.2.1/../../../../arm-freertos-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc_nano.a(lib_a-exit.o): In function `exit': exit.c:(.text.exit+0x1a): undefined reference to `_exit' collect2: error: ld returned 1 exit status Determining if the C compiler works failed with the following output: Compiling the C compiler identification source file "CMakeCCompilerId.c" failed. Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc Build flags: ;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL; Id flags: The output was: 1 /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/../lib/gcc/arm-freertos-eabi/6.2.1/../../../../arm-freertos-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc_nano.a(lib_a-exit.o): In function `exit': exit.c:(.text.exit+0x1a): undefined reference to `_exit' collect2: error: ld returned 1 exit status Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed. Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-g++ Build flags: ;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL; Id flags: The output was: 1 /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/../lib/gcc/arm-freertos-eabi/6.2.1/../../../../arm-freertos-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libc_nano.a(lib_a-exit.o): In function `exit': exit.c:(.text.exit+0x1a): undefined reference to `_exit' collect2: error: ld returned 1 exit status Determining if the C compiler works failed with the following output: ~~~~eof, no output~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Toolchain file: # FreeRTOS custom toolchain set(target_os freertos) set(target_toolchain /opt/gcc-arm-${target_os}-eabi-6_2-2017q1/bin) # Linker file set(EXE_LINKER_FLAGS "${EXE_LINKER_FLAGS} -T path/to/linker/file/STM32F303CBTx_FLASH.ld") set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) #can?t link without linker file ## specify the cross compiler set(CROSSTOOLCHAIN_PATH ${target_toolchain}) set(CMAKE_SYSTEM_PROCESSOR arm-${target_os}-eabi) set(CROSSTOOLCHAIN_PREFIX ${CMAKE_SYSTEM_PROCESSOR}-) #cmake_force_c_compiler(${CROSSTOOLCHAIN_PATH}/${CROSSTOOLCHAIN_PREFIX}gcc GNU ) #cmake_force_cxx_compiler(${CROSSTOOLCHAIN_PATH}/${CROSSTOOLCHAIN_PREFIX}g++ GNU ) set(CMAKE_C_COMPILER ${CROSSTOOLCHAIN_PATH}/${CROSSTOOLCHAIN_PREFIX}gcc) set(CMAKE_CXX_COMPILER ${CROSSTOOLCHAIN_PATH}/${CROSSTOOLCHAIN_PREFIX}g++) ## where is the target environment set(CMAKE_FIND_ROOT_PATH ${CROSSTOOLCHAIN_PATH}) ## search for programs in the build host directories set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) ## for libraries and headers in the target directories set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) # Cortex M4 Compilerflags # gcc-arm-none-eabi-4_9-2015q3/share/doc/gcc-arm-none-eabi/readme.txt set(C_FLAGS "${C_FLAGS} -mcpu=cortex-m4") set(C_FLAGS "${C_FLAGS} -mfpu=fpv4-sp-d16") set(C_FLAGS "${C_FLAGS} -mfloat-abi=hard") set(C_FLAGS "${C_FLAGS} -mthumb") # newlib Nano. REENT_SMALL needed for FreeRTOS! set(C_FLAGS "${C_FLAGS} --specs=nano.specs -D_REENT_SMALL ") # Bare Metal Target set(EXE_LINKER_FLAGS "${EXE_LINKER_FLAGS} --specs=rdimon.specs -lrdimon") set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} ${C_FLAGS} CACHE STRING "Cortex M4 C Flags") set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${C_FLAGS} CACHE STRING "Cortex M4 C++ Flags") set(CMAKE_ASM_FLAGS ${CMAKE_ASM_FLAGS} ${C_FLAGS} CACHE STRING "Cortex M4 asm Flags") set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} ${EXE_LINKER_FLAGS} CACHE STRING "Cortex M4 Linker Flags") From rschwarzelt at gmail.com Wed Mar 29 06:33:28 2017 From: rschwarzelt at gmail.com (Robert Schwarzelt) Date: Wed, 29 Mar 2017 12:33:28 +0200 Subject: [CMake] get complete list of compile definitions Message-ID: <002801d2a877$e7fc9370$b7f5ba50$@googlemail.com> Hi all, I need to implement a code export function, that will only export code used in a specific project configuration. For this purpose I want to use unifdef (http://dotat.at/prog/unifdef/), which is capable of removing unused #ifdef blocks. The project uses static libraries like in following example: add_library( foo STATIC foo.c ) add_library( bar STATIC bar.c ) target_compile_definitions(bar INTERFACE HAVE_BAR) target_link_libraries(foo LINK_PUBLIC bar) Now foo.c will be compiled with -DHAVE_BAR at build time. To create a custom target using unifdef i need this information at cmake configure time. I expected to find this in the property COMPILE_DEFINITIONS of either the source file foo.c or target foo, but both are empty. Does anyone know, how to get a list of definitions (that will be used at build time) for targets or files? Regards, Robert Schwarzelt From eric.noulard at gmail.com Wed Mar 29 07:37:06 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 29 Mar 2017 13:37:06 +0200 Subject: [CMake] cmake --graphviz not dumping custom target in the graph Message-ID: Hi all, It appears that cmake --graphviz command line option does not dump custom target in the generated dot graph but "only" target appearing in add_executable or add_library (plain or IMPORTED). Is there any fundamental reason for that ? I'd like to see ALL target (including custom) in my dependency graph. -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Wed Mar 29 08:30:51 2017 From: craig.scott at crascit.com (Craig Scott) Date: Wed, 29 Mar 2017 23:30:51 +1100 Subject: [CMake] cmake --graphviz not dumping custom target in the graph In-Reply-To: References: Message-ID: Does the behavior change if your custom target is part of the ALL target or not? On Wed, Mar 29, 2017 at 10:37 PM, Eric Noulard wrote: > Hi all, > > It appears that cmake --graphviz command line option does not dump custom > target > in the generated dot graph but "only" target appearing in add_executable > or add_library (plain or IMPORTED). > > Is there any fundamental reason for that ? > > I'd like to see ALL target (including custom) in my dependency graph. > > -- > Eric > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Wed Mar 29 10:46:21 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 29 Mar 2017 16:46:21 +0200 Subject: [CMake] cmake --graphviz not dumping custom target in the graph In-Reply-To: References: Message-ID: I did not try that. It appears that none of my custom target do belong to ALL. I'll try right away and let you know. 2017-03-29 14:30 GMT+02:00 Craig Scott : > Does the behavior change if your custom target is part of the ALL target > or not? > > On Wed, Mar 29, 2017 at 10:37 PM, Eric Noulard > wrote: > >> Hi all, >> >> It appears that cmake --graphviz command line option does not dump >> custom target >> in the generated dot graph but "only" target appearing in add_executable >> or add_library (plain or IMPORTED). >> >> Is there any fundamental reason for that ? >> >> I'd like to see ALL target (including custom) in my dependency graph. >> >> -- >> Eric >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > > > -- > Craig Scott > Melbourne, Australia > https://crascit.com > -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From rschwarzelt at gmail.com Wed Mar 29 11:16:24 2017 From: rschwarzelt at gmail.com (Robert Schwarzelt) Date: Wed, 29 Mar 2017 17:16:24 +0200 Subject: [CMake] get complete list of compile definitions Message-ID: <004e01d2a89f$6e716f80$4b544e80$@googlemail.com> Just in case anyone is interested - I found a hint in this old thread: https://cmake.org/pipermail/cmake/2014-February/056993.html Trick is to use a generator expression like this: "$" Regards, Robert Schwarzelt From sbv1976 at gmail.com Wed Mar 29 11:24:40 2017 From: sbv1976 at gmail.com (Steven Velez) Date: Wed, 29 Mar 2017 11:24:40 -0400 Subject: [CMake] ZERO_CHECK generation and Xcode Message-ID: If I understand correctly the purpose of the ZERO_CHECK target is to update the generated project files when necessary. That's fine, but I have noticed on Xcode (8.2) that when ZERO_CHECK runs and updates the project, it causes the xcode build to abort. Unfortunately, it seems this build abort happens before the xcode project regeneration has a chance to complete and update/touch CMakeFiles/cmake.check_cache, so once the target is out of date, it pretty much stays that way, and the builds are always (or least frequently) subsequently aborted because of an update to generated project files. If I go in to the terminal and manually execute "make -f ReRunCMake.make" then the process completes and the ZERO_CHECK target is good, and it does not run any more. Is there any known way to deal with this other than by specifying CMAKE_SUPRRESS_REGENERATION:BOOL=YES ? Thanks, Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.noulard at gmail.com Wed Mar 29 11:50:33 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Wed, 29 Mar 2017 17:50:33 +0200 Subject: [CMake] Fwd: cmake --graphviz not dumping custom target in the graph In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Eric Noulard Date: 2017-03-29 17:50 GMT+02:00 Subject: Re: [CMake] cmake --graphviz not dumping custom target in the graph To: Craig Scott After checking this does not change. It seems that the only targets that appear in the graph are the one from add_executable/add_library In fact the culprit seems to be: https://gitlab.kitware.com/cmake/cmake/blob/master/ Source/cmGraphVizWriter.cxx cmGraphVizWriter::GenerateForTargetType which filters out other kind of target. 2017-03-29 16:46 GMT+02:00 Eric Noulard : > I did not try that. > It appears that none of my custom target do belong to ALL. > I'll try right away and let you know. > > 2017-03-29 14:30 GMT+02:00 Craig Scott : > >> Does the behavior change if your custom target is part of the ALL target >> or not? >> >> On Wed, Mar 29, 2017 at 10:37 PM, Eric Noulard >> wrote: >> >>> Hi all, >>> >>> It appears that cmake --graphviz command line option does not dump >>> custom target >>> in the generated dot graph but "only" target appearing in add_executable >>> or add_library (plain or IMPORTED). >>> >>> Is there any fundamental reason for that ? >>> >>> I'd like to see ALL target (including custom) in my dependency graph. >>> >>> -- >>> Eric >>> >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >>> >> >> >> >> -- >> Craig Scott >> Melbourne, Australia >> https://crascit.com >> > > > > -- > Eric > -- Eric -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From gjasny at googlemail.com Wed Mar 29 14:33:28 2017 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 29 Mar 2017 20:33:28 +0200 Subject: [CMake] ZERO_CHECK generation and Xcode In-Reply-To: References: Message-ID: <92a51b13-612b-60f2-2643-ae928b2db63a@googlemail.com> Hi Steven, On 3/29/17 5:24 PM, Steven Velez wrote: > If I understand correctly the purpose of the ZERO_CHECK target is to update > the generated project files when necessary. > > That's fine, but I have noticed on Xcode (8.2) that when ZERO_CHECK runs > and updates the project, it causes the xcode build to abort. > Unfortunately, it seems this build abort happens before the xcode project > regeneration has a chance to complete and update/touch > CMakeFiles/cmake.check_cache, so once the target is out of date, it pretty > much stays that way, and the builds are always (or least frequently) > subsequently aborted because of an update to generated project files. > > If I go in to the terminal and manually execute "make -f ReRunCMake.make" > then the process completes and the ZERO_CHECK target is good, and it does > not run any more. > > Is there any known way to deal with this other than by specifying > CMAKE_SUPRRESS_REGENERATION:BOOL=YES ? Could you please file a bug about this? I'll take a look during the 3.9 development cycle. Do you have a rather large or small project? Thanks, Gregor From gjasny at googlemail.com Wed Mar 29 16:22:16 2017 From: gjasny at googlemail.com (Gregor Jasny) Date: Wed, 29 Mar 2017 22:22:16 +0200 Subject: [CMake] ZERO_CHECK generation and Xcode In-Reply-To: References: <92a51b13-612b-60f2-2643-ae928b2db63a@googlemail.com> Message-ID: On 3/29/17 10:15 PM, Steven Velez wrote: > I do have a pretty large project with around 142 targets. > > Another characteristic of note, and which I noticed while investigating > this is that our project suffers from > https://gitlab.kitware.com/cmake/cmake/issues/14297, and I think it is > because we have "project" declarations underneath the top-level... so > ZERO_CHECK builds concurrently with other targets. Oh boy. Thanks for pointing this out. > I did create an xcode scheme that builds a smaller set of targets (6), and > made sure that they all depended on ZERO_CHECK, and then ZERO_CHECK ran by > itself, and it appeared that after a single test, it did manage to complete > updating so that it did not run on subsequent invocations. I'll have a look. From rcdailey.lists at gmail.com Wed Mar 29 20:10:32 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 29 Mar 2017 19:10:32 -0500 Subject: [CMake] Building third party libraries along with normal targets Message-ID: Interested in hearing everyone's thoughts on this idea of mine. Right now I have several third party libraries: openssl, boost, libpng, zlib, etc. List goes on. I need to support these libraries on at least 3 different platforms: ARM android, x86 linux, x86 windows. It's a real pain in the rear to build each of these libraries a total of 3 times (once per platform). It makes upgrades painful. So I was thinking: If I set up each third party library to build from source as a normal target with the rest of my targets, this would get me the libraries for each third party lib "for free". Basically, they would all build the same way no matter what platform I'm on. I can move to other platforms or architectures in the future with no extra effort. The downside, of course, is that they build along with my normal targets. Which means doing "ninja clean" will clean them, when I really don't need to, and it will make build times get longer. Any thoughts on this idea? Are there any other downsides? Is this the best way to have library support across platforms? From rcdailey.lists at gmail.com Wed Mar 29 20:46:15 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 29 Mar 2017 19:46:15 -0500 Subject: [CMake] include() doesn't work with relative paths? Message-ID: This fails: include( foo/bar/myscript.cmake ) But this works: include( ${CMAKE_CURRENT_LIST_DIR}/foo/bar/myscript.cmake ) Why are relative paths not working? From florent.castelli at gmail.com Wed Mar 29 21:18:50 2017 From: florent.castelli at gmail.com (Florent Castelli) Date: Thu, 30 Mar 2017 03:18:50 +0200 Subject: [CMake] Building third party libraries along with normal targets In-Reply-To: References: Message-ID: <237bc054-7bb4-6be1-e688-36c8d37b7fbb@gmail.com> On 30/03/2017 02:10, Robert Dailey wrote: > Interested in hearing everyone's thoughts on this idea of mine. > > Right now I have several third party libraries: openssl, boost, > libpng, zlib, etc. List goes on. I need to support these libraries on > at least 3 different platforms: ARM android, x86 linux, x86 windows. > It's a real pain in the rear to build each of these libraries a total > of 3 times (once per platform). It makes upgrades painful. > > So I was thinking: If I set up each third party library to build from > source as a normal target with the rest of my targets, this would get > me the libraries for each third party lib "for free". Basically, they > would all build the same way no matter what platform I'm on. I can > move to other platforms or architectures in the future with no extra > effort. This is known as "super build". Yes, this is exactly why I made my Boost CMake build scripts, which you use unless you changed your mind today :) It can be done for other projects as well. Sometimes, they even provide CMake build scripts you can use directly with "add_subdirectory()" so you don't have to write CMake scripts or use "ExternalProject_Add()" (which isn't all great since it doesn't propagate all your current project settings). > The downside, of course, is that they build along with my normal > targets. Which means doing "ninja clean" will clean them, when I > really don't need to, and it will make build times get longer. You can use ccache or its Windows variants to make it faster. But you also shouldn't need "ninja clean" most of the time. Possibly, you could just clean a specific target "ninja -t clean foo". If you declare all your dependencies properly, then you could just always run "ninja" and the build will just be correct. If your purpose is to see the compiler output again (to fix warnings), it is acceptable to clean and rebuild (with ccache it should be fast enough). Personally, I just have a very long history in my terminal and scroll back or pipe the build content to a file to look at it later. Some IDEs will also record all the compilation output and make it available later (Xcode does it), then it's less of an issue. > Any thoughts on this idea? Are there any other downsides? Is this the > best way to have library support across platforms? The downside is that you have to maintain lots of 3rd party build scripts. Depending on the side of the project, it might be a big overhead for the team. But it might also be totally worth it in order to support a lot of platforms, it just makes it easier than handling a huge matrix of binaries for each platform, arch and compiler and compiler options. "Hey, you want to try LTO? Just add the flag and it's done!". /Florent From rcdailey.lists at gmail.com Wed Mar 29 21:54:47 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 29 Mar 2017 20:54:47 -0500 Subject: [CMake] Building third party libraries along with normal targets In-Reply-To: <237bc054-7bb4-6be1-e688-36c8d37b7fbb@gmail.com> References: <237bc054-7bb4-6be1-e688-36c8d37b7fbb@gmail.com> Message-ID: On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli wrote: > This is known as "super build". > Yes, this is exactly why I made my Boost CMake build scripts, which you use > unless you changed your mind today :) You mean this? https://github.com/Orphis/boost-cmake It's on the drawing board, for sure. It's the best solution I've found. It's also part of the reason I'm asking this question to begin with. Although, this specific method of building boost doesn't use superbuild, it uses normal add_subdirectory() with target. > It can be done for other projects as well. Sometimes, they even provide > CMake build scripts you can use directly with "add_subdirectory()" so you > don't have to write CMake scripts or use "ExternalProject_Add()" (which > isn't all great since it doesn't propagate all your current project > settings). Long term, I'm thinking a project like hunter[1] would be the best choice. The problem with hunter is that it doesn't separate concerns between host machine and target host. Specifically, when cross compiling. All the superbuild commands assume linux command syntax, simply because I specified a toolchain utilizing android NDK. For this reason it requires a lot of TLC to get working. [1]: https://github.com/ruslo/hunter > You can use ccache or its Windows variants to make it faster. But you also > shouldn't need "ninja clean" most of the time. Possibly, you could just > clean a specific target "ninja -t clean foo". > If you declare all your dependencies properly, then you could just always > run "ninja" and the build will just be correct. > If your purpose is to see the compiler output again (to fix warnings), it is > acceptable to clean and rebuild (with ccache it should be fast enough). > Personally, I just have a very long history in my terminal and scroll back > or pipe the build content to a file to look at it later. Some IDEs will also > record all the compilation output and make it available later (Xcode does > it), then it's less of an issue. Never used ccache before, what does it do? Also if even if you ninja -t to clean, it will also clean dependencies. So if I specify those in-project dependencies that actually build third party libs, those will be cleaned too. From florent.castelli at gmail.com Wed Mar 29 22:32:42 2017 From: florent.castelli at gmail.com (Florent Castelli) Date: Thu, 30 Mar 2017 04:32:42 +0200 Subject: [CMake] Building third party libraries along with normal targets In-Reply-To: References: <237bc054-7bb4-6be1-e688-36c8d37b7fbb@gmail.com> Message-ID: <65d8e7cb-edde-f713-b771-2477f813919c@gmail.com> On 30/03/2017 03:54, Robert Dailey wrote: > On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli > wrote: >> This is known as "super build". >> Yes, this is exactly why I made my Boost CMake build scripts, which you use >> unless you changed your mind today :) > You mean this? > https://github.com/Orphis/boost-cmake > > It's on the drawing board, for sure. It's the best solution I've > found. It's also part of the reason I'm asking this question to begin > with. > > Although, this specific method of building boost doesn't use > superbuild, it uses normal add_subdirectory() with target. It doesn't "super build" its dependencies, you have to provide them externally, but it is a possible addition. But it is designed to be part of a super build environment and is used as such at some large companies shipping to millions of people. > >> It can be done for other projects as well. Sometimes, they even provide >> CMake build scripts you can use directly with "add_subdirectory()" so you >> don't have to write CMake scripts or use "ExternalProject_Add()" (which >> isn't all great since it doesn't propagate all your current project >> settings). > Long term, I'm thinking a project like hunter[1] would be the best > choice. The problem with hunter is that it doesn't separate concerns > between host machine and target host. Specifically, when cross > compiling. > > All the superbuild commands assume linux command syntax, simply > because I specified a toolchain utilizing android NDK. For this reason > it requires a lot of TLC to get working. > > [1]: https://github.com/ruslo/hunter There are those issues and also ABI changing flags that can become an issue as they aren't always propagated from what I can see. >> You can use ccache or its Windows variants to make it faster. But you also >> shouldn't need "ninja clean" most of the time. Possibly, you could just >> clean a specific target "ninja -t clean foo". >> If you declare all your dependencies properly, then you could just always >> run "ninja" and the build will just be correct. >> If your purpose is to see the compiler output again (to fix warnings), it is >> acceptable to clean and rebuild (with ccache it should be fast enough). >> Personally, I just have a very long history in my terminal and scroll back >> or pipe the build content to a file to look at it later. Some IDEs will also >> record all the compilation output and make it available later (Xcode does >> it), then it's less of an issue. > Never used ccache before, what does it do? Also if even if you ninja > -t to clean, it will also clean dependencies. So if I specify those > in-project dependencies that actually build third party libs, those > will be cleaned too. It's a program you use to record compilation outputs and save them to a disk cache. If you build a file again, instead of compiling it, it will just fetch the outputs from the cache and return the same warnings. It's usually a safe optimization in a build pipeline and is quite easy to use with CMake and Ninja generator. It works well with GCC or Clang and there are some alternative versions for the Microsoft compiler too. /Florent From rcdailey.lists at gmail.com Wed Mar 29 22:38:42 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 29 Mar 2017 21:38:42 -0500 Subject: [CMake] Building third party libraries along with normal targets In-Reply-To: <65d8e7cb-edde-f713-b771-2477f813919c@gmail.com> References: <237bc054-7bb4-6be1-e688-36c8d37b7fbb@gmail.com> <65d8e7cb-edde-f713-b771-2477f813919c@gmail.com> Message-ID: On Wed, Mar 29, 2017 at 9:32 PM, Florent Castelli wrote: > On 30/03/2017 03:54, Robert Dailey wrote: >> >> On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli >> wrote: >>> >>> This is known as "super build". >>> Yes, this is exactly why I made my Boost CMake build scripts, which you >>> use >>> unless you changed your mind today :) >> >> You mean this? >> https://github.com/Orphis/boost-cmake >> >> It's on the drawing board, for sure. It's the best solution I've >> found. It's also part of the reason I'm asking this question to begin >> with. >> >> Although, this specific method of building boost doesn't use >> superbuild, it uses normal add_subdirectory() with target. > > It doesn't "super build" its dependencies, you have to provide them > externally, but it is a possible addition. > But it is designed to be part of a super build environment and is used as > such at some large companies shipping to millions of people. > >> >>> It can be done for other projects as well. Sometimes, they even provide >>> CMake build scripts you can use directly with "add_subdirectory()" so you >>> don't have to write CMake scripts or use "ExternalProject_Add()" (which >>> isn't all great since it doesn't propagate all your current project >>> settings). >> >> Long term, I'm thinking a project like hunter[1] would be the best >> choice. The problem with hunter is that it doesn't separate concerns >> between host machine and target host. Specifically, when cross >> compiling. >> >> All the superbuild commands assume linux command syntax, simply >> because I specified a toolchain utilizing android NDK. For this reason >> it requires a lot of TLC to get working. >> >> [1]: https://github.com/ruslo/hunter > > There are those issues and also ABI changing flags that can become an issue > as they aren't always propagated from what I can see. > >>> You can use ccache or its Windows variants to make it faster. But you >>> also >>> shouldn't need "ninja clean" most of the time. Possibly, you could just >>> clean a specific target "ninja -t clean foo". >>> If you declare all your dependencies properly, then you could just always >>> run "ninja" and the build will just be correct. >>> If your purpose is to see the compiler output again (to fix warnings), it >>> is >>> acceptable to clean and rebuild (with ccache it should be fast enough). >>> Personally, I just have a very long history in my terminal and scroll >>> back >>> or pipe the build content to a file to look at it later. Some IDEs will >>> also >>> record all the compilation output and make it available later (Xcode does >>> it), then it's less of an issue. >> >> Never used ccache before, what does it do? Also if even if you ninja >> -t to clean, it will also clean dependencies. So if I specify those >> in-project dependencies that actually build third party libs, those >> will be cleaned too. > > > It's a program you use to record compilation outputs and save them to a disk > cache. If you build a file again, instead of compiling it, it will just > fetch the outputs from the cache and return the same warnings. It's usually > a safe optimization in a build pipeline and is quite easy to use with CMake > and Ninja generator. > > It works well with GCC or Clang and there are some alternative versions for > the Microsoft compiler too. At the end of the day, I've solved the Boost problem but I have many other libraries I still manually build: openssl, libpng, zlib, etc. It's as you said, maintaining build scripts for all of these will be challenging but I think that's the proper way to go in my specific situation (multi platform). It'll be less maintenance than rebuilding binaries 3x per each. Do you know how to set up the boost cmake project I linked on github to work with superbuild? And do you prefer your superbuild execution to happen during cmake generate (basically cmake invokes itself for the superbuild) or do you prefer a separate external run, independent of the normal one (basically 2x cmake invocations)? Do you know of similar projects for other libraries I mentioned? Could hand write my own, but seems better to piggyback on someone else's efforts. Thanks for your feedback! From florent.castelli at gmail.com Wed Mar 29 23:01:56 2017 From: florent.castelli at gmail.com (Florent Castelli) Date: Thu, 30 Mar 2017 05:01:56 +0200 Subject: [CMake] Building third party libraries along with normal targets In-Reply-To: References: <237bc054-7bb4-6be1-e688-36c8d37b7fbb@gmail.com> <65d8e7cb-edde-f713-b771-2477f813919c@gmail.com> Message-ID: On 30/03/2017 04:38, Robert Dailey wrote: > At the end of the day, I've solved the Boost problem but I have many > other libraries I still manually build: openssl, libpng, zlib, etc. > It's as you said, maintaining build scripts for all of these will be > challenging but I think that's the proper way to go in my specific > situation (multi platform). It'll be less maintenance than rebuilding > binaries 3x per each. > > Do you know how to set up the boost cmake project I linked on github > to work with superbuild? And do you prefer your superbuild execution > to happen during cmake generate (basically cmake invokes itself for > the superbuild) or do you prefer a separate external run, independent > of the normal one (basically 2x cmake invocations)? > > Do you know of similar projects for other libraries I mentioned? Could > hand write my own, but seems better to piggyback on someone else's > efforts. > > Thanks for your feedback! Only a few libraries are tricky to build, libpng or zlib are trivial for example. A super-build is just having one big project and defining all the targets directly in there, using external CMake build scripts through add_subdirectory() for example. There is just one CMake invocation. This is how my Boost CMake project (yes, I'm the one being it) works. As for the Boost dependencies, are you really using them? If you're not, then you don't need to build the parts of Boost using them, most are optional. If you do, then you can provide Find*.cmake scripts returning targets you've built yourself currently. Feel free to create issues on the bug tracker if you need assistance with that. I don't know on the top of my head similar projects for all libraries, but I know there are many people writing CMake build scripts for all kind of libraries, so just search on the web :) /Florent From tiagomacarios at gmail.com Thu Mar 30 00:59:45 2017 From: tiagomacarios at gmail.com (Tiago Macarios) Date: Wed, 29 Mar 2017 21:59:45 -0700 Subject: [CMake] assembly on windows Message-ID: Hi, Is there a simple way to get a Visual Studio + assembly project on windows? This seems to work on Linux: cmake_minimum_required(VERSION 3.7) project(assembler C ASM) set_source_files_properties(hello.s PROPERTIES COMPILE_FLAGS "-x assembler-with-cpp") add_executable(hello hello.s) What would be the windows version of the above? If I naively try the code above on Windows I get the following output: -- Building for: Visual Studio 15 2017 -- The C compiler identification is MSVC 19.10.25017.0 -- The ASM compiler identification is MSVC -- Found assembler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Warning: Did not find file Compiler/MSVC-ASM -- Configuring done -- Generating done -- Build files have been written to: C:/Users/Mac/test/cmake/build and build fails Thanks! Mac -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamas.kenez at gmail.com Thu Mar 30 04:42:27 2017 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Thu, 30 Mar 2017 10:42:27 +0200 Subject: [CMake] Building third party libraries along with normal targets In-Reply-To: References: <237bc054-7bb4-6be1-e688-36c8d37b7fbb@gmail.com> <65d8e7cb-edde-f713-b771-2477f813919c@gmail.com> Message-ID: An alternative to the CMake superbuild: leave your actual project intact. Simply create a separate shell script which builds all the dependencies (by running cmake commands). Or, if you do like the ExternalProject stuff, create a superbuild which builds only the dependencies. Tamas On Thu, Mar 30, 2017 at 5:01 AM, Florent Castelli < florent.castelli at gmail.com> wrote: > On 30/03/2017 04:38, Robert Dailey wrote: > >> At the end of the day, I've solved the Boost problem but I have many >> other libraries I still manually build: openssl, libpng, zlib, etc. >> It's as you said, maintaining build scripts for all of these will be >> challenging but I think that's the proper way to go in my specific >> situation (multi platform). It'll be less maintenance than rebuilding >> binaries 3x per each. >> >> Do you know how to set up the boost cmake project I linked on github >> to work with superbuild? And do you prefer your superbuild execution >> to happen during cmake generate (basically cmake invokes itself for >> the superbuild) or do you prefer a separate external run, independent >> of the normal one (basically 2x cmake invocations)? >> >> Do you know of similar projects for other libraries I mentioned? Could >> hand write my own, but seems better to piggyback on someone else's >> efforts. >> >> Thanks for your feedback! >> > > Only a few libraries are tricky to build, libpng or zlib are trivial for > example. > > A super-build is just having one big project and defining all the targets > directly in there, using external CMake build scripts through > add_subdirectory() for example. There is just one CMake invocation. > This is how my Boost CMake project (yes, I'm the one being it) works. As > for the Boost dependencies, are you really using them? If you're not, then > you don't need to build the parts of Boost using them, most are optional. > If you do, then you can provide Find*.cmake scripts returning targets > you've built yourself currently. Feel free to create issues on the bug > tracker if you need assistance with that. > > I don't know on the top of my head similar projects for all libraries, but > I know there are many people writing CMake build scripts for all kind of > libraries, so just search on the web :) > > /Florent > > > -- > > 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/opensou > rce/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Thu Mar 30 09:45:07 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 30 Mar 2017 08:45:07 -0500 Subject: [CMake] Building third party libraries along with normal targets In-Reply-To: References: <237bc054-7bb4-6be1-e688-36c8d37b7fbb@gmail.com> <65d8e7cb-edde-f713-b771-2477f813919c@gmail.com> Message-ID: On Thu, Mar 30, 2017 at 3:42 AM, Tam?s Ken?z wrote: > An alternative to the CMake superbuild: leave your actual project intact. > Simply create a separate shell script which builds all the dependencies (by > running cmake commands). Or, if you do like the ExternalProject stuff, > create a superbuild which builds only the dependencies. Problem with that is that it's not a portable solution. The #1 benefit of using CMake superbuilds (supplied with CMake build solution for the target library) is that it will function correctly on all platforms. From christophe.demez at luciad.com Thu Mar 30 10:10:27 2017 From: christophe.demez at luciad.com (Christophe Demez) Date: Thu, 30 Mar 2017 16:10:27 +0200 Subject: [CMake] ExternalProject_Add ... output directy (sln file directory) Message-ID: Hi, I'm currently using one CMakeLists.txt file that will execute an external CMakeLists.txt (and dependency). For this I use the ExternalProject_Add command, but I can't find a way to specify where the ".sln" file will be generated. I have also created StackOverflow question here with more information, if someone have an idea for a solution ? http://stackoverflow.com/questions/43117117/cmake-use-externalproject-add-and-specify-the-output-folder Thanks From DLRdave at aol.com Thu Mar 30 10:20:12 2017 From: DLRdave at aol.com (David Cole) Date: Thu, 30 Mar 2017 10:20:12 -0400 Subject: [CMake] ExternalProject_Add ... output directy (sln file directory) In-Reply-To: References: Message-ID: Do give it a BINARY_DIR, but do NOT give it a BUILD_COMMAND. Giving it an empty BUILD_COMMAND means "do nothing" for the build step and using "cmake --build ./LibraryBuild" does not work unless cmake is in your PATH, and with a Visual Studio solution, you also need to specify "--config Release" or "--config Debug" Also posted on SO. HTH, David C. On Thu, Mar 30, 2017 at 10:10 AM, Christophe Demez wrote: > Hi, > > I'm currently using one CMakeLists.txt file that will execute an external > CMakeLists.txt (and dependency). > > For this I use the ExternalProject_Add command, but I can't find a way to > specify where the ".sln" file will be generated. > > I have also created StackOverflow question here with more information, if > someone have an idea for a solution ? > > http://stackoverflow.com/questions/43117117/cmake-use-externalproject-add-and-specify-the-output-folder > > Thanks > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From elizabeth.fischer at columbia.edu Thu Mar 30 10:24:17 2017 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Thu, 30 Mar 2017 10:24:17 -0400 Subject: [CMake] Building third party libraries along with normal targets In-Reply-To: References: <237bc054-7bb4-6be1-e688-36c8d37b7fbb@gmail.com> <65d8e7cb-edde-f713-b771-2477f813919c@gmail.com> Message-ID: I do this using the spack autobuilder. Only problem is it doesn't run on windows. Maybe Conda? On Mar 30, 2017 9:45 AM, "Robert Dailey" wrote: > On Thu, Mar 30, 2017 at 3:42 AM, Tam?s Ken?z > wrote: > > An alternative to the CMake superbuild: leave your actual project intact. > > Simply create a separate shell script which builds all the dependencies > (by > > running cmake commands). Or, if you do like the ExternalProject stuff, > > create a superbuild which builds only the dependencies. > > Problem with that is that it's not a portable solution. The #1 benefit > of using CMake superbuilds (supplied with CMake build solution for the > target library) is that it will function correctly on all platforms. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From bitminer at gmail.com Thu Mar 30 10:58:49 2017 From: bitminer at gmail.com (Brian Davis) Date: Thu, 30 Mar 2017 09:58:49 -0500 Subject: [CMake] ExternalProject_Add and include_external_msproject dynamic duo... but what if their powers combined? In-Reply-To: References: Message-ID: Apologies for not responding sooner... this fell off my radar and I found it in my email. On Thu, Jan 12, 2017 at 6:29 AM, David Cole wrote: > Why not just use a BUILD_COMMAND which builds the VS project using the > msbuild command line directly? Do you have an example of this? Even if this is an option it would not seem to allow adding the vcxproj project files to VS solution, but may be a better option for the way ExternalProject_Add wraps the underlying project and hides all sub-project goop in a single target. With what I am proposing the vcxproj files would be added to VS solution as individual targets. I have used BUILD_COMMAND in the past for *attempting* build of boost in CMake, but due to complaints on command line argument length in VS had to resort to using BUILD_COMMAND to call bjam/b2 in bat file generated using configure_file then called from ExternalProject_add. I then went on to write and configure_file the roll my own boost CMake package support and install. Ultimately I was able to get it to work. I can now build any version of boost from within CMake simply by selecting version in CMake gui. I have been working on a superbuild of superbuilds [Super-E-Duper-Builder SEDB / SeeDeb See Dependency downloaded, built and installed) which in theory could download, build, and install any C++ code in the Ether that ExternalProject_Add supports though zip, git, svn, hg etc. It's goes where ExternalProject add and find_package left the dev community... with a finite quantum of tools, but no abilty to get any software downloaded, built and installed though say an "ultimate package manager". This is where a programmer comes to the realization of the "wild west" of 3rd Party lib developers use of CMake package. Some are new to it like fltk and do not version files or there cmake package directory nor do they put package files in lib/cmake/flltk-/ as itk and vmtk do and instead put it in ${CMAKE_INSTALL_PREFIX}/CMake/. Others like dcmtk put it in share\dcmtk (again without version info as itk and vmtk do \lib\cmake\ITK-4.8\). But ITK is no great example either as on windows has a limit due to path length limiting on where ITK can be build (build dir) I think it's something like 56 characters (resulting in build paths outside the project like C:\itk\src\ITK-4.8.1) and I have stated my aggravation regarding this on ITK's user forum. I must be joking right? well from ITK root CMakeLists.txt file: if( CMAKE_HOST_WIN32 ) string( LENGTH "${CMAKE_CURRENT_SOURCE_DIR}" n ) if( n GREATER 50 ) message( FATAL_ERROR "ITK source code directory path length is too long (${n} > 50)." "Please move the ITK source code directory to a directory with a shorter path." ) endif() Sadly no and .. ok so it's 50. VMTK puts stuff in build dir minus needed libs like tet.lib and nl.lib and pkgfiles point back to get this... the build dir and not install dir for include files. I feel like a CMake package marshal trying to herd cats on the internet... lost cause for sure. Then there are 3rdParty libs that use superbuild themselves to checkout and build various libs (vmtk usign vtk and itk). VMTK allows user to use installed version. But lets say two 3rd party libs use super build to build two different versions of packages such as fltk or dcmtk and install into a single directory ${CMAKE_PACKAGE_PREFIX} = C:\projects\proj1\install... what happens to the package files... yep the last build blast away the installed package files as no versioning was used. Also 3rdparty lib devs expand vars in installed package files and do not use configure_file( ... @ONLY) to keep things relative. Then there is the "roll their own" use of CMAKE__PREFIX where they don't use (or don't know it exists) it but instead postfix ('d') it themselves (fltk) based on build config so if developer comes along and sets it as it do ends up with dd.lib... I mean that's a double d lib... and must be for super debugging. And what is it about CMake not supporting CMAKE__PREFIX automatically for executables as though they are second class targets. Leaving devs to use SET_TARGET_PROPERTIES( ${APP_NAME} PROPERTIES COMPILE_DEFINITIONS "${DEFINITIONS_STRING}" DEBUG_POSTFIX ${CMAKE_DEBUG_POSTFIX} ) The guide at https://cmake.org/cmake/help/v3.8/manual/cmake-packages.7.html is certainly a great start though include(CMakePackageConfigHelpers) Could do a great deal more to aid in creating some sort of standards and aid 3rdPart lib devs in putting bits in the right place and correctly versioning. Not to mention... er wait I'll mention it ... 3rd party dev's use of project(thirdPartyProjName) where version info is not used so by default on windows CMAKE_INSTALL_PREFIX defaults to C:\Program Files\thirdPartyProjName and not thirdPartyProjName- where again things can get blasted away. One could say it's the 3rd party lib devs fault for not adhering to CMake standard/best practices... but CMake/Kitware could do more to aid 3rd party lib devs. Added macros to CMakePackage ConfigHelpers might help. Then there are the users which install packages, but cant' figure out why CMake keeps using the installed version of the package as per CMake's default package definitions and don't realize it has to do with not specifying HINTS, PATHS, PATH_SUFFIXES find_package( [version] [EXACT] [QUIET] [HINTS path1 [path2 ... ]] [PATHS path1 [path2 ... ]] [PATH_SUFFIXES suffix1 [suffix2 ...]] And then makes me question the internal package support bundled with CMake. Over the years the internal package support has in my experience lagged (CUDA .. Though NVIIDA could not decide on any standards as to where to put stuff in their releases making it impossible for CMake to crystal ball a next release) and I had to roll my own. Regarding lib naming convention: If anyone has taken the time to look at boost naming convention for their libs and understand the reasons for it it makes a lot of sense. Some standards in CMake or at least macros for those who would like to support standardization of lib name, version, 32/64, ms VS, versions etc might make IMO a great addition to CMake (And CONFIGURE_COMMAND "" since there > is typically no configure step for VS-based projects...) > > Yes this is what I do. HTH, David C. On Thu, Jan 12, 2017 at 2:13 AM, Brian J. Davis wrote: > Every time I create a superbuild using ExternalProject_Add sooner or later a > project will not support cmake, but will have buried within its bowels a > visual studio solution project .sln and sometimes gobs of .vcxproj files > (read CPython). Now ofcourse include_external_msproject can do this. If > only these two wonder twins (https://en.wikipedia.org/wiki/Wonder_Twins) > could work together in the same ExternalProject_Add command. Maybe by > adding after HG_TAG say VCX_PROJS or some such. > > Only thing better would be getting original project maintainer to support > CMake. > > So feature request: Can we get ExternalProject_Add to support visual studio > project files? > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe.demez at luciad.com Thu Mar 30 11:11:39 2017 From: christophe.demez at luciad.com (Christophe Demez) Date: Thu, 30 Mar 2017 17:11:39 +0200 Subject: [CMake] ExternalProject_Add ... output directy (sln file directory) In-Reply-To: References: Message-ID: <91b8100c-2caf-6c29-46de-2a7b506b2b9f@luciad.com> BTW, I notice this too, if I use the following command line with an empty cmakelists.txt file : cmake -G "Visual Studio 15 2017 Win64" And it also generate the .sln (and other files) in the same folder, but I don't request to build such a solution ! right ? In reality, I only need a cmakelists.txt file that will build an external library for Android (Ninja generator, directly from AndroidStudio). For now I use the wrong generator for test. On 30/03/2017 16:20, David Cole wrote: > Do give it a BINARY_DIR, but do NOT give it a BUILD_COMMAND. Giving it > an empty BUILD_COMMAND means "do nothing" for the build step and using > "cmake --build ./LibraryBuild" does not work unless cmake is in your > PATH, and with a Visual Studio solution, you also need to specify > "--config Release" or "--config Debug" > > Also posted on SO. > > > HTH, > David C. > > > > On Thu, Mar 30, 2017 at 10:10 AM, Christophe Demez > wrote: >> Hi, >> >> I'm currently using one CMakeLists.txt file that will execute an external >> CMakeLists.txt (and dependency). >> >> For this I use the ExternalProject_Add command, but I can't find a way to >> specify where the ".sln" file will be generated. >> >> I have also created StackOverflow question here with more information, if >> someone have an idea for a solution ? >> >> http://stackoverflow.com/questions/43117117/cmake-use-externalproject-add-and-specify-the-output-folder >> >> Thanks >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake -- Luciad Email Signature *Christophe Demez * PROJECT LEADER *LUCIAD* CONNECT ? VISUALIZE ? ANALYZE ? ACT christophe.demez at luciad.com ? T +32 16 23 95 91 Follow us on LinkedIn or @LUCIADconnect Luciad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: luciad-logo.png Type: image/png Size: 2447 bytes Desc: not available URL: From MillerHenry at JohnDeere.com Thu Mar 30 11:02:18 2017 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Thu, 30 Mar 2017 15:02:18 +0000 Subject: [CMake] Building third party libraries along with normal targets In-Reply-To: References: <237bc054-7bb4-6be1-e688-36c8d37b7fbb@gmail.com> <65d8e7cb-edde-f713-b771-2477f813919c@gmail.com> Message-ID: <35F6921410093E4CA40D524BD5C18D4C30F3DD65@EDXMB89.jdnet.deere.com> I have found the following projects which all seem to do some variation of a meta build so that you can build multiple projects that depend on each other and manage dependencies. (there are a couple others that seem to not be maintained as well) https://gradle.org/ https://bazel.build/ https://github.com/LLNL/spack https://github.com/ruslo/hunter http://www.biicode.com https://conan.io/ https://conda.io/ Unfortunately I have never found anyone who has actually compared even two of these. None of the projects have good marketing: it appears they somehow solve similar problems, but none actually have defined the problem or their solution. It is like everyone assumes that everyone in the world has their exact same problem and the solution is obvious so the only thing left is the details of implementing it. This of course tells me nothing about if they handle cross compiling (not a common use case but it is yours and mine), what packages they create, what compromises they make, what they expect of my environment... These are important questions: I'm pretty sure that I could eliminate several just by comparing my needs to their features. I'm currently using an in house system that builds everything in a Docker which lets me ensure nobody is accidentally using the wrong compiler. (we cross compile for a x86 target - 90% of the time if you build with gcc for the local system everything will work just fine, the other 10% of the time our system has an imcompatible version of some library and things blow up when you try to use some uncommon feature). I'm thinking about moving to one of the above, but I haven't actually evaluated anything. If you do evaluate any of the above please document your experience and in particular what is good/bad about the things you look at. This is getting off-topic for the cmake mailing list, but I don't know where else to move the conversation. -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Dailey Sent: Wednesday, March 29, 2017 9:39 PM To: Florent Castelli Cc: CMake Subject: Re: [CMake] Building third party libraries along with normal targets On Wed, Mar 29, 2017 at 9:32 PM, Florent Castelli wrote: > On 30/03/2017 03:54, Robert Dailey wrote: >> >> On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli >> wrote: >>> >>> This is known as "super build". >>> Yes, this is exactly why I made my Boost CMake build scripts, which >>> you use unless you changed your mind today :) >> >> You mean this? >> https://github.com/Orphis/boost-cmake >> >> It's on the drawing board, for sure. It's the best solution I've >> found. It's also part of the reason I'm asking this question to begin >> with. >> >> Although, this specific method of building boost doesn't use >> superbuild, it uses normal add_subdirectory() with target. > > It doesn't "super build" its dependencies, you have to provide them > externally, but it is a possible addition. > But it is designed to be part of a super build environment and is used > as such at some large companies shipping to millions of people. > >> >>> It can be done for other projects as well. Sometimes, they even >>> provide CMake build scripts you can use directly with >>> "add_subdirectory()" so you don't have to write CMake scripts or use >>> "ExternalProject_Add()" (which isn't all great since it doesn't >>> propagate all your current project settings). >> >> Long term, I'm thinking a project like hunter[1] would be the best >> choice. The problem with hunter is that it doesn't separate concerns >> between host machine and target host. Specifically, when cross >> compiling. >> >> All the superbuild commands assume linux command syntax, simply >> because I specified a toolchain utilizing android NDK. For this >> reason it requires a lot of TLC to get working. >> >> [1]: https://github.com/ruslo/hunter > > There are those issues and also ABI changing flags that can become an > issue as they aren't always propagated from what I can see. > >>> You can use ccache or its Windows variants to make it faster. But >>> you also shouldn't need "ninja clean" most of the time. Possibly, >>> you could just clean a specific target "ninja -t clean foo". >>> If you declare all your dependencies properly, then you could just >>> always run "ninja" and the build will just be correct. >>> If your purpose is to see the compiler output again (to fix >>> warnings), it is acceptable to clean and rebuild (with ccache it >>> should be fast enough). >>> Personally, I just have a very long history in my terminal and >>> scroll back or pipe the build content to a file to look at it later. >>> Some IDEs will also record all the compilation output and make it >>> available later (Xcode does it), then it's less of an issue. >> >> Never used ccache before, what does it do? Also if even if you ninja >> -t to clean, it will also clean dependencies. So if I specify those >> in-project dependencies that actually build third party libs, those >> will be cleaned too. > > > It's a program you use to record compilation outputs and save them to > a disk cache. If you build a file again, instead of compiling it, it > will just fetch the outputs from the cache and return the same > warnings. It's usually a safe optimization in a build pipeline and is > quite easy to use with CMake and Ninja generator. > > It works well with GCC or Clang and there are some alternative > versions for the Microsoft compiler too. At the end of the day, I've solved the Boost problem but I have many other libraries I still manually build: openssl, libpng, zlib, etc. It's as you said, maintaining build scripts for all of these will be challenging but I think that's the proper way to go in my specific situation (multi platform). It'll be less maintenance than rebuilding binaries 3x per each. Do you know how to set up the boost cmake project I linked on github to work with superbuild? And do you prefer your superbuild execution to happen during cmake generate (basically cmake invokes itself for the superbuild) or do you prefer a separate external run, independent of the normal one (basically 2x cmake invocations)? Do you know of similar projects for other libraries I mentioned? Could hand write my own, but seems better to piggyback on someone else's efforts. Thanks for your feedback! -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From annulen at yandex.ru Thu Mar 30 11:41:33 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 30 Mar 2017 18:41:33 +0300 Subject: [CMake] Building third party libraries along with normal targets In-Reply-To: <35F6921410093E4CA40D524BD5C18D4C30F3DD65@EDXMB89.jdnet.deere.com> References: <237bc054-7bb4-6be1-e688-36c8d37b7fbb@gmail.com> <65d8e7cb-edde-f713-b771-2477f813919c@gmail.com> <35F6921410093E4CA40D524BD5C18D4C30F3DD65@EDXMB89.jdnet.deere.com> Message-ID: <2246091490888493@web55j.yandex.ru> 30.03.2017, 18:15, "Miller Henry" : > I have found the following projects which all seem to do some variation of a meta build so that you can build multiple projects that depend on each other and manage dependencies. (there are a couple others that seem to not be maintained as well) > > https://gradle.org/ > https://bazel.build/ > https://github.com/LLNL/spack > https://github.com/ruslo/hunter > http://www.biicode.com > https://conan.io/ > https://conda.io/ Also, https://github.com/GNOME/jhbuild (notably used by GNOME, WebKit, and X.org communities) > > Unfortunately I have never found anyone who has actually compared even two of these. None of the projects have good marketing: it appears they somehow solve similar problems, but none actually have defined the problem or their solution. It is like everyone assumes that everyone in the world has their exact same problem and the solution is obvious so the only thing left is the details of implementing it. This of course tells me nothing about if they handle cross compiling (not a common use case but it is yours and mine), what packages they create, what compromises they make, what they expect of my environment... These are important questions: I'm pretty sure that I could eliminate several just by comparing my needs to their features. > > I'm currently using an in house system that builds everything in a Docker which lets me ensure nobody is accidentally using the wrong compiler. (we cross compile for a x86 target - 90% of the time if you build with gcc for the local system everything will work just fine, the other 10% of the time our system has an imcompatible version of some library and things blow up when you try to use some uncommon feature). I'm thinking about moving to one of the above, but I haven't actually evaluated anything. > > If you do evaluate any of the above please document your experience and in particular what is good/bad about the things you look at. > > This is getting off-topic for the cmake mailing list, but I don't know where else to move the conversation. > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Robert Dailey > Sent: Wednesday, March 29, 2017 9:39 PM > To: Florent Castelli > Cc: CMake > Subject: Re: [CMake] Building third party libraries along with normal targets > > On Wed, Mar 29, 2017 at 9:32 PM, Florent Castelli wrote: >> ?On 30/03/2017 03:54, Robert Dailey wrote: >>> ?On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli >>> ? wrote: >>>> ?This is known as "super build". >>>> ?Yes, this is exactly why I made my Boost CMake build scripts, which >>>> ?you use unless you changed your mind today :) >>> >>> ?You mean this? >>> ?https://github.com/Orphis/boost-cmake >>> >>> ?It's on the drawing board, for sure. It's the best solution I've >>> ?found. It's also part of the reason I'm asking this question to begin >>> ?with. >>> >>> ?Although, this specific method of building boost doesn't use >>> ?superbuild, it uses normal add_subdirectory() with target. >> >> ?It doesn't "super build" its dependencies, you have to provide them >> ?externally, but it is a possible addition. >> ?But it is designed to be part of a super build environment and is used >> ?as such at some large companies shipping to millions of people. >> >>>> ?It can be done for other projects as well. Sometimes, they even >>>> ?provide CMake build scripts you can use directly with >>>> ?"add_subdirectory()" so you don't have to write CMake scripts or use >>>> ?"ExternalProject_Add()" (which isn't all great since it doesn't >>>> ?propagate all your current project settings). >>> >>> ?Long term, I'm thinking a project like hunter[1] would be the best >>> ?choice. The problem with hunter is that it doesn't separate concerns >>> ?between host machine and target host. Specifically, when cross >>> ?compiling. >>> >>> ?All the superbuild commands assume linux command syntax, simply >>> ?because I specified a toolchain utilizing android NDK. For this >>> ?reason it requires a lot of TLC to get working. >>> >>> ?[1]: https://github.com/ruslo/hunter >> >> ?There are those issues and also ABI changing flags that can become an >> ?issue as they aren't always propagated from what I can see. >> >>>> ?You can use ccache or its Windows variants to make it faster. But >>>> ?you also shouldn't need "ninja clean" most of the time. Possibly, >>>> ?you could just clean a specific target "ninja -t clean foo". >>>> ?If you declare all your dependencies properly, then you could just >>>> ?always run "ninja" and the build will just be correct. >>>> ?If your purpose is to see the compiler output again (to fix >>>> ?warnings), it is acceptable to clean and rebuild (with ccache it >>>> ?should be fast enough). >>>> ?Personally, I just have a very long history in my terminal and >>>> ?scroll back or pipe the build content to a file to look at it later. >>>> ?Some IDEs will also record all the compilation output and make it >>>> ?available later (Xcode does it), then it's less of an issue. >>> >>> ?Never used ccache before, what does it do? Also if even if you ninja >>> ?-t to clean, it will also clean dependencies. So if I specify those >>> ?in-project dependencies that actually build third party libs, those >>> ?will be cleaned too. >> >> ?It's a program you use to record compilation outputs and save them to >> ?a disk cache. If you build a file again, instead of compiling it, it >> ?will just fetch the outputs from the cache and return the same >> ?warnings. It's usually a safe optimization in a build pipeline and is >> ?quite easy to use with CMake and Ninja generator. >> >> ?It works well with GCC or Clang and there are some alternative >> ?versions for the Microsoft compiler too. > > At the end of the day, I've solved the Boost problem but I have many other libraries I still manually build: openssl, libpng, zlib, etc. > It's as you said, maintaining build scripts for all of these will be challenging but I think that's the proper way to go in my specific situation (multi platform). It'll be less maintenance than rebuilding binaries 3x per each. > > Do you know how to set up the boost cmake project I linked on github to work with superbuild? And do you prefer your superbuild execution to happen during cmake generate (basically cmake invokes itself for the superbuild) or do you prefer a separate external run, independent of the normal one (basically 2x cmake invocations)? > > Do you know of similar projects for other libraries I mentioned? Could hand write my own, but seems better to piggyback on someone else's efforts. > > Thanks for your feedback! > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -- Regards, Konstantin From robert.maynard at kitware.com Thu Mar 30 11:53:32 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 30 Mar 2017 11:53:32 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.8.0-rc4 now ready for testing! Message-ID: I am proud to announce the fourth CMake 3.8 release candidate. https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.8 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.8/release/3.8.html Some of the more significant changes in CMake 3.8 are: * CMake now supports "CSharp" (C#) as a first-class language. It is currently supported by the Visual Studio Generators for VS 2010 and above. * CMake now supports "CUDA" as a first-class language. It is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". CMake 3.8 Release Notes *********************** Changes made since CMake 3.7 include the following. New Features ============ Languages --------- C# ~~ * CMake learned to support "CSharp" (C#) as a first-class language that can be enabled via the "project()" and "enable_language()" commands. It is currently supported by the Visual Studio Generators for VS 2010 and above. C# assemblies and programs can be added just like common C++ targets using the "add_library()" and "add_executable()" commands. References between C# targets in the same source tree may be specified by "target_link_libraries()" like for C++. References to system or 3rd-party assemblies may be specified by the target properties "VS_DOTNET_REFERENCE_" and "VS_DOTNET_REFERENCES". * More fine tuning of C# targets may be done using target and source file properties. Specifically the target properties related to Visual Studio ("VS_*") are worth a look (for setting toolset versions, root namespaces, assembly icons, ...). CUDA ~~~~ * CMake learned to support "CUDA" as a first-class language that can be enabled via the "project()" and "enable_language()" commands. * "CUDA" is currently supported by the Makefile Generators and the "Ninja" generator on Linux, macOS, and Windows. Support for the Visual Studio IDE is under development but not included in this release. * The NVIDIA CUDA Toolkit compiler ("nvcc") is supported. C & C++ ~~~~~~~ * The "Compile Features" functionality now offers meta-features that request compiler modes for specific language standard levels (e.g. "cxx_std_11"). See "CMAKE_C_KNOWN_FEATURES" and "CMAKE_CXX_KNOWN_FEATURES". * The "Compile Features" functionality is now aware of C++ 17. No specific features are yet enumerated besides the "cxx_std_17" meta- feature. * The "Compile Features" functionality is now aware of the availability of C99 in gcc since version 3.4. Platforms --------- * A new minimal platform file for "Fuchsia" was added. Generators ---------- * The "CodeBlocks" extra generator may now be used to generate with "NMake Makefiles JOM". * The Visual Studio Generators for VS 2013 and above learned to support a "host=x64" option in the "CMAKE_GENERATOR_TOOLSET" value (e.g. via the "cmake(1)" "-T" option) to request use of a VS 64-bit toolchain on 64-bit hosts. * The Visual Studio Generators learned to treat files passed to "target_link_libraries()" whose names end in ".targets" as MSBuild "targets" files to be imported into generated project files. Commands -------- * The "add_custom_command()" and "add_custom_target()" commands learned the option "COMMAND_EXPAND_LISTS" which causes lists in the "COMMAND" argument to be expanded, including lists created by generator expressions. * The "execute_process()" command gained an "ENCODING" option to specify on Windows which encoding is used for output from child process. * The "math(EXPR)" command gained support for unary "+" and "-" operators. * The "source_group()" command gained "TREE" and "PREFIX" options to add groups following source tree directory structure. * The "string(TIMESTAMP)" command learned to treat "%%" as a way to encode plain "%". * The "string(TIMESTAMP)" command will now honor the "SOURCE_DATE_EPOCH" environment variable and use its value instead of the current time. * The "try_compile()" command source file signature gained new options to specify the language standard to use in the generated test project. * The "try_compile()" command source file signature now honors language standard variables like "CMAKE_CXX_STANDARD". See policy "CMP0067". Variables --------- * A "CMAKE_CODELITE_USE_TARGETS" variable was added to tell the "CodeLite" extra generator to change the generated project to have target-centric organization. The "build", "rebuild", and "clean" operations within "CodeLite" then work on a selected target rather than the whole workspace. (Note that the "Ninja" clean operation on a target includes its dependencies, though.) * The "CMAKE_SUBLIME_TEXT_2_ENV_SETTINGS" variable was added to tell the "Sublime Text 2" extra generator to place specified environment variables in the generated ".sublime-project". * The "CMAKE_SUBLIME_TEXT_2_EXCLUDE_BUILD_TREE" variable was added to tell the "Sublime Text 2" extra generator whether to exclude the build tree from the ".sublime-project" when it is inside the source tree. * A "CMAKE_VS_INCLUDE_PACKAGE_TO_DEFAULT_BUILD" variable was added to tell Visual Studio Generators for VS 2010 and above to include the "PACKAGE" target in the default build, similar to the existing "CMAKE_VS_INCLUDE_INSTALL_TO_DEFAULT_BUILD" variable for the "INSTALL" target. Properties ---------- * A "BUILD_RPATH" target property and corresponding "CMAKE_BUILD_RPATH" variable were added to support custom "RPATH" locations to be added to binaries in the build tree. * The "COMPILE_FLAGS" source file property learned to support "generator expressions". * The "FRAMEWORK" target property may now also be applied to static libraries on Apple targets. It will result in a proper Framework but with a static library inside. * Imported Interface Libraries learned new "IMPORTED_LIBNAME" and "IMPORTED_LIBNAME_" target properties to specify a link library name since interface libraries do not build their own library files. * A "_CPPLINT" target property and supporting "CMAKE__CPPLINT" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run the "cpplint" style checker along with the compiler for "C" and "CXX" languages. * A "MANUALLY_ADDED_DEPENDENCIES" target property has been added. It provides a read-only list of dependencies that have been added with the "add_dependencies()" command. * The "MAP_IMPORTED_CONFIG_" target property learned to interpret empty list elements as referring to the configuration-less imported location specified by "IMPORTED_LOCATION". * The "NO_SYSTEM_FROM_IMPORTED" target property is now supported on Imported Interface Libraries. * New source file properties "SKIP_AUTOMOC", "SKIP_AUTOUIC", "SKIP_AUTORCC", and "SKIP_AUTOGEN" were added to allow source files to be excluded from processing by "AUTOMOC", "AUTOUIC", and "AUTORCC" target properties. * A "VS_COPY_TO_OUT_DIR" source file property was added to tell Visual Studio Generators for VS 2010 and above whether or not a file should e copied to the output directory. * A "VS_DEBUGGER_WORKING_DIRECTORY" target property was added to tell Visual Studio Generators for VS 2010 and above what debugger working directory should be set for the target. * A "VS_DOTNET_REFERENCES_COPY_LOCAL" target property was added to specify whether to copy referenced assemblies to the output directory. * A "VS_DOTNET_REFERENCE_" target property was added to tell Visual Studio Generators for VS 2010 and above to add a .NET reference with a given hint path. * A "VS_INCLUDE_IN_VSIX" source file property was added to tell Visual Studio Generators for VS 2010 and above whether to include the file in a Visual Studio extension package. * A "VS_RESOURCE_GENERATOR" source file property was added to give Visual Studio Generators for VS 2010 and above a setting for the resource generator ("C#" only). * A "VS_USER_PROPS" target property was added to tell Visual Studio Generators for VS 2010 and above to use a custom MSBuild user ".props" file. * A "XCODE_EMIT_EFFECTIVE_PLATFORM_NAME" global property was added to tell the "Xcode" generator whether to emit the "EFFECTIVE_PLATFORM_NAME" variable. This is useful when building with multiple SDKs like "macosx" and "iphoneos" in parallel. * New "XCODE_PRODUCT_TYPE" and "XCODE_EXPLICIT_FILE_TYPE" target properties were created to tell the "Xcode" generator to use custom values of the corresponding attributes for a target in the generated Xcode project. Modules ------- * A "CSharpUtilities" module was added to aid parameterization of Visual Studio C# targets. It provides functions to allow automated setting of source file properties to support Windows Forms, WPF/XAML or other technologies as needed. * The "ExternalData" module learned to support multiple content links for one data file using different hashes, e.g. "img.png.sha256" and "img.png.sha1". This allows objects to be fetched from sources indexed by different hash algorithms. * The "ExternalProject" module gained the "GIT_PROGRESS" option to force Git to show progress when cloning repositories. * The "ExternalProject" module gained a "GIT_CONFIG" option to pass " --config" options to Git when cloning repositories. * The "FeatureSummary" module "feature_summary()" command now accepts a new "QUIET_ON_EMPTY" option that suppresses the output when the list of packages that belong to the selected category is empty. * The "FeatureSummary" module "add_feature_info()" command now accepts lists of dependencies for deciding whether a feature is enabled or not. * The package types accepted by the "FeatureSummary" module can now be tweaked by changing the "FeatureSummary_PKG_TYPES", "FeatureSummary_REQUIRED_PKG_TYPES" and "FeatureSummary_DEFAULT_PKG_TYPE" global properties. * The "FindOpenGL" module now provides imported targets "OpenGL::GL" and "OpenGL::GLU" when the libraries are found. * The "UseSWIG" module gained a "swig_add_library" command to give more flexibility over the old "swig_add_module" command. * The "UseSWIG" module "swig_add_source_to_module" command learned a new "SWIG_OUTFILE_DIR" option to control the output file location ("swig -o"). * The "WriteCompilerDetectionHeader" module gained the "ALLOW_UNKNOWN_COMPILERS" and "ALLOW_UNKNOWN_COMPILER_VERSIONS" options that allow creation of headers that will work also with unknown or old compilers by simply assuming they do not support any of the requested features. CTest ----- * The "ctest_memcheck()" command gained a "DEFECT_COUNT " option to capture the number of memory defects detected. * The "ctest_memcheck()" command learned to read the location of suppressions files for sanitizers from the "CTEST_MEMORYCHECK_SUPPRESSIONS_FILE" variable. * The "ctest_memcheck()" command learned to support "LeakSanitizer" independently from "AddressSanitizer". * The "ctest_update()" command "CDASH_UPLOAD" signature was taught to honor the "RETRY_COUNT", "RETRY_DELAY", and "QUIET" options. CPack ----- * The "CPackIFWConfigureFile" module was added to define a new "cpack_ifw_configure_file()" command to configure file templates prepared in QtIFW/SDK/Creator style. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands gained a new "DEFAULT", "VIRTUAL", "FORCED_INSTALLATION", "REQUIRES_ADMIN_RIGHTS", "DISPLAY_NAME", "UPDATE_TEXT", "DESCRIPTION", "RELEASE_DATE", "AUTO_DEPEND_ON" and "TRANSLATIONS" options to more specific configuration. * The "CPackIFW" module "cpack_ifw_configure_component()" command gained a new "DEPENDENCIES" alias for "DEPENDS" option. * The "CPackIFW" module "cpack_ifw_configure_component_group()" command gained a new "DEPENDS" option. The "DEPENDENCIES" alias also added. * The "CPackIFW" module "cpack_ifw_configure_component()" and "cpack_ifw_configure_component_group()" commands "PRIORITY" option now is deprecated and will be removed in a future version of CMake. Please use new "SORTING_PRIORITY" option instead. * The "CPackIFW" module gained new "CPACK_IFW_PACKAGE_WATERMARK", "CPACK_IFW_PACKAGE_BANNER", "CPACK_IFW_PACKAGE_BACKGROUND", "CPACK_IFW_PACKAGE_WIZARD_STYLE", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_WIDTH", "CPACK_IFW_PACKAGE_WIZARD_DEFAULT_HEIGHT", and "CPACK_IFW_PACKAGE_TITLE_COLOR" variables to customize a QtIFW installer look. * The "CPackProductBuild" module gained options to sign packages. See the variables "CPACK_PRODUCTBUILD_IDENTITY_NAME", "CPACK_PRODUCTBUILD_KEYCHAIN_PATH", "CPACK_PKGBUILD_IDENTITY_NAME", and "CPACK_PKGBUILD_KEYCHAIN_PATH". * The "CPackRPM" module learned to omit tags that are not supported by provided "rpmbuild" tool. If unsupported tags are set they are ignored and a developer warning is printed out. * The "CPackRPM" module learned to generate main component package which forces generation of a rpm for defined component without component suffix in filename and package name. See "CPACK_RPM_MAIN_COMPONENT" variable. * The "CPackRPM" module learned to generate a single "debuginfo" package on demand even if components packaging is used. See "CPACK_RPM_DEBUGINFO_SINGLE_PACKAGE" variable. * The "CPackRPM" module learned to support multiple directives per file when using "CPACK_RPM_USER_FILELIST" variable. Other ----- * CMake functionality using cryptographic hashes now supports SHA-3 algorithms. * A new generator expression "$" was added. It resolves to the true-value if the condition is "1" and resolves to the false-value if the condition is "0". Deprecated and Removed Features =============================== * The "FeatureSummary" module commands "set_package_info()", "set_feature_info()", "print_enabled_features()", and "print_disabled_features()" are now deprecated. * The "UseSWIG" module "swig_add_module" command is now deprecated in favor of "swig_add_library". Other Changes ============= * If a command specified by the "_CLANG_TIDY" target property returns non-zero at build time this is now treated as an error instead of silently ignored. * The "ctest_memcheck()" command no longer automatically adds "leak_check=1" to the options used by "AddressSanitizer". The default behavior of "AddressSanitizer" is to run *LeakSanitizer* to check leaks unless "leak_check=0". * The "ctest_memcheck()" command was fixed to correctly append extra sanitizer options read from the "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable to the environment variables used internally by the sanitizers. * The "FeatureSummary" module "set_package_properties()" command no longer forces the package type to "OPTIONAL" when the type is not explicitly set. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 17.0 on UNIX and Windows platforms. * Calls to the "FindPkgConfig" module "pkg_check_modules()" command following a successful call learned to re-evaluate the cached values for a given prefix after changes to the parameters to the command for that prefix. * When using "AUTOMOC" or "AUTOUIC", generated "moc_*", "*.moc" and "ui_*" are placed in the "/_autogen/include" directory which is automatically added to the target's "INCLUDE_DIRECTORIES". It is therefore not necessary anymore to have "CMAKE_CURRENT_BINARY_DIR" in the target's "INCLUDE_DIRECTORIES". * The "Sublime Text 2" generator no longer runs the native build command (e.g. "ninja" or "make") with verbose build output enabled. * The "try_compile()" command source file signature now honors the "CMAKE_WARN_DEPRECATED" variable value in the generated test project. * The Visual Studio Generators for VS 2010 and above now place per- source file flags after target-wide flags when they are classified as raw flags with no project file setting ("AdditionalOptions"). This behavior is more consistent with the ordering of flags produced by other generators, and allows flags on more-specific properties (per-source) to override those on more general ones (per-target). * The precompiled Windows binary MSI package provided on "cmake.org" now records the installation directory in the Windows Registry under the key "HKLM\Software\Kitware\CMake" with a value named "InstallDir". ---------------------------------------------------------------------------- Changes made since CMake 3.8.0-rc3: Brad King (11): InstallRequiredSystemLibraries: Split VS 2017 search paths Add undocumented CMake language means to find VS 2017 InstallRequiredSystemLibraries: Find VS 2017 redist directory libarchive: backport zip directory recognition fix cmIDEOptions: Add GetDefines method cmVisualStudio10TargetGenerator: De-duplicate preprocessor defs VS: Honor preprocessor definitions in RC flags RC: Add missing CMAKE_RC_FLAGS_ entries to cache MSVC: Restore _DEBUG preprocessor definition in RC debug builds SDCC: Fix identification of current sdcc compiler CMake 3.8.0-rc4 Christian Pfeiffer (1): Ninja: Fix command line limit when sysconf has no ARG_MAX Domen Vrankar (2): CPack/RPM can now generate a single debuginfo package CPack/RPM tests: handle build-id links Gregor Jasny (2): Swift: Default to Swift 3.0 with Xcode 8.3 and later Swift: Simplify mixed test case to make it version agnostic Roger Leigh (1): FindBoost: Update 1.64 dependencies using 1.64 beta1 From dflogeras2 at gmail.com Thu Mar 30 11:59:58 2017 From: dflogeras2 at gmail.com (Dave Flogeras) Date: Thu, 30 Mar 2017 12:59:58 -0300 Subject: [CMake] FindThreads and toolchains Message-ID: I am using CMake 3.7.2 and playing around with the FindThread finder. The following simple CMakeLists.txt works fine on various compilers: GCC, clang, MSVC (tried 2013 and 2015). CMAKE_MINIMUM_REQUIRED( VERSION 3.1 ) ADD_EXECUTABLE( mythread main.cpp ) SET( THREADS_PREFER_PTHREAD_FLAG TRUE ) FIND_PACKAGE( Threads REQUIRED ) TARGET_LINK_LIBRARIES( thread Threads::Threads ) TARGET_COMPILE_OPTIONS( thread INTERFACE Threads::Threads ) However, when I attempt to cross-compile for ARM with "cmake -DCMAKE_TOOLCHAIN_FILE=blah ..", I get the following: -- The C compiler identification is GNU 4.9.4 -- The CXX compiler identification is GNU 4.9.4 -- Check for working C compiler: /usr/bin/armv6j-hardfloat-linux-gnueabi-gcc-4.9.4 -- Check for working C compiler: /usr/bin/armv6j-hardfloat-linux-gnueabi-gcc-4.9.4 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/armv6j-hardfloat-linux-gnueabi-g++-4.9.4 -- Check for working CXX compiler: /usr/bin/armv6j-hardfloat-linux-gnueabi-g++-4.9.4 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Looking for pthread.h -- Looking for pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found -- Check if compiler accepts -pthread CMake Error: TRY_RUN() invoked in cross-compiling mode, please set the following cache variables appropriately: THREADS_PTHREAD_ARG (advanced) For details see /tmp/thread/build/TryRunResults.cmake -- Check if compiler accepts -pthread - no -- Found Threads: TRUE -- Configuring incomplete, errors occurred! See also "/tmp/thread/build/CMakeFiles/CMakeOutput.log". See also "/tmp/thread/build/CMakeFiles/CMakeError.log". I can verify that the compiler does indeed accept -pthread, and IIRC might require it for pthreads to work. I can see from the CMakeError.log that it might be forgetting to specify -lpthread when trying to compile the test: Run Build Command:"/usr/bin/gmake" "cmTC_13694/fast" /usr/bin/gmake -f CMakeFiles/cmTC_13694.dir/build.make CMakeFiles/cmTC_13694.dir/build gmake[1]: Entering directory '/tmp/thread/build/CMakeFiles/CMakeTmp' Building C object CMakeFiles/cmTC_13694.dir/CheckSymbolExists.c.o /usr/bin/armv6j-hardfloat-linux-gnueabi-gcc-4.9.4 --sysroot=/mnt/data/chroots/pie/ -o CMakeFiles/cmTC_13694.dir/CheckSymbolExists.c.o -c /tmp/thread/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c Linking C executable cmTC_13694 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_13694.dir/link.txt --verbose=1 /usr/bin/armv6j-hardfloat-linux-gnueabi-gcc-4.9.4 --sysroot=/mnt/data/chroots/pie/ CMakeFiles/cmTC_13694.dir/CheckSymbolExists.c.o -o cmTC_13694 -rdynamic CMakeFiles/cmTC_13694.dir/CheckSymbolExists.c.o: In function `main': CheckSymbolExists.c:(.text+0x38): undefined reference to `pthread_create' collect2: error: ld returned 1 exit status gmake[1]: *** [CMakeFiles/cmTC_13694.dir/build.make:98: cmTC_13694] Error 1 gmake[1]: Leaving directory '/tmp/thread/build/CMakeFiles/CMakeTmp' gmake: *** [Makefile:126: cmTC_13694/fast] Error 2 File /tmp/thread/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c: /* */ #include int main(int argc, char** argv) { (void)argv; #ifndef pthread_create return ((int*)(&pthread_create))[argc]; #else (void)argc; return 0; #endif } Is this a bug? Or am I not using the find correctly? -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at mcfuller.com Thu Mar 30 15:01:26 2017 From: thomas at mcfuller.com (Thomas Fuller) Date: Thu, 30 Mar 2017 19:01:26 +0000 Subject: [CMake] Creating List file outputs from each source file Message-ID: Hi, I hope this is a simple question and I'm just missing something fundamental. I'm trying to emulate a binary build manager for an embedded Cortex-M0 target using a CMake project. I'm having some trouble figuring out how to generate list files for each dependency of my executable target. The current build system, when compiling a file called main.c passes -Wa,-alh=.\CortexM0\ARM_GCC_493\Debug/main.lst as an argument to gcc. I'd like to do something similar, but I can't figure out how to get CMake to use the current filename being compiled to save the file. I've looked at the get_filename_component command, but it appears only to get the filename of the output: add_executable(TestExe main.c) get_filename_component(curr_name TestExe NAME_WM) message(${curr_name}) As expected, this prints TestExe instead of the hoped for main Is there a simple variable I'm overlooking that I could put in my toolchain file's CMAKE_C_FLAGS like -Wa,-alh=${CURR_SOURCE}.lst? Or some other method that I'm not seeing? System info: - Windows 10 - Msys shell - CMake 3.7.2 - arm-none-eabi-gcc v4.9.3 -Thomas Fuller -------------- next part -------------- An HTML attachment was scrubbed... URL: From elizabeth.fischer at columbia.edu Thu Mar 30 22:23:40 2017 From: elizabeth.fischer at columbia.edu (Elizabeth A. Fischer) Date: Thu, 30 Mar 2017 22:23:40 -0400 Subject: [CMake] Building third party libraries along with normal targets In-Reply-To: <35F6921410093E4CA40D524BD5C18D4C30F3DD65@EDXMB89.jdnet.deere.com> References: <237bc054-7bb4-6be1-e688-36c8d37b7fbb@gmail.com> <65d8e7cb-edde-f713-b771-2477f813919c@gmail.com> <35F6921410093E4CA40D524BD5C18D4C30F3DD65@EDXMB89.jdnet.deere.com> Message-ID: Miller, Thank you for your input; I'm hoping we can use it to improve our description of Spack at http://spack.io . I'm cross-posting to the Spack list, maybe someone there can add to this. https://github.com/LLNL/spack/issues/2115 There has been talk of a comparison; but I'm not familiar enough with the other systems to talk about them. I can/will say a bit about Spack. > but none actually have defined the problem or their solution. Spack is aimed at people involved in scientific computing. This is more a social distinction than technical: there is nothing particularly special about scientific software environments, and I know of corporate environments that are considering Spack as well. However, this intended audience does drive the design in some ways. 1. As with Macports, Homebrew, Gentoo, etc. Spack is focused on building things from source. There has been some work on packing up Spack builds as RPMs so they can be quickly installed across multiple machines. 2. Spack supports cross-compilers. Cross compilation is an intrinsic part of some supercomputers, in which the login nodes are a different architecture from the nodes the software runs on. Maybe a Spacker who has done cross-compiling can speak up here... 3. Spack supports multiple versions of installed packages --- where the "version" is actually a hash of the package version, plus the version of all its dependencies. Central to Spack is the "concretization" algorithm, which chooses which version of each package to build for you, based on the constraints you give it. For example, you could build 24 versions of NetCDF, based on different compilers and MPI options you choose. This kind of flexibility is incredibly useful in a scientific environment, where different top-level applications require different versions of various underlying dependencies. AFAIK, this concretization algorithm unique among auto-builders; and it deserves some time to think about (look at the Powerpoint presentations on the Spack page). More common are builders (eg, those used for Linux distros) that produce a *single* version of each desired package --- and you have to manually specify the version of each package you want. This is the step that Spack does automatically for you. > what packages they create, Spack now has over 1000 packages it knows how to build: https://github.com/LLNL/spack/tree/develop/var/spack/repos/builtin/packages NOTE: Be careful when comparing how many packages an auto-builder can create. Some package managers, for example, have a different "package" for each version that might be installed. For example, *netcdf-1.0*, *netcdf-1.1*, *netcdf-1.2*, etc. In Spack, each "package" corresponds to an upstream piece of software (i.e. just *netcdf)*, and Spack knows how to install potentially many versions and variants of it*.* > what compromises they make, > what they expect of my environment... Just Python 2.6 or 2.7: do a "git clone", then run, starting up is very easy. Spack needs other basic tools as well (*git*, *curl*, etc.). On newer systems, they "just work"; on older systems, Spack can be used to install them. limitations 1. Spack currently runs on Linux + MacOS, not Windows. 2. Spack doesn't really know how to work with sub-package managers: eg, using Spack to install `pip`, and then using `pip` to install things. Same thing for `luarocks`, `conda`, `node-js`, etc. Spack *can* install these things, just don't expect great integration. We've thought a lot about how to integrate well, and haven't come up with any home run ideas. The issue is most significant with *node-js* when a Spack package wants to depend on a bunch of Javascript packages. 3. Spack's concretization algorithm, while still much faster than a human, is too slow to conveniently use for software stacks of greater than ~100 packages. This also makes it less than ideal for the Javascript world, where packages are small and numerous. > the other 10% of the time our system has an imcompatible version of some > library and things blow up when you try to use some uncommon feature). Spack goes to great lengths to build all dependencies itself, and not "accidentally" depend on system-supplied software. This is getting off-topic for the cmake mailing list, but I don't know > where else to move the conversation. > Feel free to join the Spack mailing list (CC'd above). -- Elizabeth -------------- next part -------------- An HTML attachment was scrubbed... URL: From kipade at 163.com Thu Mar 30 22:41:58 2017 From: kipade at 163.com (kipade) Date: Fri, 31 Mar 2017 10:41:58 +0800 (CST) Subject: [CMake] How to exclude some files from building? Message-ID: <88e098e.43ec.15b223dab07.Coremail.kipade@163.com> There are some files I do not want to build if the specified condition was ture. For example, for testing, I want build a new file witch include a main entry just for testing; if not, a new file would be compile for normal task. I do not want to write two main entries in the same file just using macros to control compiling. I want to use different clean and simple files. So, how to do it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkook11 at gmail.com Fri Mar 31 01:46:07 2017 From: tkook11 at gmail.com (=?UTF-8?B?44Km44Or44Ow?=) Date: Fri, 31 Mar 2017 01:46:07 -0400 Subject: [CMake] Linker error when building 3.8.0-rc4 on Linux Message-ID: Trying to build CMake 3.8.0-rc4 from source on Ubuntu 16.10 gives the following output: $ make [ 2%] Built target cmsys [ 3%] Built target cmsysTestDynload [ 4%] Built target cmsys_c [ 4%] Built target cmsysTestProcess [ 4%] Built target cmsysTestSharedForward [ 5%] Built target cmsysTestsC [ 6%] Built target cmsysTestsCxx [ 6%] Built target testConsoleBufChild [ 7%] Built target kwiml_test [ 8%] Built target cmlibrhash [ 9%] Built target cmzlib [ 24%] Built target cmcurl [ 24%] Built target LIBCURL [ 24%] Built target cmcompress [ 24%] Built target cmexpat [ 25%] Built target cmbzip2 [ 33%] Built target cmliblzma [ 46%] Built target cmlibarchive [ 47%] Built target cmjsoncpp [ 50%] Built target cmlibuv [ 55%] Built target cmForm [ 83%] Built target CMakeLib [ 84%] Built target CMakeServerLib [ 86%] Built target CPackLib [ 92%] Built target CTestLib [ 92%] Linking CXX executable ../bin/ccmake ../Utilities/cmlibarchive/libarchive/libcmlibarchive.a(archive_hmac.c.o): In function `__hmac_sha1_init': archive_hmac.c:(.text+0x25): undefined reference to `HMAC_CTX_new' ../Utilities/cmlibarchive/libarchive/libcmlibarchive.a(archive_hmac.c.o): In function `__hmac_sha1_cleanup': archive_hmac.c:(.text+0x12d): undefined reference to `HMAC_CTX_free' collect2: error: ld returned 1 exit status Source/CMakeFiles/ccmake.dir/build.make:422: recipe for target 'bin/ccmake' failed make[2]: *** [bin/ccmake] Error 1 CMakeFiles/Makefile2:2314: recipe for target 'Source/CMakeFiles/ccmake.dir/all' failed make[1]: *** [Source/CMakeFiles/ccmake.dir/all] Error 2 Makefile:162: recipe for target 'all' failed make: *** [all] Error 2 Is this a bug with the build configuration or have I forgotten to do something I need to do? Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From tkook11 at gmail.com Fri Mar 31 01:55:36 2017 From: tkook11 at gmail.com (=?UTF-8?B?44Km44Or44Ow?=) Date: Fri, 31 Mar 2017 01:55:36 -0400 Subject: [CMake] Linker error when building 3.8.0-rc4 on Linux In-Reply-To: References: Message-ID: Can confirm that this happens with the latest source from Github as well. From domen.vrankar at gmail.com Fri Mar 31 02:10:12 2017 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Fri, 31 Mar 2017 08:10:12 +0200 Subject: [CMake] How to exclude some files from building? In-Reply-To: <88e098e.43ec.15b223dab07.Coremail.kipade@163.com> References: <88e098e.43ec.15b223dab07.Coremail.kipade@163.com> Message-ID: 2017-03-31 4:41 GMT+02:00 kipade : > There are some files I do not want to build if the specified condition was > ture. > For example, for testing, I want build a new file witch include a main > entry just > for testing; if not, a new file would be compile for normal task. > I do not want to write two main entries in the same file just using macros > to > control compiling. I want to use different clean and simple files. > So, how to do it? > You can either use generator expressions: ------------------------- cmake_minimum_required(VERSION 3.5) project(dependent CXX) set(MY_DEPEND "ON" CACHE BOOL "toggle feature") add_executable( ${PROJECT_NAME} main.cpp $<$:first/a.cpp> $<$>:second/a.cpp> ) target_include_directories( ${PROJECT_NAME} PRIVATE "${CMAKE_CURRENT_SOURCE_DIR}" ) ------------------------- Or add files to a variable: ------------------------- cmake_minimum_required(VERSION 3.5) project(dependent CXX) set(MY_DEPEND "ON" CACHE BOOL "toggle feature") if(MY_DEPEND) set(extra_src_ "first/a.cpp") else() set(extra_src_ "second/a.cpp") endif() add_executable( ${PROJECT_NAME} main.cpp ${extra_src_} ) target_include_directories( ${PROJECT_NAME} PRIVATE "${CMAKE_CURRENT_SOURCE_DIR}" ) ------------------------- Regards, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Fri Mar 31 02:28:43 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 31 Mar 2017 08:28:43 +0200 Subject: [CMake] Linker error when building 3.8.0-rc4 on Linux In-Reply-To: References: Message-ID: <25a8f375-3846-bcf7-383e-0ca9b18d4481@gmail.com> On 03/31/2017 07:46 AM, ??? wrote: > ../Utilities/cmlibarchive/libarchive/libcmlibarchive.a(archive_hmac.c.o): > In function `__hmac_sha1_init': > archive_hmac.c:(.text+0x25): undefined reference to `HMAC_CTX_new' > ../Utilities/cmlibarchive/libarchive/libcmlibarchive.a(archive_hmac.c.o): > In function `__hmac_sha1_cleanup': > archive_hmac.c:(.text+0x12d): undefined reference to `HMAC_CTX_free' > collect2: error: ld returned 1 exit status > Source/CMakeFiles/ccmake.dir/build.make:422: recipe for target > 'bin/ccmake' failed > make[2]: *** [bin/ccmake] Error 1 > CMakeFiles/Makefile2:2314: recipe for target > 'Source/CMakeFiles/ccmake.dir/all' failed > make[1]: *** [Source/CMakeFiles/ccmake.dir/all] Error 2 > Makefile:162: recipe for target 'all' failed > make: *** [all] Error 2 > > Is this a bug with the build configuration or have I forgotten to do > something I need to do? According to the OpenSSL documentation HMAC_CTX_new() and HMAC_CTX_free() were introduced in 1.1.0. Presumably your OpenSSL version is older than that and disabling OpenSSL (presuming you don't need it) or building against a newer version should help. To disable OpenSSL e.g. "cmake ... -DCMAKE_USE_OPENSSL=false" or "bootstrap ... -- -DCMAKE_USE_OPENSSL=false". To point CMake at a custom OpenSSL installation instead setting the CMAKE_PREFIX_PATH environment to the installation should work. Nils From tkook11 at gmail.com Fri Mar 31 03:04:27 2017 From: tkook11 at gmail.com (=?UTF-8?B?44Km44Or44Ow?=) Date: Fri, 31 Mar 2017 03:04:27 -0400 Subject: [CMake] Linker error when building 3.8.0-rc4 on Linux In-Reply-To: <25a8f375-3846-bcf7-383e-0ca9b18d4481@gmail.com> References: <25a8f375-3846-bcf7-383e-0ca9b18d4481@gmail.com> Message-ID: > To disable OpenSSL e.g. "cmake ... -DCMAKE_USE_OPENSSL=false" or "bootstrap > ... -- -DCMAKE_USE_OPENSSL=false". What would be the ramifications of building CMake without OpenSSL? From nilsgladitz at gmail.com Fri Mar 31 03:12:41 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 31 Mar 2017 09:12:41 +0200 Subject: [CMake] Linker error when building 3.8.0-rc4 on Linux In-Reply-To: References: <25a8f375-3846-bcf7-383e-0ca9b18d4481@gmail.com> Message-ID: <16b258a8-a74b-c6db-1538-f2b33251900d@gmail.com> On 03/31/2017 09:04 AM, ??? wrote: >> To disable OpenSSL e.g. "cmake ... -DCMAKE_USE_OPENSSL=false" or "bootstrap >> ... -- -DCMAKE_USE_OPENSSL=false". > What would be the ramifications of building CMake without OpenSSL? As far as I am aware it would mean no "https://" support in curl which would mean no "https://" support in e.g. file(DOWNLOAD) and CTest submissions. Nils From kipade at 163.com Fri Mar 31 04:00:48 2017 From: kipade at 163.com (kipade) Date: Fri, 31 Mar 2017 16:00:48 +0800 (CST) Subject: [CMake] How to exclude some files from building? In-Reply-To: References: <88e098e.43ec.15b223dab07.Coremail.kipade@163.com> Message-ID: <5e775f40.9e58.15b23619300.Coremail.kipade@163.com> Oh, I got it. I think the first method was so cool. Thank you very much. At 2017-03-31 14:10:12, "Domen Vrankar" wrote: 2017-03-31 4:41 GMT+02:00 kipade : There are some files I do not want to build if the specified condition was ture. For example, for testing, I want build a new file witch include a main entry just for testing; if not, a new file would be compile for normal task. I do not want to write two main entries in the same file just using macros to control compiling. I want to use different clean and simple files. So, how to do it? You can either use generator expressions: ------------------------- cmake_minimum_required(VERSION 3.5) project(dependent CXX) set(MY_DEPEND "ON" CACHE BOOL "toggle feature") add_executable( ${PROJECT_NAME} main.cpp $<$:first/a.cpp> $<$>:second/a.cpp> ) target_include_directories( ${PROJECT_NAME} PRIVATE "${CMAKE_CURRENT_SOURCE_DIR}" ) ------------------------- Or add files to a variable: ------------------------- cmake_minimum_required(VERSION 3.5) project(dependent CXX) set(MY_DEPEND "ON" CACHE BOOL "toggle feature") if(MY_DEPEND) set(extra_src_ "first/a.cpp") else() set(extra_src_ "second/a.cpp") endif() add_executable( ${PROJECT_NAME} main.cpp ${extra_src_} ) target_include_directories( ${PROJECT_NAME} PRIVATE "${CMAKE_CURRENT_SOURCE_DIR}" ) ------------------------- Regards, Domen -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe.demez at luciad.com Fri Mar 31 04:59:18 2017 From: christophe.demez at luciad.com (Christophe Demez) Date: Fri, 31 Mar 2017 10:59:18 +0200 Subject: [CMake] ExternalProject_Add ... output directy (sln file directory) In-Reply-To: <91b8100c-2caf-6c29-46de-2a7b506b2b9f@luciad.com> References: <91b8100c-2caf-6c29-46de-2a7b506b2b9f@luciad.com> Message-ID: Also, I have try with a sample, just a main and a lib. But it seems that the lib CMakeLists.txt file is not called ! The project is created, but it does not point to the source code by example and the "message" are not displayed in the console too ! The download link : https://www.dropbox.com/s/eto84gwtw2rx8oe/CMakeTest.zip?dl=0 On 30/03/2017 17:11, Christophe Demez wrote: > > BTW, > > I notice this too, if I use the following command line with an empty > cmakelists.txt file : cmake -G "Visual Studio 15 2017 Win64" > > And it also generate the .sln (and other files) in the same folder, > but I don't request to build such a solution ! right ? > > In reality, I only need a cmakelists.txt file that will build an > external library for Android (Ninja generator, directly from > AndroidStudio). > For now I use the wrong generator for test. > > > On 30/03/2017 16:20, David Cole wrote: >> Do give it a BINARY_DIR, but do NOT give it a BUILD_COMMAND. Giving it >> an empty BUILD_COMMAND means "do nothing" for the build step and using >> "cmake --build ./LibraryBuild" does not work unless cmake is in your >> PATH, and with a Visual Studio solution, you also need to specify >> "--config Release" or "--config Debug" >> >> Also posted on SO. >> >> >> HTH, >> David C. >> >> >> >> On Thu, Mar 30, 2017 at 10:10 AM, Christophe Demez >> wrote: >>> Hi, >>> >>> I'm currently using one CMakeLists.txt file that will execute an external >>> CMakeLists.txt (and dependency). >>> >>> For this I use the ExternalProject_Add command, but I can't find a way to >>> specify where the ".sln" file will be generated. >>> >>> I have also created StackOverflow question here with more information, if >>> someone have an idea for a solution ? >>> >>> http://stackoverflow.com/questions/43117117/cmake-use-externalproject-add-and-specify-the-output-folder >>> >>> Thanks >>> -- >>> >>> Powered bywww.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >>> http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For more >>> information on each offering, please visit: >>> >>> CMake Support:http://cmake.org/cmake/help/support.html >>> CMake Consulting:http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses:http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake > > -- > Luciad Email Signature *Christophe Demez * > PROJECT LEADER > > *LUCIAD* CONNECT ? VISUALIZE ? ANALYZE ? ACT > > christophe.demez at luciad.com ? T > +32 16 23 95 91 > Follow us on LinkedIn or > @LUCIADconnect > > Luciad > > -- Luciad Email Signature *Christophe Demez * PROJECT LEADER *LUCIAD* CONNECT ? VISUALIZE ? ANALYZE ? ACT christophe.demez at luciad.com ? T +32 16 23 95 91 Follow us on LinkedIn or @LUCIADconnect Luciad -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2447 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: luciad-logo.png Type: image/png Size: 2447 bytes Desc: not available URL: From irwin at beluga.phys.uvic.ca Fri Mar 31 05:54:48 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 31 Mar 2017 02:54:48 -0700 (PDT) Subject: [CMake] Linker error when building 3.8.0-rc4 on Linux In-Reply-To: <16b258a8-a74b-c6db-1538-f2b33251900d@gmail.com> References: <25a8f375-3846-bcf7-383e-0ca9b18d4481@gmail.com> <16b258a8-a74b-c6db-1538-f2b33251900d@gmail.com> Message-ID: On 2017-03-31 09:12+0200 Nils Gladitz wrote: > On 03/31/2017 09:04 AM, ??? wrote: > >>> To disable OpenSSL e.g. "cmake ... -DCMAKE_USE_OPENSSL=false" or >>> "bootstrap >>> ... -- -DCMAKE_USE_OPENSSL=false". >> What would be the ramifications of building CMake without OpenSSL? > > As far as I am aware it would mean no "https://" support in curl which would > mean no "https://" support in e.g. file(DOWNLOAD) and CTest submissions. Hi Nils: And use of ExternalProject_Add, etc. In other words, this is a pretty crippling restriction for users with Linux distributions (such as the quite recent Ubuntu 2016.10 of the original poster) that do not yet give access to libssl version 1.1.0 (the oldest version of libssl where HMAC_CTX_new() and HMAC_CTX_free() are available according to your previous post). @ The original poster, ??? (whose real name I do not know because he obviously did not use the normal UTF-8 encoding for his mail address name): I suggest you try the experiment of using the system version of libcurl instead (which also supplies SSL capability). For example, my Linux distribution is Debian Stable which only installs libssl 1.0.1. And for that case when I tried the bootstrap method with the --system-curl option (the usual way I build cmake), I do not confirm your linking issue. So my expectation is you will also avoid that linking issue on Ubuntu 2016.10 if you use that bootstrap option or a similar system libcurl option for the non-bootstrap case. @Nils: Even if the original poster finds the suggested workaround (of using the system version of libcurl rather than system version of libopenssl) works to provide key CMake SSL functionality, on general principles (because Linux distribution support for libssl version 1.1.0 is obviously not widespread at the current time), I would strongly suggest CMake developers drop use of HMAC_CTX_new() and HMAC_CTX_free() throughout CMake for the final version of CMake-3.8.0. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From nilsgladitz at gmail.com Fri Mar 31 08:00:34 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 31 Mar 2017 14:00:34 +0200 Subject: [CMake] Linker error when building 3.8.0-rc4 on Linux In-Reply-To: References: <25a8f375-3846-bcf7-383e-0ca9b18d4481@gmail.com> <16b258a8-a74b-c6db-1538-f2b33251900d@gmail.com> Message-ID: <293eb338-1b50-4913-085d-821cfb236a70@gmail.com> On 03/31/2017 11:54 AM, Alan W. Irwin wrote: > Hi Nils: > > And use of ExternalProject_Add, etc. In other words, this is a pretty > crippling restriction for users with Linux distributions (such as the > quite recent Ubuntu 2016.10 of the original poster) that do not yet > give access to libssl version 1.1.0 (the oldest version of libssl > where HMAC_CTX_new() and HMAC_CTX_free() are available according to > your previous post). Strangely enough I have no issue on Ubuntu 16.04 with the system default installation of OpenSSL. What I missed in the original post is that the error comes from libarchive rather than libcurl. But libarchive itself also seems to provide inline definitions of the missing functions in Utilities/cmlibarchive/libarchive/archive_openssl_hmac_private.h for OpenSSL < 1.1. I can't tell why the inline definitions aren't used on the original posters system. Perhaps there is a mismatch between OpenSSL headers and libraries? Nils From tamas.kenez at gmail.com Fri Mar 31 08:14:04 2017 From: tamas.kenez at gmail.com (=?UTF-8?B?VGFtw6FzIEtlbsOpeg==?=) Date: Fri, 31 Mar 2017 14:14:04 +0200 Subject: [CMake] Building third party libraries along with normal targets In-Reply-To: References: <237bc054-7bb4-6be1-e688-36c8d37b7fbb@gmail.com> <65d8e7cb-edde-f713-b771-2477f813919c@gmail.com> Message-ID: [about shell script portability] We do use shell-scripts on Windows since git-bash comes with git for free. Our workflow is centered around the command-line (git-bash for Windows) and you can run shell scripts in git-bash, that's why compatibility is not a problem. All our scripts and workflows are the same on all our platforms (windows, linux, mac). This is an issue only if you're not using git on Windows so adding git-bash to the workflow would be an extra hassle. On Thu, Mar 30, 2017 at 3:45 PM, Robert Dailey wrote: > On Thu, Mar 30, 2017 at 3:42 AM, Tam?s Ken?z > wrote: > > An alternative to the CMake superbuild: leave your actual project intact. > > Simply create a separate shell script which builds all the dependencies > (by > > running cmake commands). Or, if you do like the ExternalProject stuff, > > create a superbuild which builds only the dependencies. > > Problem with that is that it's not a portable solution. The #1 benefit > of using CMake superbuilds (supplied with CMake build solution for the > target library) is that it will function correctly on all platforms. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Fri Mar 31 16:44:15 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Fri, 31 Mar 2017 13:44:15 -0700 (PDT) Subject: [CMake] Linker error when building 3.8.0-rc4 on Linux In-Reply-To: <293eb338-1b50-4913-085d-821cfb236a70@gmail.com> References: <25a8f375-3846-bcf7-383e-0ca9b18d4481@gmail.com> <16b258a8-a74b-c6db-1538-f2b33251900d@gmail.com> <293eb338-1b50-4913-085d-821cfb236a70@gmail.com> Message-ID: On 2017-03-31 14:00+0200 Nils Gladitz wrote: > On 03/31/2017 11:54 AM, Alan W. Irwin wrote: > >> Hi Nils: >> >> And use of ExternalProject_Add, etc. In other words, this is a pretty >> crippling restriction for users with Linux distributions (such as the >> quite recent Ubuntu 2016.10 of the original poster) that do not yet >> give access to libssl version 1.1.0 (the oldest version of libssl >> where HMAC_CTX_new() and HMAC_CTX_free() are available according to >> your previous post). > > Strangely enough I have no issue on Ubuntu 16.04 with the system default > installation of OpenSSL. > > What I missed in the original post is that the error comes from libarchive > rather than libcurl. > But libarchive itself also seems to provide inline definitions of the missing > functions in Utilities/cmlibarchive/libarchive/archive_openssl_hmac_private.h > for OpenSSL < 1.1. > > I can't tell why the inline definitions aren't used on the original posters > system. > Perhaps there is a mismatch between OpenSSL headers and libraries? Hi Nils: Strictly from what you have said (since my result bypassed OpenSSL completely by using libcurl for SSL functionality), it appears to me that CMake (or libarchive?) developers have attempted to adjust for the case where OpenSSL < 1.1, and that adjustment works for you with Ubuntu 16.04, but does not work for the O.P. with Ubuntu 16.10. Ultimately, of course, it is strictly up to the CMake developers how carefully they respond to reports of OpenSSL issues, but from my perspective CMake SSL functionality is important because of the widely used ExternalProject module that depends on that functionality. Therefore, from the sidelines I am encouraging you guys to be extraordinarily careful about this particular issue; e.g., by attempting to to confirm this CMake-3.8.0-rc4 issue independently for Ubuntu 16.10. Further to such confirmation does the CMake dashboard already test system OpenSSL for the Ubuntu 16.10 case or does one of the CMake developers have ready access to a Ubuntu 16.10 system so they can attempt to confirm the issue? That is the end of my ideas for helping you to debug this issue so I am likely bowing out of further discussion in this thread. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ From nilsgladitz at gmail.com Fri Mar 31 17:02:00 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 31 Mar 2017 23:02:00 +0200 Subject: [CMake] Linker error when building 3.8.0-rc4 on Linux In-Reply-To: References: <25a8f375-3846-bcf7-383e-0ca9b18d4481@gmail.com> <16b258a8-a74b-c6db-1538-f2b33251900d@gmail.com> <293eb338-1b50-4913-085d-821cfb236a70@gmail.com> Message-ID: <182476be-61c2-896b-3df4-296335b59665@gmail.com> On 31.03.2017 22:44, Alan W. Irwin wrote: > > Therefore, from the sidelines I am encouraging you guys to be > extraordinarily careful about this particular issue; e.g., by > attempting to to confirm this CMake-3.8.0-rc4 issue independently for > Ubuntu 16.10. FWIW I tried reproducing it from within an Ubuntu 16.10 Docker container and it worked there as-is. Nils From tkook11 at gmail.com Fri Mar 31 18:31:14 2017 From: tkook11 at gmail.com (=?UTF-8?B?44Km44Or44Ow?=) Date: Fri, 31 Mar 2017 18:31:14 -0400 Subject: [CMake] Linker error when building 3.8.0-rc4 on Linux In-Reply-To: <182476be-61c2-896b-3df4-296335b59665@gmail.com> References: <25a8f375-3846-bcf7-383e-0ca9b18d4481@gmail.com> <16b258a8-a74b-c6db-1538-f2b33251900d@gmail.com> <293eb338-1b50-4913-085d-821cfb236a70@gmail.com> <182476be-61c2-896b-3df4-296335b59665@gmail.com> Message-ID: > I suggest you try the experiment of using the system version of > libcurl instead (which also supplies SSL capability). For example, my > Linux distribution is Debian Stable which only installs libssl 1.0.1. > And for that case when I tried the bootstrap method with the > --system-curl option (the usual way I build cmake), I do not confirm > your linking issue. So my expectation is you will also avoid that > linking issue on Ubuntu 2016.10 if you use that bootstrap option or a > similar system libcurl option for the non-bootstrap case. I tried running ./bootstrap with the --system-curl option, and I see a different error: [ 93%] Linking CXX executable ../bin/ccmake /usr/bin/ld: ../Utilities/cmlibarchive/libarchive/libcmlibarchive.a(archive_cryptor.c.o): undefined reference to symbol 'EVP_aes_256_ecb@@OPENSSL_1.0.0' //lib/x86_64-linux-gnu/libcrypto.so.1.0.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Source/CMakeFiles/ccmake.dir/build.make:420: recipe for target 'bin/ccmake' failed make[2]: *** [bin/ccmake] Error 1 CMakeFiles/Makefile2:2135: recipe for target 'Source/CMakeFiles/ccmake.dir/all' failed make[1]: *** [Source/CMakeFiles/ccmake.dir/all] Error 2 Makefile:162: recipe for target 'all' failed make: *** [all] Error 2 So the problem is likely on my end.