From gerhard.gappmeier at ascolab.com Fri Sep 1 07:26:36 2017 From: gerhard.gappmeier at ascolab.com (Gerhard Gappmeier) Date: Fri, 1 Sep 2017 13:26:36 +0200 Subject: [CMake] CMake Coverage broken with Ninja Message-ID: hi all, just recently I discovered that our coverage builds on CDash don't work anymore. By analyzing the problem I found out that this is related to Ninja generator. I don't know when the problem was introduced but it still exists with CMake 3.9.1. (GCC and gcov are version 4.9.4, but this is not important) I attached a simple test program to reproduce the problem. $> tar xf demo.tar.gz $> cd demo $> mkdir bld $> cmake -GNinja .. $> ninja Nightly ... Configure project Each . represents 1024 bytes of output . Size of output: 0K Build project Each symbol represents 1024 bytes of output. '!' represents an error and '*' a warning. . Size of output: 0K 0 Compiler errors 0 Compiler warnings Test project /home/gergap/tmp/cmaketest/bld Start 1: mytest 1/1 Test #1: mytest ........................... Passed 0.00 sec 100% tests passed, 0 tests failed out of 1 Total Test time (real) = 0.00 sec Performing coverage Processing coverage (each . represents one file): . Accumulating results (each . represents one file): .Cannot find file: /home/gergap/tmp/cmaketest/bld/Testing/main.c Covered LOC: 0 Not covered LOC: 0 Total LOC: 0 Percentage Coverage: 0.00% ... When using make instead everything works as expected. $> tar xf demo.tar.gz $> cd demo $> mkdir bld $> cmake .. $> make Nightly Configure project Each . represents 1024 bytes of output . Size of output: 0K Build project Each symbol represents 1024 bytes of output. '!' represents an error and '*' a warning. . Size of output: 0K 0 Compiler errors 0 Compiler warnings Test project /home/gergap/tmp/cmaketest/bld Start 1: mytest 1/1 Test #1: mytest ........................... Passed 0.00 sec 100% tests passed, 0 tests failed out of 1 Total Test time (real) = 0.00 sec Performing coverage Processing coverage (each . represents one file): . Accumulating results (each . represents one file): . Covered LOC: 3 Not covered LOC: 0 Total LOC: 3 Percentage Coverage: 100.00% Is this problem known? Are there any fixes/workaround available? -- mit freundlichen Gr??en / best regards *Gerhard Gappmeier* ascolab GmbH - automation systems communication laboratory Tel.: +49 911 569846 203 Fax: +49 911 569846 400 Web: http://www.ascolab.com GPG-KeyId: 7A78B0A7 GPG-Fingerprint: A964 56A2 32E9 A537 AB7E EBD6 8D09 0D72 7A78 B0A7 -- *ascolab GmbH* Gesch?ftsf?hrer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrau? Sitz der Gesellschaft: An der Kaufleite 34 ? 90562 Kalchreuth ? Germany Registernummer: HRB 9360 Registergericht: Amtsgericht F?rth -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: demo.tar.gz Type: application/gzip Size: 517 bytes Desc: not available URL: From haocheng.liu at kitware.com Fri Sep 1 08:49:54 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Fri, 1 Sep 2017 08:49:54 -0400 Subject: [CMake] CMake Coverage broken with Ninja In-Reply-To: References: Message-ID: Hi Gerhard, On Fri, Sep 1, 2017 at 7:26 AM, Gerhard Gappmeier < gerhard.gappmeier at ascolab.com> wrote: > hi all, > > just recently I discovered that our coverage builds on CDash don't work > anymore. > By analyzing the problem I found out that this is related to Ninja > generator. > I don't know when the problem was introduced but it still exists with > CMake 3.9.1. > (GCC and gcov are version 4.9.4, but this is not important) > > I attached a simple test program to reproduce the problem. > > $> tar xf demo.tar.gz > $> cd demo > $> mkdir bld > What if you call `chcp 65001` here before the CMake call? (Force using UTF-8 console) > > $> cmake -GNinja .. > $> ninja Nightly > ... > Configure project > Each . represents 1024 bytes of output > . Size of output: 0K > Build project > Each symbol represents 1024 bytes of output. > '!' represents an error and '*' a warning. > . Size of output: 0K > 0 Compiler errors > 0 Compiler warnings > Test project /home/gergap/tmp/cmaketest/bld > Start 1: mytest > 1/1 Test #1: mytest ........................... Passed 0.00 sec > > 100% tests passed, 0 tests failed out of 1 > > Total Test time (real) = 0.00 sec > Performing coverage > Processing coverage (each . represents one file): > . > Accumulating results (each . represents one file): > .Cannot find file: /home/gergap/tmp/cmaketest/bld/Testing/main.c > > Covered LOC: 0 > Not covered LOC: 0 > Total LOC: 0 > Percentage Coverage: 0.00% > ... > > When using make instead everything works as expected. > $> tar xf demo.tar.gz > $> cd demo > $> mkdir bld > $> cmake .. > $> make Nightly > Configure project > Each . represents 1024 bytes of output > . Size of output: 0K > Build project > Each symbol represents 1024 bytes of output. > '!' represents an error and '*' a warning. > . Size of output: 0K > 0 Compiler errors > 0 Compiler warnings > Test project /home/gergap/tmp/cmaketest/bld > Start 1: mytest > 1/1 Test #1: mytest ........................... Passed 0.00 sec > > 100% tests passed, 0 tests failed out of 1 > > Total Test time (real) = 0.00 sec > Performing coverage > Processing coverage (each . represents one file): > . > Accumulating results (each . represents one file): > . > Covered LOC: 3 > Not covered LOC: 0 > Total LOC: 3 > Percentage Coverage: 100.00% > > Is this problem known? > I believe it's related to CMake issue 17191 that CMake is not properly converting the -showIncludes prefix (${displayedInSystemLanguage}) to its internal UTF-8 encoding. > Are there any fixes/workaround available? > > Thanks to Brad it has been fixed in CMake MR 1179 . If you do not want to use CMake from source build then adding `chcp 6500`1 should do the trick. > -- > mit freundlichen Gr??en / best regards > > *Gerhard Gappmeier* > ascolab GmbH - automation systems communication laboratory > Tel.: +49 911 569846 203 <+49%20911%20569846203> > Fax: +49 911 569846 400 <+49%20911%20569846400> > Web: http://www.ascolab.com > GPG-KeyId: 7A78B0A7 > GPG-Fingerprint: A964 56A2 32E9 A537 AB7E EBD6 8D09 0D72 7A78 B0A7 > > -- > *ascolab GmbH* > Gesch?ftsf?hrer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrau? > Sitz der Gesellschaft: An der Kaufleite 34 ? 90562 Kalchreuth ? Germany > Registernummer: HRB 9360 > Registergericht: Amtsgericht F?rth > > -- > > 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 > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerhard.gappmeier at ascolab.com Fri Sep 1 09:41:00 2017 From: gerhard.gappmeier at ascolab.com (Gerhard Gappmeier) Date: Fri, 1 Sep 2017 15:41:00 +0200 Subject: [CMake] CMake Coverage broken with Ninja In-Reply-To: References: Message-ID: Hi Haocheng, `chcp` seems to be a Windows command. I'm talking about Linux, which is UTF-8 by default: $> locale LANG=en_US.utf8 LC_CTYPE="en_US.utf8" LC_NUMERIC="en_US.utf8" LC_TIME="en_US.utf8" LC_COLLATE="en_US.utf8" LC_MONETARY="en_US.utf8" LC_MESSAGES="en_US.utf8" LC_PAPER="en_US.utf8" LC_NAME="en_US.utf8" LC_ADDRESS="en_US.utf8" LC_TELEPHONE="en_US.utf8" LC_MEASUREMENT="en_US.utf8" LC_IDENTIFICATION="en_US.utf8" LC_ALL= any ideas for the Linux platform? mit freundlichen Gr??en / best regards *Gerhard Gappmeier* ascolab GmbH - automation systems communication laboratory Tel.: +49 911 569846 203 Fax: +49 911 569846 400 Web: http://www.ascolab.com GPG-KeyId: 7A78B0A7 GPG-Fingerprint: A964 56A2 32E9 A537 AB7E EBD6 8D09 0D72 7A78 B0A7 -- *ascolab GmbH* Gesch?ftsf?hrer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrau? Sitz der Gesellschaft: An der Kaufleite 34 ? 90562 Kalchreuth ? Germany Registernummer: HRB 9360 Registergericht: Amtsgericht F?rth On 09/01/2017 02:49 PM, Haocheng Liu wrote: > chcp 65001 -------------- next part -------------- An HTML attachment was scrubbed... URL: From haocheng.liu at kitware.com Fri Sep 1 10:09:22 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Fri, 1 Sep 2017 10:09:22 -0400 Subject: [CMake] CMake Coverage broken with Ninja In-Reply-To: References: Message-ID: On Fri, Sep 1, 2017 at 9:41 AM, Gerhard Gappmeier < gerhard.gappmeier at ascolab.com> wrote: > Hi Haocheng, > > `chcp` seems to be a Windows command. > I'm talking about Linux, which is UTF-8 by default: > > $> locale > LANG=en_US.utf8 > LC_CTYPE="en_US.utf8" > LC_NUMERIC="en_US.utf8" > LC_TIME="en_US.utf8" > LC_COLLATE="en_US.utf8" > LC_MONETARY="en_US.utf8" > LC_MESSAGES="en_US.utf8" > LC_PAPER="en_US.utf8" > LC_NAME="en_US.utf8" > LC_ADDRESS="en_US.utf8" > LC_TELEPHONE="en_US.utf8" > LC_MEASUREMENT="en_US.utf8" > LC_IDENTIFICATION="en_US.utf8" > LC_ALL= > > any ideas for the Linux platform? > > Hum, I tried your example, the problem is that ${CMAKE_BUILD_DIRECTORY}/testing is missing a main.c file. If I create a fake file and the coverage reports 100%. I've Cc Brad King since He is most familiar with Ninja related issues. > > mit freundlichen Gr??en / best regards > > *Gerhard Gappmeier* > ascolab GmbH - automation systems communication laboratory > Tel.: +49 911 569846 203 <+49%20911%20569846203> > Fax: +49 911 569846 400 <+49%20911%20569846400> > Web: http://www.ascolab.com > GPG-KeyId: 7A78B0A7 > GPG-Fingerprint: A964 56A2 32E9 A537 AB7E EBD6 8D09 0D72 7A78 B0A7 > > -- > *ascolab GmbH* > Gesch?ftsf?hrer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrau? > Sitz der Gesellschaft: An der Kaufleite 34 ? 90562 Kalchreuth ? Germany > Registernummer: HRB 9360 > Registergericht: Amtsgericht F?rth > On 09/01/2017 02:49 PM, Haocheng Liu wrote: > > chcp 65001 > > > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Fri Sep 1 11:39:31 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 1 Sep 2017 10:39:31 -0500 Subject: [CMake] Proper process for static & shared variants of config packages? Message-ID: Suppose I have a library target and I setup a config package for it and install target exports for it. What is the process for supporting installation of the shared library and static library variants (maybe the same answer applies to debug and release variants too)? Should you create 1 target and rely on BUILD_SHARED_LIBS, which means generating two binary directories, building and installing once in each? Will this overwrite existing target.cmake and config.cmake files in a negative way? Or should there be 2 library targets (something like foo_shared and foo_static) and build & install once? From rcdailey.lists at gmail.com Fri Sep 1 14:21:59 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 1 Sep 2017 13:21:59 -0500 Subject: [CMake] How should config packages handle components? Message-ID: First of all, I want to apologize for including the developer list. Maybe I'm not being patient enough, but it seems like every post I've made on the normal users list doesn't get any attention. Secondly, the cmake-packages portion of the cmake documentation doesn't go into a ton of detail about components, but it does give an example towards the bottom of how you export targets for components. This leads to my questions: When defining the target exports via install(TARGET foo EXPORT foo-export), is it recommended for all components to collectively export as 1 target.cmake script? Or is it better to have 1 target.cmake script per component? If we use Boost as an example, the latter would mean having: boost-config.cmake boost-target-filesystem.cmake boost-target-thread.cmake ...etc... This means that boost-config.cmake would "include()" only the relevant target cmake scripts based on the provided COMPONENTS list, I assume? Which is the better approach here and why? One problem I thought of with the former (one big target.cmake with all import targets in there) is that if you only ask for a subset of components in find_package(), you will still get all of them since all imports are defined in a single file. Does this go against any design principles? Assuming this really happens, are there any negative side effects? From i.zaufi at gmail.com Fri Sep 1 14:40:39 2017 From: i.zaufi at gmail.com (Alex Turbov) Date: Fri, 1 Sep 2017 21:40:39 +0300 Subject: [CMake] [cmake-developers] How should config packages handle components? In-Reply-To: References: Message-ID: Hi Robert, On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey wrote: > > One problem I thought of with the former (one big target.cmake with > all import targets in there) is that if you only ask for a subset of > components in find_package(), you will still get all of them since all > imports are defined in a single file. In my project I have a bunch of components and do one exported target per component exactly by the mentioned reason -- user didn't ask for others... > Does this go against any design > principles? As far as I know, there are no clear design principles :) (yet, at least nowadays) -- at least doing a lot of CMake projects since 2009, I've never seen an explicit list of them %) IMHO, there is a lack of "official guildelines" (or it is really hard to search for 'em) Assuming this really happens, are there any negative side > effects? > I could see the impact on build time only in this case... and for me the most obvious is increasing time to process the lists (which is for some reasons really slow on Windows, at least in our build farm which uses vargant and VirtualBox images) (but I don't have any particular numbers, cuz never implemented the first approach) -- > > 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-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Fri Sep 1 14:49:09 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Fri, 1 Sep 2017 13:49:09 -0500 Subject: [CMake] [cmake-developers] How should config packages handle components? In-Reply-To: References: Message-ID: On Fri, Sep 1, 2017 at 1:40 PM, Alex Turbov wrote: > Hi Robert, > > > On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey > wrote: >> >> >> One problem I thought of with the former (one big target.cmake with >> all import targets in there) is that if you only ask for a subset of >> components in find_package(), you will still get all of them since all >> imports are defined in a single file. > > > In my project I have a bunch of components and do one exported target per > component > exactly by the mentioned reason -- user didn't ask for others... > >> >> Does this go against any design >> principles? > > > As far as I know, there are no clear design principles :) (yet, at least > nowadays) -- at least doing > a lot of CMake projects since 2009, I've never seen an explicit list of them > %) > IMHO, there is a lack of "official guildelines" (or it is really hard to > search for 'em) > >> Assuming this really happens, are there any negative side >> effects? > > > I could see the impact on build time only in this case... and for me the > most obvious is increasing > time to process the lists (which is for some reasons really slow on Windows, > at least in our > build farm which uses vargant and VirtualBox images) > (but I don't have any particular numbers, cuz never implemented the first > approach) Thanks for the quick response. The "official guidelines" or "package standard" is really exactly what we need I think. What worries me the most is that it seems like this is deep knowledge that is stuck in the brains of folks like Brad King and David Cole. I think somehow getting a knowledge dump from them into a documentation page would be a valuable task. I think for something as complex and variable as packages in CMake (install process in general) deserves some standardization, because we need the ability to distinguish between practices that we should follow for legacy (backward compatibility) reasons, non-cmake project reasons, and fully "modern" cmake packages. From i.zaufi at gmail.com Fri Sep 1 15:11:17 2017 From: i.zaufi at gmail.com (Alex Turbov) Date: Fri, 1 Sep 2017 22:11:17 +0300 Subject: [CMake] [cmake-developers] How should config packages handle components? In-Reply-To: References: Message-ID: I've started to use CMake a quite long time ago, and do not search for "standards" or "guidelines" anymore %) But I could mention some chapters in the official documentation (in the "Reference Manuals" section) which are really full of "secret knowledge", but the problem is that they are too complicated for newcomers %) but personally I read them many many times before and each time found smth "new" to me :) I would say that after a couple of years I started to feel comfortable w/ CMake -- when I've used almost all offered features in a different set of platform and generators. On Fri, Sep 1, 2017 at 9:49 PM, Robert Dailey wrote: > On Fri, Sep 1, 2017 at 1:40 PM, Alex Turbov wrote: > > Hi Robert, > > > > > > On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey > > wrote: > >> > >> > >> One problem I thought of with the former (one big target.cmake with > >> all import targets in there) is that if you only ask for a subset of > >> components in find_package(), you will still get all of them since all > >> imports are defined in a single file. > > > > > > In my project I have a bunch of components and do one exported target per > > component > > exactly by the mentioned reason -- user didn't ask for others... > > > >> > >> Does this go against any design > >> principles? > > > > > > As far as I know, there are no clear design principles :) (yet, at least > > nowadays) -- at least doing > > a lot of CMake projects since 2009, I've never seen an explicit list of > them > > %) > > IMHO, there is a lack of "official guildelines" (or it is really hard to > > search for 'em) > > > >> Assuming this really happens, are there any negative side > >> effects? > > > > > > I could see the impact on build time only in this case... and for me the > > most obvious is increasing > > time to process the lists (which is for some reasons really slow on > Windows, > > at least in our > > build farm which uses vargant and VirtualBox images) > > (but I don't have any particular numbers, cuz never implemented the first > > approach) > > Thanks for the quick response. The "official guidelines" or "package > standard" is really exactly what we need I think. What worries me the > most is that it seems like this is deep knowledge that is stuck in the > brains of folks like Brad King and David Cole. I think somehow getting > a knowledge dump from them into a documentation page would be a > valuable task. I think for something as complex and variable as > packages in CMake (install process in general) deserves some > standardization, because we need the ability to distinguish between > practices that we should follow for legacy (backward compatibility) > reasons, non-cmake project reasons, and fully "modern" cmake packages. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From florent.castelli at gmail.com Fri Sep 1 15:47:03 2017 From: florent.castelli at gmail.com (Florent Castelli) Date: Fri, 1 Sep 2017 21:47:03 +0200 Subject: [CMake] [cmake-developers] How should config packages handle components? In-Reply-To: References: Message-ID: <506b6a64-f04c-7470-1253-e352e9a5bebf@gmail.com> On 01/09/2017 20:40, Alex Turbov wrote: > Hi Robert, > > > On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey > > wrote: > > > One problem I thought of with the former (one big target.cmake with > all import targets in there) is that if you only ask for a subset of > components in find_package(), you will still get all of them since all > imports are defined in a single file. > > > In my project I have a bunch of components and do one exported target > per component > exactly by the mentioned reason -- user didn't ask for others... > > Does this go against any design > principles? > > > As far as I know, there are no clear design principles :) (yet, at > least nowadays) -- at least doing > a lot of CMake projects since 2009, I've never seen an explicit list > of them %) > IMHO, there is a lack of "official guildelines" (or it is really hard > to search for 'em) > > Assuming this really happens, are there any negative side > effects? > > > I could see the impact on build time only in this case... and for me > the most obvious is increasing > time to process the lists (which is for some reasons really slow on > Windows, at least in our > build farm which uses vargant and VirtualBox images) > (but I don't have any particular numbers, cuz never implemented the > first approach) Well, there's no impact on build time. The module will provide IMPORTED targets, if they are not used, they won't be used in the solution / Makefile. And I don't think CMake has any significant bottleneck on having just a few more IMPORTED targets around from a find_package() module. Components might be important for an old "FindFoo.cmake" module where you don't want to find a lot more libraries in your path, not so much for a "FooConfig.cmake" which is a "dumb" file that just defines a lot of targets and their properties. /Florent -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerhard.gappmeier at ascolab.com Sat Sep 2 03:14:16 2017 From: gerhard.gappmeier at ascolab.com (Gerhard Gappmeier) Date: Sat, 2 Sep 2017 09:14:16 +0200 Subject: [CMake] CMake Coverage broken with Ninja In-Reply-To: References: Message-ID: <02f744e4-e714-e1ba-5acf-4a2e99ea3011@ascolab.com> Hi Haocheng, thanks for helping. I guess this has to do with another issue. The Ninja generator generates different paths then the default Unix Makefile generator. This leads to the following behavior in normal build operations: I introduced a warning in the printf line to demonstrate this. With Makefiles: mkdir bld && cd bld && cmake .. Build inside Vim using ":make" [ 50%] Building C object CMakeFiles/demo.dir/main.c.o /home/gergap/tmp/demo/main.c: In function ?main?: /home/gergap/tmp/demo/main.c:5:12: warning: format ?%i? expects a matching ?int? argument [-Wformat=] ???? printf("Hello World %i\n"); ??????????? ^ [100%] Linking C executable demo [100%] Built target demo Press ENTER or type command to continue as you can see the warning message contains the absolute path, so parsing the errors works for Vim (Emacs, or whatever tool), and you can jump to the error location. Now the same with Ninja: mkdir bld && cd bld && cmake -GNinja .. Build inside Vim using ":make" (use ":set makeprg=ninja" first) cd into build dir '/home/gergap/tmp/demo/bld/../bld'... executing ninja... [1/2] Building C object CMakeFiles/demo.dir/main.c.o ../main.c: In function ?main?: ../main.c:5:12: warning: format ?%i? expects a matching ?int? argument [-Wformat=] ???? printf("Hello World %i\n"); ??????????? ^ [2/2] Linking C executable demo cd back /home/gergap/tmp/demo/bld Press ENTER or type command to continue As you can see now the paths are relative to the build folder, thus jumping to the error location only works when Vim has the build folder set as working dir, and this is typically not the case. This is quite annoying, inconsistent with Makefiles and was already reported once here: https://cmake.org/Bug/print_bug_page.php?bug_id=13894 AFAIK this was never fixed. Now I suspect this to be also the reason for the coverage issues. I hope this helps. On 09/01/2017 04:09 PM, Haocheng Liu wrote: > > > On Fri, Sep 1, 2017 at 9:41 AM, Gerhard Gappmeier > > > wrote: > > Hi Haocheng, > > `chcp` seems to be a Windows command. > I'm talking about Linux, which is UTF-8 by default: > > $> locale > LANG=en_US.utf8 > LC_CTYPE="en_US.utf8" > LC_NUMERIC="en_US.utf8" > LC_TIME="en_US.utf8" > LC_COLLATE="en_US.utf8" > LC_MONETARY="en_US.utf8" > LC_MESSAGES="en_US.utf8" > LC_PAPER="en_US.utf8" > LC_NAME="en_US.utf8" > LC_ADDRESS="en_US.utf8" > LC_TELEPHONE="en_US.utf8" > LC_MEASUREMENT="en_US.utf8" > LC_IDENTIFICATION="en_US.utf8" > LC_ALL= > > any ideas for the Linux platform? > > Hum, I tried your example, the problem is > that?${CMAKE_BUILD_DIRECTORY}/testing is missing a main.c file. If I > create a fake file and the coverage reports 100%. I've Cc Brad King > since He is most familiar with Ninja related issues. > > > mit freundlichen Gr??en / best regards > > *Gerhard Gappmeier* > ascolab GmbH - automation systems communication laboratory > Tel.: +49 911 569846 203 > Fax: +49 911 569846 400 > Web: http://www.ascolab.com > GPG-KeyId: 7A78B0A7 > GPG-Fingerprint: A964 56A2 32E9 A537 AB7E EBD6 8D09 0D72 7A78 B0A7 > > -- > *ascolab GmbH* > Gesch?ftsf?hrer: Gerhard Gappmeier, Matthias Damm, Uwe Steinkrau? > Sitz der Gesellschaft: An der Kaufleite 34 ? 90562 Kalchreuth ? > Germany > Registernummer: HRB 9360 > Registergericht: Amtsgericht F?rth > > On 09/01/2017 02:49 PM, Haocheng Liu wrote: >> chcp 65001 > > > > > -- > Best regards > Haocheng > > Haocheng LIU > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone:?518-881-4421 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfultz2 at yahoo.com Sat Sep 2 04:08:25 2017 From: pfultz2 at yahoo.com (P F) Date: Sat, 2 Sep 2017 03:08:25 -0500 Subject: [CMake] Should configuration package files define module package variables? In-Reply-To: References: Message-ID: > On Aug 25, 2017, at 11:21 AM, Robert Dailey wrote: > > So I've been studying the find_package[1] and "creating packages"[2] > documentation, as well as the CMakePackageConfigHelpers[3] page. > > Based on the current offerings of configuration packages, I do not > understand the need for the relocatable config.cmake file when all it > really contains is: > > include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake) In general, if the library does not have any dependencies, you can just export the targets directly to the config.cmake file: install(TARGETS foo EXPORT foo-config) install(EXPORT foo-config DESTINATION lib/cmake/foo) However, if the library has dependencies, you will need to iterate over them in the config.cmake file. That is if `foo` uses zlib, like this: find_package(ZLIB) target_link_libraries(foo ZLIB::ZLIB) Then the foo-config.cmake needs to do this(assuming the export targets are written to foo-targets): include(CMakeFindDependencyMacro) find_dependency(ZLIB) include("${CMAKE_CURRENT_LIST_DIR}/foo-targets.cmake?) The reason for this is that the imported foo target will link against ZLIB::ZLIB, but it will not define it. Actually, the generated foo-targets.cmake will create an error if ZLIB::ZLIB doesn?t exists, which is why `find_dependency(ZLIB)`(which is really just `find_package` underneath) needs to be called before including the foo-targets.cmake. Hopefully that makes sense. > > However, what I'm wondering is even though the import targets should > contain all information about include directories, libraries, etc, > should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES > variables? Example of what foo-config.cmake would be like: > > include(${CMAKE_CURRENT_LIST_DIR}/foo-config.cmake) > set( Foo_INCLUDE_DIRS "... path here...." ) > set( Foo_LIBRARIES "List of libraries here...? ) In general, defining relocatable variables like `Foo_INCLUDE_DIRS` was more common in with cmake 2.8. With modern cmake using just the imported targets is much better then dealing with all those variables and trying to make them relocatable. From roman.wueger at gmx.at Mon Sep 4 03:01:39 2017 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Mon, 4 Sep 2017 09:01:39 +0200 Subject: [CMake] Path to vc_redist Message-ID: <66AEE89B-868C-41F6-8714-0DFFEE31B1B3@gmx.at> Hello, is there already an existing function to get the vc_redist.exe for the current generator? Regards Roman From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Mon Sep 4 04:06:05 2017 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Mon, 4 Sep 2017 08:06:05 +0000 Subject: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues Message-ID: <8D981219EEA621479C112DA9BDC39A8E7098F2D4@EXMBS2.ad.igd.fraunhofer.de> I'm having two issues with debug symbols for CUDA libraries on a project: 1. The PDBs are not placed where the linker later expects to find them (haven't been able to replicate this in a minimal project yet) 2. Trying to circumnavigate this issue by using "/Z7" instead of "/Zi" does not work, Zi is always used (replicable in any project with CUDA) Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by -Z7 or /Z7. Build and see several warnings like "cl : Command line warning D9025: overriding '/Z7' with '/Zi'" in the output window. And do the flags in the -Xcompiler make sense at all in VS? The CUDA build tools seem to determine these automatically anyways... for example I get the following call in the above scenario: "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" -gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -cudart static -Xcompiler="/EHsc -Z7 -Ob0" -g -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu" 3. Also, -gencode flags do not behave as expected when given in the form -gencode=arch=compute_20,code="sm_20,compute_20", as this causes the VS build system to error out: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations\CUDA 8.0.targets(216,9): error : Item '..\..\a\a.cu' Code Generation value is not in the expected format '[Arch],[Code]'. The code generation value in this example is set to compute_20,sm_20,compute_20 by CMake. Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From jc.fernandez.navarro.lists at gmail.com Mon Sep 4 07:58:36 2017 From: jc.fernandez.navarro.lists at gmail.com (Jose Fernandez Navarro) Date: Mon, 4 Sep 2017 13:58:36 +0200 Subject: [CMake] QT AUTOMOC problems with latest versions Message-ID: <9CFE6C38-4B50-4E7F-A635-289CE7F1E368@gmail.com> Hello, The cmake?s automoc functionality has stopped working in my codebase since version 3.8.2 and 3.9.1. My code base was compiling/building fine until I updated CMake. If I downgrade it to 3.7.9 or lower then it compiles fine again. The error code that I get is the following: Scanning dependencies of target analysis [ 65%] Building CXX object src/model/CMakeFiles/model.dir/GeneItemModel.cpp.o [ 66%] Building CXX object src/analysis/CMakeFiles/analysis.dir/AnalysisDEA.cpp.o [ 67%] Building CXX object src/viewRenderer/CMakeFiles/viewRenderer.dir/GraphicItemGL.cpp.o [ 68%] Built target viewPages [ 70%] Building CXX object src/model/CMakeFiles/model.dir/SpotItemModel.cpp.o [ 71%] Built target viewRenderer [ 72%] Building CXX object src/analysis/CMakeFiles/analysis.dir/AnalysisQC.cpp.o [ 73%] Building CXX object src/analysis/CMakeFiles/analysis.dir/AnalysisCorrelation.cpp.o [ 74%] Built target model [ 75%] Building CXX object src/analysis/CMakeFiles/analysis.dir/AnalysisClustering.cpp.o [ 76%] Building CXX object src/analysis/CMakeFiles/analysis.dir/ChartView.cpp.o [ 77%] Built target analysis Scanning dependencies of target STViewer make[2]: *** No rule to make target `src/dialogs/CMakeFiles/dialogs.dir/dialogs_autogen/moc_compilation.cpp.o', needed by `STViewer.app/Contents/MacOS/STViewer'. Stop. make[2]: *** Waiting for unfinished jobs.... [ 78%] Building CXX object src/CMakeFiles/STViewer.dir/main.cpp.o [ 81%] Building CXX object src/CMakeFiles/STViewer.dir/STViewer_autogen/moc_compilation.cpp.o [ 82%] Building CXX object src/CMakeFiles/STViewer.dir/mainWindow.cpp.o [ 82%] Building CXX object src/CMakeFiles/STViewer.dir/STViewer_autogen/AXPSB5LYZJ/qrc_application.cpp.o make[1]: *** [src/CMakeFiles/STViewer.dir/all] Error 2 make: *** [all] Error 2 The source is structured in different source folders and I use the cmake?s automoc set(CMAKE_AUTOMOC ON) Has anybody experienced similar issues? Has anything changed in the way cmake performs automoc since version 3.8.x? Thanks in advance! Best, Jose -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Sep 4 09:20:32 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 4 Sep 2017 09:20:32 -0400 Subject: [CMake] Path to vc_redist In-Reply-To: <66AEE89B-868C-41F6-8714-0DFFEE31B1B3@gmx.at> References: <66AEE89B-868C-41F6-8714-0DFFEE31B1B3@gmx.at> Message-ID: You can use the InstallRequiredSystemLibraries to do this. Since it sounds like you don't want all the libraries installed, use CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP and than deduce the path of vc_redist.exe from the value(s) in CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS. On Mon, Sep 4, 2017 at 3:01 AM, Roman W?ger wrote: > Hello, > > is there already an existing function to get the vc_redist.exe for the > current generator? > > Regards > Roman > -- > > 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 ycollette.nospam at free.fr Mon Sep 4 09:38:02 2017 From: ycollette.nospam at free.fr (ycollette.nospam at free.fr) Date: Mon, 4 Sep 2017 15:38:02 +0200 (CEST) Subject: [CMake] Ctest and AND operator on labels In-Reply-To: <977230142.160183476.1504532241137.JavaMail.root@zimbra35-e6> Message-ID: <18479483.160185165.1504532282686.JavaMail.root@zimbra35-e6> Hello, I would like to launch tests with 2 specific labels: LEVEL1 and NEW To launch tests with several labels and the OR logical operator, you can do that: cmake -L "(LEVEL1|NEW)" But how can you perform the AND operator ? Best regards, YC From eldlistmailingz at tropicsoft.com Mon Sep 4 09:40:03 2017 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Mon, 4 Sep 2017 09:40:03 -0400 Subject: [CMake] Adding compile and build type tests to CMake/CTest Message-ID: Boost Build has tests for running an application successfully or not, for compiling one or more source files successfully or not, and for building one or more source files into an exe or not. These tests in Boost Build are the run/run-fail, compile/compile-fail, and link/link-fail rules. CMake/CTest has the exact equivalent to the run/run-fail rule in its add_test framework, but there is not add_test equivalent to the other two sets of rules. It sure would be nice, when Boost transitions to using CMake/CTest instead of Boost Build, if CMake/CTest had the equivalent of the other two sets of types of test in its add_test framework. Is there any consensus that these other two types of tests might be valuable for CMake/CTest, or any way to make this happen ? From rleigh at codelibre.net Mon Sep 4 09:51:07 2017 From: rleigh at codelibre.net (Roger Leigh) Date: Mon, 4 Sep 2017 14:51:07 +0100 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: References: Message-ID: <98e84b16-7590-63b4-1080-34db0eb9dc18@codelibre.net> On 04/09/17 14:40, Edward Diener wrote: > Boost Build has tests for running an application successfully or not, > for compiling one or more source files successfully or not, and for > building one or more source files into an exe or not. These tests in > Boost Build are the run/run-fail, compile/compile-fail, and > link/link-fail rules. > > CMake/CTest has the exact equivalent to the run/run-fail rule in its > add_test framework, but there is not add_test equivalent to the other > two sets of rules. It sure would be nice, when Boost transitions to > using CMake/CTest instead of Boost Build, if CMake/CTest had the > equivalent of the other two sets of types of test in its add_test > framework. > > Is there any consensus that these other two types of tests might be > valuable for CMake/CTest, or any way to make this happen ? I've certainly wished for them. Particularly when testing templated code where you want to test that certain things fail correctly, e.g. via static_assert or simply being invalid. I understand it's possible to make this work partially, by creating targets which aren't built by default, and then add tests which invoke the targets. But this appears to have some caveats, such as potential misbehaviour with parallel testing. Or you can have a separate CMake build for each individual target, but it's extra complexity. Having a proper means of registering such tests would be very, very nice. Regards, Roger From eric.noulard at gmail.com Mon Sep 4 12:02:34 2017 From: eric.noulard at gmail.com (Eric Noulard) Date: Mon, 4 Sep 2017 18:02:34 +0200 Subject: [CMake] Ctest and AND operator on labels In-Reply-To: <18479483.160185165.1504532282686.JavaMail.root@zimbra35-e6> References: <977230142.160183476.1504532241137.JavaMail.root@zimbra35-e6> <18479483.160185165.1504532282686.JavaMail.root@zimbra35-e6> Message-ID: 2017-09-04 15:38 GMT+02:00 : > Hello, > > I would like to launch tests with 2 specific labels: LEVEL1 and NEW > To launch tests with several labels and the OR logical operator, you can > do that: > cmake -L "(LEVEL1|NEW)" > > But how can you perform the AND operator ? > You can't. See https://cmake.org/pipermail/cmake/2017-March/065168.html -- Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Sep 4 13:37:27 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 4 Sep 2017 13:37:27 -0400 Subject: [CMake] Understanding constraint graph cycles In-Reply-To: <66D554C8-05E2-40D5-B18E-05E3E93FE218@kdab.com> References: <66D554C8-05E2-40D5-B18E-05E3E93FE218@kdab.com> Message-ID: Hi, Yes you are correct the issue is related to rpath. When CMake constructs the rpath for the library linking it will have two paths ( /home/jenkins/workspace/FlightGear/dist/lib64, /home/jenkins/workspace/SimGear/dist/lib64) each that contain a copy of libosgText.so.130. CMake is warning that which version of libosgText is undefined. On Thu, Aug 24, 2017 at 10:08 AM, James Turner wrote: > Hi, > > Since upgrading to a recent CMake, the FLightGear build system is now > reporting this: > > ========== > CMake Warning at utils/fgai/CMakeLists.txt:1 (add_executable): > Cannot generate a safe runtime search path for target fgai because there > is > a cycle in the constraint graph: > > dir 0 is [/home/jenkins/workspace/FlightGear/dist/lib64] > dir 1 must precede it due to runtime library [libosgText.so.130] > dir 1 is [/home/jenkins/workspace/SimGear/dist/lib64] > dir 0 must precede it due to runtime library [libosgText.so.130] > > Some of these libraries may not be found correctly. > ============== > > > I can guess various dumb things I might have done to cause this, but can > anyone give me some context? This is about rpath setting in the executables? > > SimGear is a helper library for FlightGear, build as static libs, and > imported into FlightGear directly. SimGear and FlightGear both depend on > OpenSceneGraph, and on our buiuld server (but not commonly in real life) > Simgear and FlightGear are being configured with different install prefixes > (that?s the /home/jenkins/workspace/dist/lib64 part) > > Again rather than making ad-hoc changes to fix this, I?d like a bit more > understanding about what is intended here, if anyone can suggest it. > > All this code is publicly visible on SourceForge BTW: > > https://sourceforge.net/p/flightgear/_list/git?source=navbar > > Kind regards, > James > -- > > 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 aleskx at gmail.com Mon Sep 4 13:37:53 2017 From: aleskx at gmail.com (Aleksandar Fabijanic) Date: Mon, 4 Sep 2017 12:37:53 -0500 Subject: [CMake] Using CMake with WEC 2013 and VS 2015 Message-ID: Hello, I am trying to generate a VS 2015 project for a WEC 2015 (CMakeLists.txt works fine for generation of the projects for "regular" VC 2015 platform target). I have the WEC, Platform builder etc installed, my SDK (SDK1) built and installed; I can create and build a "hello world" console app for CE800 Platform Toolset using the wizard in VS GUI IDE. However, when I try to use CMake to generate VS 2015 project(s): ? cat ..\cmake\WEC2013.cmake set(CMAKE_SYSTEM_NAME WindowsCE) set(CMAKE_SYSTEM_VERSION 8.0) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_GENERATOR_TOOLSET CE800) set(CMAKE_GENERATOR_PLATFORM SDK1) ? cmake --debug-trycompile -DCMAKE_TOOLCHAIN_FILE=..\WEC2013.cmake .. I run into following problem (comments in /**/ are mine, unimportant portions of cmake output cut out for clarity): -- Building for: Visual Studio 14 2015 -- The C compiler identification is MSVC 17.0.50727.114 -- The CXX compiler identification is MSVC 17.0.50727.114 -- Check for working C compiler: C:/Program Files (x86)/Windows CE Tools/SDKs/SDK1/Sdk/bin/i386/X86/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Windows CE Tools/SDKs/SDK1/Sdk/bin/i386/X86/cl.exe -- broken /* ... */ /* this warning also shows in the GUI "hello world", but it does not prevent it to build - I tried many recipes to get rid of it but none worked */ C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets(366,5): warning MSB8003: Could not find WindowsSDKDir variable from the registry. TargetFrameworkVersion or PlatformToolset may be set to an invalid version number. /* ... */ ClCompile: C:\Program Files (x86)\Windows CE Tools\SDKs\SDK1\sdk\bin\i386\x86\CL.exe /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D _WIN32_WCE=0x800 /D UNDER_CE /D WINCE /D X86 /D _X86_ /D _WINDOWS /D "CMAKE_INTDIR=\"Deb g\"" /D UNDER_CE /D WINCE /D _WIN32_WCE=0x800 /D x86 /D _X86_ /D _USESTL /D _MBCS /Gm- /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_c8221.dir\Debug\\" /Fd"cmTC_c8221.dir\Debug\v 140.pdb" /Gd /TC /analyze- /errorReport:queue /arch:IA32 C:\Temp\cmake_build\CMakeFiles\CMakeTmp\testCCompiler.c /* ... */ cl /c /Zi /W3 /WX- /Od /Ob0 /Oy- /D _WIN32_WCE=0x800 /D UNDER_CE /D WINCE /D X86 /D _X86_ /D _WINDOWS /D "CMAKE_INTDIR=\"Debug\"" /D UNDER_CE /D WINCE /D _WIN32_WCE=0x800 /D x86 /D _X86_ /D _USESTL /D _MBCS /Gm- /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_c8221.dir\Debug\\" /Fd"cmTC_c8221.dir\Debug\vc140.pdb" /Gd /TC /analyze- /errorReport:queue /arch:IA32 C:\Temp\cmake_build\CMakeFiles\CMakeTmp\testCCompiler.c cl : Command line warning D9002: ignoring unknown option '/Zc:inline' [C:\Users\alex\poco\cmake_build\CMakeFiles\CMakeTmp\cmTC_c8221.vcxproj] testCCompiler.c Link: C:\Program Files (x86)\Windows CE Tools\SDKs\SDK1\sdk\bin\i386\x86\link.exe /ERRORREPORT:QUEUE /OUT:"C:\Temp\cmake_build\CMakeFiles\CMakeTmp\Debug\cmTC_c8221.exe" /INCREMENTAL /NOLOGO oredll.lib ole32.lib oleaut32.lib uuid.lib commctrl.lib /NODEFAULTLIB:libc.lib /NODEFAULTLIB:oldnames.lib /MANIFEST /MANIFESTUAC:NO /DEBUG /PDB:"C:/Temp/cmake_build/CMakeFiles/CMakeTmp/Debug/cmTC_c8221.pdb" /SUBSYSTEM:WINDOWSCE /TLBID:1 /ENTRY:"mainACRTStartup" /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:/Temp/cmake_build/CMakeFiles/CMakeTmp/Debug/cmTC_c8221.lib" /MACHINE:X86 /SAFESH /machine:X86 cmTC_c8221.dir\Debug\testCCompiler.obj LINK : fatal error LNK1104: cannot open file 'ole32.lib' [C:\Temp\cmake_build\CMakeFiles\CMakeTmp\cmTC_c8221.vcxproj] Since I run cmake with `--debug-trycompile`, I can subsequently open the generated temporary `cmTC_c8221.vcxproj`, add the missing lib directories (after I add the one for ole32.lib, there are also errors for uuid.lib and commctrl.lib), and the project will build. But I would expect this process to generate "out of the box", without errors. Am I not doing something right here or is this a CMake-related problem? Thanks in advance for any help. Alex Virus-free. www.avast.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.turner at kdab.com Mon Sep 4 16:39:20 2017 From: james.turner at kdab.com (James Turner) Date: Mon, 4 Sep 2017 21:39:20 +0100 Subject: [CMake] Understanding constraint graph cycles In-Reply-To: References: <66D554C8-05E2-40D5-B18E-05E3E93FE218@kdab.com> Message-ID: <4765F92A-A6DC-42CE-BE64-6D9D197A20AA@kdab.com> > On 4 Sep 2017, at 18:37, Robert Maynard wrote: > > Yes you are correct the issue is related to rpath. When CMake constructs the rpath for the library linking it will have two paths ( /home/jenkins/workspace/FlightGear/dist/lib64, /home/jenkins/workspace/SimGear/dist/lib64) each that contain a copy of libosgText.so.130. CMake is warning that which version of libosgText is undefined. Can I control whether CMake includes the rpath flags for a static library like SimGear? Normally the default behaviour is correct but for this particular config it would be easier to disable the rpath for OSG inside SimGear, than adjust the build setup to use a common dist dir, I think. Kind regards, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dvir.Yitzchaki at ceva-dsp.com Tue Sep 5 02:47:58 2017 From: Dvir.Yitzchaki at ceva-dsp.com (Dvir Yitzchaki) Date: Tue, 5 Sep 2017 06:47:58 +0000 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: <98e84b16-7590-63b4-1080-34db0eb9dc18@codelibre.net> References: <98e84b16-7590-63b4-1080-34db0eb9dc18@codelibre.net> Message-ID: There's already CheckCXXSourceCompiles and friends. The only problem is that try_compile is not scriptable otherwise you could let the test invoke ${CMAKE_COMMAND} -P check_source_compiles.cmake. -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Roger Leigh Sent: Monday, September 4, 2017 16:51 To: cmake at cmake.org Subject: Re: [CMake] Adding compile and build type tests to CMake/CTest On 04/09/17 14:40, Edward Diener wrote: > Boost Build has tests for running an application successfully or not, > for compiling one or more source files successfully or not, and for > building one or more source files into an exe or not. These tests in > Boost Build are the run/run-fail, compile/compile-fail, and > link/link-fail rules. > > CMake/CTest has the exact equivalent to the run/run-fail rule in its > add_test framework, but there is not add_test equivalent to the other > two sets of rules. It sure would be nice, when Boost transitions to > using CMake/CTest instead of Boost Build, if CMake/CTest had the > equivalent of the other two sets of types of test in its add_test > framework. > > Is there any consensus that these other two types of tests might be > valuable for CMake/CTest, or any way to make this happen ? I've certainly wished for them. Particularly when testing templated code where you want to test that certain things fail correctly, e.g. via static_assert or simply being invalid. I understand it's possible to make this work partially, by creating targets which aren't built by default, and then add tests which invoke the targets. But this appears to have some caveats, such as potential misbehaviour with parallel testing. Or you can have a separate CMake build for each individual target, but it's extra complexity. Having a proper means of registering such tests would be very, very nice. Regards, Roger -- 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 roman.wueger at gmx.at Tue Sep 5 03:44:49 2017 From: roman.wueger at gmx.at (=?utf-8?Q?Roman_W=C3=BCger?=) Date: Tue, 5 Sep 2017 09:44:49 +0200 Subject: [CMake] Path to vc_redist In-Reply-To: References: <66AEE89B-868C-41F6-8714-0DFFEE31B1B3@gmx.at> Message-ID: <6730E089-CC52-40D4-9C44-C953F8145AF0@gmx.at> Thank you Robert, I came up with the following, maybe someone has a better idea: if (WIN32) if(CMAKE_SIZEOF_VOID_P EQUAL 8) # 64-bit set(REDIST_ARCH x64) else() set(REDIST_ARCH x86) endif() set(REDIST_FILE vcredist_${REDIST_ARCH}.exe) set(CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP TRUE) include(InstallRequiredSystemLibraries) # Check if the list contains minimum one element, to get the path from list(LENGTHCMAKE_INSTALL_SYSTEM_RUNTIME_LIBS libsCount) if (libsCount GREATER 0) list(GET CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS 0 _path) get_filename_component(_path ${_path} DIRECTORY) get_filename_component(_path ${_path}/../../ ABSOLUTE) if (EXISTS "${_path}/${REDIST_FILE}") # VS 2017 set(REDIST_FILE ${_path}/${REDIST_FILE}) else() get_filename_component(_path ${_path}/1033ABSOLUTE) set(REDIST_FILE ${_path}/${REDIST_FILE}) endif() install(PROGRAMS ${_path}/${REDIST_FILE}) endif() endif() Regards Roman > Am 04.09.2017 um 15:20 schrieb Robert Maynard : > > You can use the InstallRequiredSystemLibraries to do this. Since it sounds like you don't want all the libraries installed, use CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS_SKIP and than deduce the path of vc_redist.exe from the value(s) in CMAKE_INSTALL_SYSTEM_RUNTIME_LIBS. > >> On Mon, Sep 4, 2017 at 3:01 AM, Roman W?ger wrote: >> Hello, >> >> is there already an existing function to get the vc_redist.exe for the current generator? >> >> Regards >> Roman >> -- >> >> 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 brad.king at kitware.com Tue Sep 5 07:31:36 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 5 Sep 2017 07:31:36 -0400 Subject: [CMake] CMake Coverage broken with Ninja In-Reply-To: <02f744e4-e714-e1ba-5acf-4a2e99ea3011@ascolab.com> References: <02f744e4-e714-e1ba-5acf-4a2e99ea3011@ascolab.com> Message-ID: <158d1e99-982c-70eb-5c9d-ebf74f0fce78@kitware.com> On 09/02/2017 03:14 AM, Gerhard Gappmeier wrote: > This is quite annoying, inconsistent with Makefiles and was already > reported once here: https://cmake.org/Bug/print_bug_page.php?bug_id=13894 > AFAIK this was never fixed. Discussion of that issue is now here: https://gitlab.kitware.com/cmake/cmake/issues/13894 We made a serious attempt to fix it, but ran into a major problem described here: https://gitlab.kitware.com/cmake/cmake/issues/13894#note_233789 Fixing it requires a feature in Ninja: https://github.com/ninja-build/ninja/issues/1251 I posted a proposal to their list about it but got no response: https://groups.google.com/forum/#!topic/ninja-build/yJvs7u0n2iA --- One may use out-of-source builds to get absolute paths to the files in the main source tree. -Brad From gerhard.gappmeier at ascolab.com Tue Sep 5 07:42:22 2017 From: gerhard.gappmeier at ascolab.com (Gerhard Gappmeier) Date: Tue, 5 Sep 2017 13:42:22 +0200 Subject: [CMake] CMake Coverage broken with Ninja In-Reply-To: <158d1e99-982c-70eb-5c9d-ebf74f0fce78@kitware.com> References: <02f744e4-e714-e1ba-5acf-4a2e99ea3011@ascolab.com> <158d1e99-982c-70eb-5c9d-ebf74f0fce78@kitware.com> Message-ID: <6daf52ad-5704-5bc1-28b7-9f6b83e57a9c@ascolab.com> Hi Brad, thanks for that information. It is great to see that you are working on this. Could you already verify if this problem is also the cause for the coverage issue? On 09/05/2017 01:31 PM, Brad King wrote: > On 09/02/2017 03:14 AM, Gerhard Gappmeier wrote: >> This is quite annoying, inconsistent with Makefiles and was already >> reported once here: https://cmake.org/Bug/print_bug_page.php?bug_id=13894 >> AFAIK this was never fixed. > Discussion of that issue is now here: > > https://gitlab.kitware.com/cmake/cmake/issues/13894 > > We made a serious attempt to fix it, but ran into a major problem > described here: > > https://gitlab.kitware.com/cmake/cmake/issues/13894#note_233789 > > Fixing it requires a feature in Ninja: > > https://github.com/ninja-build/ninja/issues/1251 > > I posted a proposal to their list about it but got no response: > > https://groups.google.com/forum/#!topic/ninja-build/yJvs7u0n2iA > > --- > > One may use out-of-source builds to get absolute paths to the files > in the main source tree. > > -Brad From brad.king at kitware.com Tue Sep 5 07:47:04 2017 From: brad.king at kitware.com (Brad King) Date: Tue, 5 Sep 2017 07:47:04 -0400 Subject: [CMake] CMake Coverage broken with Ninja In-Reply-To: <6daf52ad-5704-5bc1-28b7-9f6b83e57a9c@ascolab.com> References: <02f744e4-e714-e1ba-5acf-4a2e99ea3011@ascolab.com> <158d1e99-982c-70eb-5c9d-ebf74f0fce78@kitware.com> <6daf52ad-5704-5bc1-28b7-9f6b83e57a9c@ascolab.com> Message-ID: <031524c8-7c9e-10e7-2bb8-c460fdcc6b68@kitware.com> On 09/05/2017 07:42 AM, Gerhard Gappmeier wrote: > Could you already verify if this problem is also the cause for the > coverage issue? I tried your example in a fully out-of-source build (where the build tree is not inside the source tree), and coverage works. -Brad From rcdailey.lists at gmail.com Tue Sep 5 10:38:38 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 5 Sep 2017 09:38:38 -0500 Subject: [CMake] Should configuration package files define module package variables? In-Reply-To: References: Message-ID: On Sat, Sep 2, 2017 at 3:08 AM, P F wrote: > In general, if the library does not have any dependencies, you can just export the targets directly to the config.cmake file: > > install(TARGETS foo EXPORT foo-config) > install(EXPORT foo-config DESTINATION lib/cmake/foo) > > However, if the library has dependencies, you will need to iterate over them in the config.cmake file. That is if `foo` uses zlib, like this: > > find_package(ZLIB) > target_link_libraries(foo ZLIB::ZLIB) > > Then the foo-config.cmake needs to do this(assuming the export targets are written to foo-targets): > > include(CMakeFindDependencyMacro) > find_dependency(ZLIB) > include("${CMAKE_CURRENT_LIST_DIR}/foo-targets.cmake?) > > The reason for this is that the imported foo target will link against ZLIB::ZLIB, but it will not define it. Actually, the generated foo-targets.cmake will create an error if ZLIB::ZLIB doesn?t exists, which is why `find_dependency(ZLIB)`(which is really just `find_package` underneath) needs to be called before including the foo-targets.cmake. When you throw components in the mix, where you have 1 targets.cmake exported per component, each may have its own find_dependency() requirements. It would be nice if that was self-contained in the targets.cmake script itself, but there's no examples I could find on how to manage per-component find dependencies like this, especially if those components are put into `OPTIONAL_COMPONENTS`. Thanks for the information, it is very helpful! From eldlistmailingz at tropicsoft.com Tue Sep 5 12:33:37 2017 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Tue, 5 Sep 2017 12:33:37 -0400 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: <98e84b16-7590-63b4-1080-34db0eb9dc18@codelibre.net> References: <98e84b16-7590-63b4-1080-34db0eb9dc18@codelibre.net> Message-ID: On 9/4/2017 9:51 AM, Roger Leigh wrote: > On 04/09/17 14:40, Edward Diener wrote: >> Boost Build has tests for running an application successfully or not, >> for compiling one or more source files successfully or not, and for >> building one or more source files into an exe or not. These tests in >> Boost Build are the run/run-fail, compile/compile-fail, and >> link/link-fail rules. >> >> CMake/CTest has the exact equivalent to the run/run-fail rule in its >> add_test framework, but there is not add_test equivalent to the other >> two sets of rules. It sure would be nice, when Boost transitions to >> using CMake/CTest instead of Boost Build, if CMake/CTest had the >> equivalent of the other two sets of types of test in its add_test >> framework. >> >> Is there any consensus that these other two types of tests might be >> valuable for CMake/CTest, or any way to make this happen ? > > I've certainly wished for them.? Particularly when testing templated > code where you want to test that certain things fail correctly, e.g. via > static_assert or simply being invalid. I think that CMake has missed out on the simple fact that in modern C++ you can create compile-time tests/asserts rather than rely on run-time tests. In other words CMake has no provision for compile-time testing, only run-time testing. In this respect CMake is definitely behind the curve of modern C++ development. Of course unless the CMake developers wake up to this simple fact, and plan to provide compile-time testing, and possibly even build testing, ala Boost Build, to CMake it will remain behind the curve for modern C++ development. When the Boost Steering Committee decided to move Boost to using CMake in the near future, it may not have taken into account the fact that CMake might be missing something that modern C++ development in Boost uses via Boost Build. Unless there is some sort of push back to the CMake developers so that the needed functionality is added to CMake, it is going to be a long, hard road for converting from Boost Build to CMake for the Boost library and tools. This is not a knock against CMake, which is widely used and widely popular, but rather a recognition that Boost uses modern C++ and CMake may not provide all the building/testing facilities needed for a modern C++ development environment such as Boost. > > I understand it's possible to make this work partially, by creating > targets which aren't built by default, and then add tests which invoke > the targets.? But this appears to have some caveats, such as potential > misbehaviour with parallel testing.? Or you can have a separate CMake > build for each individual target, but it's extra complexity.? Having a > proper means of registering such tests would be very, very nice. > > > Regards, > Roger From eldlistmailingz at tropicsoft.com Tue Sep 5 12:44:17 2017 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Tue, 5 Sep 2017 12:44:17 -0400 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: References: <98e84b16-7590-63b4-1080-34db0eb9dc18@codelibre.net> Message-ID: On 9/5/2017 2:47 AM, Dvir Yitzchaki wrote: > There's already CheckCXXSourceCompiles and friends. > The only problem is that try_compile is not scriptable otherwise you could let the test invoke > ${CMAKE_COMMAND} -P check_source_compiles.cmake. To put it succinctly CMake should adding compile-time testing so that when some compilation succeeds the test is successful and if the compilation fails the test is not successful, with the proviso that you can reverse the result as a compile should fail type of test. Similarly a build type testing, without having to run anything should be added along the same lines. In modern C++ it is perfectly feasible, especially with template programming, to do compile time testing, invoking a compile-time static assert as a compile-time failure. Boost has had this for years and modern C++ has it as part of the latest version of the C++ standard. CMake needs to update itself to the reality that pure compile-time testing is a reality for modern C++ and should update itself accordingly. Only having run-time testing is an artifact of the past. Hopefully CMake developers will get the message and make the necessary update to CMake/CTest. > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Roger Leigh > Sent: Monday, September 4, 2017 16:51 > To: cmake at cmake.org > Subject: Re: [CMake] Adding compile and build type tests to CMake/CTest > > On 04/09/17 14:40, Edward Diener wrote: >> Boost Build has tests for running an application successfully or not, >> for compiling one or more source files successfully or not, and for >> building one or more source files into an exe or not. These tests in >> Boost Build are the run/run-fail, compile/compile-fail, and >> link/link-fail rules. >> >> CMake/CTest has the exact equivalent to the run/run-fail rule in its >> add_test framework, but there is not add_test equivalent to the other >> two sets of rules. It sure would be nice, when Boost transitions to >> using CMake/CTest instead of Boost Build, if CMake/CTest had the >> equivalent of the other two sets of types of test in its add_test >> framework. >> >> Is there any consensus that these other two types of tests might be >> valuable for CMake/CTest, or any way to make this happen ? > > I've certainly wished for them. Particularly when testing templated code where you want to test that certain things fail correctly, e.g. via static_assert or simply being invalid. > > I understand it's possible to make this work partially, by creating targets which aren't built by default, and then add tests which invoke the targets. But this appears to have some caveats, such as potential misbehaviour with parallel testing. Or you can have a separate CMake build for each individual target, but it's extra complexity. Having a proper means of registering such tests would be very, very nice. > > > Regards, > Roger > From rcdailey.lists at gmail.com Tue Sep 5 15:33:32 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 5 Sep 2017 14:33:32 -0500 Subject: [CMake] How should config packages handle components? In-Reply-To: References: Message-ID: In the case where I'm exporting 1 target.cmake script per component for a single package, could someone provide an example on how to manage dependencies? There are 2 types of dependencies: 1. Dependencies on external packages 2. Cross-dependencies within the same package (i.e. on other components in the same package) The cmake-packages doc kind of goes over #1, but #2 doesn't seem to have examples. On Fri, Sep 1, 2017 at 1:21 PM, Robert Dailey wrote: > First of all, I want to apologize for including the developer list. > Maybe I'm not being patient enough, but it seems like every post I've > made on the normal users list doesn't get any attention. > > Secondly, the cmake-packages portion of the cmake documentation > doesn't go into a ton of detail about components, but it does give an > example towards the bottom of how you export targets for components. > This leads to my questions: > > When defining the target exports via install(TARGET foo EXPORT > foo-export), is it recommended for all components to collectively > export as 1 target.cmake script? Or is it better to have 1 > target.cmake script per component? If we use Boost as an example, the > latter would mean having: > > boost-config.cmake > boost-target-filesystem.cmake > boost-target-thread.cmake > ...etc... > > This means that boost-config.cmake would "include()" only the relevant > target cmake scripts based on the provided COMPONENTS list, I assume? > > Which is the better approach here and why? > > One problem I thought of with the former (one big target.cmake with > all import targets in there) is that if you only ask for a subset of > components in find_package(), you will still get all of them since all > imports are defined in a single file. Does this go against any design > principles? Assuming this really happens, are there any negative side > effects? From irwin at beluga.phys.uvic.ca Wed Sep 6 03:29:35 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Wed, 6 Sep 2017 00:29:35 -0700 (PDT) Subject: [CMake] How should config packages handle components? In-Reply-To: References: Message-ID: On 2017-09-05 14:33-0500 Robert Dailey wrote: > In the case where I'm exporting 1 target.cmake script per component > for a single package, could someone provide an example on how to > manage dependencies? There are 2 types of dependencies: > > 1. Dependencies on external packages > 2. Cross-dependencies within the same package (i.e. on other > components in the same package) > > The cmake-packages doc kind of goes over #1, but #2 doesn't seem to > have examples. Hi Robert: This is an interesting topic to me because I am not at all satisfied with the way that PLplot currently exports its components (which have both kinds of the above dependencies). I implemented those exports a decade ago so the result is far from best practices. Therefore, I am glad you have brought up this topic, and I am looking forward to seeing how your questions are finally answered. To make it easier to get those final answers on best export practices, I suggest you implement the simplest possible example with say two components that have the two kinds of dependencies above. Then follow up by asking the experts here to comment on the best export practices for that simple example with the goal that once your simple example has been modified to use best export practices that it should be published in the CMake Wiki. Such an example would be a big help to me and I presume others as well who want to modernize the exports from their project or who are designing a build system from scratch for a project with multiple components that are exported. By the way, I think cross-posting is a bad idea since it means those subscribed to both lists always get annoying duplicate posts. So I have thought about which list should be used for this topic, and my conclusion is it belongs on the CMake list for now since it is about how to use CMake rather than about some suggested CMake implementation change. But it can always be moved later to the CMake developer list in the unlikely event that some CMake implementation change is required to allow build-system designers to follow best export practices. 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 robert.maynard at kitware.com Wed Sep 6 09:38:01 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 6 Sep 2017 09:38:01 -0400 Subject: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E7098F2D4@EXMBS2.ad.igd.fraunhofer.de> References: <8D981219EEA621479C112DA9BDC39A8E7098F2D4@EXMBS2.ad.igd.fraunhofer.de> Message-ID: As far as gencode goes, your line has errors. With CUDA 8 it should look like: -gencode arch=compute_20,code=\"sm_20,compute_20\" On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > I?m having two issues with debug symbols for CUDA libraries on a project: > > > > 1. The PDBs are not placed where the linker later expects to find > them (haven?t been able to replicate this in a minimal project yet) > > 2. Trying to circumnavigate this issue by using ?/Z7? instead of > ?/Zi? does not work, Zi is always used (replicable in any project with CUDA) > > Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by > -Z7 or /Z7. Build and see several warnings like ?cl : Command line warning > D9025: overriding '/Z7' with '/Zi'? in the output window. > And do the flags in the ?Xcompiler make sense at all in VS? The CUDA build > tools seem to determine these automatically anyways? for example I get the > following call in the above scenario: > > "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" > -gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env > --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio > 14.0\VC\bin\amd64" -I"C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 > --machine 64 --compile -cudart static -Xcompiler="/EHsc -Z7 -Ob0" -g > -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o > A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu" > > 3. Also, -gencode flags do not behave as expected when given in the > form -gencode=arch=compute_20,code="sm_20,compute_20", as this causes the > VS build system to error out: > > C:\Program Files (x86)\MSBuild\Microsoft.Cpp\ > v4.0\V140\BuildCustomizations\CUDA 8.0.targets(216,9): error : Item > '..\..\a\a.cu' Code Generation value is not in the expected format > '[Arch],[Code]'. > > The code generation value in this example is set to > compute_20,sm_20,compute_20 by CMake. > > > > Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD > > Fraunhoferstr. 5 | 64283 Darmstadt | Germany > > Tel +49 6151 155-606 <+49%206151%20155606> | Fax +49 6151 155-139 > <+49%206151%20155139> > > johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de > > > > -- > > 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 Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Wed Sep 6 10:36:07 2017 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Wed, 6 Sep 2017 14:36:07 +0000 Subject: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues In-Reply-To: References: <8D981219EEA621479C112DA9BDC39A8E7098F2D4@EXMBS2.ad.igd.fraunhofer.de> Message-ID: <8D981219EEA621479C112DA9BDC39A8E7098FE44@EXMBS2.ad.igd.fraunhofer.de> If the comment is wrt 3., the result is the same no matter if I use a space or an equals sign, if I double escape the quotes (e.g., use the value as you wrote it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS becomes compute_20,"sm_20,compute_20" instead of compute_20,sm_20,compute_20, which is equally illegal and will cause the same error message, also double escaping should not be necessary for a subset of flags (Xcompiler works fine without it, even if the default values are pointless). If the comment is wrt 2., this is the line automatically generated by CMake/VS when not passing in any gencode flags explicitly. Or am I misunderstanding what you mean? Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de From: Robert Maynard [mailto:robert.maynard at kitware.com] Sent: Wednesday, September 6, 2017 15:38 To: Mueller-Roemer, Johannes Sebastian Cc: cmake at cmake.org Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues As far as gencode goes, your line has errors. With CUDA 8 it should look like: -gencode arch=compute_20,code=\"sm_20,compute_20\" On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian > wrote: I?m having two issues with debug symbols for CUDA libraries on a project: 1. The PDBs are not placed where the linker later expects to find them (haven?t been able to replicate this in a minimal project yet) 2. Trying to circumnavigate this issue by using ?/Z7? instead of ?/Zi? does not work, Zi is always used (replicable in any project with CUDA) Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by -Z7 or /Z7. Build and see several warnings like ?cl : Command line warning D9025: overriding '/Z7' with '/Zi'? in the output window. And do the flags in the ?Xcompiler make sense at all in VS? The CUDA build tools seem to determine these automatically anyways? for example I get the following call in the above scenario: "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" -gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -cudart static -Xcompiler="/EHsc -Z7 -Ob0" -g -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu" 3. Also, -gencode flags do not behave as expected when given in the form -gencode=arch=compute_20,code="sm_20,compute_20", as this causes the VS build system to error out: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations\CUDA 8.0.targets(216,9): error : Item '..\..\a\a.cu' Code Generation value is not in the expected format '[Arch],[Code]'. The code generation value in this example is set to compute_20,sm_20,compute_20 by CMake. Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de -- 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 robert.maynard at kitware.com Wed Sep 6 10:44:21 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 6 Sep 2017 10:44:21 -0400 Subject: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E7098FE44@EXMBS2.ad.igd.fraunhofer.de> References: <8D981219EEA621479C112DA9BDC39A8E7098F2D4@EXMBS2.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E7098FE44@EXMBS2.ad.igd.fraunhofer.de> Message-ID: Yes I was responding to comment 3. I am curious, does the longer form signature "-gencode arch=compute_20,code=sm_20 -gencode arch=compute_20,code=compute_20" work correctly? CMake has to parse the gencode flags and move them to special msbuild entries, and I wonder if there is a bug when parsing multiple code options. On Wed, Sep 6, 2017 at 10:36 AM, Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > If the comment is wrt 3., the result is the same no matter if I use a > space or an equals sign, if I double escape the quotes (e.g., use the value > as you wrote it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS > becomes compute_20,"sm_20,compute_20" instead of > compute_20,sm_20,compute_20, which is equally illegal and will cause the > same error message, also double escaping should not be necessary for a > subset of flags (Xcompiler works fine without it, even if the default > values are pointless). > > If the comment is wrt 2., this is the line automatically generated by > CMake/VS when not passing in any gencode flags explicitly. > > > > Or am I misunderstanding what you mean? > > > > Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD > > Fraunhoferstr. 5 | 64283 Darmstadt | Germany > > Tel +49 6151 155-606 <+49%206151%20155606> | Fax +49 6151 155-139 > <+49%206151%20155139> > > johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de > > > > *From:* Robert Maynard [mailto:robert.maynard at kitware.com] > *Sent:* Wednesday, September 6, 2017 15:38 > *To:* Mueller-Roemer, Johannes Sebastian Roemer at igd.fraunhofer.de> > *Cc:* cmake at cmake.org > *Subject:* Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags > issues > > > > As far as gencode goes, your line has errors. With CUDA 8 it should look > like: > > -gencode arch=compute_20,code=\"sm_20,compute_20\" > > > > > > On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian < > Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > > I?m having two issues with debug symbols for CUDA libraries on a project: > > > > 1. The PDBs are not placed where the linker later expects to find > them (haven?t been able to replicate this in a minimal project yet) > > 2. Trying to circumnavigate this issue by using ?/Z7? instead of > ?/Zi? does not work, Zi is always used (replicable in any project with CUDA) > > Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by > -Z7 or /Z7. Build and see several warnings like ?cl : Command line warning > D9025: overriding '/Z7' with '/Zi'? in the output window. > And do the flags in the ?Xcompiler make sense at all in VS? The CUDA build > tools seem to determine these automatically anyways? for example I get the > following call in the above scenario: > > "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" > -gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env > --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio > 14.0\VC\bin\amd64" -I"C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 > --machine 64 --compile -cudart static -Xcompiler="/EHsc -Z7 -Ob0" -g > -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o > A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu" > > 3. Also, -gencode flags do not behave as expected when given in the > form -gencode=arch=compute_20,code="sm_20,compute_20", as this causes the > VS build system to error out: > > C:\Program Files (x86)\MSBuild\Microsoft.Cpp\ > v4.0\V140\BuildCustomizations\CUDA 8.0.targets(216,9): error : Item > '..\..\a\a.cu' Code Generation value is not in the expected format > '[Arch],[Code]'. > > The code generation value in this example is set to > compute_20,sm_20,compute_20 by CMake. > > > > Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD > > Fraunhoferstr. 5 | 64283 Darmstadt | Germany > > Tel +49 6151 155-606 <+49%206151%20155606> | Fax +49 6151 155-139 > <+49%206151%20155139> > > johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de > > > > > -- > > 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 Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Wed Sep 6 11:16:24 2017 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Wed, 6 Sep 2017 15:16:24 +0000 Subject: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues In-Reply-To: References: <8D981219EEA621479C112DA9BDC39A8E7098F2D4@EXMBS2.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E7098FE44@EXMBS2.ad.igd.fraunhofer.de> Message-ID: <8D981219EEA621479C112DA9BDC39A8E7098FE66@EXMBS2.ad.igd.fraunhofer.de> The long form fills the Code Generation field with compute_20,sm_20;compute_20,compute_20 (the default without gencode parameters is compute_20,sm_20) and results in the following command line: D:\jsroemer\projects\cuda-pdb-test\build\a>"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" -gencode=arch=compute_20,code=\"sm_20,compute_20\" -gencode=arch=compute_20,code=\"compute_20,compute_20\" --use-local-env --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -cudart static -Xcompiler="/EHsc -Zi -Ob0" -g -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu" Which is somewhat redundant MSVC turns compute_20,sm_20 into -gencode=arch=compute_20,code=\"sm_20,compute_20\" and compute_20,compute_20 into -gencode=arch=compute_20,code=\"compute_20,compute_20\" Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de From: Robert Maynard [mailto:robert.maynard at kitware.com] Sent: Wednesday, September 6, 2017 16:44 To: Mueller-Roemer, Johannes Sebastian Cc: cmake at cmake.org Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues Yes I was responding to comment 3. I am curious, does the longer form signature "-gencode arch=compute_20,code=sm_20 -gencode arch=compute_20,code=compute_20" work correctly? CMake has to parse the gencode flags and move them to special msbuild entries, and I wonder if there is a bug when parsing multiple code options. On Wed, Sep 6, 2017 at 10:36 AM, Mueller-Roemer, Johannes Sebastian > wrote: If the comment is wrt 3., the result is the same no matter if I use a space or an equals sign, if I double escape the quotes (e.g., use the value as you wrote it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS becomes compute_20,"sm_20,compute_20" instead of compute_20,sm_20,compute_20, which is equally illegal and will cause the same error message, also double escaping should not be necessary for a subset of flags (Xcompiler works fine without it, even if the default values are pointless). If the comment is wrt 2., this is the line automatically generated by CMake/VS when not passing in any gencode flags explicitly. Or am I misunderstanding what you mean? Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de From: Robert Maynard [mailto:robert.maynard at kitware.com] Sent: Wednesday, September 6, 2017 15:38 To: Mueller-Roemer, Johannes Sebastian > Cc: cmake at cmake.org Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues As far as gencode goes, your line has errors. With CUDA 8 it should look like: -gencode arch=compute_20,code=\"sm_20,compute_20\" On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian > wrote: I?m having two issues with debug symbols for CUDA libraries on a project: 1. The PDBs are not placed where the linker later expects to find them (haven?t been able to replicate this in a minimal project yet) 2. Trying to circumnavigate this issue by using ?/Z7? instead of ?/Zi? does not work, Zi is always used (replicable in any project with CUDA) Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by -Z7 or /Z7. Build and see several warnings like ?cl : Command line warning D9025: overriding '/Z7' with '/Zi'? in the output window. And do the flags in the ?Xcompiler make sense at all in VS? The CUDA build tools seem to determine these automatically anyways? for example I get the following call in the above scenario: "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" -gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -cudart static -Xcompiler="/EHsc -Z7 -Ob0" -g -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu" 3. Also, -gencode flags do not behave as expected when given in the form -gencode=arch=compute_20,code="sm_20,compute_20", as this causes the VS build system to error out: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations\CUDA 8.0.targets(216,9): error : Item '..\..\a\a.cu' Code Generation value is not in the expected format '[Arch],[Code]'. The code generation value in this example is set to compute_20,sm_20,compute_20 by CMake. Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de -- 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 robert.maynard at kitware.com Wed Sep 6 12:58:38 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 6 Sep 2017 12:58:38 -0400 Subject: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E7098FE66@EXMBS2.ad.igd.fraunhofer.de> References: <8D981219EEA621479C112DA9BDC39A8E7098F2D4@EXMBS2.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E7098FE44@EXMBS2.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E7098FE66@EXMBS2.ad.igd.fraunhofer.de> Message-ID: So it works when they are separate gen-code options, but fails when they are combined. Is that correct? On Wed, Sep 6, 2017 at 11:16 AM, Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > The long form fills the Code Generation field with > compute_20,sm_20;compute_20,compute_20 (the default without gencode > parameters is compute_20,sm_20) and results in the following command line: > > > > D:\jsroemer\projects\cuda-pdb-test\build\a>"C:\Program Files\NVIDIA GPU > Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" -gencode=arch=compute_20,code=\"sm_20,compute_20\" > -gencode=arch=compute_20,code=\"compute_20,compute_20\" --use-local-env > --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio > 14.0\VC\bin\amd64" -I"C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 > --machine 64 --compile -cudart static -Xcompiler="/EHsc -Zi -Ob0" -g > -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o > A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu" > > > > Which is somewhat redundant > > > > MSVC turns compute_20,sm_20 into -gencode=arch=compute_20,code=\"sm_20,compute_20\" > and compute_20,compute_20 into -gencode=arch=compute_20,code= > \"compute_20,compute_20\" > > > > > > Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD > > Fraunhoferstr. 5 | 64283 Darmstadt | Germany > > Tel +49 6151 155-606 <+49%206151%20155606> | Fax +49 6151 155-139 > <+49%206151%20155139> > > johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de > > > > *From:* Robert Maynard [mailto:robert.maynard at kitware.com] > *Sent:* Wednesday, September 6, 2017 16:44 > > *To:* Mueller-Roemer, Johannes Sebastian Roemer at igd.fraunhofer.de> > *Cc:* cmake at cmake.org > *Subject:* Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags > issues > > > > Yes I was responding to comment 3. > > > > I am curious, does the longer form signature "-gencode > arch=compute_20,code=sm_20 -gencode arch=compute_20,code=compute_20" > work correctly? CMake has to parse the gencode flags and move them to > special msbuild entries, and I wonder if there is a bug when parsing > multiple code options. > > > > On Wed, Sep 6, 2017 at 10:36 AM, Mueller-Roemer, Johannes Sebastian < > Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > > If the comment is wrt 3., the result is the same no matter if I use a > space or an equals sign, if I double escape the quotes (e.g., use the value > as you wrote it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS > becomes compute_20,"sm_20,compute_20" instead of > compute_20,sm_20,compute_20, which is equally illegal and will cause the > same error message, also double escaping should not be necessary for a > subset of flags (Xcompiler works fine without it, even if the default > values are pointless). > > If the comment is wrt 2., this is the line automatically generated by > CMake/VS when not passing in any gencode flags explicitly. > > > > Or am I misunderstanding what you mean? > > > > Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD > > Fraunhoferstr. 5 | 64283 Darmstadt | Germany > > Tel +49 6151 155-606 <+49%206151%20155606> | Fax +49 6151 155-139 > <+49%206151%20155139> > > johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de > > > > *From:* Robert Maynard [mailto:robert.maynard at kitware.com] > *Sent:* Wednesday, September 6, 2017 15:38 > *To:* Mueller-Roemer, Johannes Sebastian Roemer at igd.fraunhofer.de> > *Cc:* cmake at cmake.org > *Subject:* Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags > issues > > > > As far as gencode goes, your line has errors. With CUDA 8 it should look > like: > > -gencode arch=compute_20,code=\"sm_20,compute_20\" > > > > > > On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian < > Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > > I?m having two issues with debug symbols for CUDA libraries on a project: > > > > 1. The PDBs are not placed where the linker later expects to find > them (haven?t been able to replicate this in a minimal project yet) > > 2. Trying to circumnavigate this issue by using ?/Z7? instead of > ?/Zi? does not work, Zi is always used (replicable in any project with CUDA) > > Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by > -Z7 or /Z7. Build and see several warnings like ?cl : Command line warning > D9025: overriding '/Z7' with '/Zi'? in the output window. > And do the flags in the ?Xcompiler make sense at all in VS? The CUDA build > tools seem to determine these automatically anyways? for example I get the > following call in the above scenario: > > "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" > -gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env > --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio > 14.0\VC\bin\amd64" -I"C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 > --machine 64 --compile -cudart static -Xcompiler="/EHsc -Z7 -Ob0" -g > -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o > A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu" > > 3. Also, -gencode flags do not behave as expected when given in the > form -gencode=arch=compute_20,code="sm_20,compute_20", as this causes the > VS build system to error out: > > C:\Program Files (x86)\MSBuild\Microsoft.Cpp\ > v4.0\V140\BuildCustomizations\CUDA 8.0.targets(216,9): error : Item > '..\..\a\a.cu' Code Generation value is not in the expected format > '[Arch],[Code]'. > > The code generation value in this example is set to > compute_20,sm_20,compute_20 by CMake. > > > > Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD > > Fraunhoferstr. 5 | 64283 Darmstadt | Germany > > Tel +49 6151 155-606 <+49%206151%20155606> | Fax +49 6151 155-139 > <+49%206151%20155139> > > johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de > > > > > -- > > 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 rcdailey.lists at gmail.com Wed Sep 6 14:24:18 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 6 Sep 2017 13:24:18 -0500 Subject: [CMake] configuration packages, IMPORTED targets, and global scope Message-ID: So it took me a while to figure out why find_package() calls I was making (with CONFIG) option were not accessible outside of the directory in which it was invoked. I realized that all targets seem to be global by default except IMPORTED targets (according to add_library() docs). I find this counterintuitive, since I expect imported targets to behave the same as normal ones WRT scope. Is there a reason that imported targets need to be explicitly made GLOBAL? Barring that, I'd like to find some way to make find_package() convert those imported targets to global. I don't see a target property I can set or a command I can call to make an existing imported target a global one. Any thoughts on workarounds? If there are none, are there some changes we could make to CMake to support this behavior? My use case is that I have a subdirectory I step into, which builds various third party libraries and then follows up with a find_package() call. I do this in a isolated but central place because I have to set up various variables like CMAKE_PREFIX_PATH and many others to isolate searches to a controlled location. Beyond this, if a target needs one of these third party libs, the expectation is that they only have to do target_link_libraries() with the import target names to use those libs. However, because they are out of scope, they can't use them. From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Wed Sep 6 15:19:59 2017 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Wed, 6 Sep 2017 19:19:59 +0000 Subject: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues In-Reply-To: References: <8D981219EEA621479C112DA9BDC39A8E7098F2D4@EXMBS2.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E7098FE44@EXMBS2.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E7098FE66@EXMBS2.ad.igd.fraunhofer.de>, Message-ID: <8D981219EEA621479C112DA9BDC39A8E7098FE9C@EXMBS2.ad.igd.fraunhofer.de> Yes ________________________________ From: Robert Maynard [robert.maynard at kitware.com] Sent: Wednesday, September 06, 2017 6:58 PM To: Mueller-Roemer, Johannes Sebastian Cc: cmake at cmake.org Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues So it works when they are separate gen-code options, but fails when they are combined. Is that correct? On Wed, Sep 6, 2017 at 11:16 AM, Mueller-Roemer, Johannes Sebastian > wrote: The long form fills the Code Generation field with compute_20,sm_20;compute_20,compute_20 (the default without gencode parameters is compute_20,sm_20) and results in the following command line: D:\jsroemer\projects\cuda-pdb-test\build\a>"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" -gencode=arch=compute_20,code=\"sm_20,compute_20\" -gencode=arch=compute_20,code=\"compute_20,compute_20\" --use-local-env --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -cudart static -Xcompiler="/EHsc -Zi -Ob0" -g -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu" Which is somewhat redundant MSVC turns compute_20,sm_20 into -gencode=arch=compute_20,code=\"sm_20,compute_20\" and compute_20,compute_20 into -gencode=arch=compute_20,code=\"compute_20,compute_20\" Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de From: Robert Maynard [mailto:robert.maynard at kitware.com] Sent: Wednesday, September 6, 2017 16:44 To: Mueller-Roemer, Johannes Sebastian > Cc: cmake at cmake.org Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues Yes I was responding to comment 3. I am curious, does the longer form signature "-gencode arch=compute_20,code=sm_20 -gencode arch=compute_20,code=compute_20" work correctly? CMake has to parse the gencode flags and move them to special msbuild entries, and I wonder if there is a bug when parsing multiple code options. On Wed, Sep 6, 2017 at 10:36 AM, Mueller-Roemer, Johannes Sebastian > wrote: If the comment is wrt 3., the result is the same no matter if I use a space or an equals sign, if I double escape the quotes (e.g., use the value as you wrote it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS becomes compute_20,"sm_20,compute_20" instead of compute_20,sm_20,compute_20, which is equally illegal and will cause the same error message, also double escaping should not be necessary for a subset of flags (Xcompiler works fine without it, even if the default values are pointless). If the comment is wrt 2., this is the line automatically generated by CMake/VS when not passing in any gencode flags explicitly. Or am I misunderstanding what you mean? Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de From: Robert Maynard [mailto:robert.maynard at kitware.com] Sent: Wednesday, September 6, 2017 15:38 To: Mueller-Roemer, Johannes Sebastian > Cc: cmake at cmake.org Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues As far as gencode goes, your line has errors. With CUDA 8 it should look like: -gencode arch=compute_20,code=\"sm_20,compute_20\" On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian > wrote: I?m having two issues with debug symbols for CUDA libraries on a project: 1. The PDBs are not placed where the linker later expects to find them (haven?t been able to replicate this in a minimal project yet) 2. Trying to circumnavigate this issue by using ?/Z7? instead of ?/Zi? does not work, Zi is always used (replicable in any project with CUDA) Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by -Z7 or /Z7. Build and see several warnings like ?cl : Command line warning D9025: overriding '/Z7' with '/Zi'? in the output window. And do the flags in the ?Xcompiler make sense at all in VS? The CUDA build tools seem to determine these automatically anyways? for example I get the following call in the above scenario: "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" -gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -cudart static -Xcompiler="/EHsc -Z7 -Ob0" -g -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu" 3. Also, -gencode flags do not behave as expected when given in the form -gencode=arch=compute_20,code="sm_20,compute_20", as this causes the VS build system to error out: C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations\CUDA 8.0.targets(216,9): error : Item '..\..\a\a.cu' Code Generation value is not in the expected format '[Arch],[Code]'. The code generation value in this example is set to compute_20,sm_20,compute_20 by CMake. Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD Fraunhoferstr. 5 | 64283 Darmstadt | Germany Tel +49 6151 155-606 | Fax +49 6151 155-139 johannes.mueller-roemer at igd.fraunhofer.de | www.igd.fraunhofer.de -- 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 rcdailey.lists at gmail.com Wed Sep 6 17:26:32 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Wed, 6 Sep 2017 16:26:32 -0500 Subject: [CMake] Configuration packages & versioning for parallel installations Message-ID: First obvious question is: Should this even be a concern? The cmake-packages documentation doesn't really touch on versioning, but there are a couple of concerns I see when you want users to be able to install (with CMake) multiple versions of the same library side-by-side: 1. The library files have to use VERSION or SOVERSION properties to affect their name (this needs to be consistent on all platforms) 2. Debug configurations should alter the name of the library (to support multi-configuration generators like Visual Studio, for the most part, but also useful to single-configuration generators) 3. Header file installation: How do you do versioning? How do you have a foo.h that is version 1.0, and a foo.h that is version 2.0? Does this even make sense? One approach I've taken so far is: 1. CMake scripts like config scripts and exported target scripts go under "share/libraryname-1.0/cmake" 2. Library names follow a format like "libfoo-1.0.0", or "libfoo-1.0.0-debug" for debug versions of that same library. I have no answer for include files. From i.zaufi at gmail.com Wed Sep 6 17:55:32 2017 From: i.zaufi at gmail.com (Alex Turbov) Date: Thu, 7 Sep 2017 00:55:32 +0300 Subject: [CMake] [cmake-developers] How should config packages handle components? In-Reply-To: References: Message-ID: In my projects I always, have external dependencies with finder module providing exported (imported in my project) targets, so my targets (one per file) always have a list of `Vendor::target`. Some of them are mine (i.e. your type 2 -- built by the same project). I wrote a helper module and a function to write an additional `blah-blah-target-depedencies.cmake`. And this is a little bit subtle thing... Normally, generated `blah-blah-target.cmake` (where the `blah-blah-target` is the export name used in call to `install(EXPORT)`) to load all installed configurations do the following: file(GLOB CONFIG_FILES "${_DIR}/blah-blah-target-*.cmake") so my additional file would be loaded "automatically" :) My helper function accepts a target name as the only parameter. First of all, it collects all dependencies of the given target and classifies them as internal (same project) and external. It prepares some variables and finally, render a `blah-blah-target-dependencies.cmake` which is a result of the combination of 3 templates: 0) a base, header+footer and conditionally "include" the next two 1) import internal dependencies 2) import external dependencies Note templates have random string in final names, so being running (loading) by the same script (`blah-blah-config.cmake`) won't interfere... As for "prepared variables" there are the following: * "internal dependencies" is just a list of target names... having a name is enough to form a `blah-blah-target.cmake` name to be `include()`d, cuz we really know where this file is installed * for external dependencies the most important a list of packages, assuming that the initial external (imported) target had the form of `Vendor::target`, and `Vendor` in fact is a package name suitable as the first argument to `find_package()`. * other variables related to external targets have a variadic part based on upcased name of the vendor. Example: set(_blah_blah_PACKAGES ACE;Boost) set(_blah_blah_ACE_VENDOR ACE) set(_blah_blah_ACE_COMPONENTS ace;ssl) set(_blah_blah_ACE_VERSION 5.7.5) set(_blah_blah_BOOST_VENDOR Boost) set(_blah_blah_BOOST_COMPONENTS chrono;filesystem;program_options;thread) set(_blah_blah_BOOST_VERSION 1.65.0) Now about generated `*-config.cmake`. As one may guess it handle targets to import as `COMPONENTS` of `find_package()`, where every component is an exported target name. So this module just `include()` it and check if target appeared: # Find components if requested set(blah_FOUND_COMPONENTS) foreach(_module ${blah_FIND_COMPONENTS}) # TODO Avoid more than once find? (But be aware that is not a trivial `if` and skip %-) # TODO Make sure component is supported (exists) include( "${CMAKE_CURRENT_LIST_DIR}/blah-${_module}-targets.cmake" OPTIONAL RESULT_VARIABLE blah_${_module}_FOUND ) if(blah_${_module}_FOUND AND TARGET Blah::${_module}) list(APPEND blah_FOUND_COMPONENTS ${_module}) # Add some interface properties to all found components string(TOUPPER "${_module}" _module_id) string(MAKE_C_IDENTIFIER "${_module_id}" _module_id) set_target_properties( Blah::${_module} PROPERTIES # Set compatible version usage requirement INTERFACE_BLAH_VERSION_MAJOR "${BLAH_VERSION_MAJOR}" # What package to find INTERFACE_BLAH_${_module_id}_PACKAGE_NAME "blah" ) set_property( TARGET Blah::${_module} APPEND PROPERTY COMPATIBLE_INTERFACE_STRING BLAH_VERSION_MAJOR ) unset(_module_id) else() set(blah_${_module}_FOUND NOTFOUND) if (blah_FIND_REQUIRED_${_module}) list(APPEND blah_NOT_FOUND_REQUIRED_COMPONENTS ${_module}) else() list(APPEND blah_NOT_FOUND_COMPONENTS ${_module}) endif() endif() endforeach() unset(_module) When all components checked call the final package found/not-found checker: check_required_components(blah) Yes, this particular implementation have obvious limitations to be named "universal and generic", but it works few years for me w/o problems... (however, I do some improvements from time to time %) It do not handle "plain old library names"... and as I said, all my external packages provide imported targets, where the Vendor name is the package name in fact... so I don't care (while having no reason to improve it for this case... maybe later %). I'll attach my module (stripping not related and vendor specific parts) for further inspiration... Feel free to ask for details (or more code, if attached doesn't work... probably I miss some functions (from other parts of my framework)). Have fun! :) On Tue, Sep 5, 2017 at 10:33 PM, Robert Dailey wrote: > In the case where I'm exporting 1 target.cmake script per component > for a single package, could someone provide an example on how to > manage dependencies? There are 2 types of dependencies: > > 1. Dependencies on external packages > 2. Cross-dependencies within the same package (i.e. on other > components in the same package) > > The cmake-packages doc kind of goes over #1, but #2 doesn't seem to > have examples. > > On Fri, Sep 1, 2017 at 1:21 PM, Robert Dailey > wrote: > > First of all, I want to apologize for including the developer list. > > Maybe I'm not being patient enough, but it seems like every post I've > > made on the normal users list doesn't get any attention. > > > > Secondly, the cmake-packages portion of the cmake documentation > > doesn't go into a ton of detail about components, but it does give an > > example towards the bottom of how you export targets for components. > > This leads to my questions: > > > > When defining the target exports via install(TARGET foo EXPORT > > foo-export), is it recommended for all components to collectively > > export as 1 target.cmake script? Or is it better to have 1 > > target.cmake script per component? If we use Boost as an example, the > > latter would mean having: > > > > boost-config.cmake > > boost-target-filesystem.cmake > > boost-target-thread.cmake > > ...etc... > > > > This means that boost-config.cmake would "include()" only the relevant > > target cmake scripts based on the provided COMPONENTS list, I assume? > > > > Which is the better approach here and why? > > > > One problem I thought of with the former (one big target.cmake with > > all import targets in there) is that if you only ask for a subset of > > components in find_package(), you will still get all of them since all > > imports are defined in a single file. Does this go against any design > > principles? Assuming this really happens, are there any negative side > > effects? > -- > > 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-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cmake-export-dependencies.tar.bz2 Type: application/x-bzip2 Size: 5200 bytes Desc: not available URL: From i.zaufi at gmail.com Wed Sep 6 18:17:01 2017 From: i.zaufi at gmail.com (Alex Turbov) Date: Thu, 7 Sep 2017 01:17:01 +0300 Subject: [CMake] Configuration packages & versioning for parallel installations In-Reply-To: References: Message-ID: Hi, On Thu, Sep 7, 2017 at 12:26 AM, Robert Dailey wrote: > First obvious question is: Should this even be a concern? Yes, definitely! > The > cmake-packages documentation doesn't really touch on versioning, but > there are a couple of concerns I see when you want users to be able to > install (with CMake) multiple versions of the same library > side-by-side: > that is quite usual practice (at least for me) to have multiple versions installed and (try) link my package w/ 'em. > > 1. The library files have to use VERSION or SOVERSION properties to > affect their name (this needs to be consistent on all platforms) > I use versioned static libraries on all platforms (*NIX/Linux and Windows) and dynamic in Windows only. For linux dynamic libraries use traditional format `libblah.so.X.Y.Z`. (yea w/ VERSION and SOVERSION properties) > 2. Debug configurations should alter the name of the library (to > support multi-configuration generators like Visual Studio, for the > most part, but also useful to single-configuration generators) > I do it for Windows only... (just don't need it for linux, where I prefer a single ocnifuration to be installed, just like most pakcages do in my Gentoo). > 3. Header file installation: How do you do versioning? How do you have > a foo.h that is version 1.0, and a foo.h that is version 2.0? Does > this even make sense? > Header files installed into `/usr/include/package-X.Y.Z/`, and exported targets always know this (and set the corresponding INTERFACE properties) > > One approach I've taken so far is: > > 1. CMake scripts like config scripts and exported target scripts go > under "share/libraryname-1.0/cmake" > yep, it would work... for linux personally I prefer `/usr/lib/cmake/package-X.Y.Z/` > 2. Library names follow a format like "libfoo-1.0.0", or > "libfoo-1.0.0-debug" for debug versions of that same library. > > Personally I use semantic versioning (http://semver.org) and 'SameMajor' compatibility option work pretty fine for me even w/ dozen of dependencies... > I have no answer for include 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 pfultz2 at yahoo.com Wed Sep 6 23:39:37 2017 From: pfultz2 at yahoo.com (P F) Date: Wed, 6 Sep 2017 22:39:37 -0500 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: References: <98e84b16-7590-63b4-1080-34db0eb9dc18@codelibre.net> Message-ID: <405D2C82-58F6-46C7-90AC-75D4C51314F4@yahoo.com> The `add_test` function can run whatever command you want it to, including compiling a target: add_library(foo_compile_test STATIC EXCLUDE_FROM_ALL foo_compile_test.cpp) add_test(NAME foo_compile_test COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test --config $ WORKING_DIRECTORY ${CMAKE_BINARY_DIR}) Then you set cmake to expect failure: set_tests_properties(foo_compile_test PROPERTIES WILL_FAIL TRUE) You can also check for output instead of just expecting failure: set_tests_properties(mytest PROPERTIES PASS_REGULAR_EXPRESSION "foo failed" ) This is especially useful to make sure that the error is from the static_assert message and not from another compile error. Of course, cmake could provide a module which provides a function to do this, which additionally could help workaround the caveats of this approach. This is essentially what `bcm_test` in the boost cmake modules do. Hopefully, in the future this module could be merged upstream into cmake. > On Sep 5, 2017, at 11:44 AM, Edward Diener wrote: > > On 9/5/2017 2:47 AM, Dvir Yitzchaki wrote: >> There's already CheckCXXSourceCompiles and friends. >> The only problem is that try_compile is not scriptable otherwise you could let the test invoke >> ${CMAKE_COMMAND} -P check_source_compiles.cmake. > > To put it succinctly CMake should adding compile-time testing so that when some compilation succeeds the test is successful and if the compilation fails the test is not successful, with the proviso that you can reverse the result as a compile should fail type of test. Similarly a build type testing, without having to run anything should be added along the same lines. > > In modern C++ it is perfectly feasible, especially with template programming, to do compile time testing, invoking a compile-time static assert as a compile-time failure. Boost has had this for years and modern C++ has it as part of the latest version of the C++ standard. CMake needs to update itself to the reality that pure compile-time testing is a reality for modern C++ and should update itself accordingly. Only having run-time testing is an artifact of the past. Hopefully CMake developers will get the message and make the necessary update to CMake/CTest. > >> -----Original Message----- >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Roger Leigh >> Sent: Monday, September 4, 2017 16:51 >> To: cmake at cmake.org >> Subject: Re: [CMake] Adding compile and build type tests to CMake/CTest >> On 04/09/17 14:40, Edward Diener wrote: >>> Boost Build has tests for running an application successfully or not, >>> for compiling one or more source files successfully or not, and for >>> building one or more source files into an exe or not. These tests in >>> Boost Build are the run/run-fail, compile/compile-fail, and >>> link/link-fail rules. >>> >>> CMake/CTest has the exact equivalent to the run/run-fail rule in its >>> add_test framework, but there is not add_test equivalent to the other >>> two sets of rules. It sure would be nice, when Boost transitions to >>> using CMake/CTest instead of Boost Build, if CMake/CTest had the >>> equivalent of the other two sets of types of test in its add_test >>> framework. >>> >>> Is there any consensus that these other two types of tests might be >>> valuable for CMake/CTest, or any way to make this happen ? >> I've certainly wished for them. Particularly when testing templated code where you want to test that certain things fail correctly, e.g. via static_assert or simply being invalid. >> I understand it's possible to make this work partially, by creating targets which aren't built by default, and then add tests which invoke the targets. But this appears to have some caveats, such as potential misbehaviour with parallel testing. Or you can have a separate CMake build for each individual target, but it's extra complexity. Having a proper means of registering such tests would be very, very nice. >> Regards, >> Roger > > > -- > > 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 pfultz2 at yahoo.com Thu Sep 7 00:07:22 2017 From: pfultz2 at yahoo.com (P F) Date: Wed, 6 Sep 2017 23:07:22 -0500 Subject: [CMake] Proper process for static & shared variants of config packages? In-Reply-To: References: Message-ID: <6B072547-6421-4734-BB62-DA963453B47F@yahoo.com> > On Sep 1, 2017, at 10:39 AM, Robert Dailey wrote: > > Suppose I have a library target and I setup a config package for it > and install target exports for it. What is the process for supporting > installation of the shared library and static library variants (maybe > the same answer applies to debug and release variants too)? > > Should you create 1 target and rely on BUILD_SHARED_LIBS, which means > generating two binary directories, building and installing once in > each? This is the best approach as it leaves the decision of building shared or static to the clients. > Will this overwrite existing target.cmake and config.cmake files > in a negative way? You could install each variant of shared and static to separate install directories. For debug and release you can install together, as cmake generates a target-.cmake for each configuration. I suppose you could embed some logic in the config.cmake file to pick a different export file for shared or static as well. > > Or should there be 2 library targets (something like foo_shared and > foo_static) and build & install once? No, this is rather problematic: 1) If your dependencies are built for just one variant as well, then one of those targets could fail. 2) A downstream library may only want to create 1 target, and now it has to add extra logic to decide if it should choose the shared or static target, which is cumbersome. From eldlistmailingz at tropicsoft.com Thu Sep 7 02:58:13 2017 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Thu, 7 Sep 2017 02:58:13 -0400 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: <405D2C82-58F6-46C7-90AC-75D4C51314F4@yahoo.com> References: <98e84b16-7590-63b4-1080-34db0eb9dc18@codelibre.net> <405D2C82-58F6-46C7-90AC-75D4C51314F4@yahoo.com> Message-ID: On 9/6/2017 11:39 PM, P F via CMake wrote: > The `add_test` function can run whatever command you want it to, including compiling a target: > > add_library(foo_compile_test STATIC EXCLUDE_FROM_ALL foo_compile_test.cpp) > add_test(NAME foo_compile_test > COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test --config $ > WORKING_DIRECTORY ${CMAKE_BINARY_DIR}) > > Then you set cmake to expect failure: > > set_tests_properties(foo_compile_test PROPERTIES WILL_FAIL TRUE) > > You can also check for output instead of just expecting failure: > > set_tests_properties(mytest PROPERTIES > PASS_REGULAR_EXPRESSION "foo failed" > ) > > This is especially useful to make sure that the error is from the static_assert message and not from another compile error. > > Of course, cmake could provide a module which provides a function to do this, which additionally could help workaround the caveats of this approach. This is essentially what `bcm_test` in the boost cmake modules do. > > Hopefully, in the future this module could be merged upstream into cmake. It seems like a hack to have to build a CMake target, with the add_library call, just to compile a source file as a test. You end up creating libraries, even if they are static libraries, just to test a compile. I understand that it might be seen that creating static libraries is no different than creating object files, but this technique appears to me a limitation of CMake. I should be able to add a test which just attempts to compile source file(s) into object file(s), not create static libraries. > > >> On Sep 5, 2017, at 11:44 AM, Edward Diener wrote: >> >> On 9/5/2017 2:47 AM, Dvir Yitzchaki wrote: >>> There's already CheckCXXSourceCompiles and friends. >>> The only problem is that try_compile is not scriptable otherwise you could let the test invoke >>> ${CMAKE_COMMAND} -P check_source_compiles.cmake. >> >> To put it succinctly CMake should adding compile-time testing so that when some compilation succeeds the test is successful and if the compilation fails the test is not successful, with the proviso that you can reverse the result as a compile should fail type of test. Similarly a build type testing, without having to run anything should be added along the same lines. >> >> In modern C++ it is perfectly feasible, especially with template programming, to do compile time testing, invoking a compile-time static assert as a compile-time failure. Boost has had this for years and modern C++ has it as part of the latest version of the C++ standard. CMake needs to update itself to the reality that pure compile-time testing is a reality for modern C++ and should update itself accordingly. Only having run-time testing is an artifact of the past. Hopefully CMake developers will get the message and make the necessary update to CMake/CTest. >> >>> -----Original Message----- >>> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Roger Leigh >>> Sent: Monday, September 4, 2017 16:51 >>> To: cmake at cmake.org >>> Subject: Re: [CMake] Adding compile and build type tests to CMake/CTest >>> On 04/09/17 14:40, Edward Diener wrote: >>>> Boost Build has tests for running an application successfully or not, >>>> for compiling one or more source files successfully or not, and for >>>> building one or more source files into an exe or not. These tests in >>>> Boost Build are the run/run-fail, compile/compile-fail, and >>>> link/link-fail rules. >>>> >>>> CMake/CTest has the exact equivalent to the run/run-fail rule in its >>>> add_test framework, but there is not add_test equivalent to the other >>>> two sets of rules. It sure would be nice, when Boost transitions to >>>> using CMake/CTest instead of Boost Build, if CMake/CTest had the >>>> equivalent of the other two sets of types of test in its add_test >>>> framework. >>>> >>>> Is there any consensus that these other two types of tests might be >>>> valuable for CMake/CTest, or any way to make this happen ? >>> I've certainly wished for them. Particularly when testing templated code where you want to test that certain things fail correctly, e.g. via static_assert or simply being invalid. >>> I understand it's possible to make this work partially, by creating targets which aren't built by default, and then add tests which invoke the targets. But this appears to have some caveats, such as potential misbehaviour with parallel testing. Or you can have a separate CMake build for each individual target, but it's extra complexity. Having a proper means of registering such tests would be very, very nice. >>> Regards, >>> Roger From marc.chevrier at sap.com Thu Sep 7 03:32:17 2017 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 7 Sep 2017 07:32:17 +0000 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: References: <98e84b16-7590-63b4-1080-34db0eb9dc18@codelibre.net> <405D2C82-58F6-46C7-90AC-75D4C51314F4@yahoo.com> Message-ID: Rather than building a STATIC library, you can build an OBJECT library. In this case only compilation step is done. On 07/09/2017, 08:59, "CMake on behalf of Edward Diener" wrote: On 9/6/2017 11:39 PM, P F via CMake wrote: > The `add_test` function can run whatever command you want it to, including compiling a target: > > add_library(foo_compile_test STATIC EXCLUDE_FROM_ALL foo_compile_test.cpp) > add_test(NAME foo_compile_test > COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test --config $ > WORKING_DIRECTORY ${CMAKE_BINARY_DIR}) > > Then you set cmake to expect failure: > > set_tests_properties(foo_compile_test PROPERTIES WILL_FAIL TRUE) > > You can also check for output instead of just expecting failure: > > set_tests_properties(mytest PROPERTIES > PASS_REGULAR_EXPRESSION "foo failed" > ) > > This is especially useful to make sure that the error is from the static_assert message and not from another compile error. > > Of course, cmake could provide a module which provides a function to do this, which additionally could help workaround the caveats of this approach. This is essentially what `bcm_test` in the boost cmake modules do. > > Hopefully, in the future this module could be merged upstream into cmake. It seems like a hack to have to build a CMake target, with the add_library call, just to compile a source file as a test. You end up creating libraries, even if they are static libraries, just to test a compile. I understand that it might be seen that creating static libraries is no different than creating object files, but this technique appears to me a limitation of CMake. I should be able to add a test which just attempts to compile source file(s) into object file(s), not create static libraries. > > >> On Sep 5, 2017, at 11:44 AM, Edward Diener wrote: >> >> On 9/5/2017 2:47 AM, Dvir Yitzchaki wrote: >>> There's already CheckCXXSourceCompiles and friends. >>> The only problem is that try_compile is not scriptable otherwise you could let the test invoke >>> ${CMAKE_COMMAND} -P check_source_compiles.cmake. >> >> To put it succinctly CMake should adding compile-time testing so that when some compilation succeeds the test is successful and if the compilation fails the test is not successful, with the proviso that you can reverse the result as a compile should fail type of test. Similarly a build type testing, without having to run anything should be added along the same lines. >> >> In modern C++ it is perfectly feasible, especially with template programming, to do compile time testing, invoking a compile-time static assert as a compile-time failure. Boost has had this for years and modern C++ has it as part of the latest version of the C++ standard. CMake needs to update itself to the reality that pure compile-time testing is a reality for modern C++ and should update itself accordingly. Only having run-time testing is an artifact of the past. Hopefully CMake developers will get the message and make the necessary update to CMake/CTest. >> >>> -----Original Message----- >>> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Roger Leigh >>> Sent: Monday, September 4, 2017 16:51 >>> To: cmake at cmake.org >>> Subject: Re: [CMake] Adding compile and build type tests to CMake/CTest >>> On 04/09/17 14:40, Edward Diener wrote: >>>> Boost Build has tests for running an application successfully or not, >>>> for compiling one or more source files successfully or not, and for >>>> building one or more source files into an exe or not. These tests in >>>> Boost Build are the run/run-fail, compile/compile-fail, and >>>> link/link-fail rules. >>>> >>>> CMake/CTest has the exact equivalent to the run/run-fail rule in its >>>> add_test framework, but there is not add_test equivalent to the other >>>> two sets of rules. It sure would be nice, when Boost transitions to >>>> using CMake/CTest instead of Boost Build, if CMake/CTest had the >>>> equivalent of the other two sets of types of test in its add_test >>>> framework. >>>> >>>> Is there any consensus that these other two types of tests might be >>>> valuable for CMake/CTest, or any way to make this happen ? >>> I've certainly wished for them. Particularly when testing templated code where you want to test that certain things fail correctly, e.g. via static_assert or simply being invalid. >>> I understand it's possible to make this work partially, by creating targets which aren't built by default, and then add tests which invoke the targets. But this appears to have some caveats, such as potential misbehaviour with parallel testing. Or you can have a separate CMake build for each individual target, but it's extra complexity. Having a proper means of registering such tests would be very, very nice. >>> Regards, >>> Roger -- 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 dbahadir at benocs.com Thu Sep 7 05:02:21 2017 From: dbahadir at benocs.com (Deniz Bahadir) Date: Thu, 7 Sep 2017 11:02:21 +0200 Subject: [CMake] configuration packages, IMPORTED targets, and global scope In-Reply-To: References: Message-ID: <76146c0a-ad16-2d39-d9db-ae97eac42f2a@benocs.com> Am 06.09.2017 um 20:24 schrieb Robert Dailey: > So it took me a while to figure out why find_package() calls I was > making (with CONFIG) option were not accessible outside of the > directory in which it was invoked. I realized that all targets seem to > be global by default except IMPORTED targets (according to > add_library() docs). I find this counterintuitive, since I expect > imported targets to behave the same as normal ones WRT scope. > > Is there a reason that imported targets need to be explicitly made GLOBAL? > > Barring that, I'd like to find some way to make find_package() convert > those imported targets to global. I don't see a target property I can > set or a command I can call to make an existing imported target a > global one. Any thoughts on workarounds? If there are none, are there > some changes we could make to CMake to support this behavior? Just a two days ago I created an issue for this: https://gitlab.kitware.com/cmake/cmake/issues/17256 It would probably help if you participate in that discussion. > My use case is that I have a subdirectory I step into, which builds > various third party libraries and then follows up with a > find_package() call. I do this in a isolated but central place because > I have to set up various variables like CMAKE_PREFIX_PATH and many > others to isolate searches to a controlled location. Beyond this, if a > target needs one of these third party libs, the expectation is that > they only have to do target_link_libraries() with the import target > names to use those libs. However, because they are out of scope, they > can't use them. > HTH, Deniz From rcdailey.lists at gmail.com Thu Sep 7 09:36:08 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Thu, 7 Sep 2017 08:36:08 -0500 Subject: [CMake] configuration packages, IMPORTED targets, and global scope In-Reply-To: <76146c0a-ad16-2d39-d9db-ae97eac42f2a@benocs.com> References: <76146c0a-ad16-2d39-d9db-ae97eac42f2a@benocs.com> Message-ID: Thanks, I am watching that discussion and will try to contribute where I can. On Thu, Sep 7, 2017 at 4:02 AM, Deniz Bahadir wrote: > Am 06.09.2017 um 20:24 schrieb Robert Dailey: >> >> So it took me a while to figure out why find_package() calls I was >> making (with CONFIG) option were not accessible outside of the >> directory in which it was invoked. I realized that all targets seem to >> be global by default except IMPORTED targets (according to >> add_library() docs). I find this counterintuitive, since I expect >> imported targets to behave the same as normal ones WRT scope. >> >> Is there a reason that imported targets need to be explicitly made GLOBAL? >> >> Barring that, I'd like to find some way to make find_package() convert >> those imported targets to global. I don't see a target property I can >> set or a command I can call to make an existing imported target a >> global one. Any thoughts on workarounds? If there are none, are there >> some changes we could make to CMake to support this behavior? > > > Just a two days ago I created an issue for this: > https://gitlab.kitware.com/cmake/cmake/issues/17256 > > It would probably help if you participate in that discussion. > >> My use case is that I have a subdirectory I step into, which builds >> various third party libraries and then follows up with a >> find_package() call. I do this in a isolated but central place because >> I have to set up various variables like CMAKE_PREFIX_PATH and many >> others to isolate searches to a controlled location. Beyond this, if a >> target needs one of these third party libs, the expectation is that >> they only have to do target_link_libraries() with the import target >> names to use those libs. However, because they are out of scope, they >> can't use them. >> > > HTH, > Deniz > -- > > 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 Sep 7 09:48:45 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 7 Sep 2017 09:48:45 -0400 Subject: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags issues In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E7098FE9C@EXMBS2.ad.igd.fraunhofer.de> References: <8D981219EEA621479C112DA9BDC39A8E7098F2D4@EXMBS2.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E7098FE44@EXMBS2.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E7098FE66@EXMBS2.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E7098FE9C@EXMBS2.ad.igd.fraunhofer.de> Message-ID: Okay I have opened an issue on CMake for handling multiple gencode with multiple code targets. On Wed, Sep 6, 2017 at 3:19 PM, Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > Yes > > ________________________________ > From: Robert Maynard [robert.maynard at kitware.com] > Sent: Wednesday, September 06, 2017 6:58 PM > To: Mueller-Roemer, Johannes Sebastian > Cc: cmake at cmake.org > Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags > issues > > So it works when they are separate gen-code options, but fails when they > are combined. Is that correct? > > > On Wed, Sep 6, 2017 at 11:16 AM, Mueller-Roemer, Johannes Sebastian < > Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>> wrote: > The long form fills the Code Generation field with > compute_20,sm_20;compute_20,compute_20 (the default without gencode > parameters is compute_20,sm_20) and results in the following command line: > > D:\jsroemer\projects\cuda-pdb-test\build\a>"C:\Program Files\NVIDIA GPU > Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" -gencode=arch=compute_20,code=\"sm_20,compute_20\" > -gencode=arch=compute_20,code=\"compute_20,compute_20\" --use-local-env > --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio > 14.0\VC\bin\amd64" -I"C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 > --machine 64 --compile -cudart static -Xcompiler="/EHsc -Zi -Ob0" -g > -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o > A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu< > http://a.cu>" > > Which is somewhat redundant > > MSVC turns compute_20,sm_20 into -gencode=arch=compute_20,code=\"sm_20,compute_20\" > and compute_20,compute_20 into -gencode=arch=compute_20,code= > \"compute_20,compute_20\" > > > Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD > Fraunhoferstr. 5 | 64283 Darmstadt | Germany > Tel +49 6151 155-606 | Fax +49 6151 155-139 > > johannes.mueller-roemer at igd.fraunhofer.de mueller-roemer at igd.fraunhofer.de> | www.igd.fraunhofer.de www.igd.fraunhofer.de> > > From: Robert Maynard [mailto:robert.maynard at kitware.com maynard at kitware.com>] > Sent: Wednesday, September 6, 2017 16:44 > > To: Mueller-Roemer, Johannes Sebastian Roemer at igd.fraunhofer.de Mueller-Roemer at igd.fraunhofer.de>> > Cc: cmake at cmake.org > Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags > issues > > Yes I was responding to comment 3. > > I am curious, does the longer form signature "-gencode > arch=compute_20,code=sm_20 -gencode arch=compute_20,code=compute_20" > work correctly? CMake has to parse the gencode flags and move them to > special msbuild entries, and I wonder if there is a bug when parsing > multiple code options. > > On Wed, Sep 6, 2017 at 10:36 AM, Mueller-Roemer, Johannes Sebastian < > Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>> wrote: > If the comment is wrt 3., the result is the same no matter if I use a > space or an equals sign, if I double escape the quotes (e.g., use the value > as you wrote it in the cmake-gui for CMAKE_CUDA_FLAGS), the value in VS > becomes compute_20,"sm_20,compute_20" instead of > compute_20,sm_20,compute_20, which is equally illegal and will cause the > same error message, also double escaping should not be necessary for a > subset of flags (Xcompiler works fine without it, even if the default > values are pointless). > If the comment is wrt 2., this is the line automatically generated by > CMake/VS when not passing in any gencode flags explicitly. > > Or am I misunderstanding what you mean? > > Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD > Fraunhoferstr. 5 | 64283 Darmstadt | Germany > Tel +49 6151 155-606 | Fax +49 6151 155-139 > > johannes.mueller-roemer at igd.fraunhofer.de mueller-roemer at igd.fraunhofer.de> | www.igd.fraunhofer.de www.igd.fraunhofer.de> > > From: Robert Maynard [mailto:robert.maynard at kitware.com maynard at kitware.com>] > Sent: Wednesday, September 6, 2017 15:38 > To: Mueller-Roemer, Johannes Sebastian Roemer at igd.fraunhofer.de Mueller-Roemer at igd.fraunhofer.de>> > Cc: cmake at cmake.org > Subject: Re: [CMake] CMake 3.9.x Visual Studio CUDA PDB/compiler flags > issues > > As far as gencode goes, your line has errors. With CUDA 8 it should look > like: > > -gencode arch=compute_20,code=\"sm_20,compute_20\" > > > > On Mon, Sep 4, 2017 at 4:06 AM, Mueller-Roemer, Johannes Sebastian < > Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>> wrote: > I?m having two issues with debug symbols for CUDA libraries on a project: > > > 1. The PDBs are not placed where the linker later expects to find > them (haven?t been able to replicate this in a minimal project yet) > > 2. Trying to circumnavigate this issue by using ?/Z7? instead of > ?/Zi? does not work, Zi is always used (replicable in any project with CUDA) > > Replication steps: Replace -Zi or /Zi in CMAKE_*_FLAGS* (CUDA, CXX, C) by > -Z7 or /Z7. Build and see several warnings like ?cl : Command line warning > D9025: overriding '/Z7' with '/Zi'? in the output window. > And do the flags in the ?Xcompiler make sense at all in VS? The CUDA build > tools seem to determine these automatically anyways? for example I get the > following call in the above scenario: > > "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin\nvcc.exe" > -gencode=arch=compute_20,code=\"sm_20,compute_20\" --use-local-env > --cl-version 2015 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio > 14.0\VC\bin\amd64" -I"C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v8.0\include" -I"C:\Program Files\NVIDIA GPU Computing > Toolkit\CUDA\v8.0\include" -G --keep-dir x64\Debug -maxrregcount=0 > --machine 64 --compile -cudart static -Xcompiler="/EHsc -Z7 -Ob0" -g > -D_WINDOWS -Xcompiler "/EHsc /W3 /nologo /Od /FS /Zi /RTC1 /MDd /GR" -o > A.dir\Debug\a.cu.obj "D:\jsroemer\projects\cuda-pdb-test\a\a.cu< > http://a.cu>" > > 3. Also, -gencode flags do not behave as expected when given in the > form -gencode=arch=compute_20,code="sm_20,compute_20", as this causes the > VS build system to error out: > > C:\Program Files (x86)\MSBuild\Microsoft.Cpp\ > v4.0\V140\BuildCustomizations\CUDA 8.0.targets(216,9): error : Item > '..\..\a\a.cu' Code Generation value is not in the expected > format '[Arch],[Code]'. > > The code generation value in this example is set to > compute_20,sm_20,compute_20 by CMake. > > Fraunhofer-Institut f?r Graphische Datenverarbeitung IGD > Fraunhoferstr. 5 | 64283 Darmstadt | Germany > Tel +49 6151 155-606 | Fax +49 6151 155-139 > > johannes.mueller-roemer at igd.fraunhofer.de mueller-roemer at igd.fraunhofer.de> | www.igd.fraunhofer.de www.igd.fraunhofer.de> > > > -- > > 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 eldlistmailingz at tropicsoft.com Thu Sep 7 10:02:21 2017 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Thu, 7 Sep 2017 10:02:21 -0400 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: References: <98e84b16-7590-63b4-1080-34db0eb9dc18@codelibre.net> <405D2C82-58F6-46C7-90AC-75D4C51314F4@yahoo.com> Message-ID: On 9/7/2017 3:32 AM, CHEVRIER, Marc wrote: > Rather than building a STATIC library, you can build an OBJECT library. In this case only compilation step is done. So your are saying that: add_library(foo_compile_test OBJECT EXCLUDE_FROM_ALL foo_compile_test.cpp) add_test(NAME foo_compile_test COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test --config $ WORKING_DIRECTORY ${CMAKE_BINARY_DIR}) should work properly ? > > On 07/09/2017, 08:59, "CMake on behalf of Edward Diener" wrote: > > On 9/6/2017 11:39 PM, P F via CMake wrote: > > The `add_test` function can run whatever command you want it to, including compiling a target: > > > > add_library(foo_compile_test STATIC EXCLUDE_FROM_ALL foo_compile_test.cpp) > > add_test(NAME foo_compile_test > > COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test --config $ > > WORKING_DIRECTORY ${CMAKE_BINARY_DIR}) > > > > Then you set cmake to expect failure: > > > > set_tests_properties(foo_compile_test PROPERTIES WILL_FAIL TRUE) > > > > You can also check for output instead of just expecting failure: > > > > set_tests_properties(mytest PROPERTIES > > PASS_REGULAR_EXPRESSION "foo failed" > > ) > > > > This is especially useful to make sure that the error is from the static_assert message and not from another compile error. > > > > Of course, cmake could provide a module which provides a function to do this, which additionally could help workaround the caveats of this approach. This is essentially what `bcm_test` in the boost cmake modules do. > > Hopefully, in the future this module could be merged upstream into cmake. > > It seems like a hack to have to build a CMake target, with the > add_library call, just to compile a source file as a test. You end up > creating libraries, even if they are static libraries, just to test a > compile. I understand that it might be seen that creating static > libraries is no different than creating object files, but this technique > appears to me a limitation of CMake. I should be able to add a test > which just attempts to compile source file(s) into object file(s), not > create static libraries. > > > > > > >> On Sep 5, 2017, at 11:44 AM, Edward Diener wrote: > >> > >> On 9/5/2017 2:47 AM, Dvir Yitzchaki wrote: > >>> There's already CheckCXXSourceCompiles and friends. > >>> The only problem is that try_compile is not scriptable otherwise you could let the test invoke > >>> ${CMAKE_COMMAND} -P check_source_compiles.cmake. > >> > >> To put it succinctly CMake should adding compile-time testing so that when some compilation succeeds the test is successful and if the compilation fails the test is not successful, with the proviso that you can reverse the result as a compile should fail type of test. Similarly a build type testing, without having to run anything should be added along the same lines. > >> > >> In modern C++ it is perfectly feasible, especially with template programming, to do compile time testing, invoking a compile-time static assert as a compile-time failure. Boost has had this for years and modern C++ has it as part of the latest version of the C++ standard. CMake needs to update itself to the reality that pure compile-time testing is a reality for modern C++ and should update itself accordingly. Only having run-time testing is an artifact of the past. Hopefully CMake developers will get the message and make the necessary update to CMake/CTest. > >> > >>> -----Original Message----- > >>> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Roger Leigh > >>> Sent: Monday, September 4, 2017 16:51 > >>> To: cmake at cmake.org > >>> Subject: Re: [CMake] Adding compile and build type tests to CMake/CTest > >>> On 04/09/17 14:40, Edward Diener wrote: > >>>> Boost Build has tests for running an application successfully or not, > >>>> for compiling one or more source files successfully or not, and for > >>>> building one or more source files into an exe or not. These tests in > >>>> Boost Build are the run/run-fail, compile/compile-fail, and > >>>> link/link-fail rules. > >>>> > >>>> CMake/CTest has the exact equivalent to the run/run-fail rule in its > >>>> add_test framework, but there is not add_test equivalent to the other > >>>> two sets of rules. It sure would be nice, when Boost transitions to > >>>> using CMake/CTest instead of Boost Build, if CMake/CTest had the > >>>> equivalent of the other two sets of types of test in its add_test > >>>> framework. > >>>> > >>>> Is there any consensus that these other two types of tests might be > >>>> valuable for CMake/CTest, or any way to make this happen ? > >>> I've certainly wished for them. Particularly when testing templated code where you want to test that certain things fail correctly, e.g. via static_assert or simply being invalid. > >>> I understand it's possible to make this work partially, by creating targets which aren't built by default, and then add tests which invoke the targets. But this appears to have some caveats, such as potential misbehaviour with parallel testing. Or you can have a separate CMake build for each individual target, but it's extra complexity. Having a proper means of registering such tests would be very, very nice. > >>> Regards, > >>> Roger From marc.chevrier at sap.com Thu Sep 7 10:11:16 2017 From: marc.chevrier at sap.com (CHEVRIER, Marc) Date: Thu, 7 Sep 2017 14:11:16 +0000 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: References: <98e84b16-7590-63b4-1080-34db0eb9dc18@codelibre.net> <405D2C82-58F6-46C7-90AC-75D4C51314F4@yahoo.com> Message-ID: <034D7CAD-558C-46DF-9E98-049BB7A4E9A8@sap.com> Yes, exactly. I think so? On 07/09/2017, 16:04, "CMake on behalf of Edward Diener" wrote: On 9/7/2017 3:32 AM, CHEVRIER, Marc wrote: > Rather than building a STATIC library, you can build an OBJECT library. In this case only compilation step is done. So your are saying that: add_library(foo_compile_test OBJECT EXCLUDE_FROM_ALL foo_compile_test.cpp) add_test(NAME foo_compile_test COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test --config $ WORKING_DIRECTORY ${CMAKE_BINARY_DIR}) should work properly ? > > On 07/09/2017, 08:59, "CMake on behalf of Edward Diener" wrote: > > On 9/6/2017 11:39 PM, P F via CMake wrote: > > The `add_test` function can run whatever command you want it to, including compiling a target: > > > > add_library(foo_compile_test STATIC EXCLUDE_FROM_ALL foo_compile_test.cpp) > > add_test(NAME foo_compile_test > > COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test --config $ > > WORKING_DIRECTORY ${CMAKE_BINARY_DIR}) > > > > Then you set cmake to expect failure: > > > > set_tests_properties(foo_compile_test PROPERTIES WILL_FAIL TRUE) > > > > You can also check for output instead of just expecting failure: > > > > set_tests_properties(mytest PROPERTIES > > PASS_REGULAR_EXPRESSION "foo failed" > > ) > > > > This is especially useful to make sure that the error is from the static_assert message and not from another compile error. > > > > Of course, cmake could provide a module which provides a function to do this, which additionally could help workaround the caveats of this approach. This is essentially what `bcm_test` in the boost cmake modules do. > > Hopefully, in the future this module could be merged upstream into cmake. > > It seems like a hack to have to build a CMake target, with the > add_library call, just to compile a source file as a test. You end up > creating libraries, even if they are static libraries, just to test a > compile. I understand that it might be seen that creating static > libraries is no different than creating object files, but this technique > appears to me a limitation of CMake. I should be able to add a test > which just attempts to compile source file(s) into object file(s), not > create static libraries. > > > > > > >> On Sep 5, 2017, at 11:44 AM, Edward Diener wrote: > >> > >> On 9/5/2017 2:47 AM, Dvir Yitzchaki wrote: > >>> There's already CheckCXXSourceCompiles and friends. > >>> The only problem is that try_compile is not scriptable otherwise you could let the test invoke > >>> ${CMAKE_COMMAND} -P check_source_compiles.cmake. > >> > >> To put it succinctly CMake should adding compile-time testing so that when some compilation succeeds the test is successful and if the compilation fails the test is not successful, with the proviso that you can reverse the result as a compile should fail type of test. Similarly a build type testing, without having to run anything should be added along the same lines. > >> > >> In modern C++ it is perfectly feasible, especially with template programming, to do compile time testing, invoking a compile-time static assert as a compile-time failure. Boost has had this for years and modern C++ has it as part of the latest version of the C++ standard. CMake needs to update itself to the reality that pure compile-time testing is a reality for modern C++ and should update itself accordingly. Only having run-time testing is an artifact of the past. Hopefully CMake developers will get the message and make the necessary update to CMake/CTest. > >> > >>> -----Original Message----- > >>> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Roger Leigh > >>> Sent: Monday, September 4, 2017 16:51 > >>> To: cmake at cmake.org > >>> Subject: Re: [CMake] Adding compile and build type tests to CMake/CTest > >>> On 04/09/17 14:40, Edward Diener wrote: > >>>> Boost Build has tests for running an application successfully or not, > >>>> for compiling one or more source files successfully or not, and for > >>>> building one or more source files into an exe or not. These tests in > >>>> Boost Build are the run/run-fail, compile/compile-fail, and > >>>> link/link-fail rules. > >>>> > >>>> CMake/CTest has the exact equivalent to the run/run-fail rule in its > >>>> add_test framework, but there is not add_test equivalent to the other > >>>> two sets of rules. It sure would be nice, when Boost transitions to > >>>> using CMake/CTest instead of Boost Build, if CMake/CTest had the > >>>> equivalent of the other two sets of types of test in its add_test > >>>> framework. > >>>> > >>>> Is there any consensus that these other two types of tests might be > >>>> valuable for CMake/CTest, or any way to make this happen ? > >>> I've certainly wished for them. Particularly when testing templated code where you want to test that certain things fail correctly, e.g. via static_assert or simply being invalid. > >>> I understand it's possible to make this work partially, by creating targets which aren't built by default, and then add tests which invoke the targets. But this appears to have some caveats, such as potential misbehaviour with parallel testing. Or you can have a separate CMake build for each individual target, but it's extra complexity. Having a proper means of registering such tests would be very, very nice. > >>> Regards, > >>> Roger -- 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 pfultz2 at yahoo.com Thu Sep 7 10:34:09 2017 From: pfultz2 at yahoo.com (paul) Date: Thu, 07 Sep 2017 09:34:09 -0500 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: References: <98e84b16-7590-63b4-1080-34db0eb9dc18@codelibre.net> <405D2C82-58F6-46C7-90AC-75D4C51314F4@yahoo.com> Message-ID: <1504794849.28088.60.camel@yahoo.com> On Thu, 2017-09-07 at 02:58 -0400, Edward Diener wrote: > On 9/6/2017 11:39 PM, P F via CMake wrote: > > > > The `add_test` function can run whatever command you want it to, including > > compiling a target: > > > > add_library(foo_compile_test STATIC EXCLUDE_FROM_ALL foo_compile_test.cpp) > > add_test(NAME foo_compile_test > > ?????COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test --config > > $ > > ?????WORKING_DIRECTORY ${CMAKE_BINARY_DIR}) > > > > Then you set cmake to expect failure: > > > > set_tests_properties(foo_compile_test PROPERTIES WILL_FAIL TRUE) > > > > You can also check for output instead of just expecting failure: > > > > set_tests_properties(mytest PROPERTIES > > ???PASS_REGULAR_EXPRESSION "foo failed" > > ) > > > > This is especially useful to make sure that the error is from the > > static_assert message and not from another compile error. > > > > Of course, cmake could provide a module which provides a function to do > > this, which additionally could help workaround the caveats of this > > approach. This is essentially what `bcm_test` in the boost cmake modules > > do. > > Hopefully, in the future this module could be merged upstream into > > cmake. > It seems like a hack to have to build a CMake target, with the? > add_library call, just to compile a source file as a test. I dont see how this is a hack. Cmake is target-oriented, if I want to control the compile flags for this compile-test, I can do: target_compile_options(foo_compile_test -Wall -Werror) If it were builtin to cmake, how would the user set the compile options? It seems cmake would need to add `target_*` based function for compile tests as well. This seems bloated and inconsistent.? From eldlistmailingz at tropicsoft.com Thu Sep 7 10:43:08 2017 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Thu, 7 Sep 2017 10:43:08 -0400 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: <1504794849.28088.60.camel@yahoo.com> References: <98e84b16-7590-63b4-1080-34db0eb9dc18@codelibre.net> <405D2C82-58F6-46C7-90AC-75D4C51314F4@yahoo.com> <1504794849.28088.60.camel@yahoo.com> Message-ID: On 9/7/2017 10:34 AM, paul via CMake wrote: > On Thu, 2017-09-07 at 02:58 -0400, Edward Diener wrote: >> On 9/6/2017 11:39 PM, P F via CMake wrote: >>> >>> The `add_test` function can run whatever command you want it to, including >>> compiling a target: >>> >>> add_library(foo_compile_test STATIC EXCLUDE_FROM_ALL foo_compile_test.cpp) >>> add_test(NAME foo_compile_test >>> ?????COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test --config >>> $ >>> ?????WORKING_DIRECTORY ${CMAKE_BINARY_DIR}) >>> >>> Then you set cmake to expect failure: >>> >>> set_tests_properties(foo_compile_test PROPERTIES WILL_FAIL TRUE) >>> >>> You can also check for output instead of just expecting failure: >>> >>> set_tests_properties(mytest PROPERTIES >>> ???PASS_REGULAR_EXPRESSION "foo failed" >>> ) >>> >>> This is especially useful to make sure that the error is from the >>> static_assert message and not from another compile error. >>> >>> Of course, cmake could provide a module which provides a function to do >>> this, which additionally could help workaround the caveats of this >>> approach. This is essentially what `bcm_test` in the boost cmake modules >>> do. > > Hopefully, in the future this module could be merged upstream into >>> cmake. >> It seems like a hack to have to build a CMake target, with the >> add_library call, just to compile a source file as a test. > > > I dont see how this is a hack. Cmake is target-oriented, if I want to control > the compile flags for this compile-test, I can do: > > target_compile_options(foo_compile_test -Wall -Werror) > > If it were builtin to cmake, how would the user set the compile options? It > seems cmake would need to add `target_*` based function for compile tests as > well. This seems bloated and inconsistent. I meant it was a hack because you need to add a build of a STATIC library just to do a compile test. However if, as has been suggested, you can alternatively add a build of an OBJECT library to do the compile test, then that seems the correct way of doing it to me, if it actually works. I am surprised that it works, else I imagine `bcm_test` would have used that instead instead of building a STATIC library. From robert.maynard at kitware.com Thu Sep 7 15:58:33 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 7 Sep 2017 15:58:33 -0400 Subject: [CMake] [ANNOUNCE] CMake 3.9.2 available for download Message-ID: We are pleased to announce that CMake 3.9.2 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.9.2 since 3.9.1: Brad King (13): InstallRequiredSystemLibraries: Factor redist name into variable InstallRequiredSystemLibraries: Find VS 2017 Update 3 redist directory macOS: Revert default Hi-DPI support in applications Ninja: Fix support for MSVC with non-English output Xcode: Revert addition of "outputPaths" to custom command build phase cmCPackDragNDropGenerator: Add missing include cmake: Fix --find-package mode with imported targets Genex: Fix TARGET_PROPERTY value of SOURCES Android: Update for NDK r16 FindBoost: Revert "Simplify search in lists." InstallRequiredSystemLibraries: Add support for future VS 2017 toolchains Tests: Fix RunCMake.GeneratorExpression to run in CMake 3.9 CMake 3.9.2 Christian Pfeiffer (1): FindOpenMP: Restore OpenMP_FOUND result variable Maikel van den Hurk (1): CUDA: Pass host compiler to nvcc while device linking Michael St?rmer (2): VS: Do not reference output assemblies if not possible for CSharp target VS: Initialize CSharp flags consistently Sebastian Holtermann (3): Autogen: Restore AUTOUIC lookup paths from 3.8.2 Autogen: Update AUTOUIC documentation for search paths Autogen: Extend AUTOUIC search paths test Sylvain Joubert (1): Clang: Find version-suffixed LLVM/Clang binutils Tibor Szabo (1): FindCygwin: Fix regression when CYGWIN_INSTALL_PATH is already set From romain.leguay at gmail.com Fri Sep 8 12:11:56 2017 From: romain.leguay at gmail.com (Romain LEGUAY) Date: Fri, 8 Sep 2017 18:11:56 +0200 Subject: [CMake] Create Mac OS Bundle with VTK and Qt Message-ID: Hello everyone, Since this morning, I try to create a Bundle Application using CMake (3.9.1). My application use VTK (8.x) and Qt (5.x). The find_package of those two libraries works greats (no problem to build and run the application). I have many problems: 1) I try to add an icon without success. 2) I don?t know how (and where) to copy VTK dynamic libraries. ( Optional / not really related ) 3) When I try to use only some components of VTK, my application is linking to all VTK modules I?m going to details each points: 1) For the icon issue, I proceed this way: set(ICON_NAME "appIcon.icns") # I try without the icns extension without success. set(ICON_PATH "${CMAKE_CURRENT_SOURCE_DIR}/resources/icons/${ICON_NAME}") set_source_files_properties("${ICON_PATH}" PROPERTIES MACOSX_PACKAGE_LOCATION Resources) add_executable(MYAPP MACOSX_BUNDLE ${ICON_PATH} ${other_sources}) set_target_properties(CRAFPACK_GUI PROPERTIES MACOSX_BUNDLE_ICON_FILE ${ICON_NAME}) The icon is copied inside the Resources folder of my bundle and the Info.plist is well updated (the CFBundleIconFile key is set to "appIcon.icns"). When I launch my app, the default icon is used and not my icon. 2) For the libraries of VTK I tried to use macdeployqt (found using find_program) but it doesn?t found the libraries (installed in a custom directories) I tried to use BundleUtilities without any success (except to tell me that cmake doesn?t found the libraries). I attach you my CMakeLists. Is there a simple way to copy all found libraries/framework? Thank you! -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CMakeLists.txt URL: From alexvilchansky at yahoo.com Fri Sep 8 15:42:31 2017 From: alexvilchansky at yahoo.com (Oleksii Vilchanskyi) Date: Fri, 8 Sep 2017 21:42:31 +0200 Subject: [CMake] Create Mac OS Bundle with VTK and Qt In-Reply-To: References: Message-ID: Hello, > 1) I try to add an icon without success > When I launch my app, the default icon is used and not my icon. Can you elaborate on this? You say that the .icns file is under Resources and the final Info.plist contains the proper key with the proper value and that a non-default icon is used when the application is launched. If you do actually see the icon on the application [for example] in Launchpad, then the bundle is correctly built and macOS can recognize the icon. If instead you see something like this[0], then the bundle is built incorrectly. However, you also say "when I launch my app", which, if you mean application's runtime in particular, is unrelated to CMake or bundling. If the tray icon is broken etc. it's something your application is not doing (for example, we use RCC and /image for the icon). So, if this is the former, then the bundling part is incorrect, if it's the latter, the program's behaviour is incorrect. As a side note, I don't rely on MACOSX_PACKAGE_LOCATION property and install() the icon where it belongs. > 2) For the libraries of VTK I tried to use macdeployqt (found using find_program) but it doesn?t found the libraries (installed in a custom directories) > Is there a simple way to copy all found libraries/framework? I would recommend using DeployQt5.cmake module[1] instead of macdeployqt. Initially found on this list and later edited by Marcus D. Hanwell, the module (I believe) is distributed under BSD 3-clause. Usage example[2], also under BSD 3-clause (I believe). [0]: [1]: [2]: Regards, Oleksii Vilchanskyi On 8.9.2017 18:11, Romain LEGUAY wrote: > Hello everyone, > > Since this morning, I try to create a Bundle Application using CMake (3.9.1). > > My application use VTK (8.x) and Qt (5.x). The find_package of those two libraries works greats (no problem to build and run the application). > > I have many problems: > > 1) I try to add an icon without success. > 2) I don?t know how (and where) to copy VTK dynamic libraries. > ( Optional / not really related ) 3) When I try to use only some components of VTK, my application is linking to all VTK modules > > I?m going to details each points: > > 1) For the icon issue, I proceed this way: > > > set(ICON_NAME "appIcon.icns") # I try without the icns extension without success. > set(ICON_PATH "${CMAKE_CURRENT_SOURCE_DIR}/resources/icons/${ICON_NAME}") > set_source_files_properties("${ICON_PATH}" PROPERTIES MACOSX_PACKAGE_LOCATION Resources) > > add_executable(MYAPP MACOSX_BUNDLE ${ICON_PATH} ${other_sources}) > > set_target_properties(CRAFPACK_GUI PROPERTIES > MACOSX_BUNDLE_ICON_FILE ${ICON_NAME}) > > > The icon is copied inside the Resources folder of my bundle and the Info.plist is well updated (the CFBundleIconFile key is set to "appIcon.icns"). > > When I launch my app, the default icon is used and not my icon. > > > 2) For the libraries of VTK I tried to use macdeployqt (found using find_program) but it doesn?t found the libraries (installed in a custom directories) > > I tried to use BundleUtilities without any success (except to tell me that cmake doesn?t found the libraries). > > I attach you my CMakeLists. > > Is there a simple way to copy all found libraries/framework? > > Thank you! > > > From adam.getchell at gmail.com Fri Sep 8 19:56:38 2017 From: adam.getchell at gmail.com (Adam Getchell) Date: Fri, 8 Sep 2017 16:56:38 -0700 Subject: [CMake] cmake install Message-ID: <518893BF-757F-480E-B1EC-EBF205286EC2@gmail.com> Hello all, If I want to use CMake to invoke my build system, I can use: # cmake -- build . What?s the syntax for invoking the build system installer from cmake, i.e. the equivalent of: # cmake -G Ninja . # ninja # ninja install I tried: # cmake -G Ninja . # cmake --build . # cmake --build . --target install If its somewhere in the manual, I?d appreciate pointers. Thanks, Adam -- Adam Getchell https://keybase.io/adamgetchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Fri Sep 8 21:11:31 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 9 Sep 2017 11:11:31 +1000 Subject: [CMake] cmake install In-Reply-To: <518893BF-757F-480E-B1EC-EBF205286EC2@gmail.com> References: <518893BF-757F-480E-B1EC-EBF205286EC2@gmail.com> Message-ID: On Sat, Sep 9, 2017 at 9:56 AM, Adam Getchell wrote: > Hello all, > > If I want to use CMake to invoke my build system, I can use: > > # cmake -- build . > > What?s the syntax for invoking the build system installer from cmake, i.e. > the equivalent of: > > # cmake -G Ninja . > # ninja > # ninja install > > I tried: > > # cmake -G Ninja . > # cmake --build . > # cmake --build . --target install > This should be correct. Did this not work for you? If its somewhere in the manual, I?d appreciate pointers. > Which part were you looking for? The use of --target is documented as part of the Build Tool Mode section, but it seems you've already figured out that part. There's nothing technically special about the install target as far as I'm aware, you should be able to refer to it as a build target like you've done above. Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.getchell at gmail.com Fri Sep 8 21:19:57 2017 From: adam.getchell at gmail.com (Adam Getchell) Date: Fri, 8 Sep 2017 18:19:57 -0700 Subject: [CMake] cmake install In-Reply-To: References: <518893BF-757F-480E-B1EC-EBF205286EC2@gmail.com> Message-ID: <3954F77C-5A55-4425-84D0-AEA8DD148095@gmail.com> > On Sep 8, 2017, at 6:11 PM, Craig Scott wrote: > > I tried: > > # cmake -G Ninja . > # cmake --build . > # cmake --build . --target install > > This should be correct. Did this not work for you? No. https://travis-ci.org/acgetchell/CDT-plusplus/jobs/273498700 Thanks for your help. > > > If its somewhere in the manual, I?d appreciate pointers. > > Which part were you looking for? The use of --target is documented as part of the Build Tool Mode section, but it seems you've already figured out that part. There's nothing technically special about the install target as far as I'm aware, you should be able to refer to it as a build target like you've done above. > > > Craig Scott > Melbourne, Australia > https://crascit.com -- Adam Getchell https://keybase.io/adamgetchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Fri Sep 8 21:25:23 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 9 Sep 2017 11:25:23 +1000 Subject: [CMake] cmake install In-Reply-To: <3954F77C-5A55-4425-84D0-AEA8DD148095@gmail.com> References: <518893BF-757F-480E-B1EC-EBF205286EC2@gmail.com> <3954F77C-5A55-4425-84D0-AEA8DD148095@gmail.com> Message-ID: On Sat, Sep 9, 2017 at 11:19 AM, Adam Getchell wrote: > > On Sep 8, 2017, at 6:11 PM, Craig Scott wrote: > >> >> I tried: >> >> # cmake -G Ninja . >> # cmake --build . >> # cmake --build . --target install >> > > This should be correct. Did this not work for you? > > > No. > > https://travis-ci.org/acgetchell/CDT-plusplus/jobs/273498700 > > Thanks for your help. > That job uses sudo to do the install step and pipes the output to a file install.log. You will probably find the reason for the failure in that install.log file. It would also be unusual to do such an install step to a system-wide location as part of a CI job. Perhaps you might want to consider creating a package using CPack instead of doing a system-wide install. -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.scott at crascit.com Fri Sep 8 21:26:12 2017 From: craig.scott at crascit.com (Craig Scott) Date: Sat, 9 Sep 2017 11:26:12 +1000 Subject: [CMake] cmake install In-Reply-To: References: <518893BF-757F-480E-B1EC-EBF205286EC2@gmail.com> <3954F77C-5A55-4425-84D0-AEA8DD148095@gmail.com> Message-ID: On Sat, Sep 9, 2017 at 11:25 AM, Craig Scott wrote: > > > On Sat, Sep 9, 2017 at 11:19 AM, Adam Getchell > wrote: > >> >> On Sep 8, 2017, at 6:11 PM, Craig Scott wrote: >> >>> >>> I tried: >>> >>> # cmake -G Ninja . >>> # cmake --build . >>> # cmake --build . --target install >>> >> >> This should be correct. Did this not work for you? >> >> >> No. >> >> https://travis-ci.org/acgetchell/CDT-plusplus/jobs/273498700 >> >> Thanks for your help. >> > > That job uses sudo to do the install step and pipes the output to a file > install.log. You will probably find the reason for the failure in that > install.log file. It would also be unusual to do such an install step to a > system-wide location as part of a CI job. Perhaps you might want to > consider creating a package using CPack instead of doing a system-wide > install. > And I just noticed that you did "target" rather than "--target" -- Craig Scott Melbourne, Australia https://crascit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Sun Sep 10 08:42:33 2017 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Sun, 10 Sep 2017 08:42:33 -0400 Subject: [CMake] cmake install In-Reply-To: <3954F77C-5A55-4425-84D0-AEA8DD148095@gmail.com> References: <518893BF-757F-480E-B1EC-EBF205286EC2@gmail.com> <3954F77C-5A55-4425-84D0-AEA8DD148095@gmail.com> Message-ID: You should explicitly set the installation location of your package using ?DCMAKE_INSTALL_PREFIX=/xxx/xxxx/xxxx/xxx during the initial invocation of cmake. This should be set to a location you KNOW you have normal write access to. Once this is set then you will no longer need to use ?sudo? to run the commands and all _should_ work correctly. This is what we do on our dashboard builds. -- Mike Jackson From: CMake on behalf of Adam Getchell Date: Friday, September 8, 2017 at 9:20 PM To: Craig Scott Cc: CMake Subject: Re: [CMake] cmake install On Sep 8, 2017, at 6:11 PM, Craig Scott wrote: I tried: # cmake -G Ninja . # cmake --build . # cmake --build . --target install This should be correct. Did this not work for you? No. https://travis-ci.org/acgetchell/CDT-plusplus/jobs/273498700 Thanks for your help. If its somewhere in the manual, I?d appreciate pointers. Which part were you looking for? The use of --target is documented as part of the Build Tool Mode section, but it seems you've already figured out that part. There's nothing technically special about the install target as far as I'm aware, you should be able to refer to it as a build target like you've done above. Craig Scott Melbourne, Australia https://crascit.com -- Adam Getchell https://keybase.io/adamgetchell -- 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 rcdailey.lists at gmail.com Mon Sep 11 09:52:10 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Mon, 11 Sep 2017 08:52:10 -0500 Subject: [CMake] How to maintain compatibility with earlier versions? Message-ID: So typically my setup is that I have the newest CMake installed, but am working with projects that set cmake_minimum_required to something like version 2.8. Will version 3.9 of CMake prevent me from using features that were introduced after 2.8? How can I make sure that someone with *actual* version 2.8 installed will not run into errors/issues? From mateusz at loskot.net Mon Sep 11 10:58:19 2017 From: mateusz at loskot.net (Mateusz Loskot) Date: Mon, 11 Sep 2017 16:58:19 +0200 Subject: [CMake] [Windows] clang-cl.exe detected as MSVC? Message-ID: Hi, I'm building a project with CMake 3.9 using clang-cl.exe driver [1] from LLVM/clang 4.0 enabled with Visual Studio 2015 environment. CMake detects the compiler as Clang 4.0.0: -- The C compiler identification is Clang 4.0.0 -- The CXX compiler identification is Clang 4.0.0 -- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe -- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe -- works and my project builds fine. In my CMakeLists.txt, there is this flags update: if(MSVC) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MP") endif() and in build log I see: clang-cl.exe: warning: argument unused during compilation: '/MP' I have double-checked and MSVC is defined and set True for clang-cl.exe. Is this correct? Is clang-cl.exe driver considered to be "when using Microsoft Visual C++" [2] [1] https://clang.llvm.org/docs/UsersManual.html#clang-cl [2] https://cmake.org/cmake/help/v3.9/variable/MSVC.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From annulen at yandex.ru Mon Sep 11 11:06:49 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 11 Sep 2017 18:06:49 +0300 Subject: [CMake] How to maintain compatibility with earlier versions? In-Reply-To: References: Message-ID: <140721505142409@web8j.yandex.ru> 11.09.2017, 16:52, "Robert Dailey" : > So typically my setup is that I have the newest CMake installed, but > am working with projects that set cmake_minimum_required to something > like version 2.8. Will version 3.9 of CMake prevent me from using > features that were introduced after 2.8? How can I make sure that > someone with *actual* version 2.8 installed will not run into > errors/issues? Only by testing with actual 2.8 (or whatever version you support). > -- > > 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 mateusz at loskot.net Mon Sep 11 11:11:38 2017 From: mateusz at loskot.net (Mateusz Loskot) Date: Mon, 11 Sep 2017 17:11:38 +0200 Subject: [CMake] [Windows] clang-cl.exe detected as MSVC? In-Reply-To: <134781505142295@web8j.yandex.ru> References: <134781505142295@web8j.yandex.ru> Message-ID: On 11 September 2017 at 17:04, Konstantin Tokarev wrote: > 11.09.2017, 17:59, "Mateusz Loskot" : >> Hi, >> >> I'm building a project with CMake 3.9 using clang-cl.exe driver [1] >> from LLVM/clang 4.0 enabled with Visual Studio 2015 environment. >> >> CMake detects the compiler as Clang 4.0.0: >> >> -- The C compiler identification is Clang 4.0.0 >> -- The CXX compiler identification is Clang 4.0.0 >> -- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe >> -- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe -- works >> >> and my project builds fine. >> >> In my CMakeLists.txt, there is this flags update: >> >> if(MSVC) >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MP") >> endif() >> >> and in build log I see: >> >> clang-cl.exe: warning: argument unused during compilation: '/MP' >> >> I have double-checked and MSVC is defined and set True for clang-cl.exe. >> >> Is this correct? > > Yes. clang-cl is mostly compatible with MSVC on the command line Mostly, or less or more, it's subjective and my experience show it is not as compatible as one may expect. Also, AFAIU, compatibility is only at driver level that is command line interface. > so it's natural that MSVC code in existing projects is applied to clang-cl too. I'd rather expect CL.exe exclusively considered as CL.exe Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From annulen at yandex.ru Mon Sep 11 11:04:55 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 11 Sep 2017 18:04:55 +0300 Subject: [CMake] [Windows] clang-cl.exe detected as MSVC? In-Reply-To: References: Message-ID: <134781505142295@web8j.yandex.ru> 11.09.2017, 17:59, "Mateusz Loskot" : > Hi, > > I'm building a project with CMake 3.9 using clang-cl.exe driver [1] > from LLVM/clang 4.0 enabled with Visual Studio 2015 environment. > > CMake detects the compiler as Clang 4.0.0: > > -- The C compiler identification is Clang 4.0.0 > -- The CXX compiler identification is Clang 4.0.0 > -- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe > -- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe -- works > > and my project builds fine. > > In my CMakeLists.txt, there is this flags update: > > if(MSVC) > ??set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MP") > endif() > > and in build log I see: > > clang-cl.exe: warning: argument unused during compilation: '/MP' > > I have double-checked and MSVC is defined and set True for clang-cl.exe. > > Is this correct? Yes. clang-cl is mostly compatible with MSVC on the command line, so it's natural that MSVC code in existing projects is applied to clang-cl too. > Is clang-cl.exe driver considered to be "when using Microsoft Visual C++" [2] > > [1] https://clang.llvm.org/docs/UsersManual.html#clang-cl > [2] https://cmake.org/cmake/help/v3.9/variable/MSVC.html > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > -- > > 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 irwin at beluga.phys.uvic.ca Mon Sep 11 17:37:18 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Mon, 11 Sep 2017 14:37:18 -0700 (PDT) Subject: [CMake] How to maintain compatibility with earlier versions? In-Reply-To: <140721505142409@web8j.yandex.ru> References: <140721505142409@web8j.yandex.ru> Message-ID: On 2017-09-11 18:06+0300 Konstantin Tokarev wrote: > > > 11.09.2017, 16:52, "Robert Dailey" : >> So typically my setup is that I have the newest CMake installed, but >> am working with projects that set cmake_minimum_required to something >> like version 2.8. Will version 3.9 of CMake prevent me from using >> features that were introduced after 2.8? How can I make sure that >> someone with *actual* version 2.8 installed will not run into >> errors/issues? > > Only by testing with actual 2.8 (or whatever version you support). I agree such testing is the only completely safe thing to do. However, that said, if a project specifies cmake_minimum_required(VERSION FATAL_ERROR) than that, by default, implies cmake_policy(VERSION ) i.e., all policies after will default to OLD (i.e., the policy available for ) behaviour. So because of this design, CMake has pretty good backwards compatibility, i.e., a project _should_ build the same way (with policies identical to those in effect for its minimum cmake version) regardless of how far a user's cmake version is ahead of the minimum version for a project. In practice, of course, such backwards compatibility is not perfect which is why I typically test the build systems for my various software projects with both their minimum CMake version and the latest CMake version. And to avoid straining that CMake backwards compatibility design too far, I typically also bump my cmake minimum version for projects (and therefore the associated cmake policies) to be not too far behind the latest CMake version. For example, fairly recently I bumped the PLplot minimum version from 3.0.2 (the version supplied by Debian Oldstable = Jessie) to 3.6.2, and within a few months (once Cygwin provides 3.7.2) I plan to bump that minimum version again to 3.7.2 (the version supplied by Debian Stable = Stretch). Note that Debian Stretch was just designated the Debian Stable version and typically Debian has a release cycle of ~2 years. So I will likely leave that minimum version at 3.7.2 for ~2 more years which should allow most Linux users during that interval with access to up-to-date distro versions of CMake to use their system CMake version rather than forcing them to use a later version of CMake that they have to build themselves. 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 kenneth.e.poole at gmail.com Mon Sep 11 18:06:04 2017 From: kenneth.e.poole at gmail.com (ken poole) Date: Mon, 11 Sep 2017 22:06:04 +0000 Subject: [CMake] want to store hash of binaries into install - but CPack.. Message-ID: We are looking for a way to include a hash/binary element of our install. The target platform is linux, and we use the CPack feature that updates the RPATH in the binaries during the creation of the install. Is there any way to run a script after the binaries have had their RPATHs updated by cpack? Thanks, Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mateju.Miroslav at azd.cz Tue Sep 12 05:08:50 2017 From: Mateju.Miroslav at azd.cz (=?iso-8859-2?Q?Mat=ECj=F9_Miroslav=2C_Ing=2E?=) Date: Tue, 12 Sep 2017 09:08:50 +0000 Subject: [CMake] CTest model deviates from the requsted one Message-ID: <67d9d99687b246eba6bd71c863904006@azdexchstore1.AZD.LOCAL> Hi, I would like to report the following problem. I experienced that CTest running a CTestScript with a manually specified model (e.g. CTEST_START(Experimental)) sometimes deviates from the selected model. For example, when the test model Nightly is requested, the test sometimes gets reported to CDash as Continuous; the Experimental model might get reported as Nightly or Continuous. I started to experience this problem massively when I started to run Continuous tests in addition to Nightly tests on my server. I tried to add debug messages to the CTest and shell scripts which control the testing process in my environment. I found out that the wrong decision happens during the CTEST_START call. The code: IF (NOT BUILD_MODEL) MESSAGE (FATAL_ERROR "Build model is not set") ENDIF (NOT BUILD_MODEL) CTEST_EMPTY_BINARY_DIRECTORY ("${CTEST_BINARY_DIRECTORY}") MESSAGE(STATUS "Build model: ${BUILD_MODEL}") CTEST_START (${BUILD_MODEL}) MESSAGE(STATUS "Build model: ${BUILD_MODEL}") renders (using ctest -VV): -- Build model: Experimental SetCTestConfiguration:SourceDirectory:/home/ctest/trunk/tests/moduletests/cm SetCTestConfiguration:BuildDirectory:/home/ctest/trunk/_build/moduletests/cm Run dashboard with model Experimental Source directory: /home/ctest/trunk/tests/moduletests/cm Build directory: moduletests/cm Reading ctest configuration file: /home/ctest/trunk/tests/moduletests/cm/CTestConfig.cmake SetCTestConfigurationFromCMakeVariable:NightlyStartTime:CTEST_NIGHTLY_START_TIME SetCTestConfiguration:NightlyStartTime:01:00:00 UTC SetCTestConfigurationFromCMakeVariable:Site:CTEST_SITE SetCTestConfiguration:Site:MiM-testsrv-ubuntu SetCTestConfigurationFromCMakeVariable:BuildName:CTEST_BUILD_NAME SetCTestConfiguration:BuildName:cm Site: MiM-testsrv-ubuntu Build name: cm Use Continuous tag: 20170912-0800 -- Build model: Experimental I tried to upgrade CMake from the distribution-provided version up to 3.9.1 but the problem persists. I noticed that the problem appears after changing the model in the same build directory, despite it has been wiped using CTEST_EMPTY_BINARY_DIRECTORY. CTest seems to prefer the previously used model sometimes instead of the explicitly given one (using CTEST_START). So I am currently trying to work around it by using separate build directories for each model. Is it the correct way or would you recommend something else? Best regards, Ing.?Miroslav Mat?j? Programmer Analyst A?D Praha s.r.o. Technology Division Research and Development ?irovnick? 2/3146, 106 17 Prague Czech Republic Phone: +420?267?287?476 Web: www.azd.cz From prlw1 at cam.ac.uk Tue Sep 12 07:21:16 2017 From: prlw1 at cam.ac.uk (Patrick Welche) Date: Tue, 12 Sep 2017 12:21:16 +0100 Subject: [CMake] debugging CMAKE_PREFIX_PATH Message-ID: <20170912112116.GA27289@quartz> I am trying to build a package which has in its CMakeLists.txt: set(CMAKE_PREFIX_PATH "${QT_PREFIX}/lib/cmake") set(CMAKE_INCLUDE_CURRENT_DIR ON) find_package(Qt5Core ${QT_MIN_VERSION} REQUIRED) (It may be that QT_PREFIX is not set?) I build with -DCMAKE_PREFIX_PATH set, and in CMakeCache.txt, I see: //No help, variable specified on the command line. CMAKE_PREFIX_PATH:PATH=/usr/pkg/qt5 //The directory containing a CMake configuration file for Qt5Core. Qt5Core_DIR:PATH=Qt5Core_DIR-NOTFOUND # ls /usr/pkg/qt5/lib/cmake/Qt5Core/Qt5CoreConfig.cmake /usr/pkg/qt5/lib/cmake/Qt5Core/Qt5CoreConfig.cmake so AFAICT, Qt5CoreConfig.cmake should be found. What am I missing? Cheers, Patrick From annulen at yandex.ru Tue Sep 12 08:53:50 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 12 Sep 2017 15:53:50 +0300 Subject: [CMake] [Windows] clang-cl.exe detected as MSVC? In-Reply-To: References: <134781505142295@web8j.yandex.ru> Message-ID: <27171505220830@web23j.yandex.ru> 11.09.2017, 18:12, "Mateusz Loskot" : > On 11 September 2017 at 17:04, Konstantin Tokarev wrote: >> ?11.09.2017, 17:59, "Mateusz Loskot" : >>> ?Hi, >>> >>> ?I'm building a project with CMake 3.9 using clang-cl.exe driver [1] >>> ?from LLVM/clang 4.0 enabled with Visual Studio 2015 environment. >>> >>> ?CMake detects the compiler as Clang 4.0.0: >>> >>> ?-- The C compiler identification is Clang 4.0.0 >>> ?-- The CXX compiler identification is Clang 4.0.0 >>> ?-- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe >>> ?-- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe -- works >>> >>> ?and my project builds fine. >>> >>> ?In my CMakeLists.txt, there is this flags update: >>> >>> ?if(MSVC) >>> ???set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MP") >>> ?endif() >>> >>> ?and in build log I see: >>> >>> ?clang-cl.exe: warning: argument unused during compilation: '/MP' >>> >>> ?I have double-checked and MSVC is defined and set True for clang-cl.exe. >>> >>> ?Is this correct? >> >> ?Yes. clang-cl is mostly compatible with MSVC on the command line > > Mostly, or less or more, it's subjective and my experience show it is not > as compatible as one may expect. > Also, AFAIU, compatibility is only at driver level that is command > line interface. > >> ?so it's natural that MSVC code in existing projects is applied to clang-cl too. > > I'd rather expect CL.exe exclusively considered as CL.exe For fine-grained distinction you have CMAKE_CXX_COMPILER_ID > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net -- Regards, Konstantin From csiga.biga at aol.com Tue Sep 12 08:55:43 2017 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Tue, 12 Sep 2017 14:55:43 +0200 Subject: [CMake] Clang for Windows with CMake and Ninja (and Visual Studio) Message-ID: Hi! I am trying to build using the Open Folder feature of VS (with CMake server mode integration) with the Windows binary release of Clang. However, when I try to build using clang++.exe, it argues about unknown compiler switches clang++.exe: error: no such file or directory: '/nologo' while if I use the clang-cl.exe front-end of Clang, it fails saying LINK : fatal error LNK1104: cannot open file 'gdi32.lib' Does this both inside VS and in a developer command prompt. My invocation is as follows: cmake -G Ninja -DCMAKE_CXX_COMPILER=C:/Kellekek/LLVM/Clang/5.0/bin/clang++.exe C:\Users\Matty\Source\simplecpp\ My questions: 1. Why does CMake give MSVC params to Clang on Windows? 2. Is there a way to let the clang-cl front-end know how to link to system libraries? Cheers, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jakub.Zakrzewski at scheer-group.com Tue Sep 12 09:15:48 2017 From: Jakub.Zakrzewski at scheer-group.com (Zakrzewski, Jakub) Date: Tue, 12 Sep 2017 13:15:48 +0000 Subject: [CMake] debugging CMAKE_PREFIX_PATH In-Reply-To: <20170912112116.GA27289@quartz> References: <20170912112116.GA27289@quartz> Message-ID: <1505222148738.27634@scheer-group.com> Hi, > find_package(Qt5Core ${QT_MIN_VERSION} REQUIRED) > I build with -DCMAKE_PREFIX_PATH set, and in CMakeCache.txt, I see: > //No help, variable specified on the command line. > CMAKE_PREFIX_PATH:PATH=/usr/pkg/qt5 > //The directory containing a CMake configuration file for Qt5Core. > Qt5Core_DIR:PATH=Qt5Core_DIR-NOTFOUND > # ls /usr/pkg/qt5/lib/cmake/Qt5Core/Qt5CoreConfig.cmake > /usr/pkg/qt5/lib/cmake/Qt5Core/Qt5CoreConfig.cmake > so AFAICT, Qt5CoreConfig.cmake should be found. > What am I missing? according to the documentation: https://cmake.org/cmake/help/v3.0/command/find_package.html you're using the find_package() in MODULE mode, so it tries to locate a FindQt5Core.cmake. Use this: find_package(Qt5Core ${QT_MIN_VERSION} REQUIRED CONFIG) and it should do what you want. -- Gr?sse, Jakub From annulen at yandex.ru Tue Sep 12 09:37:08 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 12 Sep 2017 16:37:08 +0300 Subject: [CMake] debugging CMAKE_PREFIX_PATH In-Reply-To: <1505222148738.27634@scheer-group.com> References: <20170912112116.GA27289@quartz> <1505222148738.27634@scheer-group.com> Message-ID: <86451505223428@web9o.yandex.ru> 12.09.2017, 16:31, "Zakrzewski, Jakub" : > Hi, > >> ?find_package(Qt5Core ${QT_MIN_VERSION} REQUIRED) > >> ?I build with -DCMAKE_PREFIX_PATH set, and in CMakeCache.txt, I see: > >> ?//No help, variable specified on the command line. >> ?CMAKE_PREFIX_PATH:PATH=/usr/pkg/qt5 > >> ?//The directory containing a CMake configuration file for Qt5Core. >> ?Qt5Core_DIR:PATH=Qt5Core_DIR-NOTFOUND > >> ?# ls /usr/pkg/qt5/lib/cmake/Qt5Core/Qt5CoreConfig.cmake >> ?/usr/pkg/qt5/lib/cmake/Qt5Core/Qt5CoreConfig.cmake > >> ?so AFAICT, Qt5CoreConfig.cmake should be found. > >> ?What am I missing? > > according to the documentation: https://cmake.org/cmake/help/v3.0/command/find_package.html > you're using the find_package() in MODULE mode, so it tries to locate a FindQt5Core.cmake. > > Use this: > find_package(Qt5Core ${QT_MIN_VERSION} REQUIRED CONFIG) > > and it should do what you want. This statement is wrong, when no MODULE or CONFIG are specified, CMake tries both, so find_package(Qt5Core ${QT_MIN_VERSION} REQUIRED) is a correct way. What actually happens here: rogue CMake project overwrites user-supplied CMAKE_PREFIX_PATH with its own value, so it is disregarded. As a workaround (without changing project), you can pass -DQt5Core_DIR=/usr/pkg/qt5/lib/cmake/Qt5Core > > -- > Gr?sse, > Jakub > -- > > 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 csiga.biga at aol.com Tue Sep 12 10:37:36 2017 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Tue, 12 Sep 2017 16:37:36 +0200 Subject: [CMake] Clang for Windows with CMake and Ninja (and Visual Studio) In-Reply-To: <20170912130139.1461DFCB49@public.kitware.com> References: <20170912130139.1461DFCB49@public.kitware.com> Message-ID: The link error is some error on my setup. The /nologo et al part still stands though. Can CMake invoke the Windows binary of Clang correctly? Felad?: Nagy-Egri M?t? Ferenc via CMake Elk?ldve: 2017. szeptember 12., kedd 15:01 C?mzett: Cmake Mailing List T?rgy: [CMake] Clang for Windows with CMake and Ninja (and Visual Studio) Hi! I am trying to build using the Open Folder feature of VS (with CMake server mode integration) with the Windows binary release of Clang. However, when I try to build using clang++.exe, it argues about unknown compiler switches clang++.exe: error: no such file or directory: '/nologo' while if I use the clang-cl.exe front-end of Clang, it fails saying LINK : fatal error LNK1104: cannot open file 'gdi32.lib' Does this both inside VS and in a developer command prompt. My invocation is as follows: cmake -G Ninja -DCMAKE_CXX_COMPILER=C:/Kellekek/LLVM/Clang/5.0/bin/clang++.exe C:\Users\Matty\Source\simplecpp\ My questions: 1. Why does CMake give MSVC params to Clang on Windows? 2. Is there a way to let the clang-cl front-end know how to link to system libraries? Cheers, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From romain.leguay at gmail.com Tue Sep 12 10:44:48 2017 From: romain.leguay at gmail.com (Romain LEGUAY) Date: Tue, 12 Sep 2017 16:44:48 +0200 Subject: [CMake] Create Mac OS Bundle with VTK and Qt In-Reply-To: References: Message-ID: <8C2328EC-BE59-4057-B2C9-48DDBF24BCBB@gmail.com> Hello, Sorry for this late answer! After using DeployQt5.cmake script I succeed to resolve my problem. The icon problem was due to some mistake during the creation of my icns file. Thanks again. Romain > Le 8 sept. 2017 ? 21:42, Oleksii Vilchanskyi via CMake a ?crit : > > Hello, > >> 1) I try to add an icon without success >> When I launch my app, the default icon is used and not my icon. > > Can you elaborate on this? You say that the .icns file is under > Resources and the final Info.plist contains the proper key with the > proper value and that a non-default icon is used when the application is > launched. If you do actually see the icon on the application [for > example] in Launchpad, then the bundle is correctly built and macOS can > recognize the icon. If instead you see something like this[0], then the > bundle is built incorrectly. > > However, you also say "when I launch my app", which, if you mean > application's runtime in particular, is unrelated to CMake or bundling. > If the tray icon is broken etc. it's something your application is not > doing (for example, we use RCC and /image for the icon). > > So, if this is the former, then the bundling part is incorrect, if it's > the latter, the program's behaviour is incorrect. > > As a side note, I don't rely on MACOSX_PACKAGE_LOCATION property and > install() the icon where it belongs. > >> 2) For the libraries of VTK I tried to use macdeployqt (found using > find_program) but it doesn?t found the libraries (installed in a custom > directories) >> Is there a simple way to copy all found libraries/framework? > > I would recommend using DeployQt5.cmake module[1] instead of > macdeployqt. Initially found on this list and later edited by Marcus D. > Hanwell, the module (I believe) is distributed under BSD 3-clause. > > Usage example[2], also under BSD 3-clause (I believe). > > [0]: > > [1]: > > > [2]: > > > > Regards, > Oleksii Vilchanskyi > > On 8.9.2017 18:11, Romain LEGUAY wrote: >> Hello everyone, >> >> Since this morning, I try to create a Bundle Application using CMake (3.9.1). >> >> My application use VTK (8.x) and Qt (5.x). The find_package of those two libraries works greats (no problem to build and run the application). >> >> I have many problems: >> >> 1) I try to add an icon without success. >> 2) I don?t know how (and where) to copy VTK dynamic libraries. >> ( Optional / not really related ) 3) When I try to use only some components of VTK, my application is linking to all VTK modules >> >> I?m going to details each points: >> >> 1) For the icon issue, I proceed this way: >> >> >> set(ICON_NAME "appIcon.icns") # I try without the icns extension without success. >> set(ICON_PATH "${CMAKE_CURRENT_SOURCE_DIR}/resources/icons/${ICON_NAME}") >> set_source_files_properties("${ICON_PATH}" PROPERTIES MACOSX_PACKAGE_LOCATION Resources) >> >> add_executable(MYAPP MACOSX_BUNDLE ${ICON_PATH} ${other_sources}) >> >> set_target_properties(CRAFPACK_GUI PROPERTIES >> MACOSX_BUNDLE_ICON_FILE ${ICON_NAME}) >> >> >> The icon is copied inside the Resources folder of my bundle and the Info.plist is well updated (the CFBundleIconFile key is set to "appIcon.icns"). >> >> When I launch my app, the default icon is used and not my icon. >> >> >> 2) For the libraries of VTK I tried to use macdeployqt (found using find_program) but it doesn?t found the libraries (installed in a custom directories) >> >> I tried to use BundleUtilities without any success (except to tell me that cmake doesn?t found the libraries). >> >> I attach you my CMakeLists. >> >> Is there a simple way to copy all found libraries/framework? >> >> Thank you! >> >> >> > -- > > 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 mateusz at loskot.net Tue Sep 12 10:55:57 2017 From: mateusz at loskot.net (Mateusz Loskot) Date: Tue, 12 Sep 2017 16:55:57 +0200 Subject: [CMake] [Windows] clang-cl.exe detected as MSVC? In-Reply-To: <27171505220830@web23j.yandex.ru> References: <134781505142295@web8j.yandex.ru> <27171505220830@web23j.yandex.ru> Message-ID: On 12 September 2017 at 14:53, Konstantin Tokarev wrote: > 11.09.2017, 18:12, "Mateusz Loskot" : >> On 11 September 2017 at 17:04, Konstantin Tokarev wrote: >>> 11.09.2017, 17:59, "Mateusz Loskot" : >>>> >>>> I'm building a project with CMake 3.9 using clang-cl.exe driver [1] >>>> from LLVM/clang 4.0 enabled with Visual Studio 2015 environment. >>>> >>>> CMake detects the compiler as Clang 4.0.0: >>>> >>>> -- The C compiler identification is Clang 4.0.0 >>>> -- The CXX compiler identification is Clang 4.0.0 >>>> -- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe >>>> -- Check for working C compiler: C:/Program Files/LLVM/bin/clang-cl.exe -- works >>>> >>>> and my project builds fine. >>>> >>>> In my CMakeLists.txt, there is this flags update: >>>> >>>> if(MSVC) >>>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /MP") >>>> endif() >>>> >>>> and in build log I see: >>>> >>>> clang-cl.exe: warning: argument unused during compilation: '/MP' >>>> >>>> I have double-checked and MSVC is defined and set True for clang-cl.exe. >>>> >>>> Is this correct? >>> >>> Yes. clang-cl is mostly compatible with MSVC on the command line >> >> Mostly, or less or more, it's subjective and my experience show it is not >> as compatible as one may expect. >> Also, AFAIU, compatibility is only at driver level that is command >> line interface. >> >>> so it's natural that MSVC code in existing projects is applied to clang-cl too. >> >> I'd rather expect CL.exe exclusively considered as CL.exe > > For fine-grained distinction you have CMAKE_CXX_COMPILER_ID I'll switch over to that one. Thanks Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From ramey at rrsd.com Tue Sep 12 13:11:31 2017 From: ramey at rrsd.com (Robert Ramey) Date: Tue, 12 Sep 2017 10:11:31 -0700 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: References: Message-ID: On 9/4/17 6:40 AM, Edward Diener wrote: > Boost Build has tests for running an application successfully or not, > for compiling one or more source files successfully or not, and for > building one or more source files into an exe or not. These tests in > Boost Build are the run/run-fail, compile/compile-fail, and > link/link-fail rules. > > CMake/CTest has the exact equivalent to the run/run-fail rule in its > add_test framework, but there is not add_test equivalent to the other > two sets of rules. It sure would be nice, when Boost transitions to > using CMake/CTest instead of Boost Build, if CMake/CTest had the > equivalent of the other two sets of types of test in its add_test > framework. > > Is there any consensus that these other two types of tests might be > valuable for CMake/CTest, or any way to make this happen ? > I would like to second this suggestion. The absence of this feature presents a huge obstacle to replicating the functionality of the boost build functionality with CMake. It's amazing to me that after so many years CMake doesn't have this functionality already. It certainly seems to me that this would be easy to implement. I'm aware that suggestions using CMake macros have been proposed. But to the inexperienced user they are not intuitive or easy to understand. Could we get some response on Edward's suggestion here? It's a serious obstacle to implementing support of CMake in Boost libraries. Robert Ramey From rcdailey.lists at gmail.com Tue Sep 12 14:33:42 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 12 Sep 2017 13:33:42 -0500 Subject: [CMake] project() with ASM fails with MSVC 19 Message-ID: Using CMake 3.9, I do this: cmake_minimum_required(VERSION 3.9) project(libpng VERSION 1.6.33 LANGUAGES ASM C) I get the following error: -- The ASM compiler identification is unknown -- Didn't find assembler -- The C compiler identification is MSVC 19.11.25507.1 CMake Error at CMakeLists.txt:16 (project): No CMAKE_ASM_COMPILER could be found. Why doesn't this work? From rcdailey.lists at gmail.com Tue Sep 12 14:34:33 2017 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Tue, 12 Sep 2017 13:34:33 -0500 Subject: [CMake] project() with ASM fails with MSVC 19 In-Reply-To: References: Message-ID: Also, I am using the "Visual Studio 15 2017" generator with no other options (generating through cmake-gui on Windows) On Tue, Sep 12, 2017 at 1:33 PM, Robert Dailey wrote: > Using CMake 3.9, I do this: > > cmake_minimum_required(VERSION 3.9) > project(libpng VERSION 1.6.33 LANGUAGES ASM C) > > I get the following error: > > -- The ASM compiler identification is unknown > -- Didn't find assembler > -- The C compiler identification is MSVC 19.11.25507.1 > CMake Error at CMakeLists.txt:16 (project): > No CMAKE_ASM_COMPILER could be found. > > > Why doesn't this work? From prlw1 at cam.ac.uk Tue Sep 12 18:52:00 2017 From: prlw1 at cam.ac.uk (Patrick Welche) Date: Tue, 12 Sep 2017 23:52:00 +0100 Subject: [CMake] debugging CMAKE_PREFIX_PATH In-Reply-To: <86451505223428@web9o.yandex.ru> References: <20170912112116.GA27289@quartz> <1505222148738.27634@scheer-group.com> <86451505223428@web9o.yandex.ru> Message-ID: <20170912225200.GA900@quark> Problematic (scribus) CMakeLists.txt: set(CMAKE_PREFIX_PATH "${QT_PREFIX}/lib/cmake") set(CMAKE_INCLUDE_CURRENT_DIR ON) find_package(Qt5Core ${QT_MIN_VERSION} REQUIRED) On Tue, Sep 12, 2017 at 04:37:08PM +0300, Konstantin Tokarev wrote: > What actually happens here: rogue CMake project overwrites > user-supplied CMAKE_PREFIX_PATH with its own value, so it is > disregarded. > > As a workaround (without changing project), you can pass > -DQt5Core_DIR=/usr/pkg/qt5/lib/cmake/Qt5Core Thank you! I had found the workaround, but the list of Qt packages was becoming rather long. Getting rid of the CMAKE_PREFIX_PATH over-ride fixed things, but then revealed a further problem: set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/modules") set(CAIRO_DIR ${CMAKE_MODULE_PATH}) find_package(CAIRO REQUIRED) $ ls -1 CMakeLists.txt cmake/modules/CAIROConfig.cmake CMakeLists.txt cmake/modules/CAIROConfig.cmake Any thoughts on this variation on the theme? Cheers, Patrick From prlw1 at cam.ac.uk Tue Sep 12 19:14:40 2017 From: prlw1 at cam.ac.uk (Patrick Welche) Date: Wed, 13 Sep 2017 00:14:40 +0100 Subject: [CMake] debugging CMAKE_PREFIX_PATH In-Reply-To: <20170912225200.GA900@quark> References: <20170912112116.GA27289@quartz> <1505222148738.27634@scheer-group.com> <86451505223428@web9o.yandex.ru> <20170912225200.GA900@quark> Message-ID: <20170912231440.GB900@quark> On Tue, Sep 12, 2017 at 11:52:00PM +0100, Patrick Welche wrote: > Problematic (scribus) CMakeLists.txt: > > set(CMAKE_PREFIX_PATH "${QT_PREFIX}/lib/cmake") > set(CMAKE_INCLUDE_CURRENT_DIR ON) > find_package(Qt5Core ${QT_MIN_VERSION} REQUIRED) > > On Tue, Sep 12, 2017 at 04:37:08PM +0300, Konstantin Tokarev wrote: > > What actually happens here: rogue CMake project overwrites > > user-supplied CMAKE_PREFIX_PATH with its own value, so it is > > disregarded. > > > > As a workaround (without changing project), you can pass > > -DQt5Core_DIR=/usr/pkg/qt5/lib/cmake/Qt5Core > > Thank you! I had found the workaround, but the list of Qt packages > was becoming rather long. Getting rid of the CMAKE_PREFIX_PATH > over-ride fixed things, but then revealed a further problem: > > set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/modules") > set(CAIRO_DIR ${CMAKE_MODULE_PATH}) > find_package(CAIRO REQUIRED) > > $ ls -1 CMakeLists.txt cmake/modules/CAIROConfig.cmake > CMakeLists.txt > cmake/modules/CAIROConfig.cmake Actually, there is more to this: the build system alters the above to: set (CMAKE_MODULE_PATH "/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-Modules" "${CMAKE_SOURCE_DIR}/cmake/modules") AFAICT CMAKE_MODULE_PATH should end up as dir1;dir2, but the CMakeCache.txt says: CMAKE_MODULE_PATH:PATH=/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-Modules so only one argument to set() made it? Cheers, Patrick From adam.getchell at gmail.com Tue Sep 12 19:50:54 2017 From: adam.getchell at gmail.com (Adam Getchell) Date: Tue, 12 Sep 2017 16:50:54 -0700 Subject: [CMake] cmake install In-Reply-To: References: <518893BF-757F-480E-B1EC-EBF205286EC2@gmail.com> <3954F77C-5A55-4425-84D0-AEA8DD148095@gmail.com> Message-ID: <5518E27E-B6F5-4311-996B-8A8079AA0251@gmail.com> Thanks for the catch, sudo cmake --build . --target install &> install.log worked. Yes, I plan to use a package manager like Conan or conda rather than the horrible tangle of scripts I have now for Travis and Appveyor, just have a few other things to do first. ;-) -- Adam Getchell https://keybase.io/adamgetchell > On Sep 10, 2017, at 5:42 AM, Michael Jackson wrote: > > You should explicitly set the installation location of your package using ?DCMAKE_INSTALL_PREFIX=/xxx/xxxx/xxxx/xxx during the initial invocation of cmake. > > This should be set to a location you KNOW you have normal write access to. Once this is set then you will no longer need to use ?sudo? to run the commands and all _should_ work correctly. This is what we do on our dashboard builds. > > -- > Mike Jackson > > > From: CMake on behalf of Adam Getchell > Date: Friday, September 8, 2017 at 9:20 PM > To: Craig Scott > Cc: CMake > Subject: Re: [CMake] cmake install > > >> On Sep 8, 2017, at 6:11 PM, Craig Scott > wrote: >>> >>> I tried: >>> >>> # cmake -G Ninja . >>> # cmake --build . >>> # cmake --build . --target install >> >> This should be correct. Did this not work for you? > > No. > > https://travis-ci.org/acgetchell/CDT-plusplus/jobs/273498700 > > Thanks for your help. > >> >> >>> If its somewhere in the manual, I?d appreciate pointers. >> >> Which part were you looking for? The use of --target is documented as part of the Build Tool Mode section, but it seems you've already figured out that part. There's nothing technically special about the install target as far as I'm aware, you should be able to refer to it as a build target like you've done above. >> >> >> Craig Scott >> Melbourne, Australia >> https://crascit.com > -- > Adam Getchell > https://keybase.io/adamgetchell > > -- 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 prlw1 at cam.ac.uk Wed Sep 13 04:50:48 2017 From: prlw1 at cam.ac.uk (Patrick Welche) Date: Wed, 13 Sep 2017 09:50:48 +0100 Subject: [CMake] debugging CMAKE_PREFIX_PATH In-Reply-To: <20170912231440.GB900@quark> References: <20170912112116.GA27289@quartz> <1505222148738.27634@scheer-group.com> <86451505223428@web9o.yandex.ru> <20170912225200.GA900@quark> <20170912231440.GB900@quark> Message-ID: <20170913085048.GA1864@quark> I think I am confused by the following: 1) CMAKE_PREFIX_PATH; Problematic (scribus) CMakeLists.txt: set(CMAKE_PREFIX_PATH "${QT_PREFIX}/lib/cmake") CMakeCache.txt: //No help, variable specified on the command line. CMAKE_PREFIX_PATH:PATH=/usr/pkg/qt5 So the problem was that CMakeLists.txt overwrote the command line. Removing the set() line made things work 2) CMAKE_MODULE_PATH CMakeLists.txt (with extras to debug): set (CMAKE_MODULE_PATH "/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-Modules" "one" "two" "/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-Modules" "${CMAKE_SOURCE_DIR}/cmake/modules") set(testpath ${CMAKE_MODULE_PATH} CACHE PATH "testing path") CMakeCache.txt: //No help, variable specified on the command line. CMAKE_MODULE_PATH:PATH=/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-Modules //testing path testpath:PATH=/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-Modules;one;two;/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-Modules;/usr/obj/pkgsrc/print/scribus5/work.x86_64/scribus-1.5.3/cmake/modules So here, it seems the command line overwrites CMakeLists.txt ?! Cheers, Patrick From Alain.Miniussi at oca.eu Wed Sep 13 04:52:28 2017 From: Alain.Miniussi at oca.eu (Alain Miniussi) Date: Wed, 13 Sep 2017 10:52:28 +0200 Subject: [CMake] CMakeLists.txt location Message-ID: <0857fb2e-dcdf-3b13-1357-bf637c0d3a55@oca.eu> Hi, Is there a way, when printing CMake error, to get the exact location of the CMakeLists.txt ? For example, right now, when I have: CMake Error at CMakeLists.txt:14 (add_executable): I need to scan all my CMakeLists.txt (~200) to check which one has add_executable at line 14. Thanks Alain From nilsgladitz at gmail.com Wed Sep 13 05:16:02 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 13 Sep 2017 11:16:02 +0200 Subject: [CMake] CMakeLists.txt location In-Reply-To: <0857fb2e-dcdf-3b13-1357-bf637c0d3a55@oca.eu> References: <0857fb2e-dcdf-3b13-1357-bf637c0d3a55@oca.eu> Message-ID: <0ad2c4c7-4f19-e746-0efe-e93199eb4a8c@gmail.com> On 13.09.2017 10:52, Alain Miniussi wrote: > Hi, > > Is there a way, when printing CMake error, to get the exact location > of the CMakeLists.txt ? > > For example, right now, when I have: > > CMake Error at CMakeLists.txt:14 (add_executable): > > I need to scan all my CMakeLists.txt (~200) to check which one has > add_executable at line 14. CMake includes the (relative to the root source directory) path for me e.g.: CMake Error at Source/CMakeLists.txt:4 (add_executable): Nils From Alain.Miniussi at oca.eu Wed Sep 13 06:22:46 2017 From: Alain.Miniussi at oca.eu (Alain Miniussi) Date: Wed, 13 Sep 2017 12:22:46 +0200 Subject: [CMake] CMakeLists.txt location In-Reply-To: <0ad2c4c7-4f19-e746-0efe-e93199eb4a8c@gmail.com> References: <0857fb2e-dcdf-3b13-1357-bf637c0d3a55@oca.eu> <0ad2c4c7-4f19-e746-0efe-e93199eb4a8c@gmail.com> Message-ID: On 13/09/2017 11:16, Nils Gladitz wrote: > On 13.09.2017 10:52, Alain Miniussi wrote: >> Hi, >> >> Is there a way, when printing CMake error, to get the exact location >> of the CMakeLists.txt ? >> >> For example, right now, when I have: >> >> CMake Error at CMakeLists.txt:14 (add_executable): >> >> I need to scan all my CMakeLists.txt (~200) to check which one has >> add_executable at line 14. > > CMake includes the (relative to the root source directory) path for me > e.g.: > CMake Error at Source/CMakeLists.txt:4 (add_executable): Well, it never did for me: $grep add_executable CMakeLists.txt $ Alain From nilsgladitz at gmail.com Wed Sep 13 06:49:54 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 13 Sep 2017 12:49:54 +0200 Subject: [CMake] CMakeLists.txt location In-Reply-To: References: <0857fb2e-dcdf-3b13-1357-bf637c0d3a55@oca.eu> <0ad2c4c7-4f19-e746-0efe-e93199eb4a8c@gmail.com> Message-ID: <722a5b1c-e462-f973-f0e4-19ace285b0e5@gmail.com> On 13.09.2017 12:22, Alain Miniussi wrote: > > > On 13/09/2017 11:16, Nils Gladitz wrote: >> On 13.09.2017 10:52, Alain Miniussi wrote: >>> Hi, >>> >>> Is there a way, when printing CMake error, to get the exact location >>> of the CMakeLists.txt ? >>> >>> For example, right now, when I have: >>> >>> CMake Error at CMakeLists.txt:14 (add_executable): >>> >>> I need to scan all my CMakeLists.txt (~200) to check which one has >>> add_executable at line 14. >> >> CMake includes the (relative to the root source directory) path for >> me e.g.: >> CMake Error at Source/CMakeLists.txt:4 (add_executable): > Well, it never did for me: > $grep add_executable CMakeLists.txt > $ > > Alain Do you have a minimal reproducible example for that behaviour? e.g. given: cmake_minimum_required(VERSION 2.8.0) project(Foo NONE) file(WRITE foo/CMakeLists.txt "add_executable()") add_subdirectory(foo) I get: CMake Error at foo/CMakeLists.txt:1 (add_executable): add_executable called with incorrect number of arguments Even with the oldest CMake version currently available to me (2.8.0). Nils From mateusz at loskot.net Wed Sep 13 07:53:30 2017 From: mateusz at loskot.net (Mateusz Loskot) Date: Wed, 13 Sep 2017 13:53:30 +0200 Subject: [CMake] CMakeLists.txt location In-Reply-To: <722a5b1c-e462-f973-f0e4-19ace285b0e5@gmail.com> References: <0857fb2e-dcdf-3b13-1357-bf637c0d3a55@oca.eu> <0ad2c4c7-4f19-e746-0efe-e93199eb4a8c@gmail.com> <722a5b1c-e462-f973-f0e4-19ace285b0e5@gmail.com> Message-ID: On 13 September 2017 at 12:49, Nils Gladitz wrote: > On 13.09.2017 12:22, Alain Miniussi wrote: >> On 13/09/2017 11:16, Nils Gladitz wrote: >>> On 13.09.2017 10:52, Alain Miniussi wrote: >>>> >>>> Is there a way, when printing CMake error, to get the exact location of >>>> the CMakeLists.txt ? >>>> >>>> For example, right now, when I have: >>>> >>>> CMake Error at CMakeLists.txt:14 (add_executable): >>>> >>>> I need to scan all my CMakeLists.txt (~200) to check which one has >>>> add_executable at line 14. >>> >>> >>> CMake includes the (relative to the root source directory) path for me >>> e.g.: >>> CMake Error at Source/CMakeLists.txt:4 (add_executable): >> >> Well, it never did for me: >> $grep add_executable CMakeLists.txt >> $ > > Do you have a minimal reproducible example for that behaviour? > > e.g. given: > > cmake_minimum_required(VERSION 2.8.0) > project(Foo NONE) > file(WRITE foo/CMakeLists.txt "add_executable()") > add_subdirectory(foo) > > I get: > > CMake Error at foo/CMakeLists.txt:1 (add_executable): > add_executable called with incorrect number of arguments I can confirm this works with cmake version 3.9.0 on Windows 10 D:\tmp\cmake-location\build>cmake .. -- Building for: Visual Studio 15 2017 CMake Error at foo/CMakeLists.txt:1 (add_executable): add_executable called with incorrect number of arguments -- Configuring incomplete, errors occurred! See also "D:/tmp/cmake-location/build/CMakeFiles/CMakeOutput.log". Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From Alain.Miniussi at oca.eu Wed Sep 13 08:31:21 2017 From: Alain.Miniussi at oca.eu (Alain Miniussi) Date: Wed, 13 Sep 2017 14:31:21 +0200 Subject: [CMake] CMakeLists.txt location In-Reply-To: <722a5b1c-e462-f973-f0e4-19ace285b0e5@gmail.com> References: <0857fb2e-dcdf-3b13-1357-bf637c0d3a55@oca.eu> <0ad2c4c7-4f19-e746-0efe-e93199eb4a8c@gmail.com> <722a5b1c-e462-f973-f0e4-19ace285b0e5@gmail.com> Message-ID: On 13/09/2017 12:49, Nils Gladitz wrote: > [...] > Do you have a minimal reproducible example for that behaviour? > > > e.g. given: > > cmake_minimum_required(VERSION 2.8.0) > > project(Foo NONE) > > file(WRITE foo/CMakeLists.txt "add_executable()") > > add_subdirectory(foo) > > > I get: > > CMake Error at foo/CMakeLists.txt:1 (add_executable): > add_executable called with incorrect number of arguments > > > Even with the oldest CMake version currently available to me (2.8.0). That test case works for me too. But my real case does not. I think it would be tricky to minimized, what is failling is the second run of cmake, after a modification in the build system or in a configure_file source. -------------------------------- CMake Error at CMakeLists.txt:14 (add_executable): Target "cmTC_60ee6" links to item " -Xlinker --enable-new-dtags -Xlinker -rpath -Xlinker /opt/software/common/intel/impi/2017.0.098/intel64/lib/release_mt -Xlinker -rpath -Xlinker /opt/software/common/intel/impi/2017.0.098/intel64/lib -Xlinker -rpath -Xlinker /opt/intel/mpi-rt/2017.0.0/intel64/lib/release_mt -Xlinker -rpath -Xlinker /opt/intel/mpi-rt/2017.0.0/intel64/lib /opt/software/occigen/libraries/boost/1_63_0/intel/17.0/intelmpi/2017.0.098/lib/libboost_serialization.a" which has leading or trailing whitespace. This is now an error according to policy CMP0004. CMake Error: Internal CMake error, TryCompile generation of cmake failed INFO Boost MPI not available or too old: -------------------------------- Now, maybe the problem is with a CMakeLists.tx generated by a try_compile. Indicating that I would actually need the location of the try_compile. Thanks Alain > > > Nils > From nilsgladitz at gmail.com Wed Sep 13 08:45:33 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Wed, 13 Sep 2017 14:45:33 +0200 Subject: [CMake] CMakeLists.txt location In-Reply-To: References: <0857fb2e-dcdf-3b13-1357-bf637c0d3a55@oca.eu> <0ad2c4c7-4f19-e746-0efe-e93199eb4a8c@gmail.com> <722a5b1c-e462-f973-f0e4-19ace285b0e5@gmail.com> Message-ID: <3dbdbc64-97e0-26f4-7077-29b849c31d82@gmail.com> On 13.09.2017 14:31, Alain Miniussi wrote: > > > On 13/09/2017 12:49, Nils Gladitz wrote: >> [...] >> Do you have a minimal reproducible example for that behaviour? >> >> >> e.g. given: >> >> cmake_minimum_required(VERSION 2.8.0) >> >> project(Foo NONE) >> >> file(WRITE foo/CMakeLists.txt "add_executable()") >> >> add_subdirectory(foo) >> >> >> I get: >> >> CMake Error at foo/CMakeLists.txt:1 (add_executable): >> add_executable called with incorrect number of arguments >> >> >> Even with the oldest CMake version currently available to me (2.8.0). > That test case works for me too. But my real case does not. > I think it would be tricky to minimized, what is failling is the > second run of cmake, after a modification in the build system or in a > configure_file source. > > -------------------------------- > CMake Error at CMakeLists.txt:14 (add_executable): > Target "cmTC_60ee6" links to item " -Xlinker --enable-new-dtags > -Xlinker > -rpath -Xlinker > /opt/software/common/intel/impi/2017.0.098/intel64/lib/release_mt > -Xlinker > -rpath -Xlinker /opt/software/common/intel/impi/2017.0.098/intel64/lib > -Xlinker -rpath -Xlinker > /opt/intel/mpi-rt/2017.0.0/intel64/lib/release_mt > -Xlinker -rpath -Xlinker /opt/intel/mpi-rt/2017.0.0/intel64/lib > /opt/software/occigen/libraries/boost/1_63_0/intel/17.0/intelmpi/2017.0.098/lib/libboost_serialization.a" > > which has leading or trailing whitespace. This is now an error > according > to policy CMP0004. > > > CMake Error: Internal CMake error, TryCompile generation of cmake failed > INFO Boost MPI not available or too old: > -------------------------------- > > Now, maybe the problem is with a CMakeLists.tx generated by a > try_compile. > Indicating that I would actually need the location of the try_compile. > > Thanks > > Alain Ok, I assume that means you are actually looking at CMakeError.log and not the output you get from CMake concerning your own project's configuration run. try_compile() runs aren't necessarily meant to succeed but rather their outcome is used in conditionals which may or may not have fatal outcomes for your actual project. If a fatal diagnostic is produced based on such a conditional it would be visible in CMake's direct output (with file and line information) not CMakeError.log. You only need to look at CMakeError.log to understand why a try_compile() did not succeed even though you would have expected it to. The CMakeLists.txt where the error comes from in your failing try_compile() is generated and temporary so you will not find it in your own sources. Nils From csiga.biga at aol.com Wed Sep 13 09:08:43 2017 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Wed, 13 Sep 2017 15:08:43 +0200 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: References: Message-ID: Indeed, such a feature would come in handy to test libraries for correctly failing on erronous user input. What amazes me even more is that noone has stepped up yet to create CBench. A utility executable for measuring compilation times and capture output of some (micro)benchmark instrumentation, either one of its own or some external tool, like google/benchmark. Present output either as a table on the console, ASCII art or as .xls/.html? you get what I mean. Has it never bothered anyone enough yet to create quantitative output of a build, other than the binary failed/passed kind tests? Felad?: Robert Ramey Elk?ldve: 2017. szeptember 12., kedd 19:12 C?mzett: cmake at cmake.org T?rgy: Re: [CMake] Adding compile and build type tests to CMake/CTest On 9/4/17 6:40 AM, Edward Diener wrote: > Boost Build has tests for running an application successfully or not, > for compiling one or more source files successfully or not, and for > building one or more source files into an exe or not. These tests in > Boost Build are the run/run-fail, compile/compile-fail, and > link/link-fail rules. > > CMake/CTest has the exact equivalent to the run/run-fail rule in its > add_test framework, but there is not add_test equivalent to the other > two sets of rules. It sure would be nice, when Boost transitions to > using CMake/CTest instead of Boost Build, if CMake/CTest had the > equivalent of the other two sets of types of test in its add_test > framework. > > Is there any consensus that these other two types of tests might be > valuable for CMake/CTest, or any way to make this happen ? > I would like to second this suggestion. The absence of this feature presents a huge obstacle to replicating the functionality of the boost build functionality with CMake. It's amazing to me that after so many years CMake doesn't have this functionality already. It certainly seems to me that this would be easy to implement. I'm aware that suggestions using CMake macros have been proposed. But to the inexperienced user they are not intuitive or easy to understand. Could we get some response on Edward's suggestion here? It's a serious obstacle to implementing support of CMake in Boost libraries. Robert Ramey -- 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 robert.maynard at kitware.com Thu Sep 14 09:38:00 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 14 Sep 2017 09:38:00 -0400 Subject: [CMake] Understanding constraint graph cycles In-Reply-To: <4765F92A-A6DC-42CE-BE64-6D9D197A20AA@kdab.com> References: <66D554C8-05E2-40D5-B18E-05E3E93FE218@kdab.com> <4765F92A-A6DC-42CE-BE64-6D9D197A20AA@kdab.com> Message-ID: Yes, You most likely want to look at BUILD_RPATH or INSTALL_RPATH depending on if these libraries are located in your build directory or install directory. On Mon, Sep 4, 2017 at 4:39 PM, James Turner wrote: > > On 4 Sep 2017, at 18:37, Robert Maynard wrote: > > Yes you are correct the issue is related to rpath. When CMake constructs the > rpath for the library linking it will have two paths ( > /home/jenkins/workspace/FlightGear/dist/lib64, > /home/jenkins/workspace/SimGear/dist/lib64) each that contain a copy of > libosgText.so.130. CMake is warning that which version of libosgText is > undefined. > > > Can I control whether CMake includes the rpath flags for a static library > like SimGear? Normally the default behaviour is correct but for this > particular config it would be easier to disable the rpath for OSG inside > SimGear, than adjust the build setup to use a common dist dir, I think. > > Kind regards, > James > From bill.hoffman at kitware.com Thu Sep 14 16:45:27 2017 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 14 Sep 2017 16:45:27 -0400 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: References: Message-ID: <5995520f-33e3-062d-795a-3280b06d3d9f@kitware.com> On 9/12/2017 1:11 PM, Robert Ramey wrote: > > Could we get some response on Edward's suggestion here? It's a serious > obstacle?to?implementing?support?of?CMake?in?Boost?libraries. I don't think it would be a problem to implement something like this in CMake. It might make more sense to move this conversation to the cmake-developers list where we can discuss the particulars of the interface and implementation. Then we can figure out how to get it implemented. Edward, did you want to start the discussion on the cmake-developers list? Thanks. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman at kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 From eldlistmailingz at tropicsoft.com Thu Sep 14 23:24:55 2017 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Thu, 14 Sep 2017 23:24:55 -0400 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: <5995520f-33e3-062d-795a-3280b06d3d9f@kitware.com> References: <5995520f-33e3-062d-795a-3280b06d3d9f@kitware.com> Message-ID: On 9/14/2017 4:45 PM, Bill Hoffman wrote: > On 9/12/2017 1:11 PM, Robert Ramey wrote: >> >> Could we get some response on Edward's suggestion here? It's a serious >> obstacle?to?implementing?support?of?CMake?in?Boost?libraries. > I don't think it would be a problem to implement something like this in > CMake.? It might make more sense to move this conversation to the > cmake-developers list where we can discuss the particulars of the > interface and implementation. Then we can figure out how to get it > implemented. > > Edward, did you want to start the discussion on the cmake-developers list? I am not a CMake developer and I have been unable to subscribe to the CMake developer's list. But if you want to move my request to the CMake developers list please go ahead. > > Thanks. > > -Bill From eldlistmailingz at tropicsoft.com Thu Sep 14 23:28:36 2017 From: eldlistmailingz at tropicsoft.com (Edward Diener) Date: Thu, 14 Sep 2017 23:28:36 -0400 Subject: [CMake] Adding compile and build type tests to CMake/CTest In-Reply-To: <5995520f-33e3-062d-795a-3280b06d3d9f@kitware.com> References: <5995520f-33e3-062d-795a-3280b06d3d9f@kitware.com> Message-ID: On 9/14/2017 4:45 PM, Bill Hoffman wrote: > On 9/12/2017 1:11 PM, Robert Ramey wrote: >> >> Could we get some response on Edward's suggestion here? It's a serious >> obstacle?to?implementing?support?of?CMake?in?Boost?libraries. > I don't think it would be a problem to implement something like this in > CMake.? It might make more sense to move this conversation to the > cmake-developers list where we can discuss the particulars of the > interface and implementation. Then we can figure out how to get it > implemented. > > Edward, did you want to start the discussion on the cmake-developers list? It looks like my subscription to the CMake developers list went through. > > Thanks. > > -Bill > > > > > From randy.heiland at gmail.com Fri Sep 15 07:38:07 2017 From: randy.heiland at gmail.com (Randy Heiland) Date: Fri, 15 Sep 2017 07:38:07 -0400 Subject: [CMake] Visual Studio 2017 Message-ID: Hello, I've googled "site:cmake.org/pipermail/cmake visual studio 2017" looking for answers, but still confused, so thought I'd ask this list. Is there a "best way" to use cmake for VS17 (but same cakelists for Linux)? And by "best", I mean with minimal effort on users. To be more specific, on Windows, I *think* I'd like to have users install the cmake binary, then use Powershell to build an application. But my initial attempt to do so is confusing. I install VS17 (for C++), it installs in standard path, but 'cl' is not found in Powershell. I read that I shouldn't edit my PATH (nor do I really want users to have to), but run some .bat instead to setup my env. So, how should one specify the compiler for cmake? Oh yes, then I see that VS17 also has its own cmake?? I'd welcome suggestions. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Fri Sep 15 08:13:51 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 15 Sep 2017 14:13:51 +0200 Subject: [CMake] setting/removing compiler flag (-g) for a single project directory Message-ID: <3177894.846KUBUtOu@bola> Hi, Is it possible to set and/or remove compiler arguments on a project subdirectory that holds a tree with sources of a considerable number of build targets? An example to make this more concrete: I have a project that contains common_libs plugins/foo plugins/this_one I'm just interested in building plugins/this_one and can do so by calling make && make install/fast inside the build/plugins/this_one directory. All plugin dependencies are already installed (with debug info). The build/common_libs directory gets pretty big and is expensive to build, so ideally I would build everything in there with different flags, basically replacing -O3|-O2 with -Os and removing the -g option, possibly even running a strip before continuing the rest of the build. I know one can do this kind of thing per target or even per file, but how does one do it on a directory basis? Do I have to cache the original CMAKE_C*_FLAGS value before modifying it in common_libs/CMakeLists.txt , and restore it before returning from that file? Or is there a more elegant method? Thanks, Ren? From Mateju.Miroslav at azd.cz Fri Sep 15 08:15:21 2017 From: Mateju.Miroslav at azd.cz (=?utf-8?B?TWF0xJtqxa8gTWlyb3NsYXYsIEluZy4=?=) Date: Fri, 15 Sep 2017 12:15:21 +0000 Subject: [CMake] Visual Studio 2017 In-Reply-To: References: Message-ID: Hello Randy, From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Randy Heiland Sent: Friday, September 15, 2017 1:38 PM > Is there a "best way" to use cmake for VS17 (but same cakelists for Linux)? And by "best", I mean with minimal effort on users. > To be more specific, on Windows, I *think* I'd like to have users install the cmake binary, then use Powershell to build an application. Is there really a need for using PowerShell if you also want to use the same CMakeLists for Linux? > But my initial attempt to do so is confusing. I install VS17 (for C++), it installs in standard path, but 'cl' is not found in Powershell. I read that I shouldn't edit my PATH (nor do I really want users to have to), but run some .bat instead to setup my env. So, how should one specify the compiler for cmake? Oh yes, then I see that VS17 also has its own cmake?? Have you run CMake successfully yet? I am not really aware how it works but CMake *can* for sure detect VS in my CLI environment without having VS in PATH. If you use an IDE that understands CMake (like VS17 or Qt Creator, for example), you should be able to open a CMake project in the IDE and build it there. Please report your particular problem if it does not work for you. If you prefer to run cl.exe in CLI, then vcvarsall.bat is the .bat file you are looking for. Best regards, Ing.?Miroslav Mat?j? Programmer Analyst A?D Praha s.r.o. Technology Division Research and Development ?irovnick? 2/3146, 106 17 Prague Czech Republic Phone: +420?267?287?476 Web: www.azd.cz From bruce.david.jones at gmail.com Fri Sep 15 09:23:42 2017 From: bruce.david.jones at gmail.com (Bruce Jones) Date: Fri, 15 Sep 2017 13:23:42 +0000 Subject: [CMake] SWIG CMAKE project not linked correctly In-Reply-To: References: Message-ID: Hi, I have a relatively simple SWIG - CMAKE project that is not linked correctly, source files can be downloaded here: https://drive.google.com/open?id=0B4Y0idbHnikgTUlocmQtNDY2czQ The problem I have is if the template function Foo is implemented in the header file, the project compiles and works successfully. If Foo is instead implemented in the cpp file, the project compiles but fails either when linking on at runtime on Windows and Linux respectively. On windows the build will fail at linking with "unresolved external symbols", as though the template function is not instantiated. On Linux python fails to import the module with "undefined symbol". If I build the projects by hand (not with CMake) they compile and link successfully, and run successfully. Any suggestions? Cheers, Bruce -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Fri Sep 15 12:33:24 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Fri, 15 Sep 2017 18:33:24 +0200 Subject: [CMake] SWIG CMAKE project not linked correctly In-Reply-To: References: Message-ID: <94A475AF-4593-4FCE-B08F-A77A7B0CAD56@hendrik-sattler.de> Am 15. September 2017 15:23:42 MESZ schrieb Bruce Jones : >Hi, > >I have a relatively simple SWIG - CMAKE project that is not linked >correctly, source files can be downloaded here: >https://drive.google.com/open?id=0B4Y0idbHnikgTUlocmQtNDY2czQ > >The problem I have is if the template function Foo is implemented in >the >header file, the project compiles and works successfully. If Foo is >instead >implemented in the cpp file, the project compiles but fails either when >linking on at runtime on Windows and Linux respectively. Templated member functions must be defined in the header. Exceptions are explicitly instantiated ones for certain template parameter values. >On windows the build will fail at linking with "unresolved external >symbols", as though the template function is not instantiated. > >On Linux python fails to import the module with "undefined symbol". > >If I build the projects by hand (not with CMake) they compile and link >successfully, and run successfully. Strange. it should not work because the method definition in the cpp file will not result in any symbol due to unknown type T. So what are you doing differently? Some commands must differ. HS -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From bruce.david.jones at gmail.com Fri Sep 15 13:19:38 2017 From: bruce.david.jones at gmail.com (Bruce Jones) Date: Fri, 15 Sep 2017 17:19:38 +0000 Subject: [CMake] SWIG CMAKE project not linked correctly In-Reply-To: <94A475AF-4593-4FCE-B08F-A77A7B0CAD56@hendrik-sattler.de> References: <94A475AF-4593-4FCE-B08F-A77A7B0CAD56@hendrik-sattler.de> Message-ID: I'm not sure what is different between the CMake generated build and the manual build, but according to the swig community definitions in the cpp should be fine. I also couldn't find anything in the swig documentation to suggest otherwise. I did originally raise an issue on the swig github page: https://github.com/swig/swig/issues/1091#issuecomment-329606916 On Fri, 15 Sep 2017 at 12:33 Hendrik Sattler wrote: > > > Am 15. September 2017 15:23:42 MESZ schrieb Bruce Jones < > bruce.david.jones at gmail.com>: > >Hi, > > > >I have a relatively simple SWIG - CMAKE project that is not linked > >correctly, source files can be downloaded here: > >https://drive.google.com/open?id=0B4Y0idbHnikgTUlocmQtNDY2czQ > > > >The problem I have is if the template function Foo is implemented in > >the > >header file, the project compiles and works successfully. If Foo is > >instead > >implemented in the cpp file, the project compiles but fails either when > >linking on at runtime on Windows and Linux respectively. > > Templated member functions must be defined in the header. Exceptions are > explicitly instantiated ones for certain template parameter values. > > >On windows the build will fail at linking with "unresolved external > >symbols", as though the template function is not instantiated. > > > >On Linux python fails to import the module with "undefined symbol". > > > >If I build the projects by hand (not with CMake) they compile and link > >successfully, and run successfully. > > Strange. it should not work because the method definition in the cpp file > will not result in any symbol due to unknown type T. So what are you doing > differently? Some commands must differ. > > HS > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgt at lanl.gov Fri Sep 15 15:05:25 2017 From: kgt at lanl.gov (Thompson, KT) Date: Fri, 15 Sep 2017 19:05:25 +0000 Subject: [CMake] FW: Visual Studio 2017 In-Reply-To: References: <1598bcddc16a4027871d29a8e2a70746@EXG13-P-MBX14.win.lanl.gov> Message-ID: Randy, Miroslav's recommendation should work. To expand on his response, here are the commands that I use with VS2017 to allow cmake to run from the command line: - Start cmd session (should also work via powershell) - To import VS17's command line environment run "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 - Add extra project specific environment variables (possibly including appending PATH with the location of cmake). I created a batch file that does these steps for me (and a shortcut on my desktop that runs the batch file). @echo off rem cmake-with-vs17-env.bat @call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 %* set PATH=%PATH%;c:\MinGW\bin;C:\Program Files\CMake\bin;C:\Program Files\doxygen\bin;c:\Python27amd64 rem set CMAKE_PREFIX_PATH= With this environment, I can run cmake from the command line (cmake-gui or cmake). I can generate "Visual Studio 15 2017" or "MSYS Makefiles" projects and I can build them with or w/o the GUI. I hope this helps! -kt -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Mateju Miroslav, Ing. Sent: Friday, September 15, 2017 6:15 AM To: Randy Heiland ; cmake at cmake.org Subject: Re: [CMake] Visual Studio 2017 Hello Randy, From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Randy Heiland Sent: Friday, September 15, 2017 1:38 PM > Is there a "best way" to use cmake for VS17 (but same cakelists for Linux)? And by "best", I mean with minimal effort on users. > To be more specific, on Windows, I *think* I'd like to have users install the cmake binary, then use Powershell to build an application. Is there really a need for using PowerShell if you also want to use the same CMakeLists for Linux? > But my initial attempt to do so is confusing. I install VS17 (for C++), it installs in standard path, but 'cl' is not found in Powershell. I read that I shouldn't edit my PATH (nor do I really want users to have to), but run some .bat instead to setup my env. So, how should one specify the compiler for cmake? Oh yes, then I see that VS17 also has its own cmake?? Have you run CMake successfully yet? I am not really aware how it works but CMake *can* for sure detect VS in my CLI environment without having VS in PATH. If you use an IDE that understands CMake (like VS17 or Qt Creator, for example), you should be able to open a CMake project in the IDE and build it there. Please report your particular problem if it does not work for you. If you prefer to run cl.exe in CLI, then vcvarsall.bat is the .bat file you are looking for. Best regards, Ing.?Miroslav Mat?j? Programmer Analyst A?D Praha s.r.o. Technology Division Research and Development ?irovnick? 2/3146, 106 17 Prague Czech Republic Phone: +420?267?287?476 Web: www.azd.cz -- 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 robin at clanmills.com Sat Sep 16 03:39:51 2017 From: robin at clanmills.com (Robin Mills) Date: Sat, 16 Sep 2017 08:39:51 +0100 Subject: [CMake] CMake Visual Studio zlib zlibstatic.lib Message-ID: <8111C9CA-3DEC-43C3-BF5B-DD3582D38E79@clanmills.com> Folks My project (exiv2.org ) uses zlib and is builds well on all platforms (Linux, Cygwin, MacOS-X and Visual Studio) with CMake. A user complained that the CMake/Visual Studio static builds link zlib.dll (zlibd.dll for debug) and wants to link zlibstatic.lib (zlibstaticd.lib). I've tracked this down to FindZlib.cmake which sets ZLIB_FOUND, ZLIB_LIBRARIES and ZLIB_INCLUDE_DIRS to use the zlib dynamic libraries. For the moment, I have a work-around which externally copies zlibstatic.lib to overwrite zlib.lib. I've inspected the code in FindZlib.cmake and it doesn't appear to know about zlibstatic. I've unsuccessfully tried to use string(REPLACE ...) on ZLIB_LIBRARIES. I don't know CMake very well. Is ZLIB_LIBRARIES a string or a list of strings? How can I either edit it, or get a new variable ZLIB_STATIC_LIBRARIES to pass to target_link_libraries(...) Any suggestions? All help appreciated. Robin Mills -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Exiv2Logo.png Type: image/png Size: 49689 bytes Desc: not available URL: From rjvbertin at gmail.com Sat Sep 16 04:07:42 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sat, 16 Sep 2017 10:07:42 +0200 Subject: [CMake] setting/removing compiler flag (-g) for a single project directory In-Reply-To: References: <3177894.846KUBUtOu@bola> <3000794.YHycKNaoGH@bola> Message-ID: <2904067.AGimot0Eyc@bola> On Friday September 15 2017 16:51:24 Steven Velez wrote: >Yeah... I didn't mean to respond personally... i didn't realize my client >was doing that and not the list. OK, replying back to the list then. >What do you mean by "variables related to targets have global scope"? I probably could have been a bit less vague. Defining a target in a subdirectory sets something that behaves like a global variable (pardon, constant :)), at least for libraries. That's the whole point of that common_dir subtree: it defines library targets which are then used for linking the plugin. R. > >On Fri, Sep 15, 2017 at 3:44 PM, Ren? J.V. Bertin >wrote: > >> On Friday September 15 2017 15:34:34 Steven Velez wrote: >> >> Logically that's what I'd expect, but then the variables related to >> targets have global scope, variables set in a module directories too etc. I >> preferred to ask, so thanks :) >> >> R. >> >> >All directories in cmake have their own scopes which are initialized by >> the >> >scope of the parent directory. >> > >> >So, if you set the variables you wish to set in CMakeLists.txt of >> >common_libs, they should not influence the builds in the plugin directory, >> >but will influence the builds in that directory and subdirectories. >> > >> >https://cmake.org/cmake/help/v3.9/manual/cmake-language.7. >> html#cmake-language-variables >> > >> >For more info. >> > >> >Steven From mwpowellhtx at gmail.com Sat Sep 16 17:25:46 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Sat, 16 Sep 2017 17:25:46 -0400 Subject: [CMake] Changing the actual "src" directory where VS project and/or sln files are rooted Message-ID: Hello, Sorry if this seems like a rookie/novice question. I'm not new to CI/CD, however; this question may have been asked before, I don't know. I'll preface with a little background. It's been a little while for me using and truly "grokking" CMake, but if memory serves, CMake lifts raw source inputs and drops them into what becomes a meta-description for what is ultimately being built. That could overlay the source directories, but may not. That's if memory serves. Now, I am trying to configure and generated CMake targeting the Visual Studio 2015 environment. My repository is organized something like: $/CMakeLists.txt $/src $/src/CMakeLists.txt $/src/... (for things like tests, etc) And so on. Solution files are landing in the $/ directory, but I want them to land in the $/src directory as is customary for Visual Studio solutions. First, as far as I know, the OA (original author) is dropping CMake-driven output in the same context as the source files. Maybe that's good and/or acceptable, maybe not, considering the meta-descriptive nature of CMake. So the first question is how to cause CMake to respect the $/src objective. Otherwise, perhaps I simply have CMake generate the penultimate build structure. Close behind those questions is how to avoid outputs like ALL_BUILD and ZERO_CHECK. Those are not necessary, or perhaps are don't care, especially if output can land in $/src as envisioned. Thank you! Regards, Michael Powell From d3ck0r at gmail.com Sat Sep 16 17:44:22 2017 From: d3ck0r at gmail.com (J Decker) Date: Sat, 16 Sep 2017 14:44:22 -0700 Subject: [CMake] Changing the actual "src" directory where VS project and/or sln files are rooted In-Reply-To: References: Message-ID: On Sat, Sep 16, 2017 at 2:25 PM, Michael Powell wrote: > Hello, > > Sorry if this seems like a rookie/novice question. I'm not new to > CI/CD, however; this question may have been asked before, I don't > know. > > I'll preface with a little background. It's been a little while for me > using and truly "grokking" CMake, but if memory serves, CMake lifts > raw source inputs and drops them into what becomes a meta-description > for what is ultimately being built. That could overlay the source > directories, but may not. That's if memory serves. > > Now, I am trying to configure and generated CMake targeting the Visual > Studio 2015 environment. > > My repository is organized something like: > > $/CMakeLists.txt > $/src > $/src/CMakeLists.txt > $/src/... (for things like tests, etc) > > And so on. > > Solution files are landing in the $/ directory, but I want them to > land in the $/src directory as is customary for Visual Studio > solutions. > Then you're doing an in-source build which is not really the proper thing... they should land in something like $/build or $/../build even. and then it wouldn't matter where they were. > > First, as far as I know, the OA (original author) is dropping > CMake-driven output in the same context as the source files. Maybe > that's good and/or acceptable, maybe not, considering the > meta-descriptive nature of CMake. > > So the first question is how to cause CMake to respect the $/src > objective. Otherwise, perhaps I simply have CMake generate the > penultimate build structure. > > Close behind those questions is how to avoid outputs like ALL_BUILD > and ZERO_CHECK. Those are not necessary, or perhaps are don't care, > especially if output can land in $/src as envisioned. > > Thank you! > > Regards, > > Michael Powell > -- > > 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 mwpowellhtx at gmail.com Sat Sep 16 17:49:49 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Sat, 16 Sep 2017 17:49:49 -0400 Subject: [CMake] Changing the actual "src" directory where VS project and/or sln files are rooted In-Reply-To: References: Message-ID: On Sat, Sep 16, 2017 at 5:44 PM, J Decker wrote: > > > On Sat, Sep 16, 2017 at 2:25 PM, Michael Powell > wrote: >> >> Hello, >> >> Sorry if this seems like a rookie/novice question. I'm not new to >> CI/CD, however; this question may have been asked before, I don't >> know. >> >> I'll preface with a little background. It's been a little while for me >> using and truly "grokking" CMake, but if memory serves, CMake lifts >> raw source inputs and drops them into what becomes a meta-description >> for what is ultimately being built. That could overlay the source >> directories, but may not. That's if memory serves. >> >> Now, I am trying to configure and generated CMake targeting the Visual >> Studio 2015 environment. >> >> My repository is organized something like: >> >> $/CMakeLists.txt >> $/src >> $/src/CMakeLists.txt >> $/src/... (for things like tests, etc) >> >> And so on. >> >> Solution files are landing in the $/ directory, but I want them to >> land in the $/src directory as is customary for Visual Studio >> solutions. > > Then you're doing an in-source build which is not really the proper thing... > they should land in something like $/build or $/../build even. and then it > wouldn't matter where they were. Ah, indeed, "in-source", thank you. The vocab escaped me. Yes, that seemed odd to me as well, if my recollection served (which apparently it does). Thanks for the clarification. >> >> >> First, as far as I know, the OA (original author) is dropping >> CMake-driven output in the same context as the source files. Maybe >> that's good and/or acceptable, maybe not, considering the >> meta-descriptive nature of CMake. >> >> So the first question is how to cause CMake to respect the $/src >> objective. Otherwise, perhaps I simply have CMake generate the >> penultimate build structure. >> >> Close behind those questions is how to avoid outputs like ALL_BUILD >> and ZERO_CHECK. Those are not necessary, or perhaps are don't care, >> especially if output can land in $/src as envisioned. >> >> Thank you! >> >> Regards, >> >> Michael Powell >> -- >> >> 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 sbv1976 at gmail.com Sun Sep 17 00:25:11 2017 From: sbv1976 at gmail.com (Steven Velez) Date: Sun, 17 Sep 2017 00:25:11 -0400 Subject: [CMake] setting/removing compiler flag (-g) for a single project directory In-Reply-To: <2904067.AGimot0Eyc@bola> References: <3177894.846KUBUtOu@bola> <3000794.YHycKNaoGH@bola> <2904067.AGimot0Eyc@bola> Message-ID: Gotcha... yeah target definitions are available globally, in all directories after they are defined (source order is important). I had never thought of this as a global variable or constant, but I guess in a way it is. In that way, then I would think it is a sort of special case... but I suppose the experts should chime in. Steven On Sat, Sep 16, 2017 at 4:07 AM, Ren? J.V. Bertin wrote: > On Friday September 15 2017 16:51:24 Steven Velez wrote: > > >Yeah... I didn't mean to respond personally... i didn't realize my client > >was doing that and not the list. > > OK, replying back to the list then. > > >What do you mean by "variables related to targets have global scope"? > > I probably could have been a bit less vague. Defining a target in a > subdirectory sets something that behaves like a global variable (pardon, > constant :)), at least for libraries. That's the whole point of that > common_dir subtree: it defines library targets which are then used for > linking the plugin. > > R. > > > > >On Fri, Sep 15, 2017 at 3:44 PM, Ren? J.V. Bertin > >wrote: > > > >> On Friday September 15 2017 15:34:34 Steven Velez wrote: > >> > >> Logically that's what I'd expect, but then the variables related to > >> targets have global scope, variables set in a module directories too > etc. I > >> preferred to ask, so thanks :) > >> > >> R. > >> > >> >All directories in cmake have their own scopes which are initialized by > >> the > >> >scope of the parent directory. > >> > > >> >So, if you set the variables you wish to set in CMakeLists.txt of > >> >common_libs, they should not influence the builds in the plugin > directory, > >> >but will influence the builds in that directory and subdirectories. > >> > > >> >https://cmake.org/cmake/help/v3.9/manual/cmake-language.7. > >> html#cmake-language-variables > >> > > >> >For more info. > >> > > >> >Steven > > -- > > 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 rjvbertin at gmail.com Mon Sep 18 04:48:21 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Mon, 18 Sep 2017 10:48:21 +0200 Subject: [CMake] cmake not always replacing symlinks in the path used to access a build.dir?! Message-ID: <4344553.Kkj24fy5sj@bola> Hi, I'm seeing a weird issue with a large project: KDevelop. It was reorganised recently but I think that's what exposes the issue, rather than causing it. My workflow puts both source and out-of-source build directories rather deep in a dedicated "playground"; for convenience I create symlinks to the parent of both directories in one of my own work directories under my $HOME: %> ls -l kdevd-lnx-work lrwxrwxrwx 1 bertin bertin 92 Sep 5 15:18 kdevld-lnx-work -> /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work As long as I chdir directly into that "hidden" build.dir, invoke cmake and then make from there things are fine. Problems occur though when I change something in one of the project's CMakeLists.txt files, chdir into the build.dir via the symlink and then issue a make without running cmake by hand. Consider the example below where I tried to do partial rebuild (something that's always worked reliably for me, a feature I really appreciate with cmake!). Evidently make is being executed in the actual directory, as shown by the output from `pwd` just underneath the `CD` line. Somewhere during the snipped part (which I don't have anymore) cmake was called automatically and that's where the symlink must have found its way into the Notice how the failing build of iplugin.cpp uses search paths that include the link that don't work with the relative include paths generated by the moc compiler. How can happen, for all I can tell cmake has no way of knowing about the symlink?! FWIW, it's not something I can reproduce easily. %> where CD CD is aliased to (cd !:^ ; !:2*) %> CD kdevld-lnx-work/build/plugins/ wmake ### now in /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build/plugins ### make -w ### Sun Sep 17 20:32:06 CEST 2017 make: Entering directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build/plugins' [ 0%] Building CXX object kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/iplugin.cpp.o cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces && /opt/local/bin/ccache /opt/local/bin/clang++-mp-4.0 -DKCOREADDONS_LIB -DKDevPlatformInterfaces_EXPORTS -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050500 -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_NO_SIGNALS_SLOTS_KEYWORDS -DQT_NO_URL_CAST_FROM_STRING -DQT_STRICT_ITERATORS -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DTRANSLATION_DOMAIN=\"kdevplatform\" -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces -I/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform/interfaces -I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces/KDevPlatformInterfaces_autogen/include -I/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5 -I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build -I/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform -I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform -isystem /opt/local/include/KF5/KParts -isystem /opt/local/include/KF5 -isystem /opt/local/include/KF5/KIOWidgets -isystem /opt/local/include/KF5/KIOCore -isystem /opt/local/include/KF5/KCoreAddons -isystem /opt/local/include/qt5 -isystem /opt/local/include/qt5/QtCore -isystem /opt/local/share/qt5/mkspecs/linux-g++-64 -isystem /opt/local/include/KF5/KService -isystem /opt/local/include/KF5/KConfigCore -isystem /opt/local/include/KF5/KJobWidgets -isystem /opt/local/include/qt5/QtWidgets -isystem /opt/local/include/qt5/QtGui -isystem /opt/local/include/qt5/QtNetwork -isystem /opt/local/include/KF5/KCompletion -isystem /opt/local/include/KF5/KWidgetsAddons -isystem /opt/local/include/KF5/KXmlGui -isystem /opt/local/include/qt5/QtDBus -isystem /opt/local/include/qt5/QtXml -isystem /opt/local/include/KF5/KConfigWidgets -isystem /opt/local/include/KF5/KCodecs -isystem /opt/local/include/KF5/KConfigGui -isystem /opt/local/include/KF5/KAuth -isystem /opt/local/include/KF5/KTextWidgets -isystem /opt/local/include/KF5/SonnetUi -isystem /opt/local/include/KF5/KI18n -isystem /opt/local/include/KF5/KTextEditor -Ofast -g -DNDEBUG -std=c++11 -m64 -std=c++0x -fno-operator-names -fno-exceptions -DQT_NO_EXCEPTIONS -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wno-missing-field-initializers -Werror=undefined-bool-conversion -Werror=tautological-undefined-compare -Wdocumentation -Wno-gnu-zero-variadic-macro-arguments -pedantic -fPIC -std=gnu++11 -o CMakeFiles/KDevPlatformInterfaces.dir/iplugin.cpp.o -c /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform/interfaces/iplugin.cpp In file included from /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform/interfaces/iplugin.cpp:207: /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces/KDevPlatformInterfaces_autogen/include/moc_iplugin.cpp:9:10: fatal error: '../../../../../../kdevelop-git-5/kdevplatform/interfaces/iplugin.h' file not found #include "../../../../../../kdevelop-git-5/kdevplatform/interfaces/iplugin.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. make[2]: *** [kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/iplugin.cpp.o] Error 1 Thanks, R. From rjvbertin at gmail.com Mon Sep 18 05:19:15 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Mon, 18 Sep 2017 11:19:15 +0200 Subject: [CMake] cmake not always replacing symlinks in the path used to access a build.dir?! In-Reply-To: <4344553.Kkj24fy5sj@bola> References: <4344553.Kkj24fy5sj@bola> Message-ID: <10043465.7cpQeujzVs@bola> WTH, apparently this can even happen without regeneration (that I know of, at least): %> CD kdevld-lnx-work/build/plugins/ wmake --MP -w ### /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build/plugins ### /home/bertin/script/wmake --MP -w ### Mon Sep 18 11:06:15 CEST 2017 make: Entering directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build/plugins' cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build && /opt/local/bin/cmake -H/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5 -B/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build --check-build-system CMakeFiles/Makefile.cmake 0 cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build && /opt/local/bin/cmake -E cmake_progress_start /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/CMakeFiles /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/plugins/CMakeFiles/progress.marks cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build && make -f CMakeFiles/Makefile2 plugins/all make[1]: Entering directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build' make -f kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/build.make kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/depend make[2]: Entering directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build' cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build && /opt/local/bin/cmake -E cmake_depends "Unix Makefiles" /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5 /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform/interfaces /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/DependInfo.cmake --color= Scanning dependencies of target KDevPlatformInterfaces_autogen make[2]: Leaving directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build' make -f kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/build.make kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir/build make[2]: Entering directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build' [ 0%] Automatic MOC for target KDevPlatformInterfaces cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces && /opt/local/bin/cmake -E cmake_autogen /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces_autogen.dir MacPorts Generating MOC predefs moc_predefs.h Generating MOC source include/moc_iplugin.cpp Generating MOC source EWIEGA46WW/moc_configpage.cpp Generating MOC source EWIEGA46WW/moc_iassistant.cpp Generating MOC source EWIEGA46WW/moc_icompletionsettings.cpp Generating MOC source EWIEGA46WW/moc_icore.cpp Generating MOC source EWIEGA46WW/moc_idebugcontroller.cpp Generating MOC source EWIEGA46WW/moc_idocumentation.cpp Generating MOC source EWIEGA46WW/moc_idocumentationcontroller.cpp Generating MOC source EWIEGA46WW/moc_idocumentcontroller.cpp Generating MOC source EWIEGA46WW/moc_ilanguagecontroller.cpp Generating MOC source EWIEGA46WW/moc_ipartcontroller.cpp Generating MOC source EWIEGA46WW/moc_iplugincontroller.cpp Generating MOC source EWIEGA46WW/moc_iproject.cpp Generating MOC source EWIEGA46WW/moc_iprojectcontroller.cpp Generating MOC source EWIEGA46WW/moc_iprojectprovider.cpp Generating MOC source EWIEGA46WW/moc_iruncontroller.cpp Generating MOC source EWIEGA46WW/moc_iruntime.cpp Generating MOC source EWIEGA46WW/moc_iruntimecontroller.cpp Generating MOC source EWIEGA46WW/moc_iselectioncontroller.cpp Generating MOC source EWIEGA46WW/moc_isession.cpp Generating MOC source EWIEGA46WW/moc_isourceformatter.cpp Generating MOC source EWIEGA46WW/moc_isourceformattercontroller.cpp Generating MOC source EWIEGA46WW/moc_itestcontroller.cpp Generating MOC source EWIEGA46WW/moc_launchconfigurationpage.cpp Generating MOC source EWIEGA46WW/moc_launchconfigurationtype.cpp make[2]: Leaving directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build' [ 0%] Built target KDevPlatformInterfaces_autogen make -f kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/build.make kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/depend make[2]: Entering directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build' cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build && /opt/local/bin/cmake -E cmake_depends "Unix Makefiles" /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5 /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform/interfaces /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/DependInfo.cmake --color= Scanning dependencies of target KDevPlatformInterfaces make[2]: Leaving directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build' make -f kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/build.make kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/build make[2]: Entering directory `/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/build' [ 0%] Building CXX object kdevplatform/interfaces/CMakeFiles/KDevPlatformInterfaces.dir/iassistant.cpp.o cd /home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces && /opt/local/bin/ccache /opt/local/bin/clang++-mp-4.0 -DKCOREADDONS_LIB -DKDevPlatformInterfaces_EXPORTS -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050500 -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_NO_SIGNALS_SLOTS_KEYWORDS -DQT_NO_URL_CAST_FROM_STRING -DQT_STRICT_ITERATORS -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DTRANSLATION_DOMAIN=\"kdevplatform\" -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces -I/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform/interfaces -I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform/interfaces/KDevPlatformInterfaces_autogen/include -I/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5 -I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build -I/opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform -I/home/bertin/work/src/Scratch/KDE/KF5/kdevld-lnx-work/build/kdevplatform -isystem /opt/local/include/KF5/KParts -isystem /opt/local/include/KF5 -isystem /opt/local/include/KF5/KIOWidgets -isystem /opt/local/include/KF5/KIOCore -isystem /opt/local/include/KF5/KCoreAddons -isystem /opt/local/include/qt5 -isystem /opt/local/include/qt5/QtCore -isystem /opt/local/share/qt5/mkspecs/linux-g++-64 -isystem /opt/local/include/KF5/KService -isystem /opt/local/include/KF5/KConfigCore -isystem /opt/local/include/KF5/KJobWidgets -isystem /opt/local/include/qt5/QtWidgets -isystem /opt/local/include/qt5/QtGui -isystem /opt/local/include/qt5/QtNetwork -isystem /opt/local/include/KF5/KCompletion -isystem /opt/local/include/KF5/KWidgetsAddons -isystem /opt/local/include/KF5/KXmlGui -isystem /opt/local/include/qt5/QtDBus -isystem /opt/local/include/qt5/QtXml -isystem /opt/local/include/KF5/KConfigWidgets -isystem /opt/local/include/KF5/KCodecs -isystem /opt/local/include/KF5/KConfigGui -isystem /opt/local/include/KF5/KAuth -isystem /opt/local/include/KF5/KTextWidgets -isystem /opt/local/include/KF5/SonnetUi -isystem /opt/local/include/KF5/KI18n -isystem /opt/local/include/KF5/KTextEditor -Ofast -g -DNDEBUG -std=c++11 -m64 -std=c++0x -fno-operator-names -fno-exceptions -DQT_NO_EXCEPTIONS -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wno-missing-field-initializers -Werror=undefined-bool-conversion -Werror=tautological-undefined-compare -Wdocumentation -Wno-gnu-zero-variadic-macro-arguments -pedantic -fPIC -std=gnu++11 -o CMakeFiles/KDevPlatformInterfaces.dir/iassistant.cpp.o -c /opt/local/var/lnxports/build/_opt_local_site-ports_kf5_kf5-kdevelop/kf5-kdevelop-devel/work/kf5-kdevelop-5/kdevplatform/interfaces/iassistant.cpp From d3ck0r at gmail.com Mon Sep 18 07:01:08 2017 From: d3ck0r at gmail.com (J Decker) Date: Mon, 18 Sep 2017 04:01:08 -0700 Subject: [CMake] Howto rerun ExternalProject Install Message-ID: I have quite a few sub-projects in this project. I had added a few projects on windows that statically linked to the runtime (to make the product more portable). I realized yesterday that it was causing the static runtime flags to be applied for all projects above it too (including the core libraries). So when I was testing a very high level project that pulled the C and C++ versions of the same library to have different runtimes linked (because they each had their own static version). Anyway to I was replacing add_subdirectory for a few projects with ExternalProject_add()'s so they would get their own runtime compile flags.... but if I do a build, and then wipe out the target install directory and then rerun the install target, the products from the externalprojects don't re-install. If I just rerun building those targets, it also doesn't re-install... So how can I trigger external projects to re-install without figuring out what sources they depend on and touching them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Mon Sep 18 10:17:14 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 18 Sep 2017 10:17:14 -0400 Subject: [CMake] FW: Visual Studio 2017 In-Reply-To: References: <1598bcddc16a4027871d29a8e2a70746@EXG13-P-MBX14.win.lanl.gov> Message-ID: You shouldn't need to import VS17 vcvarsall to use the VS17 Generator, that should only be needed if using the MSYS or Ninja generators. As far as building from the command line, the easiest route is to use cmake --build --config On Fri, Sep 15, 2017 at 3:05 PM, Thompson, KT wrote: > Randy, > > Miroslav's recommendation should work. To expand on his response, here are the commands that I use with VS2017 to allow cmake to run from the command line: > > - Start cmd session (should also work via powershell) > - To import VS17's command line environment run "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 > - Add extra project specific environment variables (possibly including appending PATH with the location of cmake). > > I created a batch file that does these steps for me (and a shortcut on my desktop that runs the batch file). > > @echo off > rem cmake-with-vs17-env.bat > @call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 %* > set PATH=%PATH%;c:\MinGW\bin;C:\Program Files\CMake\bin;C:\Program Files\doxygen\bin;c:\Python27amd64 > rem set CMAKE_PREFIX_PATH= > > With this environment, I can run cmake from the command line (cmake-gui or cmake). I can generate "Visual Studio 15 2017" or "MSYS Makefiles" projects and I can build them with or w/o the GUI. > > I hope this helps! > > -kt > > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Mateju Miroslav, Ing. > Sent: Friday, September 15, 2017 6:15 AM > To: Randy Heiland ; cmake at cmake.org > Subject: Re: [CMake] Visual Studio 2017 > > Hello Randy, > > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Randy Heiland > Sent: Friday, September 15, 2017 1:38 PM > >> Is there a "best way" to use cmake for VS17 (but same cakelists for Linux)? And by "best", I mean with minimal effort on users. >> To be more specific, on Windows, I *think* I'd like to have users install the cmake binary, then use Powershell to build an application. > Is there really a need for using PowerShell if you also want to use the same CMakeLists for Linux? > >> But my initial attempt to do so is confusing. I install VS17 (for C++), it installs in standard path, but 'cl' is not found in Powershell. I read that I shouldn't edit my PATH (nor do I really want users to have to), but run some .bat instead to setup my env. So, how should one specify the compiler for cmake? Oh yes, then I see that VS17 also has its own cmake?? > > > Have you run CMake successfully yet? I am not really aware how it works but CMake *can* for sure detect VS in my CLI environment without having VS in PATH. If you use an IDE that understands CMake (like VS17 or Qt Creator, for example), you should be able to open a CMake project in the IDE and build it there. Please report your particular problem if it does not work for you. > If you prefer to run cl.exe in CLI, then vcvarsall.bat is the .bat file you are looking for. > > Best regards, > > Ing. Miroslav Mat?j? > Programmer Analyst > > A?D Praha s.r.o. > Technology Division > Research and Development > ?irovnick? 2/3146, 106 17 Prague > Czech Republic > Phone: +420 267 287 476 > Web: www.azd.cz > -- > > 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 kgt at lanl.gov Mon Sep 18 10:49:14 2017 From: kgt at lanl.gov (Thompson, KT) Date: Mon, 18 Sep 2017 14:49:14 +0000 Subject: [CMake] FW: Visual Studio 2017 In-Reply-To: References: <1598bcddc16a4027871d29a8e2a70746@EXG13-P-MBX14.win.lanl.gov> Message-ID: Robert, That certainly doesn't work for me - but maybe I'm doing something non-standard. If I don't source the vcvarsall.bat file, SDK installations (c:\Program Files (x86)\Windows Kits\... and c:\Program Files (x86)\Microsoft SDKs\...) are not found by CMake. -kt -----Original Message----- From: Robert Maynard [mailto:robert.maynard at kitware.com] Sent: Monday, September 18, 2017 8:17 AM To: Thompson, KT Cc: cmake at cmake.org Subject: Re: [CMake] FW: Visual Studio 2017 You shouldn't need to import VS17 vcvarsall to use the VS17 Generator, that should only be needed if using the MSYS or Ninja generators. As far as building from the command line, the easiest route is to use cmake --build --config On Fri, Sep 15, 2017 at 3:05 PM, Thompson, KT wrote: > Randy, > > Miroslav's recommendation should work. To expand on his response, here are the commands that I use with VS2017 to allow cmake to run from the command line: > > - Start cmd session (should also work via powershell) > - To import VS17's command line environment run "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 > - Add extra project specific environment variables (possibly including appending PATH with the location of cmake). > > I created a batch file that does these steps for me (and a shortcut on my desktop that runs the batch file). > > @echo off > rem cmake-with-vs17-env.bat > @call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 %* > set PATH=%PATH%;c:\MinGW\bin;C:\Program Files\CMake\bin;C:\Program Files\doxygen\bin;c:\Python27amd64 > rem set CMAKE_PREFIX_PATH= > > With this environment, I can run cmake from the command line (cmake-gui or cmake). I can generate "Visual Studio 15 2017" or "MSYS Makefiles" projects and I can build them with or w/o the GUI. > > I hope this helps! > > -kt > > > -----Original Message----- > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Mateju Miroslav, Ing. > Sent: Friday, September 15, 2017 6:15 AM > To: Randy Heiland ; cmake at cmake.org > Subject: Re: [CMake] Visual Studio 2017 > > Hello Randy, > > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Randy Heiland > Sent: Friday, September 15, 2017 1:38 PM > >> Is there a "best way" to use cmake for VS17 (but same cakelists for Linux)? And by "best", I mean with minimal effort on users. >> To be more specific, on Windows, I *think* I'd like to have users install the cmake binary, then use Powershell to build an application. > Is there really a need for using PowerShell if you also want to use the same CMakeLists for Linux? > >> But my initial attempt to do so is confusing. I install VS17 (for C++), it installs in standard path, but 'cl' is not found in Powershell. I read that I shouldn't edit my PATH (nor do I really want users to have to), but run some .bat instead to setup my env. So, how should one specify the compiler for cmake? Oh yes, then I see that VS17 also has its own cmake?? > > > Have you run CMake successfully yet? I am not really aware how it works but CMake *can* for sure detect VS in my CLI environment without having VS in PATH. If you use an IDE that understands CMake (like VS17 or Qt Creator, for example), you should be able to open a CMake project in the IDE and build it there. Please report your particular problem if it does not work for you. > If you prefer to run cl.exe in CLI, then vcvarsall.bat is the .bat file you are looking for. > > Best regards, > > Ing. Miroslav Mat?j? > Programmer Analyst > > A?D Praha s.r.o. > Technology Division > Research and Development > ?irovnick? 2/3146, 106 17 Prague > Czech Republic > Phone: +420 267 287 476 > Web: www.azd.cz > -- > > 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 Mon Sep 18 13:57:36 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Mon, 18 Sep 2017 13:57:36 -0400 Subject: [CMake] FW: Visual Studio 2017 In-Reply-To: References: <1598bcddc16a4027871d29a8e2a70746@EXG13-P-MBX14.win.lanl.gov> Message-ID: >From a default cmd.exe I see cmake 3.9 correctly finding VS2017 when specifying the VS Generator. C:\test\build>C:\support\cmake-3.9.2\bin\cmake -G "Visual Studio 15 2017" ../src -- The C compiler identification is MSVC 19.11.25508.2 -- The CXX compiler identification is MSVC 19.11.25508.2 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- 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: C:/test/build On Mon, Sep 18, 2017 at 10:49 AM, Thompson, KT wrote: > Robert, > > That certainly doesn't work for me - but maybe I'm doing something non-standard. > > If I don't source the vcvarsall.bat file, SDK installations (c:\Program Files (x86)\Windows Kits\... and c:\Program Files (x86)\Microsoft SDKs\...) are not found by CMake. > > -kt > > -----Original Message----- > From: Robert Maynard [mailto:robert.maynard at kitware.com] > Sent: Monday, September 18, 2017 8:17 AM > To: Thompson, KT > Cc: cmake at cmake.org > Subject: Re: [CMake] FW: Visual Studio 2017 > > You shouldn't need to import VS17 vcvarsall to use the VS17 Generator, > that should only be needed if using the MSYS or Ninja generators. > > As far as building from the command line, the easiest route is to use > cmake --build --config > > On Fri, Sep 15, 2017 at 3:05 PM, Thompson, KT wrote: >> Randy, >> >> Miroslav's recommendation should work. To expand on his response, here are the commands that I use with VS2017 to allow cmake to run from the command line: >> >> - Start cmd session (should also work via powershell) >> - To import VS17's command line environment run "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 >> - Add extra project specific environment variables (possibly including appending PATH with the location of cmake). >> >> I created a batch file that does these steps for me (and a shortcut on my desktop that runs the batch file). >> >> @echo off >> rem cmake-with-vs17-env.bat >> @call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 %* >> set PATH=%PATH%;c:\MinGW\bin;C:\Program Files\CMake\bin;C:\Program Files\doxygen\bin;c:\Python27amd64 >> rem set CMAKE_PREFIX_PATH= >> >> With this environment, I can run cmake from the command line (cmake-gui or cmake). I can generate "Visual Studio 15 2017" or "MSYS Makefiles" projects and I can build them with or w/o the GUI. >> >> I hope this helps! >> >> -kt >> >> >> -----Original Message----- >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Mateju Miroslav, Ing. >> Sent: Friday, September 15, 2017 6:15 AM >> To: Randy Heiland ; cmake at cmake.org >> Subject: Re: [CMake] Visual Studio 2017 >> >> Hello Randy, >> >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Randy Heiland >> Sent: Friday, September 15, 2017 1:38 PM >> >>> Is there a "best way" to use cmake for VS17 (but same cakelists for Linux)? And by "best", I mean with minimal effort on users. >>> To be more specific, on Windows, I *think* I'd like to have users install the cmake binary, then use Powershell to build an application. >> Is there really a need for using PowerShell if you also want to use the same CMakeLists for Linux? >> >>> But my initial attempt to do so is confusing. I install VS17 (for C++), it installs in standard path, but 'cl' is not found in Powershell. I read that I shouldn't edit my PATH (nor do I really want users to have to), but run some .bat instead to setup my env. So, how should one specify the compiler for cmake? Oh yes, then I see that VS17 also has its own cmake?? >> >> >> Have you run CMake successfully yet? I am not really aware how it works but CMake *can* for sure detect VS in my CLI environment without having VS in PATH. If you use an IDE that understands CMake (like VS17 or Qt Creator, for example), you should be able to open a CMake project in the IDE and build it there. Please report your particular problem if it does not work for you. >> If you prefer to run cl.exe in CLI, then vcvarsall.bat is the .bat file you are looking for. >> >> Best regards, >> >> Ing. Miroslav Mat?j? >> Programmer Analyst >> >> A?D Praha s.r.o. >> Technology Division >> Research and Development >> ?irovnick? 2/3146, 106 17 Prague >> Czech Republic >> Phone: +420 267 287 476 >> Web: www.azd.cz >> -- >> >> 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 satyaprakash.prasad at gmail.com Tue Sep 19 10:24:16 2017 From: satyaprakash.prasad at gmail.com (Satya Prakash Prasad) Date: Tue, 19 Sep 2017 16:24:16 +0200 Subject: [CMake] Complete Include Build Link Details Message-ID: We have a project which we compile it thru CMAKE utility. Our projects has submodules and recently it was found that developers where introducing code dependency across sub modules. Say we have submodule A and submodule B while main module C compiles both A and B and generates all the executable. As per the issue submodule B code is being used in submodule A. Though the code is compiling fine but this is highly dangerous of the dependency across sub modules. Now how can I know via CMAKE (logs / report / traces / build etc anyway) utility which includes path / link paths are involved in which binaries. The over all objective is to break the dependency if any. Is there a way to get any kind of details via CMAKE build process - the include / linking path level used for each binary (to trace libs across submodules being used for binaries)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Tue Sep 19 11:50:33 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Tue, 19 Sep 2017 12:50:33 -0300 Subject: [CMake] VC2015 and Windows 7 compatibility Message-ID: <832afd9d-f2ad-baa2-aa30-6e48c3f03959@gmail.com> I compile on Windows 8.1.? I just found out that my program does not work on Windows 7 after I upgraded my toolchain to VC2015. Users of my program on Windows 7 get: Missing DLL ms-api-win-core-libraryloader-l1-2-0.dll After some digging, I found out that it can be because the use of SDK Sets on win8.1.? And that perhaps setting the compiler compatibility to WinXP should fix it.? However, I don't know how to do that from cmake. Any ideas? If you want to see my CMakeLists.txt, you can get the code with: $ git clone ssh://ggarra13 at git.code.sf.net/p/mrviewer/code mrviewer-code -- Gonzalo Garramu?o From randy.heiland at gmail.com Tue Sep 19 11:51:31 2017 From: randy.heiland at gmail.com (Randy Heiland) Date: Tue, 19 Sep 2017 11:51:31 -0400 Subject: [CMake] FW: Visual Studio 2017 In-Reply-To: References: Message-ID: I failed to send my previous reply to the list - see below for that. This is a follow-on, using the repo mentioned previously. --- Attempt #1 # Pointing out that my Command Prompt shell doesn't need to know about the 'cl' compiler, in order to run cmake: C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cl 'cl' is not recognized as an internal or external command, operable program or batch file. C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cmake .. -- Building for: Visual Studio 15 2017 -- The C compiler identification is MSVC 19.11.25508.2 -- The CXX compiler identification is MSVC 19.11.25508.2 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found OpenMP_C: -openmp (found version "2.0") -- Found OpenMP_CXX: -openmp (found version "2.0") -- Configuring done -- Generating done -- Build files have been written to: C:/Users/Owner/dev/cmake_learn /cmake_learn-master/build This successfully builds the following files, but no Makefile so that I can simply run 'nmake' from the command line: d----- 9/19/2017 10:26 AM BioFVM d----- 9/19/2017 10:26 AM CMakeFiles d----- 9/19/2017 10:26 AM core d----- 9/19/2017 10:26 AM custom_modules d----- 9/19/2017 10:26 AM modules -a---- 9/19/2017 10:26 AM 62588 ALL_BUILD.vcxproj -a---- 9/19/2017 10:26 AM 304 ALL_BUILD.vcxproj.filters -a---- 9/19/2017 10:26 AM 14371 CMakeCache.txt -a---- 9/19/2017 10:26 AM 1841 cmake_install.cmake -a---- 9/19/2017 10:26 AM 7860 PhysiCell.sln -a---- 9/19/2017 10:26 AM 76341 PhysiCell.vcxproj -a---- 9/19/2017 10:26 AM 611 PhysiCell.vcxproj.filters -a---- 9/19/2017 10:26 AM 274 PhysiCellConfig.h -a---- 9/19/2017 10:26 AM 46027 ZERO_CHECK.vcxproj -a---- 9/19/2017 10:26 AM 547 ZERO_CHECK.vcxproj.filters -------------------------------- --- Attempt #2 (without invoking vcvarsall.bat; rf. https://dmerej.info/blog/post/cmake-visual-studio-and-the-command-line/ ) C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cmake -G"NMake Makefiles" .. -- The C compiler identification is unknown -- The CXX compiler identification is unknown CMake Error at CMakeLists.txt:5 (project): The CMAKE_C_COMPILER: cl is not a full path and was not found in the PATH. To use the NMake generator with Visual C++, cmake must be run from a shell that can use the compiler cl from the command line. This environment is unable to invoke the cl compiler. To fix this problem, run cmake from the Visual Studio Command Prompt (vcvarsall.bat). Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. -------------------------------- --- Attempt #3 (after invoking the vcvarsall.bat, thereby making my shell aware of the 'cl' compiler) C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cmake -G"NMake Makefiles" .. ... successfully runs ... Generates the following files, including a Makefile: d----- 9/19/2017 10:46 AM BioFVM d----- 9/19/2017 10:45 AM CMakeFiles d----- 9/19/2017 10:45 AM core d----- 9/19/2017 10:46 AM custom_modules d----- 9/19/2017 10:46 AM modules -a---- 9/19/2017 10:44 AM 15307 CMakeCache.txt -a---- 9/19/2017 10:44 AM 1839 cmake_install.cmake -a---- 9/19/2017 10:44 AM 7562 Makefile -a---- 9/19/2017 10:46 AM 1503232 PhysiCell.pdb -a---- 9/19/2017 10:44 AM 274 PhysiCellConfig.h PS C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build> nmake Microsoft (R) Program Maintenance Utility Version 14.11.25508.2 ... builds most of the way OK ... ... (but currently get an error at the end, trying to build code in my 'cmake_learn' repo) -Randy On Mon, Sep 18, 2017 at 10:22 PM, Randy Heiland wrote: > Thanks everyone for your replies! I continue to learn/play, but still have > problems it seems. I've created a repo, in case anyone would be willing to > show me the error of my ways: > https://github.com/rheiland/cmake_learn > > On Win10, I too *seem* to have to run the vcvarsall.bat to have things > (sort of) work. > > I'm using cmake 3.9.2. > > -Randy > > > On Mon, Sep 18, 2017 at 1:57 PM, Robert Maynard < > robert.maynard at kitware.com> wrote: > >> From a default cmd.exe I see cmake 3.9 correctly finding VS2017 when >> specifying the VS Generator. >> >> C:\test\build>C:\support\cmake-3.9.2\bin\cmake -G "Visual Studio 15 >> 2017" ../src >> -- The C compiler identification is MSVC 19.11.25508.2 >> -- The CXX compiler identification is MSVC 19.11.25508.2 >> -- Check for working C compiler: C:/Program Files (x86)/Microsoft >> Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/ >> x86/cl.exe >> -- Check for working C compiler: C:/Program Files (x86)/Microsoft >> Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/ >> x86/cl.exe >> -- works >> -- Detecting C compiler ABI info >> -- Detecting C compiler ABI info - done >> -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >> Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/ >> x86/cl.exe >> -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >> Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/ >> x86/cl.exe >> -- 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: C:/test/build >> >> On Mon, Sep 18, 2017 at 10:49 AM, Thompson, KT wrote: >> > Robert, >> > >> > That certainly doesn't work for me - but maybe I'm doing something >> non-standard. >> > >> > If I don't source the vcvarsall.bat file, SDK installations (c:\Program >> Files (x86)\Windows Kits\... and c:\Program Files (x86)\Microsoft SDKs\...) >> are not found by CMake. >> > >> > -kt >> > >> > -----Original Message----- >> > From: Robert Maynard [mailto:robert.maynard at kitware.com] >> > Sent: Monday, September 18, 2017 8:17 AM >> > To: Thompson, KT >> > Cc: cmake at cmake.org >> > Subject: Re: [CMake] FW: Visual Studio 2017 >> > >> > You shouldn't need to import VS17 vcvarsall to use the VS17 Generator, >> > that should only be needed if using the MSYS or Ninja generators. >> > >> > As far as building from the command line, the easiest route is to use >> > cmake --build --config >> > >> > On Fri, Sep 15, 2017 at 3:05 PM, Thompson, KT wrote: >> >> Randy, >> >> >> >> Miroslav's recommendation should work. To expand on his response, here >> are the commands that I use with VS2017 to allow cmake to run from the >> command line: >> >> >> >> - Start cmd session (should also work via powershell) >> >> - To import VS17's command line environment run "C:\Program Files >> (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" >> x86 >> >> - Add extra project specific environment variables (possibly including >> appending PATH with the location of cmake). >> >> >> >> I created a batch file that does these steps for me (and a shortcut on >> my desktop that runs the batch file). >> >> >> >> @echo off >> >> rem cmake-with-vs17-env.bat >> >> @call "C:\Program Files (x86)\Microsoft Visual >> Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 %* >> >> set PATH=%PATH%;c:\MinGW\bin;C:\Program Files\CMake\bin;C:\Program >> Files\doxygen\bin;c:\Python27amd64 >> >> rem set CMAKE_PREFIX_PATH= >> >> >> >> With this environment, I can run cmake from the command line >> (cmake-gui or cmake). I can generate "Visual Studio 15 2017" or "MSYS >> Makefiles" projects and I can build them with or w/o the GUI. >> >> >> >> I hope this helps! >> >> >> >> -kt >> >> >> >> >> >> -----Original Message----- >> >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Mateju >> Miroslav, Ing. >> >> Sent: Friday, September 15, 2017 6:15 AM >> >> To: Randy Heiland ; cmake at cmake.org >> >> Subject: Re: [CMake] Visual Studio 2017 >> >> >> >> Hello Randy, >> >> >> >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Randy >> Heiland >> >> Sent: Friday, September 15, 2017 1:38 PM >> >> >> >>> Is there a "best way" to use cmake for VS17 (but same cakelists for >> Linux)? And by "best", I mean with minimal effort on users. >> >>> To be more specific, on Windows, I *think* I'd like to have users >> install the cmake binary, then use Powershell to build an application. >> >> Is there really a need for using PowerShell if you also want to use >> the same CMakeLists for Linux? >> >> >> >>> But my initial attempt to do so is confusing. I install VS17 (for >> C++), it installs in standard path, but 'cl' is not found in Powershell. I >> read that I shouldn't edit my PATH (nor do I really want users to have to), >> but run some .bat instead to setup my env. So, how should one specify the >> compiler for cmake? Oh yes, then I see that VS17 also has its own cmake?? >> >> >> >> >> >> Have you run CMake successfully yet? I am not really aware how it >> works but CMake *can* for sure detect VS in my CLI environment without >> having VS in PATH. If you use an IDE that understands CMake (like VS17 or >> Qt Creator, for example), you should be able to open a CMake project in the >> IDE and build it there. Please report your particular problem if it does >> not work for you. >> >> If you prefer to run cl.exe in CLI, then vcvarsall.bat is the .bat >> file you are looking for. >> >> >> >> Best regards, >> >> >> >> Ing. Miroslav Mat?j? >> >> Programmer Analyst >> >> >> >> A?D Praha s.r.o. >> >> Technology Division >> >> Research and Development >> >> ?irovnick? 2/3146, 106 17 Prague >> >> Czech Republic >> >> Phone: +420 267 287 476 <+420%20267%20287%20476> >> >> Web: www.azd.cz >> >> -- >> >> >> >> Powered by www.kitware.com >> >> >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> >> >> Kitware offers various services to support the CMake community. For >> more information on each offering, please visit: >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://public.kitware.com/mailman/listinfo/cmake >> >> -- >> >> >> >> Powered by www.kitware.com >> >> >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> >> >> Kitware offers various services to support the CMake community. For >> more information on each offering, please visit: >> >> >> >> CMake Support: http://cmake.org/cmake/help/support.html >> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://public.kitware.com/mailman/listinfo/cmake >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis.stansvik at orexplore.com Tue Sep 19 12:57:58 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Tue, 19 Sep 2017 18:57:58 +0200 Subject: [CMake] VC2015 and Windows 7 compatibility In-Reply-To: <832afd9d-f2ad-baa2-aa30-6e48c3f03959@gmail.com> References: <832afd9d-f2ad-baa2-aa30-6e48c3f03959@gmail.com> Message-ID: 2017-09-19 17:50 GMT+02:00 Gonzalo Garramu?o : > I compile on Windows 8.1. I just found out that my program does not work on > Windows 7 after I upgraded my toolchain to VC2015. Users of my program on > Windows 7 get: > > Missing DLL ms-api-win-core-libraryloader-l1-2-0.dll > > After some digging, I found out that it can be because the use of SDK Sets > on win8.1. And that perhaps setting the compiler compatibility to WinXP > should fix it. However, I don't know how to do that from cmake. I also build on Win 8.1/MSVC 2015, targeting Windows 7+, and what I do is basically: if(WIN32) add_definitions(/D_WIN32_WINNT=0x0601) # Target Windows 7+ set(CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION ".") set(CMAKE_INSTALL_UCRT_LIBRARIES ON) include(InstallRequiredSystemLibraries) endif() The /D_WIN32_WINNT=0x0601 is what ensures Windows 7 compatibility and CMAKE_INSTALL_UCRT_LIBRARIES is what ensures Universal CRT libraries like the one you mentioned gets installed alongside the application. You'll end up with a truckload of such small DLLs, but AFAIK this is what you need to do if you want to do app-local deployment of the Universal CRT. Hope that helps. Elvis > > Any ideas? > > If you want to see my CMakeLists.txt, you can get the code with: > > $ git clone ssh://ggarra13 at git.code.sf.net/p/mrviewer/code mrviewer-code > > > -- > Gonzalo Garramu?o > > -- > > 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 micha.hergarden at gmail.com Tue Sep 19 13:22:20 2017 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Tue, 19 Sep 2017 19:22:20 +0200 Subject: [CMake] Complete Include Build Link Details In-Reply-To: References: Message-ID: <92dc7f85-d001-d945-00b0-2d8ff7604bbe@gmail.com> On 19-09-17 16:24, Satya Prakash Prasad wrote: > > We have a project which we compile it thru CMAKE utility. Our projects > has submodules and recently it was found that developers where > introducing code dependency across sub modules. > > Say we have submodule A and submodule B while main module C compiles > both A and B and generates all the executable. As per the issue > submodule B code is being used in submodule A. Though the code is > compiling fine but this is highly dangerous of the dependency across > sub modules. > > Now how can I know via CMAKE (logs / report / traces / build etc > anyway) utility which includes path / link paths are involved in which > binaries. The over all objective is to break the dependency if any. > > Is there a way to get any kind of details via CMAKE build process - > the include / linking path level used for each binary (to trace libs > across submodules being used for binaries)? > > > Hello Satya, Unfortunately you didn't say what language & buildsystem you are using? In my answer I am assuming c or c++: as far as I'm aware this list cannot (easily) be obtained from CMake. However, I suggest a tool such as 'include-what-you-use' from the Clang toolchain. One of the issues with using CMake in this case is that it is possible to get a working build without adding a dependency for all the necessary files to the cmake files (e.g. by just assuming the needed files are in a certain location and including them directly in the source files). Hth, Micha -------------- 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 d3ck0r at gmail.com Tue Sep 19 14:19:01 2017 From: d3ck0r at gmail.com (J Decker) Date: Tue, 19 Sep 2017 11:19:01 -0700 Subject: [CMake] VC2015 and Windows 7 compatibility In-Reply-To: References: <832afd9d-f2ad-baa2-aa30-6e48c3f03959@gmail.com> Message-ID: you can just install the runtime redistributuable for 2015... https://www.microsoft.com/en-us/download/details.aspx?id=48234 On Tue, Sep 19, 2017 at 9:57 AM, Elvis Stansvik < elvis.stansvik at orexplore.com> wrote: > 2017-09-19 17:50 GMT+02:00 Gonzalo Garramu?o : > > I compile on Windows 8.1. I just found out that my program does not > work on > > Windows 7 after I upgraded my toolchain to VC2015. Users of my program on > > Windows 7 get: > > > > Missing DLL ms-api-win-core-libraryloader-l1-2-0.dll > > > > After some digging, I found out that it can be because the use of SDK > Sets > > on win8.1. And that perhaps setting the compiler compatibility to WinXP > > should fix it. However, I don't know how to do that from cmake. > > I also build on Win 8.1/MSVC 2015, targeting Windows 7+, and what I do > is basically: > > if(WIN32) > add_definitions(/D_WIN32_WINNT=0x0601) # Target Windows 7+ > > set(CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION ".") > set(CMAKE_INSTALL_UCRT_LIBRARIES ON) > include(InstallRequiredSystemLibraries) > endif() > > The /D_WIN32_WINNT=0x0601 is what ensures Windows 7 compatibility and > CMAKE_INSTALL_UCRT_LIBRARIES is what ensures Universal CRT libraries > like the one you mentioned gets installed alongside the application. > > You'll end up with a truckload of such small DLLs, but AFAIK this is > what you need to do if you want to do app-local deployment of the > Universal CRT. > > Hope that helps. > > Elvis > > > > > Any ideas? > > > > If you want to see my CMakeLists.txt, you can get the code with: > > > > $ git clone ssh://ggarra13 at git.code.sf.net/p/mrviewer/code mrviewer-code > > > > > > -- > > Gonzalo Garramu?o > > > > -- > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Tue Sep 19 14:47:45 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Tue, 19 Sep 2017 20:47:45 +0200 Subject: [CMake] FW: Visual Studio 2017 In-Reply-To: References: Message-ID: Am 19. September 2017 17:51:31 MESZ schrieb Randy Heiland : >I failed to send my previous reply to the list - see below for that. >This >is a follow-on, using the repo mentioned previously. > >--- Attempt #1 > ># Pointing out that my Command Prompt shell doesn't need to know >about >the 'cl' compiler, in order to run cmake: >C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cl >'cl' is not recognized as an internal or external command, >operable program or batch file. > > >C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cmake .. >-- Building for: Visual Studio 15 2017 >-- The C compiler identification is MSVC 19.11.25508.2 >-- The CXX compiler identification is MSVC 19.11.25508.2 >-- Check for working C compiler: C:/Program Files (x86)/Microsoft >Visual >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >-- Check for working C compiler: C:/Program Files (x86)/Microsoft >Visual >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >-- >works >-- Detecting C compiler ABI info >-- Detecting C compiler ABI info - done >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >Visual >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >Visual >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >-- >works >-- Detecting CXX compiler ABI info >-- Detecting CXX compiler ABI info - done >-- Detecting CXX compile features >-- Detecting CXX compile features - done >-- Found OpenMP_C: -openmp (found version "2.0") >-- Found OpenMP_CXX: -openmp (found version "2.0") >-- Configuring done >-- Generating done >-- Build files have been written to: C:/Users/Owner/dev/cmake_learn >/cmake_learn-master/build > >This successfully builds the following files, but no Makefile so that I >can >simply run 'nmake' from the command line: Maybe you should realize that any purposed use of nmake is outdated by years. You can build .sln files from command line just fine. CMake even wraps the command with --build option. Only use nmake when you have no other options. HS -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From randy.heiland at gmail.com Tue Sep 19 16:05:36 2017 From: randy.heiland at gmail.com (Randy Heiland) Date: Tue, 19 Sep 2017 16:05:36 -0400 Subject: [CMake] FW: Visual Studio 2017 In-Reply-To: References: Message-ID: I'd love to learn more about this option, assuming it's a simple workflow via the command line. If there's a writeup related to cmake, would welcome a pointer. If you can't tell, I'm not really a Windows guy; I'm just trying to support that community. Hopefully what you're describing would not require a user having to fiddle with their PATH env var. On Tue, Sep 19, 2017 at 2:47 PM, Hendrik Sattler wrote: > > > Am 19. September 2017 17:51:31 MESZ schrieb Randy Heiland < > randy.heiland at gmail.com>: > >I failed to send my previous reply to the list - see below for that. > >This > >is a follow-on, using the repo mentioned previously. > > > >--- Attempt #1 > > > ># Pointing out that my Command Prompt shell doesn't need to know > >about > >the 'cl' compiler, in order to run cmake: > >C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cl > >'cl' is not recognized as an internal or external command, > >operable program or batch file. > > > > > >C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cmake .. > >-- Building for: Visual Studio 15 2017 > >-- The C compiler identification is MSVC 19.11.25508.2 > >-- The CXX compiler identification is MSVC 19.11.25508.2 > >-- Check for working C compiler: C:/Program Files (x86)/Microsoft > >Visual > >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > >-- Check for working C compiler: C:/Program Files (x86)/Microsoft > >Visual > >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > >-- > >works > >-- Detecting C compiler ABI info > >-- Detecting C compiler ABI info - done > >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft > >Visual > >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft > >Visual > >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > >-- > >works > >-- Detecting CXX compiler ABI info > >-- Detecting CXX compiler ABI info - done > >-- Detecting CXX compile features > >-- Detecting CXX compile features - done > >-- Found OpenMP_C: -openmp (found version "2.0") > >-- Found OpenMP_CXX: -openmp (found version "2.0") > >-- Configuring done > >-- Generating done > >-- Build files have been written to: C:/Users/Owner/dev/cmake_learn > >/cmake_learn-master/build > > > >This successfully builds the following files, but no Makefile so that I > >can > >simply run 'nmake' from the command line: > > Maybe you should realize that any purposed use of nmake is outdated by > years. You can build .sln files from command line just fine. CMake even > wraps the command with --build option. > > Only use nmake when you have no other options. > > HS > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From post at hendrik-sattler.de Tue Sep 19 16:26:56 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Tue, 19 Sep 2017 22:26:56 +0200 Subject: [CMake] FW: Visual Studio 2017 In-Reply-To: References: Message-ID: <4007C350-E667-4E84-84AE-5385D1737C96@hendrik-sattler.de> Am 19. September 2017 22:05:36 MESZ schrieb Randy Heiland : >I'd love to learn more about this option, assuming it's a simple >workflow >via the command line. If there's a writeup related to cmake, would >welcome >a pointer. If you can't tell, I'm not really a Windows guy; I'm just >trying >to support that community. Hopefully what you're describing would not >require a user having to fiddle with their PATH env var. Just type "cmake --build" to see all options. "cmake --build . --config release" will build the release configuration of a generated .sln file. >On Tue, Sep 19, 2017 at 2:47 PM, Hendrik Sattler > >wrote: > >> >> >> Am 19. September 2017 17:51:31 MESZ schrieb Randy Heiland < >> randy.heiland at gmail.com>: >> >I failed to send my previous reply to the list - see below for that. >> >This >> >is a follow-on, using the repo mentioned previously. >> > >> >--- Attempt #1 >> > >> ># Pointing out that my Command Prompt shell doesn't need to know >> >about >> >the 'cl' compiler, in order to run cmake: >> >C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cl >> >'cl' is not recognized as an internal or external command, >> >operable program or batch file. >> > >> > >> >C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cmake .. >> >-- Building for: Visual Studio 15 2017 >> >-- The C compiler identification is MSVC 19.11.25508.2 >> >-- The CXX compiler identification is MSVC 19.11.25508.2 >> >-- Check for working C compiler: C:/Program Files (x86)/Microsoft >> >Visual >> >>Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >> >-- Check for working C compiler: C:/Program Files (x86)/Microsoft >> >Visual >> >>Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >> >-- >> >works >> >-- Detecting C compiler ABI info >> >-- Detecting C compiler ABI info - done >> >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >> >Visual >> >>Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >> >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >> >Visual >> >>Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >> >-- >> >works >> >-- Detecting CXX compiler ABI info >> >-- Detecting CXX compiler ABI info - done >> >-- Detecting CXX compile features >> >-- Detecting CXX compile features - done >> >-- Found OpenMP_C: -openmp (found version "2.0") >> >-- Found OpenMP_CXX: -openmp (found version "2.0") >> >-- Configuring done >> >-- Generating done >> >-- Build files have been written to: C:/Users/Owner/dev/cmake_learn >> >/cmake_learn-master/build >> > >> >This successfully builds the following files, but no Makefile so >that I >> >can >> >simply run 'nmake' from the command line: >> >> Maybe you should realize that any purposed use of nmake is outdated >by >> years. You can build .sln files from command line just fine. CMake >even >> wraps the command with --build option. >> >> Only use nmake when you have no other options. >> >> HS >> >> -- >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail >> gesendet. >> -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From robert.maynard at kitware.com Tue Sep 19 16:35:31 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 19 Sep 2017 16:35:31 -0400 Subject: [CMake] project() with ASM fails with MSVC 19 In-Reply-To: References: Message-ID: Have you tried setting the project call of project(libpng VERSION 1.6.33 LANGUAGES ASM_MASM C) On Tue, Sep 12, 2017 at 2:34 PM, Robert Dailey wrote: > Also, I am using the "Visual Studio 15 2017" generator with no other > options (generating through cmake-gui on Windows) > > On Tue, Sep 12, 2017 at 1:33 PM, Robert Dailey wrote: >> Using CMake 3.9, I do this: >> >> cmake_minimum_required(VERSION 3.9) >> project(libpng VERSION 1.6.33 LANGUAGES ASM C) >> >> I get the following error: >> >> -- The ASM compiler identification is unknown >> -- Didn't find assembler >> -- The C compiler identification is MSVC 19.11.25507.1 >> CMake Error at CMakeLists.txt:16 (project): >> No CMAKE_ASM_COMPILER could be found. >> >> >> Why doesn't this work? > -- > > 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 randy.heiland at gmail.com Tue Sep 19 16:44:03 2017 From: randy.heiland at gmail.com (Randy Heiland) Date: Tue, 19 Sep 2017 16:44:03 -0400 Subject: [CMake] FW: Visual Studio 2017 In-Reply-To: <4007C350-E667-4E84-84AE-5385D1737C96@hendrik-sattler.de> References: <4007C350-E667-4E84-84AE-5385D1737C96@hendrik-sattler.de> Message-ID: What I'm finding online so far seems to indicate that one would need to open the Visual Studio app in order to do something with the .sln. Is that true? If so, it's not really desirable... well, maybe it is for some users, but, in general, I'd like to provide a command line solution. Is that possible? related links: http://preshing.com/20170511/how-to-build-a-cmake-based-project/#building-with-visual-studio https://docs.microsoft.com/en-us/visualstudio/extensibility/internals/solution-dot-sln-file On Tue, Sep 19, 2017 at 4:26 PM, Hendrik Sattler wrote: > > > Am 19. September 2017 22:05:36 MESZ schrieb Randy Heiland < > randy.heiland at gmail.com>: > >I'd love to learn more about this option, assuming it's a simple > >workflow > >via the command line. If there's a writeup related to cmake, would > >welcome > >a pointer. If you can't tell, I'm not really a Windows guy; I'm just > >trying > >to support that community. Hopefully what you're describing would not > >require a user having to fiddle with their PATH env var. > > Just type "cmake --build" to see all options. > > "cmake --build . --config release" will build the release configuration of > a generated .sln file. > > >On Tue, Sep 19, 2017 at 2:47 PM, Hendrik Sattler > > > >wrote: > > > >> > >> > >> Am 19. September 2017 17:51:31 MESZ schrieb Randy Heiland < > >> randy.heiland at gmail.com>: > >> >I failed to send my previous reply to the list - see below for that. > >> >This > >> >is a follow-on, using the repo mentioned previously. > >> > > >> >--- Attempt #1 > >> > > >> ># Pointing out that my Command Prompt shell doesn't need to know > >> >about > >> >the 'cl' compiler, in order to run cmake: > >> >C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cl > >> >'cl' is not recognized as an internal or external command, > >> >operable program or batch file. > >> > > >> > > >> >C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cmake .. > >> >-- Building for: Visual Studio 15 2017 > >> >-- The C compiler identification is MSVC 19.11.25508.2 > >> >-- The CXX compiler identification is MSVC 19.11.25508.2 > >> >-- Check for working C compiler: C:/Program Files (x86)/Microsoft > >> >Visual > >> > >>Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > >> >-- Check for working C compiler: C:/Program Files (x86)/Microsoft > >> >Visual > >> > >>Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > >> >-- > >> >works > >> >-- Detecting C compiler ABI info > >> >-- Detecting C compiler ABI info - done > >> >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft > >> >Visual > >> > >>Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > >> >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft > >> >Visual > >> > >>Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe > >> >-- > >> >works > >> >-- Detecting CXX compiler ABI info > >> >-- Detecting CXX compiler ABI info - done > >> >-- Detecting CXX compile features > >> >-- Detecting CXX compile features - done > >> >-- Found OpenMP_C: -openmp (found version "2.0") > >> >-- Found OpenMP_CXX: -openmp (found version "2.0") > >> >-- Configuring done > >> >-- Generating done > >> >-- Build files have been written to: C:/Users/Owner/dev/cmake_learn > >> >/cmake_learn-master/build > >> > > >> >This successfully builds the following files, but no Makefile so > >that I > >> >can > >> >simply run 'nmake' from the command line: > >> > >> Maybe you should realize that any purposed use of nmake is outdated > >by > >> years. You can build .sln files from command line just fine. CMake > >even > >> wraps the command with --build option. > >> > >> Only use nmake when you have no other options. > >> > >> HS > >> > >> -- > >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > >> gesendet. > >> > > -- > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail > gesendet. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Tue Sep 19 16:57:54 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 19 Sep 2017 16:57:54 -0400 Subject: [CMake] FW: Visual Studio 2017 In-Reply-To: References: <4007C350-E667-4E84-84AE-5385D1737C96@hendrik-sattler.de> Message-ID: While the preshing article on CMake is really good, it didn't clearly cover the fact that Visual Studio projects generated by CMake can be built from the command line using cmake --build --config < Release/Debug/... > On Tue, Sep 19, 2017 at 4:44 PM, Randy Heiland wrote: > What I'm finding online so far seems to indicate that one would need to open > the Visual Studio app in order to do something with the .sln. Is that true? > If so, it's not really desirable... well, maybe it is for some users, but, > in general, I'd like to provide a command line solution. Is that possible? > > related links: > http://preshing.com/20170511/how-to-build-a-cmake-based-project/#building-with-visual-studio > https://docs.microsoft.com/en-us/visualstudio/extensibility/internals/solution-dot-sln-file > > > > On Tue, Sep 19, 2017 at 4:26 PM, Hendrik Sattler > wrote: >> >> >> >> Am 19. September 2017 22:05:36 MESZ schrieb Randy Heiland >> : >> >I'd love to learn more about this option, assuming it's a simple >> >workflow >> >via the command line. If there's a writeup related to cmake, would >> >welcome >> >a pointer. If you can't tell, I'm not really a Windows guy; I'm just >> >trying >> >to support that community. Hopefully what you're describing would not >> >require a user having to fiddle with their PATH env var. >> >> Just type "cmake --build" to see all options. >> >> "cmake --build . --config release" will build the release configuration of >> a generated .sln file. >> >> >On Tue, Sep 19, 2017 at 2:47 PM, Hendrik Sattler >> > >> >wrote: >> > >> >> >> >> >> >> Am 19. September 2017 17:51:31 MESZ schrieb Randy Heiland < >> >> randy.heiland at gmail.com>: >> >> >I failed to send my previous reply to the list - see below for that. >> >> >This >> >> >is a follow-on, using the repo mentioned previously. >> >> > >> >> >--- Attempt #1 >> >> > >> >> ># Pointing out that my Command Prompt shell doesn't need to know >> >> >about >> >> >the 'cl' compiler, in order to run cmake: >> >> >C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cl >> >> >'cl' is not recognized as an internal or external command, >> >> >operable program or batch file. >> >> > >> >> > >> >> >C:\Users\Owner\dev\cmake_learn\cmake_learn-master\build>cmake .. >> >> >-- Building for: Visual Studio 15 2017 >> >> >-- The C compiler identification is MSVC 19.11.25508.2 >> >> >-- The CXX compiler identification is MSVC 19.11.25508.2 >> >> >-- Check for working C compiler: C:/Program Files (x86)/Microsoft >> >> >Visual >> >> >> >>Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >> >> >-- Check for working C compiler: C:/Program Files (x86)/Microsoft >> >> >Visual >> >> >> >>Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >> >> >-- >> >> >works >> >> >-- Detecting C compiler ABI info >> >> >-- Detecting C compiler ABI info - done >> >> >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >> >> >Visual >> >> >> >>Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >> >> >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >> >> >Visual >> >> >> >>Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >> >> >-- >> >> >works >> >> >-- Detecting CXX compiler ABI info >> >> >-- Detecting CXX compiler ABI info - done >> >> >-- Detecting CXX compile features >> >> >-- Detecting CXX compile features - done >> >> >-- Found OpenMP_C: -openmp (found version "2.0") >> >> >-- Found OpenMP_CXX: -openmp (found version "2.0") >> >> >-- Configuring done >> >> >-- Generating done >> >> >-- Build files have been written to: C:/Users/Owner/dev/cmake_learn >> >> >/cmake_learn-master/build >> >> > >> >> >This successfully builds the following files, but no Makefile so >> >that I >> >> >can >> >> >simply run 'nmake' from the command line: >> >> >> >> Maybe you should realize that any purposed use of nmake is outdated >> >by >> >> years. You can build .sln files from command line just fine. CMake >> >even >> >> wraps the command with --build option. >> >> >> >> Only use nmake when you have no other options. >> >> >> >> HS >> >> >> >> -- >> >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail >> >> gesendet. >> >> >> >> -- >> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail >> gesendet. > > > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From ggarra13 at gmail.com Tue Sep 19 17:22:33 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Tue, 19 Sep 2017 18:22:33 -0300 Subject: [CMake] VC2015 and Windows 7 compatibility In-Reply-To: References: <832afd9d-f2ad-baa2-aa30-6e48c3f03959@gmail.com> Message-ID: El 19/09/2017 a las 15:19, J Decker escribi?: > you can just install the runtime redistributuable for 2015... > > https://www.microsoft.com/en-us/download/details.aspx?id=48234 Unfortunately, that does not have the required ms-api-win-core* DLLs. It is something that changed with v8.0 of windows. Elvis solution seems like it should work. I am awaiting an answer from my beta testers. -- Gonzalo Garramu?o From robert.maynard at kitware.com Tue Sep 19 17:28:23 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Tue, 19 Sep 2017 17:28:23 -0400 Subject: [CMake] VC2015 and Windows 7 compatibility In-Reply-To: References: <832afd9d-f2ad-baa2-aa30-6e48c3f03959@gmail.com> Message-ID: I believe if you want to compile with XP support you can also specify that as part of the Toolset string. So from a clean build directory: make -G "Visual Studio 14 2015" -T v140_xp On Tue, Sep 19, 2017 at 5:22 PM, Gonzalo Garramu?o wrote: > > > El 19/09/2017 a las 15:19, J Decker escribi?: >> >> you can just install the runtime redistributuable for 2015... >> >> https://www.microsoft.com/en-us/download/details.aspx?id=48234 > > Unfortunately, that does not have the required ms-api-win-core* DLLs. It is > something that changed with v8.0 of windows. Elvis solution seems like it > should work. I am awaiting an answer from my beta testers. > > > -- > Gonzalo Garramu?o > > -- > > 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 Sep 19 19:00:58 2017 From: kgt at lanl.gov (Thompson, KT) Date: Tue, 19 Sep 2017 23:00:58 +0000 Subject: [CMake] FW: Visual Studio 2017 In-Reply-To: References: <1598bcddc16a4027871d29a8e2a70746@EXG13-P-MBX14.win.lanl.gov> Message-ID: <490b41b74d4b48169a32ef5468996ed2@EXG13-P-MBX09.win.lanl.gov> Hi Robert, I thought I would expand my example a little - maybe I'm doing something really stupid that I should correct. Can you comment on why wsock32.lib isn't found when I run cmake from a 'clean' cmd prompt, but *is* found after sourcing vcvars.bat? ---------------------------------------- Here's my CMakeList.txt cmake_minimum_required( VERSION 3.9 ) project( cmc CXX ) message( "C++: ${CMAKE_CXX_COMPILER}" ) find_library( Lib_win_winsock NAMES wsock32;winsock32;ws2_32 ) if( EXISTS "${Lib_win_winsock}" ) message("Winsock found at ${Lib_win_winsock}") else() message( FATAL_ERROR "winsock not found.") endif() ---------------------------------------- From a command prompt: E:\toycode\b>cmake -G "Visual Studio 15 2017" .. -- The CXX compiler identification is MSVC 19.11.25508.2 -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done C++: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe CMake Error at CMakeLists.txt:9 (message): winsock not found. ---------------------------------------- After sourcing vcvars.bat E:\toycode\b>cmake -G "Visual Studio 15 2017" .. -- The CXX compiler identification is MSVC 19.11.25508.2 -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.255 03/bin/HostX86/x86/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.255 03/bin/HostX86/x86/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done C++: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe Winsock found at C:/Program Files (x86)/Windows Kits/10/Lib/10.0.15063.0/um/x86/WSock32.Lib -- Configuring done -- Generating done ---------------------------------------- Thanks for your feedback! -kt -----Original Message----- From: Robert Maynard [mailto:robert.maynard at kitware.com] Sent: Monday, September 18, 2017 11:58 AM To: Thompson, KT Cc: cmake at cmake.org Subject: Re: [CMake] FW: Visual Studio 2017 From a default cmd.exe I see cmake 3.9 correctly finding VS2017 when specifying the VS Generator. C:\test\build>C:\support\cmake-3.9.2\bin\cmake -G "Visual Studio 15 2017" ../src -- The C compiler identification is MSVC 19.11.25508.2 -- The CXX compiler identification is MSVC 19.11.25508.2 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- 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: C:/test/build On Mon, Sep 18, 2017 at 10:49 AM, Thompson, KT wrote: > Robert, > > That certainly doesn't work for me - but maybe I'm doing something non-standard. > > If I don't source the vcvarsall.bat file, SDK installations (c:\Program Files (x86)\Windows Kits\... and c:\Program Files (x86)\Microsoft SDKs\...) are not found by CMake. > > -kt > > -----Original Message----- > From: Robert Maynard [mailto:robert.maynard at kitware.com] > Sent: Monday, September 18, 2017 8:17 AM > To: Thompson, KT > Cc: cmake at cmake.org > Subject: Re: [CMake] FW: Visual Studio 2017 > > You shouldn't need to import VS17 vcvarsall to use the VS17 Generator, > that should only be needed if using the MSYS or Ninja generators. > > As far as building from the command line, the easiest route is to use > cmake --build --config > > On Fri, Sep 15, 2017 at 3:05 PM, Thompson, KT wrote: >> Randy, >> >> Miroslav's recommendation should work. To expand on his response, here are the commands that I use with VS2017 to allow cmake to run from the command line: >> >> - Start cmd session (should also work via powershell) >> - To import VS17's command line environment run "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 >> - Add extra project specific environment variables (possibly including appending PATH with the location of cmake). >> >> I created a batch file that does these steps for me (and a shortcut on my desktop that runs the batch file). >> >> @echo off >> rem cmake-with-vs17-env.bat >> @call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 %* >> set PATH=%PATH%;c:\MinGW\bin;C:\Program Files\CMake\bin;C:\Program Files\doxygen\bin;c:\Python27amd64 >> rem set CMAKE_PREFIX_PATH= >> >> With this environment, I can run cmake from the command line (cmake-gui or cmake). I can generate "Visual Studio 15 2017" or "MSYS Makefiles" projects and I can build them with or w/o the GUI. >> >> I hope this helps! >> >> -kt >> >> >> -----Original Message----- >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Mateju Miroslav, Ing. >> Sent: Friday, September 15, 2017 6:15 AM >> To: Randy Heiland ; cmake at cmake.org >> Subject: Re: [CMake] Visual Studio 2017 >> >> Hello Randy, >> >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Randy Heiland >> Sent: Friday, September 15, 2017 1:38 PM >> >>> Is there a "best way" to use cmake for VS17 (but same cakelists for Linux)? And by "best", I mean with minimal effort on users. >>> To be more specific, on Windows, I *think* I'd like to have users install the cmake binary, then use Powershell to build an application. >> Is there really a need for using PowerShell if you also want to use the same CMakeLists for Linux? >> >>> But my initial attempt to do so is confusing. I install VS17 (for C++), it installs in standard path, but 'cl' is not found in Powershell. I read that I shouldn't edit my PATH (nor do I really want users to have to), but run some .bat instead to setup my env. So, how should one specify the compiler for cmake? Oh yes, then I see that VS17 also has its own cmake?? >> >> >> Have you run CMake successfully yet? I am not really aware how it works but CMake *can* for sure detect VS in my CLI environment without having VS in PATH. If you use an IDE that understands CMake (like VS17 or Qt Creator, for example), you should be able to open a CMake project in the IDE and build it there. Please report your particular problem if it does not work for you. >> If you prefer to run cl.exe in CLI, then vcvarsall.bat is the .bat file you are looking for. >> >> Best regards, >> >> Ing. Miroslav Mat?j? >> Programmer Analyst >> >> A?D Praha s.r.o. >> Technology Division >> Research and Development >> ?irovnick? 2/3146, 106 17 Prague >> Czech Republic >> Phone: +420 267 287 476 >> Web: www.azd.cz >> -- >> >> 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 post at hendrik-sattler.de Tue Sep 19 20:12:36 2017 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Wed, 20 Sep 2017 02:12:36 +0200 Subject: [CMake] FW: Visual Studio 2017 In-Reply-To: <490b41b74d4b48169a32ef5468996ed2@EXG13-P-MBX09.win.lanl.gov> References: <1598bcddc16a4027871d29a8e2a70746@EXG13-P-MBX14.win.lanl.gov> <490b41b74d4b48169a32ef5468996ed2@EXG13-P-MBX09.win.lanl.gov> Message-ID: Am 20. September 2017 01:00:58 MESZ schrieb "Thompson, KT" : >Hi Robert, > >I thought I would expand my example a little - maybe I'm doing >something really stupid that I should correct. Can you comment on why >wsock32.lib isn't found when I run cmake from a 'clean' cmd prompt, but >*is* found after sourcing vcvars.bat? For libraries shipped with the compiler, you should just use -lws2_32 instead of find_library(). For Microsoft compilers, this is always ws2_32 for this library. >---------------------------------------- >Here's my CMakeList.txt > >cmake_minimum_required( VERSION 3.9 ) >project( cmc CXX ) >message( "C++: ${CMAKE_CXX_COMPILER}" ) >find_library( Lib_win_winsock NAMES wsock32;winsock32;ws2_32 ) >if( EXISTS "${Lib_win_winsock}" ) > message("Winsock found at ${Lib_win_winsock}") >else() > message( FATAL_ERROR "winsock not found.") >endif() > >---------------------------------------- >From a command prompt: > >E:\toycode\b>cmake -G "Visual Studio 15 2017" .. >-- The CXX compiler identification is MSVC 19.11.25508.2 >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >Visual >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >Visual >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >-- works >-- Detecting CXX compiler ABI info >-- Detecting CXX compiler ABI info - done >-- Detecting CXX compile features >-- Detecting CXX compile features - done >C++: C:/Program Files (x86)/Microsoft Visual >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >CMake Error at CMakeLists.txt:9 (message): > winsock not found. > >---------------------------------------- >After sourcing vcvars.bat > >E:\toycode\b>cmake -G "Visual Studio 15 2017" .. >-- The CXX compiler identification is MSVC 19.11.25508.2 >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >Visual Studio/2017/Community/VC/Tools/MSVC/14.11.255 >03/bin/HostX86/x86/cl.exe >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >Visual Studio/2017/Community/VC/Tools/MSVC/14.11.255 >03/bin/HostX86/x86/cl.exe -- works >-- Detecting CXX compiler ABI info >-- Detecting CXX compiler ABI info - done >-- Detecting CXX compile features >-- Detecting CXX compile features - done >C++: C:/Program Files (x86)/Microsoft Visual >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >Winsock found at C:/Program Files (x86)/Windows >Kits/10/Lib/10.0.15063.0/um/x86/WSock32.Lib >-- Configuring done >-- Generating done > >---------------------------------------- > >Thanks for your feedback! > >-kt > >-----Original Message----- >From: Robert Maynard [mailto:robert.maynard at kitware.com] >Sent: Monday, September 18, 2017 11:58 AM >To: Thompson, KT >Cc: cmake at cmake.org >Subject: Re: [CMake] FW: Visual Studio 2017 > >From a default cmd.exe I see cmake 3.9 correctly finding VS2017 when >specifying the VS Generator. > >C:\test\build>C:\support\cmake-3.9.2\bin\cmake -G "Visual Studio 15 >2017" ../src >-- The C compiler identification is MSVC 19.11.25508.2 >-- The CXX compiler identification is MSVC 19.11.25508.2 >-- Check for working C compiler: C:/Program Files (x86)/Microsoft >Visual >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >-- Check for working C compiler: C:/Program Files (x86)/Microsoft >Visual >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >-- works >-- Detecting C compiler ABI info >-- Detecting C compiler ABI info - done >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >Visual >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft >Visual >Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe >-- 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: C:/test/build > >On Mon, Sep 18, 2017 at 10:49 AM, Thompson, KT wrote: >> Robert, >> >> That certainly doesn't work for me - but maybe I'm doing something >non-standard. >> >> If I don't source the vcvarsall.bat file, SDK installations >(c:\Program Files (x86)\Windows Kits\... and c:\Program Files >(x86)\Microsoft SDKs\...) are not found by CMake. >> >> -kt >> >> -----Original Message----- >> From: Robert Maynard [mailto:robert.maynard at kitware.com] >> Sent: Monday, September 18, 2017 8:17 AM >> To: Thompson, KT >> Cc: cmake at cmake.org >> Subject: Re: [CMake] FW: Visual Studio 2017 >> >> You shouldn't need to import VS17 vcvarsall to use the VS17 >Generator, >> that should only be needed if using the MSYS or Ninja generators. >> >> As far as building from the command line, the easiest route is to use >> cmake --build --config >> >> On Fri, Sep 15, 2017 at 3:05 PM, Thompson, KT wrote: >>> Randy, >>> >>> Miroslav's recommendation should work. To expand on his response, >here are the commands that I use with VS2017 to allow cmake to run from >the command line: >>> >>> - Start cmd session (should also work via powershell) >>> - To import VS17's command line environment run "C:\Program Files >(x86)\Microsoft Visual >Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 >>> - Add extra project specific environment variables (possibly >including appending PATH with the location of cmake). >>> >>> I created a batch file that does these steps for me (and a shortcut >on my desktop that runs the batch file). >>> >>> @echo off >>> rem cmake-with-vs17-env.bat >>> @call "C:\Program Files (x86)\Microsoft Visual >Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 %* >>> set PATH=%PATH%;c:\MinGW\bin;C:\Program Files\CMake\bin;C:\Program >Files\doxygen\bin;c:\Python27amd64 >>> rem set CMAKE_PREFIX_PATH= >>> >>> With this environment, I can run cmake from the command line >(cmake-gui or cmake). I can generate "Visual Studio 15 2017" or "MSYS >Makefiles" projects and I can build them with or w/o the GUI. >>> >>> I hope this helps! >>> >>> -kt >>> >>> >>> -----Original Message----- >>> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Mateju >Miroslav, Ing. >>> Sent: Friday, September 15, 2017 6:15 AM >>> To: Randy Heiland ; cmake at cmake.org >>> Subject: Re: [CMake] Visual Studio 2017 >>> >>> Hello Randy, >>> >>> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Randy >Heiland >>> Sent: Friday, September 15, 2017 1:38 PM >>> >>>> Is there a "best way" to use cmake for VS17 (but same cakelists for >Linux)? And by "best", I mean with minimal effort on users. >>>> To be more specific, on Windows, I *think* I'd like to have users >install the cmake binary, then use Powershell to build an application. >>> Is there really a need for using PowerShell if you also want to use >the same CMakeLists for Linux? >>> >>>> But my initial attempt to do so is confusing. I install VS17 (for >C++), it installs in standard path, but 'cl' is not found in >Powershell. I read that I shouldn't edit my PATH (nor do I really want >users to have to), but run some .bat instead to setup my env. So, how >should one specify the compiler for cmake? Oh yes, then I see that VS17 >also has its own cmake?? >>> >>> >>> Have you run CMake successfully yet? I am not really aware how it >works but CMake *can* for sure detect VS in my CLI environment without >having VS in PATH. If you use an IDE that understands CMake (like VS17 >or Qt Creator, for example), you should be able to open a CMake project >in the IDE and build it there. Please report your particular problem if >it does not work for you. >>> If you prefer to run cl.exe in CLI, then vcvarsall.bat is the .bat >file you are looking for. >>> >>> Best regards, >>> >>> Ing. Miroslav Mat?j? >>> Programmer Analyst >>> >>> A?D Praha s.r.o. >>> Technology Division >>> Research and Development >>> ?irovnick? 2/3146, 106 17 Prague >>> Czech Republic >>> Phone: +420 267 287 476 >>> Web: www.azd.cz >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For >more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >>> -- >>> >>> Powered by www.kitware.com >>> >>> Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ >>> >>> Kitware offers various services to support the CMake community. For >more information on each offering, please visit: >>> >>> CMake Support: http://cmake.org/cmake/help/support.html >>> CMake Consulting: http://cmake.org/cmake/help/consulting.html >>> CMake Training Courses: http://cmake.org/cmake/help/training.html >>> >>> Visit other Kitware open-source projects at >http://www.kitware.com/opensource/opensource.html >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/cmake >-- > >Powered by www.kitware.com > >Please keep messages on-topic and check the CMake FAQ at: >http://www.cmake.org/Wiki/CMake_FAQ > >Kitware offers various services to support the CMake community. For >more information on each offering, please visit: > >CMake Support: http://cmake.org/cmake/help/support.html >CMake Consulting: http://cmake.org/cmake/help/consulting.html >CMake Training Courses: http://cmake.org/cmake/help/training.html > >Visit other Kitware open-source projects at >http://www.kitware.com/opensource/opensource.html > >Follow this link to subscribe/unsubscribe: >http://public.kitware.com/mailman/listinfo/cmake -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. From andrew.amaclean at gmail.com Tue Sep 19 21:32:35 2017 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 20 Sep 2017 11:32:35 +1000 Subject: [CMake] =?utf-8?q?=E2=80=8BVisual_Studio_2017?= Message-ID: I actually use a .cmd file to specify everything I need. So the whole environment is set. See the attached file for an example of setting the correct environment for building VTK for example in Windows. Note the call to vcvarsall.bat. Change the attachment name to KitwareDebug.cmd Regards Andrew > -----Original Message----- > From: > ?? > Robert Maynard [mailto: > ?? > robert.maynard at kitware.com] > Sent: Monday, September 18, 2017 11:58 AM > To: Thompson, KT < > ?? > kgt at lanl.gov> > Cc: cmake at cmake.org > Subject: Re: [CMake] FW: Visual Studio 2017 > > From a default cmd.exe I see cmake 3.9 correctly finding VS2017 when > specifying the VS Generator. > > C:\test\build>C:\support\cmake-3.9.2\bin\cmake -G "Visual Studio 15 2017" > ../src > -- The C compiler identification is MSVC 19.11.25508.2 > -- The CXX compiler identification is MSVC 19.11.25508.2 > -- Check for working C compiler: C:/Program Files (x86)/Microsoft > Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/ > HostX86/x86/cl.exe > -- Check for working C compiler: C:/Program Files (x86)/Microsoft > Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/ > HostX86/x86/cl.exe > -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft > Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/ > HostX86/x86/cl.exe > -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft > Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/ > HostX86/x86/cl.exe > -- 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: C:/test/build > > On Mon, Sep 18, 2017 at 10:49 AM, Thompson, KT wrote: > > Robert, > > > > That certainly doesn't work for me - but maybe I'm doing something > non-standard. > > > > If I don't source the vcvarsall.bat file, SDK installations (c:\Program > Files (x86)\Windows Kits\... and c:\Program Files (x86)\Microsoft SDKs\...) > are not found by CMake. > > > > -kt > > > > -----Original Message----- > > From: Robert Maynard [mailto:robert.maynard at kitware.com] > > Sent: Monday, September 18, 2017 8:17 AM > > To: Thompson, KT > > Cc: cmake at cmake.org > > Subject: Re: [CMake] FW: Visual Studio 2017 > > > > You shouldn't need to import VS17 vcvarsall to use the VS17 Generator, > > that should only be needed if using the MSYS or Ninja generators. > > > > As far as building from the command line, the easiest route is to use > > cmake --build --config > > > > On Fri, Sep 15, 2017 at 3:05 PM, Thompson, KT wrote: > >> Randy, > >> > >> Miroslav's recommendation should work. To expand on his response, here > are the commands that I use with VS2017 to allow cmake to run from the > command line: > >> > >> - Start cmd session (should also work via powershell) > >> - To import VS17's command line environment run "C:\Program Files > (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" > x86 > >> - Add extra project specific environment variables (possibly including > appending PATH with the location of cmake). > >> > >> I created a batch file that does these steps for me (and a shortcut on > my desktop that runs the batch file). > >> > >> @echo off > >> rem cmake-with-vs17-env.bat > >> @call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" > x86 %* > >> set PATH=%PATH%;c:\MinGW\bin;C:\Program Files\CMake\bin;C:\Program > Files\doxygen\bin;c:\Python27amd64 > >> rem set CMAKE_PREFIX_PATH= > >> > >> With this environment, I can run cmake from the command line (cmake-gui > or cmake). I can generate "Visual Studio 15 2017" or "MSYS Makefiles" > projects and I can build them with or w/o the GUI. > >> > >> I hope this helps! > >> > >> -kt > >> > >> > >> -----Original Message----- > >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Mateju > Miroslav, Ing. > >> Sent: Friday, September 15, 2017 6:15 AM > >> To: Randy Heiland ; cmake at cmake.org > >> Subject: Re: [CMake] Visual Studio 2017 > >> > >> Hello Randy, > >> > >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Randy Heiland > >> Sent: Friday, September 15, 2017 1:38 PM > >> > >>> Is there a "best way" to use cmake for VS17 (but same cakelists for > Linux)? And by "best", I mean with minimal effort on users. > >>> To be more specific, on Windows, I *think* I'd like to have users > install the cmake binary, then use Powershell to build an application. > >> Is there really a need for using PowerShell if you also want to use the > same CMakeLists for Linux? > >> > >>> But my initial attempt to do so is confusing. I install VS17 (for > C++), it installs in standard path, but 'cl' is not found in Powershell. I > read that I shouldn't edit my PATH (nor do I really want users to have to), > but run some .bat instead to setup my env. So, how should one specify the > compiler for cmake? Oh yes, then I see that VS17 also has its own cmake?? > >> > >> > >> Have you run CMake successfully yet? I am not really aware how it works > but CMake *can* for sure detect VS in my CLI environment without having VS > in PATH. If you use an IDE that understands CMake (like VS17 or Qt Creator, > for example), you should be able to open a CMake project in the IDE and > build it there. Please report your particular problem if it does not work > for you. > >> If you prefer to run cl.exe in CLI, then vcvarsall.bat is the .bat file > you are looking for. > >> > >> Best regards, > >> > >> Ing. Miroslav Mat?j? > >> Programmer Analyst > >> > >> A?D Praha s.r.o. > >> Technology Division > >> Research and Development > >> ?irovnick? 2/3146, 106 17 Prague > >> Czech Republic > >> Phone: +420 267 287 476 > >> Web: www.azd.cz > >> -- > >> > >> Powered by www.kitware.com > >> > >> Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/cmake > >> -- > >> > >> Powered by www.kitware.com > >> > >> Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > >> > >> Kitware offers various services to support the CMake community. For > more information on each offering, please visit: > >> > >> CMake Support: http://cmake.org/cmake/help/support.html > >> CMake Consulting: http://cmake.org/cmake/help/consulting.html > >> CMake Training Courses: http://cmake.org/cmake/help/training.html > >> > >> Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/cmake > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- @echo off rem See: http://dlrdave.blogspot.com.au/2013/02/windows-dev-and-dashboard-prompt.html rem Note: The order of dlls is important in the path. set USER_PATH=%HOMEDRIVE%%HOMEPATH% set WORKING_PATH=D:%HOMEPATH% set VTK_TYPE=Debug set VTK_DIR_NAME=VTK set VTK_TEST_DIR=ExternalData\Testing set ANACONDA_VER=3 rem The compiler and python environment. set TITLE=Visual Studio 15 2017 Win64 Python 3.k TBB %VTK_TYPE% rem Manually set the base path. set Path=C:\ProgramData\Oracle\Java\javapath;C:\Program Files\doxygen\bin;C:\Program Files (x86)\Graphviz2.38\bin;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\Wbem;%SystemRoot%\system32\WindowsPowerShell\v1.0\; rem For TBB: vs15 intel64. set TBB_VER=tbb2017_20170604oss set TBB_ROOT=C:\local\Intel\TBB\%TBB_VER% call %TBB_ROOT%\bin\tbbvars.bat intel64 vs2017 rem VTK paths. set VTK_BUILD_PATH=%WORKING_PATH%\Development\Kitware\build set VTK_PATH=%VTK_BUILD_PATH%\%VTK_DIR_NAME%-%VTK_TYPE%\bin set VTK_DATA_ROOT=%VTK_BUILD_PATH%\%VTK_DIR_NAME%-%VTK_TYPE%\%VTK_TEST_DIR% set VTK_LIB=%VTK_BUILD_PATH%\%VTK_DIR_NAME%-%VTK_TYPE%\lib rem Add the VTK paths if exist "%VTK_BUILD_PATH%\%VTK_DIR_NAME%-%VTK_TYPE%\windows_path.bat" ( @call %VTK_BUILD_PATH%\%VTK_DIR_NAME%-%VTK_TYPE%\windows_path.bat ) else ( echo Error: "%VTK_BUILD_PATH%\%VTK_DIR_NAME%-%VTK_TYPE%\windows_path.bat" not found. ) @call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x64 rem Set paths for Python 3.k set Path=%USER_PATH%\Anaconda%ANACONDA_VER%;%USER_PATH%\Anaconda%ANACONDA_VER%\Scripts;%USER_PATH%\Anaconda%ANACONDA_VER%\DLLs;%Path% rem Add in Git. set Git_Path=%USER_PATH%\AppData\Local\Programs\Git set Path=%Git_Path%\cmd;%Path% rem Qt, CMake, ninja, LLVM set Path=%QTDIR%\bin;C:\local\Ninja;C:\Program Files\CMake\bin;C:\Program Files\LLVM\bin;%Path% rem Clean up set USER_PATH= set WORKING_PATH= set PY_ENV= set Git_Path= set VTK_PATH= set VTK_DIR_NAME= set VTK_TYPE= set VTK_BUILD_PATH= set VTK_TEST_DIR= set ANACONDA_VER= @title %TITLE% @echo @echo Environment set by "%~f0" @echo rem If a parameter exists it means we are calling this from another rem script and do not want to open a command window. if %1.==. @call "%COMSPEC%" From elvis.stansvik at orexplore.com Wed Sep 20 01:53:39 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 20 Sep 2017 07:53:39 +0200 Subject: [CMake] VC2015 and Windows 7 compatibility In-Reply-To: References: <832afd9d-f2ad-baa2-aa30-6e48c3f03959@gmail.com> Message-ID: 2017-09-19 23:22 GMT+02:00 Gonzalo Garramu?o : > > > El 19/09/2017 a las 15:19, J Decker escribi?: >> >> you can just install the runtime redistributuable for 2015... >> >> https://www.microsoft.com/en-us/download/details.aspx?id=48234 > > Unfortunately, that does not have the required ms-api-win-core* DLLs. It is > something that changed with v8.0 of windows. Elvis solution seems like it > should work. I am awaiting an answer from my beta testers. What I forgot to say is that you of course need the Universal CRT DLLs available somewhere on your build system where the CMake code behind CMAKE_INSTALL_UCRT_LIBRARIES will find them. I can't remember exactly what I did, but I do remember a fiddled around a bit to get them installed without having to install a full SDK, because the SDK that they were part of interfered with my build somehow. I _think_ that I took some download from Microsoft that contained multiple installers, and extracted that to get just the installer for the Universal CRT DLLs. Because I couldn't find just the Universal CRT installer as a separate download at Microsoft. I'll try to dig out/remember what I did exactly when I'm back at work with access to the Windows build box. Elvis > > > -- > Gonzalo Garramu?o > > -- > > 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 elvis.stansvik at orexplore.com Wed Sep 20 03:44:12 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Wed, 20 Sep 2017 09:44:12 +0200 Subject: [CMake] VC2015 and Windows 7 compatibility In-Reply-To: References: <832afd9d-f2ad-baa2-aa30-6e48c3f03959@gmail.com> Message-ID: 2017-09-20 7:53 GMT+02:00 Elvis Stansvik : > 2017-09-19 23:22 GMT+02:00 Gonzalo Garramu?o : >> >> >> El 19/09/2017 a las 15:19, J Decker escribi?: >>> >>> you can just install the runtime redistributuable for 2015... >>> >>> https://www.microsoft.com/en-us/download/details.aspx?id=48234 >> >> Unfortunately, that does not have the required ms-api-win-core* DLLs. It is >> something that changed with v8.0 of windows. Elvis solution seems like it >> should work. I am awaiting an answer from my beta testers. > > What I forgot to say is that you of course need the Universal CRT DLLs > available somewhere on your build system where the CMake code behind > CMAKE_INSTALL_UCRT_LIBRARIES will find them. > > I can't remember exactly what I did, but I do remember a fiddled > around a bit to get them installed without having to install a full > SDK, because the SDK that they were part of interfered with my build > somehow. I _think_ that I took some download from Microsoft that > contained multiple installers, and extracted that to get just the > installer for the Universal CRT DLLs. Because I couldn't find just the > Universal CRT installer as a separate download at Microsoft. > > I'll try to dig out/remember what I did exactly when I'm back at work > with access to the Windows build box. I now remember what I did: I downloaded the Windows 10 SDK installer (winsdksetup.exe) from: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk But instead of going ahead and installing the full SDK, which broke something for me [1], I picked the installation option: (o) Download the Windows Software Development Kit .... for installation on a separate computer This will simply download all the separate installers that constitute the SDK and put them in the specified download path. Among them is: /Installers/Universal CRT Redistributable-x86_en-us.msi And it is this specific installer I ran to get just the Universal CRT DLLs installed, without having to install the full Windows 10 SDK. I haven't been able to find this installer as a direct download from Microsoft, only as part of the Windows 10 SDK. Hope that helps. I'm attaching a screenshot showing all the stuff I have installed on my Win 8.1 builder. Note that I'm using Microsoft Visual C++ Build Tools (2015), to avoid having to install the full IDE. Elvis [1] I can't remember what broke right now, but I'm using the Win 8.1 SDK, so probably something interfered. > > Elvis > >> >> >> -- >> Gonzalo Garramu?o >> >> -- >> >> 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 -------------- A non-text attachment was scrubbed... Name: installed.png Type: image/png Size: 58242 bytes Desc: not available URL: From ggarra13 at gmail.com Wed Sep 20 08:11:11 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Wed, 20 Sep 2017 09:11:11 -0300 Subject: [CMake] VC2015 and Windows 7 compatibility In-Reply-To: References: <832afd9d-f2ad-baa2-aa30-6e48c3f03959@gmail.com> Message-ID: <632123e7-e500-d742-109f-fd260ee67782@gmail.com> El 19/09/2017 a las 18:28, Robert Maynard escribi?: > I believe if you want to compile with XP support you can also specify > that as part of the Toolset string. > > So from a clean build directory: make -G "Visual Studio 14 2015" -T v140_xp > Unfortunately I am using Makefiles ( Ninja ) which do not suppport the toolset command. -- Gonzalo Garramu?o From kgt at lanl.gov Wed Sep 20 10:02:29 2017 From: kgt at lanl.gov (Thompson, KT) Date: Wed, 20 Sep 2017 14:02:29 +0000 Subject: [CMake] =?utf-8?q?=E2=80=8BVisual_Studio_2017?= In-Reply-To: References: Message-ID: Andrew, Thanks for the example. Your workflow is very similar to mine. I setup environments for Qt, Git, LLVM, LAPACK, Metis, Parmetis, Microsoft MPI, etc. -kt From: Andrew Maclean [mailto:andrew.amaclean at gmail.com] Sent: Tuesday, September 19, 2017 7:33 PM To: cmake at cmake.org; Thompson, KT ; robert.maynard at kitware.com Subject: Re:?Visual Studio 2017 I actually use a .cmd file to specify everything I need. So the whole environment is set. See the attached file for an example of setting the correct environment for building VTK for example in Windows. Note the call to vcvarsall.bat. Change the attachment name to KitwareDebug.cmd Regards Andrew -----Original Message----- From: ?? Robert Maynard [mailto: ?? robert.maynard at kitware.com] Sent: Monday, September 18, 2017 11:58 AM To: Thompson, KT < ?? kgt at lanl.gov> Cc: cmake at cmake.org Subject: Re: [CMake] FW: Visual Studio 2017 From a default cmd.exe I see cmake 3.9 correctly finding VS2017 when specifying the VS Generator. C:\test\build>C:\support\cmake-3.9.2\bin\cmake -G "Visual Studio 15 2017" ../src -- The C compiler identification is MSVC 19.11.25508.2 -- The CXX compiler identification is MSVC 19.11.25508.2 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- 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: C:/test/build On Mon, Sep 18, 2017 at 10:49 AM, Thompson, KT > wrote: > Robert, > > That certainly doesn't work for me - but maybe I'm doing something non-standard. > > If I don't source the vcvarsall.bat file, SDK installations (c:\Program Files (x86)\Windows Kits\... and c:\Program Files (x86)\Microsoft SDKs\...) are not found by CMake. > > -kt > > -----Original Message----- > From: Robert Maynard [mailto:robert.maynard at kitware.com] > Sent: Monday, September 18, 2017 8:17 AM > To: Thompson, KT > > Cc: cmake at cmake.org > Subject: Re: [CMake] FW: Visual Studio 2017 > > You shouldn't need to import VS17 vcvarsall to use the VS17 Generator, > that should only be needed if using the MSYS or Ninja generators. > > As far as building from the command line, the easiest route is to use > cmake --build --config > > On Fri, Sep 15, 2017 at 3:05 PM, Thompson, KT > wrote: >> Randy, >> >> Miroslav's recommendation should work. To expand on his response, here are the commands that I use with VS2017 to allow cmake to run from the command line: >> >> - Start cmd session (should also work via powershell) >> - To import VS17's command line environment run "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 >> - Add extra project specific environment variables (possibly including appending PATH with the location of cmake). >> >> I created a batch file that does these steps for me (and a shortcut on my desktop that runs the batch file). >> >> @echo off >> rem cmake-with-vs17-env.bat >> @call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 %* >> set PATH=%PATH%;c:\MinGW\bin;C:\Program Files\CMake\bin;C:\Program Files\doxygen\bin;c:\Python27amd64 >> rem set CMAKE_PREFIX_PATH= >> >> With this environment, I can run cmake from the command line (cmake-gui or cmake). I can generate "Visual Studio 15 2017" or "MSYS Makefiles" projects and I can build them with or w/o the GUI. >> >> I hope this helps! >> >> -kt >> >> >> -----Original Message----- >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Mateju Miroslav, Ing. >> Sent: Friday, September 15, 2017 6:15 AM >> To: Randy Heiland >; cmake at cmake.org >> Subject: Re: [CMake] Visual Studio 2017 >> >> Hello Randy, >> >> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Randy Heiland >> Sent: Friday, September 15, 2017 1:38 PM >> >>> Is there a "best way" to use cmake for VS17 (but same cakelists for Linux)? And by "best", I mean with minimal effort on users. >>> To be more specific, on Windows, I *think* I'd like to have users install the cmake binary, then use Powershell to build an application. >> Is there really a need for using PowerShell if you also want to use the same CMakeLists for Linux? >> >>> But my initial attempt to do so is confusing. I install VS17 (for C++), it installs in standard path, but 'cl' is not found in Powershell. I read that I shouldn't edit my PATH (nor do I really want users to have to), but run some .bat instead to setup my env. So, how should one specify the compiler for cmake? Oh yes, then I see that VS17 also has its own cmake?? >> >> >> Have you run CMake successfully yet? I am not really aware how it works but CMake *can* for sure detect VS in my CLI environment without having VS in PATH. If you use an IDE that understands CMake (like VS17 or Qt Creator, for example), you should be able to open a CMake project in the IDE and build it there. Please report your particular problem if it does not work for you. >> If you prefer to run cl.exe in CLI, then vcvarsall.bat is the .bat file you are looking for. >> >> Best regards, >> >> Ing. Miroslav Mat?j? >> Programmer Analyst >> >> A?D Praha s.r.o. >> Technology Division >> Research and Development >> ?irovnick? 2/3146, 106 17 Prague >> Czech Republic >> Phone: +420 267 287 476 >> Web: www.azd.cz >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Wed Sep 20 10:27:49 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Wed, 20 Sep 2017 11:27:49 -0300 Subject: [CMake] Fwd: Re: VC2015 and Windows 7 compatibility In-Reply-To: References: Message-ID: El 19/09/2017 a las 13:57, Elvis Stansvik escribi?: > > I also build on Win 8.1/MSVC 2015, targeting Windows 7+, and what I do > is basically: > > if(WIN32) > add_definitions(/D_WIN32_WINNT=0x0601) # Target Windows 7+ > > set(CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION ".") > set(CMAKE_INSTALL_UCRT_LIBRARIES ON) > include(InstallRequiredSystemLibraries) > endif() > > The /D_WIN32_WINNT=0x0601 is what ensures Windows 7 compatibility and > CMAKE_INSTALL_UCRT_LIBRARIES is what ensures Universal CRT libraries > like the one you mentioned gets installed alongside the application. > > You'll end up with a truckload of such small DLLs, but AFAIK this is > what you need to do if you want to do app-local deployment of the > Universal CRT. > > Hope that helps. > > Elvis I followed your advice and got a bunch of api-ms-* files in the install directory when I packed it. However, for my program, there were still 3 DLLs missing: api-ms-win-core-libraryloader-l1-2-0.dll, api-ms-win-core-sysinfo-l1-2-1.dll, api-ms-win-core-processthreads-l1-1-2.dll. Not sure if this is a bug in cmake. Not sure how cmake gets those dependencies. -- Gonzalo Garramu?o From csiga.biga at aol.com Wed Sep 20 10:36:32 2017 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Wed, 20 Sep 2017 16:36:32 +0200 Subject: [CMake] CMake tutorial on Github Message-ID: Hi fellow CMakers! As part of a university course and an attempt to safeguard my time against all the one-to-one CMake tutorials I have held thus far, I have created a free CMake tutorial available here. It is fairly basic, in its current form is more or less just a jump-start guide. I wanted to maintain a consistent and modern style of scripting keeping up to date with the latest features. If you like it and have collegues that need the first push, feel free to point them in this direction. If you feel like contributing, or simply have ideas which directions to take next, I am open to both suggestions and PRs. I am aware that raw Github is not the best platform for such a writing, but it was immensely simple to fire up, I need not worry about hosting, and collaborating on the material is a breeze. Do keep in mind it is an unofficial tutorial and reflects MY understanding of CMake, not those of its day to day developers. (I have looked at the codebase on one occasion when I wanted to implement a feature, but it would?ve required a complete overhaul of the makefile generators which I did not have the capacity to do. If I?ll have the time, I?ll continue working on it, some lessons are referred to that are currently non-existent. I do intend on writing them sometime. Cheers, M?t? -------------- next part -------------- An HTML attachment was scrubbed... URL: From calebwherry at gmail.com Wed Sep 20 10:36:06 2017 From: calebwherry at gmail.com (J. Caleb Wherry) Date: Wed, 20 Sep 2017 10:36:06 -0400 Subject: [CMake] C++/CLI Wrapper with C# Message-ID: All, I recently upgraded to CMake 3.8 to get support for C# as a first class language and it works nicely. However, I am seeking clarification on something: I currently compile my C++/CLI wrapper as a SHARED lib. This produces a linking lib which I didn't expect and don't want (using the lib works fine in my build with no issues). After reading the docs ( https://cmake.org/cmake/help/v3.8/command/add_library.html), it seems like I should be compiling the lib as a MODULE since I do not want unmanaged symbols exported. However, when I change to MODULE and try to link that to a C# console app, it doesn't work anymore, I get the "MODULE_LIBRARY may not be linked into another target". My question: am I doing something wrong here? What is the standard way to build a C++/CLI lib and link it to a C# app? Some things to note: - When I link to the C# app, I use target_link_libraries, I don't put it as a reference. I was hoping I could just use this macro and not have to explicitly place it as a reference. - My C++/CLI wrapper lib does have some public C symbols which I believe is causing the linking lib to be created so I will investigate that. However, that doesn't answer the question of how to correctly compile a C++/CLI lib. If there isn't a simple answer, I can create a SSCCE (http://sscce.org/) to replicate the issue I am having. Thanks! Caleb -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Sep 20 12:06:19 2017 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 20 Sep 2017 12:06:19 -0400 Subject: [CMake] CMake 3.9.3 available for download Message-ID: We are pleased to announce that CMake 3.9.3 is now available for download. Please use the latest release from our download page: https://cmake.org/download/ Thanks for your support! ------------------------------------------------------------------------- Changes in 3.9.3 since 3.9.2: Brad King (3): VS: Do not consider MAP_IMPORTED_CONFIG_ on non-imported targets bootstrap: Fix running multiple times in-source CMake 3.9.3 Maarten de Vries (1): vim: Remove default setting of expandtab Roger Leigh (1): FindBoost: Add support for Boost 1.65.0 and 1.65.1 to CMake 3.9 Rolf Eike Beer (1): CTest: fix crash if source file for coverage cannot be found Sebastian Holtermann (2): Autogen: Backport autogen target dependency as file dependency fix Autogen: Tests: Backport tests for _autogen target dependencies From haocheng.liu at kitware.com Wed Sep 20 14:24:55 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Wed, 20 Sep 2017 14:24:55 -0400 Subject: [CMake] CMake tutorial on Github In-Reply-To: <20170920143627.AA56CFD0B8@public.kitware.com> References: <20170920143627.AA56CFD0B8@public.kitware.com> Message-ID: Hi M?t?, You can also take a look at this github repo: https://github.com/onqtam/awesome-cmake There are also many cool examples and tutorials. On Wed, Sep 20, 2017 at 10:36 AM, Nagy-Egri M?t? Ferenc via CMake < cmake at cmake.org> wrote: > Hi fellow CMakers! > > > > As part of a university course and an attempt to safeguard my time against > all the one-to-one CMake tutorials I have held thus far, I have created a > free CMake tutorial available here > . It is > fairly basic, in its current form is more or less just a jump-start guide. > I wanted to maintain a consistent and modern style of scripting keeping up > to date with the latest features. > > > > If you like it and have collegues that need the first push, feel free to > point them in this direction. If you feel like contributing, or simply have > ideas which directions to take next, I am open to both suggestions and PRs. > I am aware that raw Github is not the best platform for such a writing, but > it was immensely simple to fire up, I need not worry about hosting, and > collaborating on the material is a breeze. > > > > Do keep in mind it is an unofficial tutorial and reflects MY understanding > of CMake, not those of its day to day developers. (I have looked at the > codebase on one occasion when I wanted to implement a feature, but it > would?ve required a complete overhaul of the makefile generators which I > did not have the capacity to do. If I?ll have the time, I?ll continue > working on it, some lessons are referred to that are currently > non-existent. I do intend on writing them sometime. > > > > Cheers, > > M?t? > > > > -- > > 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 > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfultz2 at yahoo.com Wed Sep 20 17:46:26 2017 From: pfultz2 at yahoo.com (paul) Date: Wed, 20 Sep 2017 16:46:26 -0500 Subject: [CMake] CMake tutorial on Github In-Reply-To: <20170920143627.D1A57FD0B9@public.kitware.com> References: <20170920143627.D1A57FD0B9@public.kitware.com> Message-ID: <1505943986.3965.122.camel@yahoo.com> This looks good, a couple of comments: - A common misconception for libraries is to generate a Find module for downstream users. You don't suggest that in the tutorial, but in the section "Shipping Find Module scripts" it would be a good idea to emphasize that is for upstream libraries not downstream users. - It should mention `CMAKE_PREFIX_PATH` as a way to tell cmake where dependencies are installed, and really should be preferred over modifying a global "registry". On Wed, 2017-09-20 at 16:36 +0200, Nagy-Egri M?t? Ferenc via CMake wrote: > Hi fellow CMakers! > ? > As part of a university course and an attempt to safeguard my time against > all the one-to-one CMake tutorials I have held thus far, I have created a > free CMake tutorial available here. It is fairly basic, in its current form > is more or less just a jump-start guide. I wanted to maintain a consistent > and modern style of scripting keeping up to date with the latest features. > ? > If you like it and have collegues that need the first push, feel free to > point them in this direction. If you feel like contributing, or simply have > ideas which directions to take next, I am open to both suggestions and PRs. > I am aware that raw Github is not the best platform for such a writing, but > it was immensely simple to fire up, I need not worry about hosting, and > collaborating on the material is a breeze. > ? > Do keep in mind it is an unofficial tutorial and reflects MY understanding > of CMake, not those of its day to day developers. (I have looked at the > codebase on one occasion when I wanted to implement a feature, but it > would?ve required a complete overhaul of the makefile generators which I did > not have the capacity to do. If I?ll have the time, I?ll continue working on > it, some lessons are referred to that are currently non-existent. I do > intend on writing them sometime. > ? > Cheers, > M?t? > ? > --? > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.o > rg/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/opensourc > e/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From ggarra13 at gmail.com Wed Sep 20 18:20:51 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Wed, 20 Sep 2017 19:20:51 -0300 Subject: [CMake] VC2015 and Windows 7 compatibility In-Reply-To: References: <832afd9d-f2ad-baa2-aa30-6e48c3f03959@gmail.com> Message-ID: El 20/09/2017 a las 04:44, Elvis Stansvik escribi?: > 2017-09-20 7:53 GMT+02:00 Elvis Stansvik : >> 2017-09-19 23:22 GMT+02:00 Gonzalo Garramu?o : >>> >>> El 19/09/2017 a las 15:19, J Decker escribi?: >>>> you can just install the runtime redistributuable for 2015... >>>> >>>> https://www.microsoft.com/en-us/download/details.aspx?id=48234 >>> Unfortunately, that does not have the required ms-api-win-core* DLLs. It is >>> something that changed with v8.0 of windows. Elvis solution seems like it >>> should work. I am awaiting an answer from my beta testers. >> What I forgot to say is that you of course need the Universal CRT DLLs >> available somewhere on your build system where the CMake code behind >> CMAKE_INSTALL_UCRT_LIBRARIES will find them. Thanks, Elvis. That helps. I was able to get a Win64 build running on my Win7 (sans SP1) box once all the api-ms-win-core* packages were disted. The Win32 build of my program cannot start with an api-ms-win-core-crt-*.dll error. However since then I read that those api DLLs are not part of the Microsoft Runtime and as such cannot legally be disted and they shouldn't in any case for technical reasons (Microsoft might want to change them from version to version). I am now trying to get a Windows7 SP1 box for myself to try further. -- Gonzalo Garramu?o From elvis.stansvik at orexplore.com Thu Sep 21 01:55:13 2017 From: elvis.stansvik at orexplore.com (Elvis Stansvik) Date: Thu, 21 Sep 2017 07:55:13 +0200 Subject: [CMake] VC2015 and Windows 7 compatibility In-Reply-To: References: <832afd9d-f2ad-baa2-aa30-6e48c3f03959@gmail.com> Message-ID: 2017-09-21 0:20 GMT+02:00 Gonzalo Garramu?o : > > > El 20/09/2017 a las 04:44, Elvis Stansvik escribi?: >> >> 2017-09-20 7:53 GMT+02:00 Elvis Stansvik : >>> >>> 2017-09-19 23:22 GMT+02:00 Gonzalo Garramu?o : >>>> >>>> >>>> El 19/09/2017 a las 15:19, J Decker escribi?: >>>>> >>>>> you can just install the runtime redistributuable for 2015... >>>>> >>>>> https://www.microsoft.com/en-us/download/details.aspx?id=48234 >>>> >>>> Unfortunately, that does not have the required ms-api-win-core* DLLs. >>>> It is >>>> something that changed with v8.0 of windows. Elvis solution seems like >>>> it >>>> should work. I am awaiting an answer from my beta testers. >>> >>> What I forgot to say is that you of course need the Universal CRT DLLs >>> available somewhere on your build system where the CMake code behind >>> CMAKE_INSTALL_UCRT_LIBRARIES will find them. > > Thanks, Elvis. That helps. I was able to get a Win64 build running on my > Win7 (sans SP1) box once all the api-ms-win-core* packages were disted. > The Win32 build of my program cannot start with an api-ms-win-core-crt-*.dll > error. Alright, glad you've made some progress. I only do x64 builds, so I haven't tried to get it working on x86. > > However since then I read that those api DLLs are not part of the Microsoft > Runtime and as such cannot legally be disted and they shouldn't in any case > for technical reasons (Microsoft might want to change them from version to > version). Hm, it would surprise me if Microsoft made app-local deployment of the Universal CRT illegal. I know Microsoft discourages app-local deployment, preferring other means of doing it that allows for the DLLs to be updated centrally, but making it muddy legally would be another level of stupid. See the initial blog post about the Universal CRT here: https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ , and especially the "Updated September 11, 2015" section in red. So I think it is supported, just discouraged. Elvis > > I am now trying to get a Windows7 SP1 box for myself to try further. > > -- > Gonzalo Garramu?o > From d3ck0r at gmail.com Thu Sep 21 07:09:48 2017 From: d3ck0r at gmail.com (J Decker) Date: Thu, 21 Sep 2017 04:09:48 -0700 Subject: [CMake] rebuild externalprojects Message-ID: how do I make sure that externalprojects get built if I change a source in one? -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Sep 21 07:18:46 2017 From: DLRdave at aol.com (David Cole) Date: Thu, 21 Sep 2017 07:18:46 -0400 Subject: [CMake] rebuild externalprojects In-Reply-To: References: Message-ID: By manually deleting (or touching) the stamp file associated with the earliest step you need to re-run. ExternalProject is not for auto-detecting changes to stuff and minimally re-running build steps. It's for static stuff that doesn't change much. Find the "-build" stamp file that's associated with the project containing the source you changed and delete it. Then run the build from the top and that one and everything that depends on it afterwards should rebuild. HTH, David C. On Thu, Sep 21, 2017 at 7:09 AM, J Decker wrote: > how do I make sure that externalprojects get built if I change a source in > one? > > > > -- > > 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 craig.scott at crascit.com Thu Sep 21 07:21:09 2017 From: craig.scott at crascit.com (Craig Scott) Date: Thu, 21 Sep 2017 21:21:09 +1000 Subject: [CMake] rebuild externalprojects In-Reply-To: References: Message-ID: You probably want the BUILD_ALWAYS option. Have a look at the overhauled docs for ExternalProject (only available on master at the moment) for a more informative description of the option and the module in general: https://cmake.org/cmake/help/git-master/module/ExternalProject.html On Thu, Sep 21, 2017 at 9:09 PM, J Decker wrote: > how do I make sure that externalprojects get built if I change a source in > one? > > > > -- > > 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 nilsgladitz at gmail.com Thu Sep 21 07:21:13 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 21 Sep 2017 13:21:13 +0200 Subject: [CMake] rebuild externalprojects In-Reply-To: References: Message-ID: On Thu, Sep 21, 2017 at 1:09 PM, J Decker wrote: > how do I make sure that externalprojects get built if I change a source in > one? > "BUILD_ALWAYS 1" should always trigger the build of the external project. This would be required since only the external project's build system will know if something relevant has changed or not. Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Thu Sep 21 07:34:00 2017 From: d3ck0r at gmail.com (J Decker) Date: Thu, 21 Sep 2017 04:34:00 -0700 Subject: [CMake] rebuild externalprojects In-Reply-To: References: Message-ID: On Thu, Sep 21, 2017 at 4:21 AM, Craig Scott wrote: > You probably want the BUILD_ALWAYS option. Have a look at the overhauled > docs for ExternalProject (only available on master at the moment) for a > more informative description of the option and the module in general: > > Excellent that fixes my issues. It appears that I'll need to update my required to 3.1... 3.0 didn't have it. https://cmake.org/cmake/help/v3.1/module/ExternalProject.html > https://cmake.org/cmake/help/git-master/module/ExternalProject.html > > > On Thu, Sep 21, 2017 at 9:09 PM, J Decker wrote: > >> how do I make sure that externalprojects get built if I change a source >> in one? >> >> >> >> -- >> >> 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 prlw1 at cam.ac.uk Thu Sep 21 09:26:04 2017 From: prlw1 at cam.ac.uk (Patrick Welche) Date: Thu, 21 Sep 2017 14:26:04 +0100 Subject: [CMake] ; list Message-ID: <20170921132604.GA19928@quartz> Having run cmake 3.9.2 once already, I see: $ cat CMakeLists.txt set(var one two) message(${var}) $ cmake . onetwo -- Configuring done -- Generating done -- Build files have been written to: /tmp/cmaketest Would you have expected "one;two" rather than "onetwo"? Cheers, Patrick From nilsgladitz at gmail.com Thu Sep 21 09:35:13 2017 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 21 Sep 2017 15:35:13 +0200 Subject: [CMake] ; list In-Reply-To: <20170921132604.GA19928@quartz> References: <20170921132604.GA19928@quartz> Message-ID: On Thu, Sep 21, 2017 at 3:26 PM, Patrick Welche wrote: > Having run cmake 3.9.2 once already, I see: > > $ cat CMakeLists.txt > set(var one two) > message(${var}) > $ cmake . > onetwo > -- Configuring done > -- Generating done > -- Build files have been written to: /tmp/cmaketest > > Would you have expected "one;two" rather than "onetwo"? > When unquoted each list items is turned into a distinct argument for the message() invocation. message() concatenates its arguments hence "onetwo". To preserve the semicolon in the message try message("${var}") Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From haocheng.liu at kitware.com Thu Sep 21 09:35:16 2017 From: haocheng.liu at kitware.com (Haocheng Liu) Date: Thu, 21 Sep 2017 09:35:16 -0400 Subject: [CMake] ; list In-Reply-To: <20170921132604.GA19928@quartz> References: <20170921132604.GA19928@quartz> Message-ID: Hi Patrick, On Thu, Sep 21, 2017 at 9:26 AM, Patrick Welche wrote: > Having run cmake 3.9.2 once already, I see: > > $ cat CMakeLists.txt > set(var one two) > message(${var}) > $ cmake . > onetwo > -- Configuring done > -- Generating done > -- Build files have been written to: /tmp/cmaketest > > Would you have expected "one;two" rather than "onetwo"? > > It should be "onetwo". If you want it to be "one;two", then try ```cmake message(${"var}") # Use quotes here ``` Reference link: https://cmake.org/Wiki/CMake/Language_Syntax > Cheers, > > Patrick > -- > > 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 > -- Best regards Haocheng Haocheng LIU Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4421 <(518)%20881-4421> -------------- next part -------------- An HTML attachment was scrubbed... URL: From julius.caro at gmail.com Thu Sep 21 10:08:40 2017 From: julius.caro at gmail.com (Luis Caro Campos) Date: Thu, 21 Sep 2017 15:08:40 +0100 Subject: [CMake] Fwd: Re: VC2015 and Windows 7 compatibility In-Reply-To: References: Message-ID: Hi Gonzalo, Since you are using ninja files and building from command line, I suspect you are using a Visual Studio 2015 command prompt. It may be beneficial to initialise a command prompt to specifically target Windows 8.1 SDK which is the one to go to target Windows 7. First, make sure Windows 8.1 SDK is installed (can't remember but it is likely that the visual studio 2015 installer can help). Then open a command prompt and run the vcvarsall.bat passing arguments "x64 8.1" if you are building on a 64-bit install of windows targeting 64-bit windows. Then run cmake and ninja from there, and I suspect there's a chance the produced binaries will no longer depend on those files. Like you mentioned, those files are not redistributable by developers. My vcvarsall.bat is located at: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC Regards, Luis On 20 Sep 2017 15:28, "Gonzalo Garramu?o" wrote: > El 19/09/2017 a las 13:57, Elvis Stansvik escribi?: > >> >> I also build on Win 8.1/MSVC 2015, targeting Windows 7+, and what I do >> is basically: >> >> if(WIN32) >> add_definitions(/D_WIN32_WINNT=0x0601) # Target Windows 7+ >> >> set(CMAKE_INSTALL_SYSTEM_RUNTIME_DESTINATION ".") >> set(CMAKE_INSTALL_UCRT_LIBRARIES ON) >> include(InstallRequiredSystemLibraries) >> endif() >> >> The /D_WIN32_WINNT=0x0601 is what ensures Windows 7 compatibility and >> CMAKE_INSTALL_UCRT_LIBRARIES is what ensures Universal CRT libraries >> like the one you mentioned gets installed alongside the application. >> >> You'll end up with a truckload of such small DLLs, but AFAIK this is >> what you need to do if you want to do app-local deployment of the >> Universal CRT. >> >> Hope that helps. >> >> Elvis >> > > I followed your advice and got a bunch of api-ms-* files in the install > directory when I packed it. > However, for my program, there were still 3 DLLs missing: > api-ms-win-core-libraryloader-l1-2-0.dll, > api-ms-win-core-sysinfo-l1-2-1.dll, > api-ms-win-core-processthreads-l1-1-2.dll. > > Not sure if this is a bug in cmake. Not sure how cmake gets those > dependencies. > > -- > Gonzalo Garramu?o > > -- > > 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 prlw1 at cam.ac.uk Thu Sep 21 10:15:28 2017 From: prlw1 at cam.ac.uk (Patrick Welche) Date: Thu, 21 Sep 2017 15:15:28 +0100 Subject: [CMake] ; list In-Reply-To: References: <20170921132604.GA19928@quartz> Message-ID: <20170921141528.GB19928@quartz> On Thu, Sep 21, 2017 at 03:35:13PM +0200, Nils Gladitz wrote: > On Thu, Sep 21, 2017 at 3:26 PM, Patrick Welche wrote: > When unquoted each list items is turned into a distinct argument for the > message() invocation. > message() concatenates its arguments hence "onetwo". > > To preserve the semicolon in the message try message("${var}") Thank you! Patrick From csiga.biga at aol.com Thu Sep 21 10:23:35 2017 From: csiga.biga at aol.com (=?utf-8?Q?Nagy-Egri_M=C3=A1t=C3=A9_Ferenc?=) Date: Thu, 21 Sep 2017 16:23:35 +0200 Subject: [CMake] CMake tutorial on Github In-Reply-To: <1505943986.3965.122.camel@yahoo.com> References: <20170920143627.D1A57FD0B9@public.kitware.com> <1505943986.3965.122.camel@yahoo.com> Message-ID: Hi Paul! I do not quite understand your comments. - Are you referring to the SFML distribution model? I am aware that deliberately forcing my end-users to ship a FindModule script sucks and I was not trying to promote that. I just said that it happens. The part where you say ?emphasize that is for upstream libraries not downstream users?. How can I create a FindModule script FOR an upstream? Upstream is done. It?s compiled. Who else could the target audience of a FindModule script be, other other than a downstream user? - How can CMAKE_PREFIX_PATH be considered desirable over the package registry? I compile something, install and, register it, done. Fire and forget. I don?t think that either specifying toolchain files or specifying CMAKE_PREFIX_PATH are better than simply specifying? nothing? Sorry if I am lost in translation, I?m just trying to understand. Cheers, M?t? Felad?: paul Elk?ldve: 2017. szeptember 20., szerda 23:46 C?mzett: Nagy-Egri M?t? Ferenc; Cmake Mailing List T?rgy: Re: [CMake] CMake tutorial on Github This looks good, a couple of comments: - A common misconception for libraries is to generate a Find module for downstream users. You don't suggest that in the tutorial, but in the section "Shipping Find Module scripts" it would be a good idea to emphasize that is for upstream libraries not downstream users. - It should mention `CMAKE_PREFIX_PATH` as a way to tell cmake where dependencies are installed, and really should be preferred over modifying a global "registry". On Wed, 2017-09-20 at 16:36 +0200, Nagy-Egri M?t? Ferenc via CMake wrote: > Hi fellow CMakers! > ? > As part of a university course and an attempt to safeguard my time against > all the one-to-one CMake tutorials I have held thus far, I have created a > free CMake tutorial available here. It is fairly basic, in its current form > is more or less just a jump-start guide. I wanted to maintain a consistent > and modern style of scripting keeping up to date with the latest features. > ? > If you like it and have collegues that need the first push, feel free to > point them in this direction. If you feel like contributing, or simply have > ideas which directions to take next, I am open to both suggestions and PRs. > I am aware that raw Github is not the best platform for such a writing, but > it was immensely simple to fire up, I need not worry about hosting, and > collaborating on the material is a breeze. > ? > Do keep in mind it is an unofficial tutorial and reflects MY understanding > of CMake, not those of its day to day developers. (I have looked at the > codebase on one occasion when I wanted to implement a feature, but it > would?ve required a complete overhaul of the makefile generators which I did > not have the capacity to do. If I?ll have the time, I?ll continue working on > it, some lessons are referred to that are currently non-existent. I do > intend on writing them sometime. > ? > Cheers, > M?t? > ? > --? > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.o > rg/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/opensourc > e/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake -------------- next part -------------- An HTML attachment was scrubbed... URL: From ggarra13 at gmail.com Thu Sep 21 17:40:25 2017 From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=) Date: Thu, 21 Sep 2017 18:40:25 -0300 Subject: [CMake] Fwd: Re: VC2015 and Windows 7 compatibility In-Reply-To: References: Message-ID: <06f8dce5-84f2-dd33-c34c-9fd4ca827028@gmail.com> El 21/09/2017 a las 11:08, Luis Caro Campos escribi?: > Hi Gonzalo, > > Since you are using ninja files and building from command line, I > suspect you are using a Visual Studio 2015 command prompt. > > It may be beneficial to initialise a command prompt to specifically > target Windows 8.1 SDK which is the one to go to target Windows 7. > > First, make sure Windows 8.1 SDK is installed (can't remember but it > is likely that the visual studio 2015 installer can help). > > Then open a command prompt and run the vcvarsall.bat passing arguments > "x64 8.1" if you are building on a 64-bit install of windows targeting > 64-bit windows. > > Then run cmake and ninja from there, and I suspect there's a chance > the produced binaries will no longer depend on those files. Like you > mentioned, those files are not redistributable by developers. > > My vcvarsall.bat is located at: > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC > > Regards, > Luis Thank you Luis for your help. I found out why the application was failing in Windows7 32-bits. The problems was a zlib file that was compiled with the MSVC2015 compiler while the rest was compiled with MSVC2013. That was triggering the api-ms-core-runtime-l1-2-0.dll error. Talk about a helpful message. Yet, I am puzzled still with the Windows 7 64 bits version of my program. Disting many of the api-ms-core* and api-ms-crt* makes my program work. Here, as far as I can tell, it was compiled with the MSVC2015 with the -D_WIN32_WINNT=0x0501 to target the least OS. However some of the dependant libraries surely not have that -D define. It would be helpful if I knew what files are part of the universal c runtime. Currently I think: concrt140.dll, ucrtbase.dll, msvcp140.dll, vccorlib140.dll, vcomp140.dll, vcruntime140.dll. I exclude all the MFC dlls as I am not using them. -- Gonzalo Garramu?o From julius.caro at gmail.com Thu Sep 21 18:13:56 2017 From: julius.caro at gmail.com (Luis Caro Campos) Date: Thu, 21 Sep 2017 23:13:56 +0100 Subject: [CMake] Fwd: Re: VC2015 and Windows 7 compatibility In-Reply-To: <06f8dce5-84f2-dd33-c34c-9fd4ca827028@gmail.com> References: <06f8dce5-84f2-dd33-c34c-9fd4ca827028@gmail.com> Message-ID: Hi Gonzalo, Zlib has a C interface (or rather, its all C) so a version of it built with vc2013 can work with c++ code built with vs2015. But this probably means that you need both redistributables installed on the target machine (2013 and 2015). Id make sure you install both runtimes unless you build zlib with 2015. As for the rest, Id still try to make sure the application is built in an environment where the 8.1 SDK is used as opposed to the 10.0 one. At this link with examples to environment variables set for an older version of visual studio, http://blog.bfitz.us/?p=2369. Notice how some of them point to: C:\Program Files (x86)\Windows Kits\8.1 You could verify whether these are correctly set up by printing them on the console, e.g. `echo %LIB%` If windows 10 sdk is used instead I suspect thst could be a problem. Alternatively, you can the visual studio generator in cmake, instead of ninja, open the solution, and in the project properties check which "target platform" is displayed and whether 8.1 is an option. According to Microsoft's documentation SDK 8.1 would be the one to target vista, 7, server 2008, etc ( https://msdn.microsoft.com/en-us/library/8x480de8.aspx). You may also need to add your define in "targetver.h" rather than defining it through command line, but I am unsure about this. Regards, Luis On 21 Sep 2017 22:40, "Gonzalo Garramu?o" wrote: > > > El 21/09/2017 a las 11:08, Luis Caro Campos escribi?: > >> Hi Gonzalo, >> >> Since you are using ninja files and building from command line, I suspect >> you are using a Visual Studio 2015 command prompt. >> >> It may be beneficial to initialise a command prompt to specifically >> target Windows 8.1 SDK which is the one to go to target Windows 7. >> >> First, make sure Windows 8.1 SDK is installed (can't remember but it is >> likely that the visual studio 2015 installer can help). >> >> Then open a command prompt and run the vcvarsall.bat passing arguments >> "x64 8.1" if you are building on a 64-bit install of windows targeting >> 64-bit windows. >> >> Then run cmake and ninja from there, and I suspect there's a chance the >> produced binaries will no longer depend on those files. Like you mentioned, >> those files are not redistributable by developers. >> >> My vcvarsall.bat is located at: >> C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC >> >> Regards, >> Luis >> > Thank you Luis for your help. I found out why the application was failing > in Windows7 32-bits. The problems was a zlib file that was compiled with > the MSVC2015 compiler while the rest was compiled with MSVC2013. That was > triggering the api-ms-core-runtime-l1-2-0.dll error. Talk about a helpful > message. > > Yet, I am puzzled still with the Windows 7 64 bits version of my program. > Disting many of the api-ms-core* and api-ms-crt* makes my program work. > Here, as far as I can tell, it was compiled with the MSVC2015 with the > -D_WIN32_WINNT=0x0501 to target the least OS. However some of the dependant > libraries surely not have that -D define. > It would be helpful if I knew what files are part of the universal c > runtime. Currently I think: concrt140.dll, ucrtbase.dll, msvcp140.dll, > vccorlib140.dll, vcomp140.dll, vcruntime140.dll. I exclude all the MFC > dlls as I am not using them. > > -- > Gonzalo Garramu?o > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfultz2 at yahoo.com Thu Sep 21 11:36:26 2017 From: pfultz2 at yahoo.com (paul) Date: Thu, 21 Sep 2017 10:36:26 -0500 Subject: [CMake] CMake tutorial on Github In-Reply-To: <20170921142335.4128DFCC0B@public.kitware.com> References: <20170920143627.D1A57FD0B9@public.kitware.com> <1505943986.3965.122.camel@yahoo.com> <20170921142335.4128DFCC0B@public.kitware.com> Message-ID: <1506008186.3965.168.camel@yahoo.com> On Thu, 2017-09-21 at 16:23 +0200, Nagy-Egri M?t? Ferenc via CMake wrote: > Hi Paul! > ? > I do not quite understand your comments. > ? > Are you referring to the SFML distribution model? I am aware that > deliberately forcing my end-users to ship a FindModule script sucks and I > was not trying to promote that. Yes, you don't, but a casual user could possibly interpret it that way. The same thing happens with cmake official documentation, even though it clearly states a FindModule "is not shipped with upstream".? > I just said that it happens. The part where you say ?emphasize that is for > upstream libraries not downstream users?. How can I create a FindModule > script FOR an upstream? Upstream is done. It?s compiled. Who else could the > target audience of a FindModule script be, other other than a downstream > user? Yea, I think the directions here is confusing. That is, in my library, I create a FindModule to use an upstream library because the upstream library doesn't support cmake. However, in my library, I create a config file to support cmake for downstream users. > How can CMAKE_PREFIX_PATH be considered desirable over the package registry? > I compile something, install and, register it, done. Fire and forget. I > don?t think that either specifying toolchain files or specifying > CMAKE_PREFIX_PATH are better than simply specifying? nothing? If I want to install multiple versions of the library(or libraries) in different locations, that is one with `CMAKE_INSTALL_PREFIX=/opt/a` and another with `CMAKE_INSTALL_PREFIX=/opt/b`, it can leads to lots of problems. Implicitly changing where cmake searches will cause unnecessary headaches, and it is rarely done(even the clFFT example doesn't do this). There are other issues as well: it can't be done system-wide portably. It only can help find config packages, whereas `CMAKE_PREFIX_PATH` can help tell where dependencies are when using any of the `find_*` commands in cmake.? Of course, I am not saying to remove the section, but rather discuss how `CMAKE_PREFIX_PATH` can be used to tell cmake where your dependencies are installed. . From bruce4y at aim.com Sun Sep 24 17:55:13 2017 From: bruce4y at aim.com (Bruce) Date: Sun, 24 Sep 2017 23:55:13 +0200 Subject: [CMake] Can't associate Open CV with Visual Studio by CMake Message-ID: <6e9f9200-60f3-6049-49d5-f2d3d8f3dddd@aim.com> I can't link Open CV libraries with Visual Studio Community 2017 by using CMake. Where is the source code:C:/Users/John/OpenCV/sources Where to build the binaries: C:/Users/John/OpenCV/build Configure: Visual Studio 15 2017 I got error: CMAKE_CONFIGURATION_TYPES Debug; Release CMAKE_INSTALL_PREFIX C:/Users/John/OpenCV/build/install In the file "CMakeOutput.log" is "The system is: Windows - 10.0.15063 - AMD64". I have Intel i7 7500U CPU. What's the problem and how to fix it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mateusz at loskot.net Mon Sep 25 04:33:20 2017 From: mateusz at loskot.net (Mateusz Loskot) Date: Mon, 25 Sep 2017 10:33:20 +0200 Subject: [CMake] To quote (path) variables or not, and everywhere? Message-ID: Hi, A user of one of projects I maintain pointed out that according to CMake guidelines [1] all variables with strings (also paths) should be quoted, ie. include_directories(${SOCI_SOURCE_DIR}/core) should read include_directories("${SOCI_SOURCE_DIR}/core") Is that so? What is the current CMake recommendation? Some other guidelines [2] suggest rule of thumb when using variables in COMMAND calls: Use quotes for the arguments that contain file paths Does this apply to include_directories. set_target_properties, etc.? I found "Paths with spaces - Visual Studio" [3] post which reports a problem with not quoted paths but David Cole's recommendation [4] uses add_library with path not quoted. I sense, the answer to quote or not to quote might depend on which CMake command is used. Could anyone tell what is the current recommendation? [1] https://cmake.org/Wiki/CMake/Language_Syntax#CMake_splits_arguments_unless_you_use_quotation_marks_or_escapes. [2] https://stackoverflow.com/a/35853080/151641 [3] https://public.kitware.com/pipermail/cmake/2012-July/051138.html [4] https://public.kitware.com/pipermail/cmake/2012-July/051139.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From alexvilchansky at yahoo.com Mon Sep 25 06:57:48 2017 From: alexvilchansky at yahoo.com (Oleksii Vilchanskyi) Date: Mon, 25 Sep 2017 12:57:48 +0200 Subject: [CMake] To quote (path) variables or not, and everywhere? In-Reply-To: References: Message-ID: As usually with CMake, there are no recommendations/guidelines. However, here's my logic: 1) if it's a path, always quote it 2) if it's not a pat, but inside an if() or any similar core language structure, quote it as well 3) don't quote only if you're sure the string can't have spaces - otherwise do quote 4) quoting is free and doesn't hurt On Sep 25, 2017, 10:34, at 10:34, Mateusz Loskot wrote: >Hi, > >A user of one of projects I maintain pointed out that according to >CMake guidelines [1] all variables with strings (also paths) should be >quoted, ie. > >include_directories(${SOCI_SOURCE_DIR}/core) > >should read > >include_directories("${SOCI_SOURCE_DIR}/core") > >Is that so? >What is the current CMake recommendation? > >Some other guidelines [2] suggest rule of thumb when using >variables in COMMAND calls: > Use quotes for the arguments that contain file paths > >Does this apply to include_directories. set_target_properties, etc.? > >I found "Paths with spaces - Visual Studio" [3] post which reports a >problem with not quoted paths but David Cole's recommendation [4] >uses add_library with path not quoted. > >I sense, the answer to quote or not to quote might depend on >which CMake command is used. > >Could anyone tell what is the current recommendation? > >[1] >https://cmake.org/Wiki/CMake/Language_Syntax#CMake_splits_arguments_unless_you_use_quotation_marks_or_escapes. >[2] https://stackoverflow.com/a/35853080/151641 >[3] https://public.kitware.com/pipermail/cmake/2012-July/051138.html >[4] https://public.kitware.com/pipermail/cmake/2012-July/051139.html > >Best regards, >-- >Mateusz Loskot, http://mateusz.loskot.net >-- > >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 mateusz at loskot.net Mon Sep 25 07:40:35 2017 From: mateusz at loskot.net (Mateusz Loskot) Date: Mon, 25 Sep 2017 13:40:35 +0200 Subject: [CMake] To quote (path) variables or not, and everywhere? In-Reply-To: References: Message-ID: On 25 September 2017 at 12:57, Oleksii Vilchanskyi wrote: > As usually with CMake, there are no recommendations/guidelines. So, cases with the ammo for CMake sceptics and opponents are not empty, yet. Pity. > However, here's my logic: > > 1) if it's a path, always quote it > 2) if it's not a pat, but inside an if() or any similar core language > structure, quote it as well > 3) don't quote only if you're sure the string can't have spaces - otherwise > do quote > 4) quoting is free and doesn't hurt That sounds reasonable. Thank you. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From MillerHenry at JohnDeere.com Mon Sep 25 10:58:18 2017 From: MillerHenry at JohnDeere.com (Miller Henry) Date: Mon, 25 Sep 2017 14:58:18 +0000 Subject: [CMake] To quote (path) variables or not, and everywhere? In-Reply-To: References: Message-ID: <35F6921410093E4CA40D524BD5C18D4C3E16F996@EDXMB89.jdnet.deere.com> To add fuel to this, I like to argue that paths should not be quoted if at all possible. I find that in many cases where a path is quoted those quotes are being done to work around a bad project structure and you can reorganize your project to get rid of the need for quotes. -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Mateusz Loskot Sent: Monday, September 25, 2017 6:41 AM To: Oleksii Vilchanskyi Cc: cmake at cmake.org Subject: Re: [CMake] To quote (path) variables or not, and everywhere? On 25 September 2017 at 12:57, Oleksii Vilchanskyi wrote: > As usually with CMake, there are no recommendations/guidelines. So, cases with the ammo for CMake sceptics and opponents are not empty, yet. Pity. > However, here's my logic: > > 1) if it's a path, always quote it > 2) if it's not a pat, but inside an if() or any similar core language > structure, quote it as well > 3) don't quote only if you're sure the string can't have spaces - > otherwise do quote > 4) quoting is free and doesn't hurt That sounds reasonable. Thank you. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- 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 mateusz at loskot.net Mon Sep 25 12:15:16 2017 From: mateusz at loskot.net (Mateusz Loskot) Date: Mon, 25 Sep 2017 18:15:16 +0200 Subject: [CMake] To quote (path) variables or not, and everywhere? In-Reply-To: <35F6921410093E4CA40D524BD5C18D4C3E16F996@EDXMB89.jdnet.deere.com> References: <35F6921410093E4CA40D524BD5C18D4C3E16F996@EDXMB89.jdnet.deere.com> Message-ID: On 25 September 2017 at 16:58, Miller Henry wrote: > To add fuel to this, I like to argue that paths should not be quoted if at all possible. I agree. > I find that in many cases where a path is quoted those quotes are being done to > work around a bad project structure and you can reorganize your project to get rid of the need for quotes. What if (Windows) user runs cmake inside c:\my awesome projects\one-superb\build and there is xxx_command(${CMAKE_SOURCE_DIR}) I find lack of CMake standarised conventions and idioms a mistake, softly saying. Best regards -- Mateusz Loskot, http://mateusz.loskot.net From zlynx at acm.org Mon Sep 25 12:40:41 2017 From: zlynx at acm.org (Zan Lynx) Date: Mon, 25 Sep 2017 10:40:41 -0600 Subject: [CMake] To quote (path) variables or not, and everywhere? In-Reply-To: References: <35F6921410093E4CA40D524BD5C18D4C3E16F996@EDXMB89.jdnet.deere.com> Message-ID: <5c625f13-3e9a-9961-ff7e-1dd71b92b227@acm.org> On 09/25/2017 10:15 AM, Mateusz Loskot wrote: > What if (Windows) user runs cmake inside > > c:\my awesome projects\one-superb\build > > and there is xxx_command(${CMAKE_SOURCE_DIR}) Indeed. In my opinion, if software cannot handle arbitrary path names which contain anything then that software is broken. Spaces. Colons. Quotes. Even control characters should work. -- Knowledge is Power -- Power Corrupts Study Hard -- Be Evil From fifteenknots505 at gmail.com Tue Sep 26 16:14:41 2017 From: fifteenknots505 at gmail.com (Martin Weber) Date: Tue, 26 Sep 2017 22:14:41 +0200 Subject: [CMake] Wiki update - CMake with Eclipse Message-ID: <1691017.AdfNlUMPIA@linux> Hi, could someone with the powers to edit the wiki to update the available options [1]? - There is an new option: The cmake4eclipse plugin [2]. It generates the build scripts when you build the project from eclipse -- no need to manually invoke cmake manually with the CDT generator. - CDT itself seems to come with CMake support [5] but I did not try it yet. - CMakeBuilder seems to be dead [3], [4]: No downloads page, apparently no downloads in the past year. - In general, Eclipse users will find plugins supporting cmake in the Eclipse marketplace [6]. Concerning CMake Editors Support [7] in the wiki, I would like to inform that the - CMakeEd project [8] has moved; it is also available in the marketplace [9]. DISCLAIMER: I am the maintainer of cmake4eclipse and CMakeEd. Regards, Martin [1] https://cmake.org/Wiki/CMake:Eclipse_UNIX_Tutorial#CMake_with_Eclipse [2] https://marketplace.eclipse.org/content/cmake4eclipse [3] https://marketplace.eclipse.org/comment/4167#comment-4167 [4] https://marketplace.eclipse.org/content/cmakebuilder#group-metrics-tab [5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=174176 [6] https://marketplace.eclipse.org/search/site/cmake [7] https://cmake.org/Wiki/CMake_Editors_Support [8] https://github.com/15knots/cmakeed/ [9] https://marketplace.eclipse.org/content/cmake-editor -- Cd wrttn wtht vwls s mch trsr. From yegor_sub1 at visionsystems.de Wed Sep 27 01:39:09 2017 From: yegor_sub1 at visionsystems.de (Yegor Yefremov) Date: Wed, 27 Sep 2017 07:39:09 +0200 Subject: [CMake] Support for SWIG and Node.js Message-ID: <623012b4-5187-032b-2a53-ed043f4588e2@visionsystems.de> I've seen, that CMake has updated UseSWIG in version 3.8.x. But it doesn't seem to support the following use case: swig -c++ -javascript -node interface.i src.c I.e. I can define "-c++" via set_property(SOURCE interface.i PROPERTY CPLUSPLUS ON), but how to specify "-node" or "-jsc" or "-v8"? Best regards, Yegor From bruce.david.jones at gmail.com Wed Sep 27 11:04:44 2017 From: bruce.david.jones at gmail.com (Bruce Jones) Date: Wed, 27 Sep 2017 15:04:44 +0000 Subject: [CMake] Support for SWIG and Node.js In-Reply-To: <623012b4-5187-032b-2a53-ed043f4588e2@visionsystems.de> References: <623012b4-5187-032b-2a53-ed043f4588e2@visionsystems.de> Message-ID: I don't have a solution for you, but I agree that this functionality would be incredibly useful! On Wed, 27 Sep 2017 at 01:39 Yegor Yefremov wrote: > I've seen, that CMake has updated UseSWIG in version 3.8.x. But it doesn't > seem to support the following use case: > > swig -c++ -javascript -node interface.i src.c > > I.e. I can define "-c++" via set_property(SOURCE interface.i PROPERTY > CPLUSPLUS ON), but how to specify "-node" or "-jsc" or "-v8"? > > Best regards, > Yegor > -- > > 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 mellery451 at gmail.com Wed Sep 27 11:18:53 2017 From: mellery451 at gmail.com (Michael Ellery) Date: Wed, 27 Sep 2017 08:18:53 -0700 Subject: [CMake] Support for SWIG and Node.js In-Reply-To: <623012b4-5187-032b-2a53-ed043f4588e2@visionsystems.de> References: <623012b4-5187-032b-2a53-ed043f4588e2@visionsystems.de> Message-ID: <447A7D7C-672A-4D4E-8707-C08D112B9374@gmail.com> > On Sep 26, 2017, at 10:39 PM, Yegor Yefremov wrote: > > I've seen, that CMake has updated UseSWIG in version 3.8.x. But it doesn't seem to support the following use case: > > swig -c++ -javascript -node interface.i src.c > > I.e. I can define "-c++" via set_property(SOURCE interface.i PROPERTY CPLUSPLUS ON), but how to specify "-node" or "-jsc" or "-v8"? > > Best regards, > Yegor Have you tried setting CMAKE_SWIG_FLAGS ? https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/UseSWIG.cmake#L41 -Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From mwpowellhtx at gmail.com Wed Sep 27 14:38:38 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Wed, 27 Sep 2017 14:38:38 -0400 Subject: [CMake] CMake GUI "stuck" state Message-ID: Hello, I am trying for the life of me to persuade CMake GUI to process my CMakeLists.txt, but it just does not want to go. It seems to be failing to evaluate obvious things like EXISTS "path/to/submodule/CMakeList.txt", for instance, when I want to test for existence of a Git Submodule with CMake support and I can't seem to figure out what CMake is "thinking", so to speak, how and why it gets stuck like this. Then magically, when I cut and paste the conditions either to their own set (VAR ...), or into an if (), etc, then suddenly the state is "broken" and things begin to process about as I expect them to (or not, if I have bugs further on, for example). Truly annoying and I wonder if anyone else has experienced similar behavior out of CMake GUI? And just how to persuade the GUI to do the right thing when I want it to: i.e. I've edited the CMakeLists.txt and want to test the change. I am using CMake v3.9.2 for Windows at the moment. Cheers, Michael Powell From saadrustam at gmail.com Wed Sep 27 22:27:56 2017 From: saadrustam at gmail.com (Saad Khattak) Date: Thu, 28 Sep 2017 02:27:56 +0000 Subject: [CMake] Compiler output for check_cxx_source_compiles Message-ID: Hello, Is it possible to get the compiler output for check_cxx_source_compiles so that I can check why it failed? Thanks, Saad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwpowellhtx at gmail.com Wed Sep 27 23:17:40 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Wed, 27 Sep 2017 23:17:40 -0400 Subject: [CMake] External Projects: just what are they? Message-ID: Hello, I am trying to understand external projects. What are they? What kind of support is there for them? I found: https://cmake.org/cmake/help/v3.9/module/ExternalProject.html#command:externalproject_add For instance. I have a Git Submodule which I want to support. It represents a core library that is essential for a wrapper piece. If I understand correctly, technically it is an "external" project, but is there support for Git Submodules? And how does that work exactly? Ideally, I'd like to include the Submodule CMakeLists.txt from the context of my wrapper piece, but is this even possible? Thanks! Cheers, Michael Powell From rleigh at codelibre.net Thu Sep 28 06:20:02 2017 From: rleigh at codelibre.net (rleigh at codelibre.net) Date: Thu, 28 Sep 2017 11:20:02 +0100 Subject: [CMake] Compiler output for check_cxx_source_compiles In-Reply-To: References: Message-ID: <67efdd0132c06fa349d6dba265818d70@codelibre.net> On 2017-09-28 03:27, Saad Khattak wrote: > Hello, > > Is it possible to get the compiler output for > check_cxx_source_compiles so that I can check why it failed? It should have been recorded in CMakeFiles/CMakeError.log. Regards, Roger From yegor_sub1 at visionsystems.de Thu Sep 28 08:19:27 2017 From: yegor_sub1 at visionsystems.de (Yegor Yefremov) Date: Thu, 28 Sep 2017 14:19:27 +0200 Subject: [CMake] Support for SWIG and Node.js In-Reply-To: <447A7D7C-672A-4D4E-8707-C08D112B9374@gmail.com> References: <623012b4-5187-032b-2a53-ed043f4588e2@visionsystems.de> <447A7D7C-672A-4D4E-8707-C08D112B9374@gmail.com> Message-ID: On 27.09.2017 17:18, Michael Ellery wrote: >> On Sep 26, 2017, at 10:39 PM, Yegor Yefremov wrote: >> >> I've seen, that CMake has updated UseSWIG in version 3.8.x. But it doesn't seem to support the following use case: >> >> swig -c++ -javascript -node interface.i src.c >> >> I.e. I can define "-c++" via set_property(SOURCE interface.i PROPERTY CPLUSPLUS ON), but how to specify "-node" or "-jsc" or "-v8"? >> >> Best regards, >> Yegor > Have you tried setting CMAKE_SWIG_FLAGS ? > > https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/UseSWIG.cmake#L41 > > -Mike > I think it won't work this way. Because in this case swig can only make a binding cxx file, i.e. I'm not using SWIG_LINK_LIBRARIES. Further steps will be made via npm/node-gyp. That's why I get: CMake Error: CMake can not determine linker language for target: jsonrisc CMake Error: Cannot determine link language for target "jsonrisc". I'll stick for custom command for now. Thanks. Yegor From mwpowellhtx at gmail.com Thu Sep 28 10:06:38 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Thu, 28 Sep 2017 10:06:38 -0400 Subject: [CMake] External Projects: just what are they? In-Reply-To: References: Message-ID: On Wed, Sep 27, 2017 at 11:17 PM, Michael Powell wrote: > Hello, > > I am trying to understand external projects. What are they? What kind > of support is there for them? Based on a couple of the blogs I read about it, I'm not sure this is trying to do too much, but I could be wrong. In my scenario, I simply have a Git Submodule committed to my repository that I want to update, then include/invoke/etc its CMakeLists as an "external project". So at best, maybe I could invoke ExternalProject_Add with GIT_SUBMODULES "${MYPROJ_SOURCE_DIR}/repos/mysubmod". Or am I missing something? Thoughts? Suggestions? > I found: https://cmake.org/cmake/help/v3.9/module/ExternalProject.html#command:externalproject_add > > For instance. > > I have a Git Submodule which I want to support. It represents a core > library that is essential for a wrapper piece. If I understand > correctly, technically it is an "external" project, but is there > support for Git Submodules? And how does that work exactly? > > Ideally, I'd like to include the Submodule CMakeLists.txt from the > context of my wrapper piece, but is this even possible? > > Thanks! > > Cheers, > > Michael Powell From mwpowellhtx at gmail.com Thu Sep 28 12:06:16 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Thu, 28 Sep 2017 12:06:16 -0400 Subject: [CMake] Execute CMake process not working: source directory confusion Message-ID: Hello, This is fairly long, but this is intentional. I message the "Invoking" message. Invoking CMake: C:/Dev/CMake/bin/cmake.exe -G "Visual Studio 14 2015 Win64" -D CMAKE_CONFIGURATION_TYPES:STRING="Debug;Release;MinSizeRel;RelWithDebInfo" -D CMAKE_INSTALL_PREFIX:STRING="G:/Source/Spikes/nanomsg/cppnngswig-testing/build/nng" -D NNG_ENABLE_COVERAGE:BOOL=OFF -D NNG_ENABLE_DOC:BOOL=OFF -D NNG_ENABLE_NNGCAT:BOOL=OFF -D NNG_ENABLE_TESTS:BOOL=OFF -D NNG_ENABLE_TOOLS:BOOL=OFF -D NNG_ENABLE_ZEROTIER:BOOL=OFF Prior to running: execute_process ( COMMAND "${CMAKE_COMMAND}" ${CPPNNG_NNG_CMAKE_OPTIONS} WORKING_DIRECTORY "${GIT_SUBMODULE_NNG_REPO_DIR}" RESULT_VARIABLE CPPNN_NNG_CONFIG_EC OUTPUT_VARIABLE CPPNN_NNG_CONFIG_MSG ) Which is yielding: CMake Error: The source directory "G:/Source/Spikes/nanomsg/cppnngswig-testing/repos/nng/ -G "Visual Studio 14 2015 Win64" -D CMAKE_CONFIGURATION_TYPES:STRING="Debug;Release;MinSizeRel;RelWithDebInfo" -D CMAKE_INSTALL_PREFIX:STRING="G:/Source/Spikes/nanomsg/cppnngswig-testing/build/nng" -D NNG_ENABLE_COVERAGE:BOOL=OFF -D NNG_ENABLE_DOC:BOOL=OFF -D NNG_ENABLE_NNGCAT:BOOL=OFF -D NNG_ENABLE_TESTS:BOOL=OFF -D NNG_ENABLE_TOOLS:BOOL=OFF -D NNG_ENABLE_ZEROTIER:BOOL=OFF" does not exist. The GIT_SUBMODULE_NNG_REPO_DIR is indeed set to G:/Source/Spikes/nanomsg/cppnngswig-testing/repos/nng/, so how can that not be the source directory? But further, how is it seeing the rest of the options as "source directory"? I only got to this point by doing what seems like extreme string gymnastics just to arrive at what I think is an appropriate command. i.e. macro (cppnng_nng_add_cmake_generator GEN) set (CPPNNG_NNG_CMAKE_OPTIONS "${CPPNNG_NNG_CMAKE_OPTIONS} -G \"${GEN}\"") endmacro () macro (cppnng_nng_add_cmake_var OPT TYPE VALUE) set (CPPNNG_NNG_CMAKE_OPTIONS "${CPPNNG_NNG_CMAKE_OPTIONS} -D ${OPT}:${TYPE}=${VALUE}") endmacro () cppnng_nng_add_cmake_generator ("${CMAKE_GENERATOR}") # This is like string GYMNASTICS in order to allow semi-colons to properly pass through. string(REPLACE ";" "\;" REPLACED_TYPES "${CMAKE_CONFIGURATION_TYPES}") cppnng_nng_add_cmake_var ("CMAKE_CONFIGURATION_TYPES" STRING "\"${REPLACED_TYPES}\"") cppnng_nng_add_cmake_var ("CMAKE_INSTALL_PREFIX" STRING "\"${cppnng_SOURCE_DIR}/build/nng\"") cppnng_nng_add_cmake_var ("NNG_ENABLE_COVERAGE" BOOL OFF) cppnng_nng_add_cmake_var ("NNG_ENABLE_DOC" BOOL OFF) cppnng_nng_add_cmake_var ("NNG_ENABLE_NNGCAT" BOOL OFF) cppnng_nng_add_cmake_var ("NNG_ENABLE_TESTS" BOOL OFF) cppnng_nng_add_cmake_var ("NNG_ENABLE_TOOLS" BOOL OFF) # TODO: TBD: at the moment we do not care about ZeroTier, but this could change moving forward. cppnng_nng_add_cmake_var ("NNG_ENABLE_ZEROTIER" BOOL OFF) # message (FATAL_ERROR "options: ${CPPNNG_NNG_CMAKE_OPTIONS}") # message (STATUS "${REPLACED_TYPES}") message (STATUS "Invoking CMake: " "${CMAKE_COMMAND}" ${CPPNNG_NNG_CMAKE_OPTIONS}) Cheers, Michael Powell From mwpowellhtx at gmail.com Thu Sep 28 12:18:56 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Thu, 28 Sep 2017 12:18:56 -0400 Subject: [CMake] Execute CMake process not working: source directory confusion In-Reply-To: References: Message-ID: On Thu, Sep 28, 2017 at 12:06 PM, Michael Powell wrote: > ---------- Forwarded message ---------- > From: Michael Powell > Date: Thu, Sep 28, 2017 at 12:06 PM > Subject: Execute CMake process not working: source directory confusion > To: cmake at cmake.org > > > Hello, > > This is fairly long, but this is intentional. I message the "Invoking" message. Ah, I figured it out! >From the help: cmake [options] So I simply tacked on a "\"${GIT_SUBMODULE_NNG_REPO_DIR}\"" where was expected. Curious CMake would "see" the ENTIRE argument string as "path-to-source" though. Not sure quite what's going on with that, though. The outcome wasn't quite what I expected. How do I specify "path to source", where the source CMakeLists.txt is, properly. And the path to the build, where I want the build environment to land? With this scenario, currently things are landing "in the source directory", which is incorrect, not what I am expecting. Probably my confusion over, prefix directory? Or is "source" directory where things actually land? Thanks! > Invoking CMake: C:/Dev/CMake/bin/cmake.exe -G "Visual Studio 14 2015 > Win64" -D CMAKE_CONFIGURATION_TYPES:STRING="Debug;Release;MinSizeRel;RelWithDebInfo" > -D CMAKE_INSTALL_PREFIX:STRING="G:/Source/Spikes/nanomsg/cppnngswig-testing/build/nng" > -D NNG_ENABLE_COVERAGE:BOOL=OFF -D NNG_ENABLE_DOC:BOOL=OFF -D > NNG_ENABLE_NNGCAT:BOOL=OFF -D NNG_ENABLE_TESTS:BOOL=OFF -D > NNG_ENABLE_TOOLS:BOOL=OFF -D NNG_ENABLE_ZEROTIER:BOOL=OFF > > Prior to running: > > execute_process ( > COMMAND "${CMAKE_COMMAND}" ${CPPNNG_NNG_CMAKE_OPTIONS} > WORKING_DIRECTORY "${GIT_SUBMODULE_NNG_REPO_DIR}" > RESULT_VARIABLE CPPNN_NNG_CONFIG_EC > OUTPUT_VARIABLE CPPNN_NNG_CONFIG_MSG > ) > > Which is yielding: > > CMake Error: The source directory > "G:/Source/Spikes/nanomsg/cppnngswig-testing/repos/nng/ -G "Visual > Studio 14 2015 Win64" -D > CMAKE_CONFIGURATION_TYPES:STRING="Debug;Release;MinSizeRel;RelWithDebInfo" > -D CMAKE_INSTALL_PREFIX:STRING="G:/Source/Spikes/nanomsg/cppnngswig-testing/build/nng" > -D NNG_ENABLE_COVERAGE:BOOL=OFF -D NNG_ENABLE_DOC:BOOL=OFF -D > NNG_ENABLE_NNGCAT:BOOL=OFF -D NNG_ENABLE_TESTS:BOOL=OFF -D > NNG_ENABLE_TOOLS:BOOL=OFF -D NNG_ENABLE_ZEROTIER:BOOL=OFF" does not > exist. > > The GIT_SUBMODULE_NNG_REPO_DIR is indeed set to > G:/Source/Spikes/nanomsg/cppnngswig-testing/repos/nng/, so how can > that not be the source directory? But further, how is it seeing the > rest of the options as "source directory"? > > I only got to this point by doing what seems like extreme string > gymnastics just to arrive at what I think is an appropriate command. > > i.e. > > macro (cppnng_nng_add_cmake_generator GEN) > set (CPPNNG_NNG_CMAKE_OPTIONS "${CPPNNG_NNG_CMAKE_OPTIONS} -G \"${GEN}\"") > endmacro () > > macro (cppnng_nng_add_cmake_var OPT TYPE VALUE) > set (CPPNNG_NNG_CMAKE_OPTIONS "${CPPNNG_NNG_CMAKE_OPTIONS} -D > ${OPT}:${TYPE}=${VALUE}") > endmacro () > > cppnng_nng_add_cmake_generator ("${CMAKE_GENERATOR}") > > # This is like string GYMNASTICS in order to allow semi-colons to > properly pass through. > string(REPLACE ";" "\;" REPLACED_TYPES "${CMAKE_CONFIGURATION_TYPES}") > cppnng_nng_add_cmake_var ("CMAKE_CONFIGURATION_TYPES" STRING > "\"${REPLACED_TYPES}\"") > > cppnng_nng_add_cmake_var ("CMAKE_INSTALL_PREFIX" STRING > "\"${cppnng_SOURCE_DIR}/build/nng\"") > cppnng_nng_add_cmake_var ("NNG_ENABLE_COVERAGE" BOOL OFF) > cppnng_nng_add_cmake_var ("NNG_ENABLE_DOC" BOOL OFF) > cppnng_nng_add_cmake_var ("NNG_ENABLE_NNGCAT" BOOL OFF) > cppnng_nng_add_cmake_var ("NNG_ENABLE_TESTS" BOOL OFF) > cppnng_nng_add_cmake_var ("NNG_ENABLE_TOOLS" BOOL OFF) > # TODO: TBD: at the moment we do not care about ZeroTier, but this > could change moving forward. > cppnng_nng_add_cmake_var ("NNG_ENABLE_ZEROTIER" BOOL OFF) > > # message (FATAL_ERROR "options: ${CPPNNG_NNG_CMAKE_OPTIONS}") > > # message (STATUS "${REPLACED_TYPES}") > > message (STATUS "Invoking CMake: " "${CMAKE_COMMAND}" > ${CPPNNG_NNG_CMAKE_OPTIONS}) > > Cheers, > > Michael Powell From petr.kmoch at gmail.com Thu Sep 28 12:36:14 2017 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 28 Sep 2017 18:36:14 +0200 Subject: [CMake] Execute CMake process not working: source directory confusion In-Reply-To: References: Message-ID: Hi Michael. On 28 September 2017 at 18:18, Michael Powell wrote: > On Thu, Sep 28, 2017 at 12:06 PM, Michael Powell > wrote: > > ---------- Forwarded message ---------- > > From: Michael Powell > > Date: Thu, Sep 28, 2017 at 12:06 PM > > Subject: Execute CMake process not working: source directory confusion > > To: cmake at cmake.org > > > > > > Hello, > > > > This is fairly long, but this is intentional. I message the "Invoking" > message. > > Ah, I figured it out! > > From the help: > > cmake [options] > > So I simply tacked on a "\"${GIT_SUBMODULE_NNG_REPO_DIR}\"" where > was expected. > > Curious CMake would "see" the ENTIRE argument string as > "path-to-source" though. Not sure quite what's going on with that, > though. > That's because you're constructing CPPNNG_NNG_CMAKE_OPTIONS as a single string containing spaces. Spaces *in strings* do not delimit CMake arguments, even if spaces in CMake file syntax do. In other words: foo(a b c) calls 'foo' with 3 arguments: "a", "b", and "c". set(args a b c) foo(${args}) also calls 'foo' with these 3 arguments. However, set(args "a b c") foo(${args}) calls 'foo' with only ONE argument: the string "a b c". You need to drop one level of quoting inside your cppnng_nng_add_* macros. > > The outcome wasn't quite what I expected. How do I specify "path to > source", where the source CMakeLists.txt is, properly. And the path to > the build, where I want the build environment to land? > > With this scenario, currently things are landing "in the source > directory", which is incorrect, not what I am expecting. > Once you solve the quoting issue, you should be able to pass what you want as the source directory. It's effectively the first non-option argument to 'cmake'. The generated buildsystem lands in the working directory from which cmake was invoked. So what you want is this: execute_process( ${CMAKE_COMMAND} ${CPPNNG_NNG_CMAKE_OPTIONS} ${GIT_SUBMODULE_NNG_REPO_DIR} WORKING_DIRECTORY wherever/you/want/the/buildystem/to/end/up ) Petr > > Probably my confusion over, prefix directory? Or is "source" directory > where things actually land? > > Thanks! > > > Invoking CMake: C:/Dev/CMake/bin/cmake.exe -G "Visual Studio 14 2015 > > Win64" -D CMAKE_CONFIGURATION_TYPES:STRING="Debug;Release; > MinSizeRel;RelWithDebInfo" > > -D CMAKE_INSTALL_PREFIX:STRING="G:/Source/Spikes/nanomsg/ > cppnngswig-testing/build/nng" > > -D NNG_ENABLE_COVERAGE:BOOL=OFF -D NNG_ENABLE_DOC:BOOL=OFF -D > > NNG_ENABLE_NNGCAT:BOOL=OFF -D NNG_ENABLE_TESTS:BOOL=OFF -D > > NNG_ENABLE_TOOLS:BOOL=OFF -D NNG_ENABLE_ZEROTIER:BOOL=OFF > > > > Prior to running: > > > > execute_process ( > > COMMAND "${CMAKE_COMMAND}" ${CPPNNG_NNG_CMAKE_OPTIONS} > > WORKING_DIRECTORY "${GIT_SUBMODULE_NNG_REPO_DIR}" > > RESULT_VARIABLE CPPNN_NNG_CONFIG_EC > > OUTPUT_VARIABLE CPPNN_NNG_CONFIG_MSG > > ) > > > > Which is yielding: > > > > CMake Error: The source directory > > "G:/Source/Spikes/nanomsg/cppnngswig-testing/repos/nng/ -G "Visual > > Studio 14 2015 Win64" -D > > CMAKE_CONFIGURATION_TYPES:STRING="Debug;Release; > MinSizeRel;RelWithDebInfo" > > -D CMAKE_INSTALL_PREFIX:STRING="G:/Source/Spikes/nanomsg/ > cppnngswig-testing/build/nng" > > -D NNG_ENABLE_COVERAGE:BOOL=OFF -D NNG_ENABLE_DOC:BOOL=OFF -D > > NNG_ENABLE_NNGCAT:BOOL=OFF -D NNG_ENABLE_TESTS:BOOL=OFF -D > > NNG_ENABLE_TOOLS:BOOL=OFF -D NNG_ENABLE_ZEROTIER:BOOL=OFF" does not > > exist. > > > > The GIT_SUBMODULE_NNG_REPO_DIR is indeed set to > > G:/Source/Spikes/nanomsg/cppnngswig-testing/repos/nng/, so how can > > that not be the source directory? But further, how is it seeing the > > rest of the options as "source directory"? > > > > I only got to this point by doing what seems like extreme string > > gymnastics just to arrive at what I think is an appropriate command. > > > > i.e. > > > > macro (cppnng_nng_add_cmake_generator GEN) > > set (CPPNNG_NNG_CMAKE_OPTIONS "${CPPNNG_NNG_CMAKE_OPTIONS} -G > \"${GEN}\"") > > endmacro () > > > > macro (cppnng_nng_add_cmake_var OPT TYPE VALUE) > > set (CPPNNG_NNG_CMAKE_OPTIONS "${CPPNNG_NNG_CMAKE_OPTIONS} -D > > ${OPT}:${TYPE}=${VALUE}") > > endmacro () > > > > cppnng_nng_add_cmake_generator ("${CMAKE_GENERATOR}") > > > > # This is like string GYMNASTICS in order to allow semi-colons to > > properly pass through. > > string(REPLACE ";" "\;" REPLACED_TYPES "${CMAKE_CONFIGURATION_TYPES}" > ) > > cppnng_nng_add_cmake_var ("CMAKE_CONFIGURATION_TYPES" STRING > > "\"${REPLACED_TYPES}\"") > > > > cppnng_nng_add_cmake_var ("CMAKE_INSTALL_PREFIX" STRING > > "\"${cppnng_SOURCE_DIR}/build/nng\"") > > cppnng_nng_add_cmake_var ("NNG_ENABLE_COVERAGE" BOOL OFF) > > cppnng_nng_add_cmake_var ("NNG_ENABLE_DOC" BOOL OFF) > > cppnng_nng_add_cmake_var ("NNG_ENABLE_NNGCAT" BOOL OFF) > > cppnng_nng_add_cmake_var ("NNG_ENABLE_TESTS" BOOL OFF) > > cppnng_nng_add_cmake_var ("NNG_ENABLE_TOOLS" BOOL OFF) > > # TODO: TBD: at the moment we do not care about ZeroTier, but this > > could change moving forward. > > cppnng_nng_add_cmake_var ("NNG_ENABLE_ZEROTIER" BOOL OFF) > > > > # message (FATAL_ERROR "options: ${CPPNNG_NNG_CMAKE_OPTIONS}") > > > > # message (STATUS "${REPLACED_TYPES}") > > > > message (STATUS "Invoking CMake: " "${CMAKE_COMMAND}" > > ${CPPNNG_NNG_CMAKE_OPTIONS}) > > > > Cheers, > > > > Michael Powell > -- > > 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 mateusz at loskot.net Thu Sep 28 12:49:47 2017 From: mateusz at loskot.net (Mateusz Loskot) Date: Thu, 28 Sep 2017 18:49:47 +0200 Subject: [CMake] To quote (path) variables or not, and everywhere? In-Reply-To: <5c625f13-3e9a-9961-ff7e-1dd71b92b227@acm.org> References: <35F6921410093E4CA40D524BD5C18D4C3E16F996@EDXMB89.jdnet.deere.com> <5c625f13-3e9a-9961-ff7e-1dd71b92b227@acm.org> Message-ID: On 25 September 2017 at 18:40, Zan Lynx wrote: > On 09/25/2017 10:15 AM, Mateusz Loskot wrote: >> What if (Windows) user runs cmake inside >> >> c:\my awesome projects\one-superb\build >> >> and there is xxx_command(${CMAKE_SOURCE_DIR}) > > Indeed. > > In my opinion, if software cannot handle arbitrary path names which > contain anything then that software is broken. This is no good. As CMake advocate, I've noticed traces of disappointment accumulated over the years. In CMake 2 times, that was a small pill to swallow. In CMake 3.9, it's very frustrating. Idioms, conventions, PEP kind of papers, whatever is a must. Niall Douglas crafted a quick CMake'ification demo for Boost [1] and from the short README one can learn more about **how** to properly develop a good build setup with CMake than from the CMake documentation. [1] https://github.com/ned14/boost-bmv-cmake Best regards, -- Mateusz Loskot, http://mateusz.loskot.net From mwpowellhtx at gmail.com Thu Sep 28 13:01:11 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Thu, 28 Sep 2017 13:01:11 -0400 Subject: [CMake] Execute CMake process not working: source directory confusion In-Reply-To: References: Message-ID: On Thu, Sep 28, 2017 at 12:53 PM, Michael Powell wrote: > On Thu, Sep 28, 2017 at 12:36 PM, Petr Kmoch wrote: >> Hi Michael. >> >> On 28 September 2017 at 18:18, Michael Powell wrote: >>> >>> On Thu, Sep 28, 2017 at 12:06 PM, Michael Powell >>> wrote: >>> > ---------- Forwarded message ---------- >>> > From: Michael Powell >>> > Date: Thu, Sep 28, 2017 at 12:06 PM >>> > Subject: Execute CMake process not working: source directory confusion >>> > To: cmake at cmake.org >>> > >>> > >>> > Hello, >>> > >>> > This is fairly long, but this is intentional. I message the "Invoking" >>> > message. >>> >>> Ah, I figured it out! >>> >>> From the help: >>> >>> cmake [options] >>> >>> So I simply tacked on a "\"${GIT_SUBMODULE_NNG_REPO_DIR}\"" where >>> was expected. >>> >>> Curious CMake would "see" the ENTIRE argument string as >>> "path-to-source" though. Not sure quite what's going on with that, >>> though. >> >> >> That's because you're constructing CPPNNG_NNG_CMAKE_OPTIONS as a single >> string containing spaces. Spaces *in strings* do not delimit CMake >> arguments, even if spaces in CMake file syntax do. In other words: >> >> foo(a b c) >> >> calls 'foo' with 3 arguments: "a", "b", and "c". >> >> set(args a b c) >> foo(${args}) >> >> also calls 'foo' with these 3 arguments. >> >> However, >> >> set(args "a b c") >> foo(${args}) >> >> calls 'foo' with only ONE argument: the string "a b c". >> >> You need to drop one level of quoting inside your cppnng_nng_add_* macros. >> >>> >>> >>> The outcome wasn't quite what I expected. How do I specify "path to >>> source", where the source CMakeLists.txt is, properly. And the path to >>> the build, where I want the build environment to land? >>> >>> With this scenario, currently things are landing "in the source >>> directory", which is incorrect, not what I am expecting. >> >> >> Once you solve the quoting issue, you should be able to pass what you want >> as the source directory. It's effectively the first non-option argument to >> 'cmake'. >> >> The generated buildsystem lands in the working directory from which cmake >> was invoked. So what you want is this: >> >> execute_process( >> ${CMAKE_COMMAND} ${CPPNNG_NNG_CMAKE_OPTIONS} ${GIT_SUBMODULE_NNG_REPO_DIR} >> WORKING_DIRECTORY wherever/you/want/the/buildystem/to/end/up >> ) > > Thanks for that insight! > > I ended up with something like this: > > message (STATUS "Invoking CMake: \"${CMAKE_COMMAND}\" > ${CPPNNG_NNG_CMAKE_OPTIONS} \"${GIT_SUBMODULE_NNG_REPO_DIR}\"") > > execute_process ( > COMMAND "\"${CMAKE_COMMAND}\" ${CPPNNG_NNG_CMAKE_OPTIONS} > \"${GIT_SUBMODULE_NNG_REPO_DIR}\"" > WORKING_DIRECTORY "${GIT_SUBMODULE_NNG_REPO_DIR}" > RESULT_VARIABLE CPPNN_NNG_CONFIG_EC > OUTPUT_VARIABLE CPPNN_NNG_CONFIG_MSG > ) > > But which is now yielding an output message " (Access is denied)" (no EC). Out of curiosity, how strong is the file lock CMake is maintaining internally? i.e. with allowance for shared read? In this instance, I am running the parent CMake process from CMake GUI, which it then invokes another instance of CMake on the submodule, or at least that's the intention. If that's a non-starter in its current form, no big deal; worst case scenario I can take precautions to include the submodule source at strategic points in my consumer solution. > Console output: > > Invoking CMake: "C:/Dev/CMake/bin/cmake.exe" -G "Visual Studio 14 2015 > Win64" --build "G:/Source/Spikes/nanomsg/cppnngswig-testing/build/nng" > -D CMAKE_CONFIGURATION_TYPES:STRING="Debug\;Release\;MinSizeRel\;RelWithDebInfo" > -D CMAKE_INSTALL_PREFIX:STRING="G:/Source/Spikes/nanomsg/cppnngswig-testing/build/nng" > -D NNG_ENABLE_COVERAGE:BOOL=OFF -D NNG_ENABLE_DOC:BOOL=OFF -D > NNG_ENABLE_NNGCAT:BOOL=OFF -D NNG_ENABLE_TESTS:BOOL=OFF -D > NNG_ENABLE_TOOLS:BOOL=OFF -D NNG_ENABLE_ZEROTIER:BOOL=OFF > "G:/Source/Spikes/nanomsg/cppnngswig-testing/repos/nng" > >> Petr >> >>> >>> >>> Probably my confusion over, prefix directory? Or is "source" directory >>> where things actually land? >>> >>> Thanks! >>> >>> > Invoking CMake: C:/Dev/CMake/bin/cmake.exe -G "Visual Studio 14 2015 >>> > Win64" -D >>> > CMAKE_CONFIGURATION_TYPES:STRING="Debug;Release;MinSizeRel;RelWithDebInfo" >>> > -D >>> > CMAKE_INSTALL_PREFIX:STRING="G:/Source/Spikes/nanomsg/cppnngswig-testing/build/nng" >>> > -D NNG_ENABLE_COVERAGE:BOOL=OFF -D NNG_ENABLE_DOC:BOOL=OFF -D >>> > NNG_ENABLE_NNGCAT:BOOL=OFF -D NNG_ENABLE_TESTS:BOOL=OFF -D >>> > NNG_ENABLE_TOOLS:BOOL=OFF -D NNG_ENABLE_ZEROTIER:BOOL=OFF >>> > >>> > Prior to running: >>> > >>> > execute_process ( >>> > COMMAND "${CMAKE_COMMAND}" ${CPPNNG_NNG_CMAKE_OPTIONS} >>> > WORKING_DIRECTORY "${GIT_SUBMODULE_NNG_REPO_DIR}" >>> > RESULT_VARIABLE CPPNN_NNG_CONFIG_EC >>> > OUTPUT_VARIABLE CPPNN_NNG_CONFIG_MSG >>> > ) >>> > >>> > Which is yielding: >>> > >>> > CMake Error: The source directory >>> > "G:/Source/Spikes/nanomsg/cppnngswig-testing/repos/nng/ -G "Visual >>> > Studio 14 2015 Win64" -D >>> > >>> > CMAKE_CONFIGURATION_TYPES:STRING="Debug;Release;MinSizeRel;RelWithDebInfo" >>> > -D >>> > CMAKE_INSTALL_PREFIX:STRING="G:/Source/Spikes/nanomsg/cppnngswig-testing/build/nng" >>> > -D NNG_ENABLE_COVERAGE:BOOL=OFF -D NNG_ENABLE_DOC:BOOL=OFF -D >>> > NNG_ENABLE_NNGCAT:BOOL=OFF -D NNG_ENABLE_TESTS:BOOL=OFF -D >>> > NNG_ENABLE_TOOLS:BOOL=OFF -D NNG_ENABLE_ZEROTIER:BOOL=OFF" does not >>> > exist. >>> > >>> > The GIT_SUBMODULE_NNG_REPO_DIR is indeed set to >>> > G:/Source/Spikes/nanomsg/cppnngswig-testing/repos/nng/, so how can >>> > that not be the source directory? But further, how is it seeing the >>> > rest of the options as "source directory"? >>> > >>> > I only got to this point by doing what seems like extreme string >>> > gymnastics just to arrive at what I think is an appropriate command. >>> > >>> > i.e. >>> > >>> > macro (cppnng_nng_add_cmake_generator GEN) >>> > set (CPPNNG_NNG_CMAKE_OPTIONS "${CPPNNG_NNG_CMAKE_OPTIONS} -G >>> > \"${GEN}\"") >>> > endmacro () >>> > >>> > macro (cppnng_nng_add_cmake_var OPT TYPE VALUE) >>> > set (CPPNNG_NNG_CMAKE_OPTIONS "${CPPNNG_NNG_CMAKE_OPTIONS} -D >>> > ${OPT}:${TYPE}=${VALUE}") >>> > endmacro () >>> > >>> > cppnng_nng_add_cmake_generator ("${CMAKE_GENERATOR}") >>> > >>> > # This is like string GYMNASTICS in order to allow semi-colons to >>> > properly pass through. >>> > string(REPLACE ";" "\;" REPLACED_TYPES >>> > "${CMAKE_CONFIGURATION_TYPES}") >>> > cppnng_nng_add_cmake_var ("CMAKE_CONFIGURATION_TYPES" STRING >>> > "\"${REPLACED_TYPES}\"") >>> > >>> > cppnng_nng_add_cmake_var ("CMAKE_INSTALL_PREFIX" STRING >>> > "\"${cppnng_SOURCE_DIR}/build/nng\"") >>> > cppnng_nng_add_cmake_var ("NNG_ENABLE_COVERAGE" BOOL OFF) >>> > cppnng_nng_add_cmake_var ("NNG_ENABLE_DOC" BOOL OFF) >>> > cppnng_nng_add_cmake_var ("NNG_ENABLE_NNGCAT" BOOL OFF) >>> > cppnng_nng_add_cmake_var ("NNG_ENABLE_TESTS" BOOL OFF) >>> > cppnng_nng_add_cmake_var ("NNG_ENABLE_TOOLS" BOOL OFF) >>> > # TODO: TBD: at the moment we do not care about ZeroTier, but this >>> > could change moving forward. >>> > cppnng_nng_add_cmake_var ("NNG_ENABLE_ZEROTIER" BOOL OFF) >>> > >>> > # message (FATAL_ERROR "options: ${CPPNNG_NNG_CMAKE_OPTIONS}") >>> > >>> > # message (STATUS "${REPLACED_TYPES}") >>> > >>> > message (STATUS "Invoking CMake: " "${CMAKE_COMMAND}" >>> > ${CPPNNG_NNG_CMAKE_OPTIONS}) >>> > >>> > Cheers, >>> > >>> > Michael Powell >>> -- >>> >>> 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 irwin at beluga.phys.uvic.ca Thu Sep 28 12:53:17 2017 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Thu, 28 Sep 2017 09:53:17 -0700 (PDT) Subject: [CMake] Execute CMake process not working: source directory confusion In-Reply-To: References: Message-ID: On 2017-09-28 12:18-0400 Michael Powell wrote: > The outcome wasn't quite what I expected. How do I specify "path to > source", where the source CMakeLists.txt is, properly. And the path to > the build, where I want the build environment to land? > > With this scenario, currently things are landing "in the source > directory", which is incorrect, not what I am expecting. > > Probably my confusion over, prefix directory? Or is "source" directory > where things actually land? The rule is the directory where you invoke cmake is always the top-level directory of the build tree. I would strongly advise that should initially be an empty directory so you don't mix cmake-generated files with anything else in that directory. In my opinion, one of the warts of CMake is it allows you to invoke cmake from the top-level directory of the source tree (e.g., using "cmake ." which means the top-level directory of the build tree is identical to the top-level directory of the source tree. This invocation (which unfortunately is often advocated by naive CMake users, and, at least in the old days, by the CMake documentation itself) scatters cmake-generated files all over your source tree which makes it extremely difficult to restore your source tree to pristine condition (without removing the whole source tree and starting over with that using git clone, unpacking a tarball or whatever). And, of course, once you have designated the build-tree top-level, CMake doesn't allow you to change it unless you start fresh. In sum, to get out of this mess, you must both restore your source tree to pristine condition, and invoke cmake from an initially empty directory which will then become the top-level of your build tree from then on. 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 petr.kmoch at gmail.com Thu Sep 28 13:42:33 2017 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Thu, 28 Sep 2017 19:42:33 +0200 Subject: [CMake] Execute CMake process not working: source directory confusion In-Reply-To: References: Message-ID: (Added list back to copy) On 28 September 2017 at 18:53, Michael Powell wrote: > [...] > >> > >> Curious CMake would "see" the ENTIRE argument string as > >> "path-to-source" though. Not sure quite what's going on with that, > >> though. > > > > > > That's because you're constructing CPPNNG_NNG_CMAKE_OPTIONS as a single > > string containing spaces. Spaces *in strings* do not delimit CMake > > arguments, even if spaces in CMake file syntax do. In other words: > > > > foo(a b c) > > > > calls 'foo' with 3 arguments: "a", "b", and "c". > > > > set(args a b c) > > foo(${args}) > > > > also calls 'foo' with these 3 arguments. > > > > However, > > > > set(args "a b c") > > foo(${args}) > > > > calls 'foo' with only ONE argument: the string "a b c". > > > > You need to drop one level of quoting inside your cppnng_nng_add_* > macros. > > > [...] > > Thanks for that insight! > > I ended up with something like this: > > message (STATUS "Invoking CMake: \"${CMAKE_COMMAND}\" > ${CPPNNG_NNG_CMAKE_OPTIONS} \"${GIT_SUBMODULE_NNG_REPO_DIR}\"") > > execute_process ( > COMMAND "\"${CMAKE_COMMAND}\" ${CPPNNG_NNG_CMAKE_OPTIONS} > \"${GIT_SUBMODULE_NNG_REPO_DIR}\"" > WORKING_DIRECTORY "${GIT_SUBMODULE_NNG_REPO_DIR}" > RESULT_VARIABLE CPPNN_NNG_CONFIG_EC > OUTPUT_VARIABLE CPPNN_NNG_CONFIG_MSG > ) > > But which is now yielding an output message " (Access is denied)" (no EC). > > Console output: > > Invoking CMake: "C:/Dev/CMake/bin/cmake.exe" -G "Visual Studio 14 2015 > Win64" --build "G:/Source/Spikes/nanomsg/cppnngswig-testing/build/nng" > -D CMAKE_CONFIGURATION_TYPES:STRING="Debug\;Release\; > MinSizeRel\;RelWithDebInfo" > -D CMAKE_INSTALL_PREFIX:STRING="G:/Source/Spikes/nanomsg/ > cppnngswig-testing/build/nng" > -D NNG_ENABLE_COVERAGE:BOOL=OFF -D NNG_ENABLE_DOC:BOOL=OFF -D > NNG_ENABLE_NNGCAT:BOOL=OFF -D NNG_ENABLE_TESTS:BOOL=OFF -D > NNG_ENABLE_TOOLS:BOOL=OFF -D NNG_ENABLE_ZEROTIER:BOOL=OFF > "G:/Source/Spikes/nanomsg/cppnngswig-testing/repos/nng" > You're still putting quotes where there shouldn't be any. Look at this: COMMAND "\"${CMAKE_COMMAND}\" ${CPPNNG_NNG_CMAKE_OPTIONS} \"${GIT_SUBMODULE_NNG_REPO_DIR}\"" Since the entire argument to COMMAND is in quotes, it's interpreted as the *name* of the command you want to execute. What you want is to pass multiple arguments to execute_process: one for the binary, and one for each command-line argument to it. CMake will take care of proper escpaing for you. So your code should look like this: execute_process ( COMMAND "${CMAKE_COMMAND}" ${CPPNNG_NNG_CMAKE_OPTIONS} "${GIT_SUBMODULE_NNG_REPO_DIR}" WORKING_DIRECTORY "${GIT_SUBMODULE_NNG_REPO_DIR}" RESULT_VARIABLE CPPNN_NNG_CONFIG_EC OUTPUT_VARIABLE CPPNN_NNG_CONFIG_MSG ) In fact, you can even drop the quotes around the variable dereferncing if you want to; they're only necessary if the arguments can contain a semi-colon (as that would split them into multiple CMake arguments). But they're safe to keep. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwpowellhtx at gmail.com Thu Sep 28 13:46:08 2017 From: mwpowellhtx at gmail.com (Michael Powell) Date: Thu, 28 Sep 2017 13:46:08 -0400 Subject: [CMake] Execute CMake process not working: source directory confusion In-Reply-To: References: Message-ID: On Thu, Sep 28, 2017 at 1:42 PM, Petr Kmoch wrote: > (Added list back to copy) > > On 28 September 2017 at 18:53, Michael Powell wrote: >> >> [...] >> >> >> >> Curious CMake would "see" the ENTIRE argument string as >> >> "path-to-source" though. Not sure quite what's going on with that, >> >> though. >> > >> > >> > That's because you're constructing CPPNNG_NNG_CMAKE_OPTIONS as a single >> > string containing spaces. Spaces *in strings* do not delimit CMake >> > arguments, even if spaces in CMake file syntax do. In other words: >> > >> > foo(a b c) >> > >> > calls 'foo' with 3 arguments: "a", "b", and "c". >> > >> > set(args a b c) >> > foo(${args}) >> > >> > also calls 'foo' with these 3 arguments. >> > >> > However, >> > >> > set(args "a b c") >> > foo(${args}) >> > >> > calls 'foo' with only ONE argument: the string "a b c". >> > >> > You need to drop one level of quoting inside your cppnng_nng_add_* >> > macros. >> > >> [...] >> >> Thanks for that insight! >> >> I ended up with something like this: >> >> message (STATUS "Invoking CMake: \"${CMAKE_COMMAND}\" >> ${CPPNNG_NNG_CMAKE_OPTIONS} \"${GIT_SUBMODULE_NNG_REPO_DIR}\"") >> >> execute_process ( >> COMMAND "\"${CMAKE_COMMAND}\" ${CPPNNG_NNG_CMAKE_OPTIONS} >> \"${GIT_SUBMODULE_NNG_REPO_DIR}\"" >> WORKING_DIRECTORY "${GIT_SUBMODULE_NNG_REPO_DIR}" >> RESULT_VARIABLE CPPNN_NNG_CONFIG_EC >> OUTPUT_VARIABLE CPPNN_NNG_CONFIG_MSG >> ) >> >> But which is now yielding an output message " (Access is denied)" (no EC). >> >> Console output: >> >> Invoking CMake: "C:/Dev/CMake/bin/cmake.exe" -G "Visual Studio 14 2015 >> Win64" --build "G:/Source/Spikes/nanomsg/cppnngswig-testing/build/nng" >> -D >> CMAKE_CONFIGURATION_TYPES:STRING="Debug\;Release\;MinSizeRel\;RelWithDebInfo" >> -D >> CMAKE_INSTALL_PREFIX:STRING="G:/Source/Spikes/nanomsg/cppnngswig-testing/build/nng" >> -D NNG_ENABLE_COVERAGE:BOOL=OFF -D NNG_ENABLE_DOC:BOOL=OFF -D >> NNG_ENABLE_NNGCAT:BOOL=OFF -D NNG_ENABLE_TESTS:BOOL=OFF -D >> NNG_ENABLE_TOOLS:BOOL=OFF -D NNG_ENABLE_ZEROTIER:BOOL=OFF >> "G:/Source/Spikes/nanomsg/cppnngswig-testing/repos/nng" > > > You're still putting quotes where there shouldn't be any. Look at this: > > COMMAND "\"${CMAKE_COMMAND}\" ${CPPNNG_NNG_CMAKE_OPTIONS} > \"${GIT_SUBMODULE_NNG_REPO_DIR}\"" > > Since the entire argument to COMMAND is in quotes, it's interpreted as the > *name* of the command you want to execute. What you want is to pass multiple > arguments to execute_process: one for the binary, and one for each > command-line argument to it. CMake will take care of proper escpaing for > you. So your code should look like this: Ah ok... I see it now. And the result is much MUCH better. Thanks! > execute_process ( > COMMAND "${CMAKE_COMMAND}" ${CPPNNG_NNG_CMAKE_OPTIONS} > "${GIT_SUBMODULE_NNG_REPO_DIR}" > WORKING_DIRECTORY "${GIT_SUBMODULE_NNG_REPO_DIR}" > RESULT_VARIABLE CPPNN_NNG_CONFIG_EC > OUTPUT_VARIABLE CPPNN_NNG_CONFIG_MSG > ) > > In fact, you can even drop the quotes around the variable dereferncing if > you want to; they're only necessary if the arguments can contain a > semi-colon (as that would split them into multiple CMake arguments). But > they're safe to keep. > > Petr > From aluaces at udc.es Fri Sep 29 07:40:36 2017 From: aluaces at udc.es (Alberto Luaces) Date: Fri, 29 Sep 2017 13:40:36 +0200 Subject: [CMake] Transitive dependencies of header libraries Message-ID: <87fub5spfv.fsf@eps142.cdf.udc.es> Hi, I have a header-only library which itself depends on another header-only library: ``` add_library(myheaderonlylib INTERFACE) target_include_directories(myheaderonlylib INTERFACE $ ) target_link_libraries(myheaderonlylib INTERFACE Eigen3::Eigen) install(TARGETS myheaderonlylib EXPORT myheaderonlylib-config DESTINATION include) install(EXPORT myheaderonlylib-config DESTINATION share/myheaderonlylib/cmake) ``` When a third library links to "myheaderonlylib", cmake adds the target Eigen3::Eigen, but since it is not known there, the configuration step fails. I understand this is a difficult one, but I wonder if there is any other way instead of finding Eigen3::Eigen from the client package. Thanks! -- Alberto From pfultz2 at yahoo.com Fri Sep 29 15:26:51 2017 From: pfultz2 at yahoo.com (paul) Date: Fri, 29 Sep 2017 14:26:51 -0500 Subject: [CMake] Transitive dependencies of header libraries In-Reply-To: <87fub5spfv.fsf@eps142.cdf.udc.es> References: <87fub5spfv.fsf@eps142.cdf.udc.es> Message-ID: <1506713211.3965.261.camel@yahoo.com> You need to do add the dependencies in the config.cmake file, which means you need to seperate the config and export file. So in your CMakeLists.txt, you would do: install(TARGETS myheaderonlylib EXPORT myheaderonlylib-targets DESTINATION include) install(EXPORT myheaderonlylib-targets DESTINATION share/myheaderonlylib/cmake) install(FILES myheaderonlylib-config.cmake DESTINATION share/myheaderonlylib/cmake) And then in myheaderonlylib-config.cmake you would write: include(CMakeFindDependencyMacro) find_dependency(Eigen) include("${CMAKE_CURRENT_LIST_DIR}/myheaderonlylib-targets.cmake") This calls `find_dependency`, which is just a wrapper around `find_package` that makes it more friendly inside of package config cmake file. This the user just needs to call `find_package(myheaderonlylib)` and Eigen will be found automatically. On Fri, 2017-09-29 at 13:40 +0200, Alberto Luaces wrote: > Hi, I have a header-only library which itself depends on another > header-only library: > > ``` > add_library(myheaderonlylib INTERFACE) > > target_include_directories(myheaderonlylib INTERFACE > ? $ > ? ) > > target_link_libraries(myheaderonlylib INTERFACE Eigen3::Eigen) > > install(TARGETS myheaderonlylib EXPORT myheaderonlylib-config DESTINATION > include) > > install(EXPORT myheaderonlylib-config DESTINATION > share/myheaderonlylib/cmake) > ``` > > When a third library links to "myheaderonlylib", cmake adds the target > ?Eigen3::Eigen, but since it is not known there, the configuration step > ?fails. > > I understand this is a difficult one, but I wonder if there is any other > way instead of finding Eigen3::Eigen from the client package. > > Thanks! > > --? > Alberto > .