From post at hendrik-sattler.de Sat Nov 1 05:07:01 2014 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Sat, 01 Nov 2014 10:07:01 +0100 Subject: [CMake] Copying DLLs to output directory In-Reply-To: <5453E85B.7060808@classdesign.com> References: <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net> <5453E85B.7060808@classdesign.com> Message-ID: <5D6F4EA0-1B07-407F-97BE-FF5ED2181E79@hendrik-sattler.de> Am 31. Oktober 2014 20:51:55 MEZ, schrieb Bill Somerville : >On 31/10/2014 19:42, Michael Jackson wrote: >> Never said it was pretty, but here is the code I use for Qt4 based >projects. I think I had to revamp a lot of this for Qt5. I call it like >so: >> >> CMP_COPY_QT4_RUNTIME_LIBRARIES( "QtCore;QtGui;QtNetwork") >This seems an awful lot of messing around when qt-project.org already >dump all the debug and release libraries into the installation bin >directory so all you need is to ensure that the installation bin >directory is on your PATH when you run or debug executables, just like >you have to to build using the tools like moc, qmake, dumpcpp, qrc, >etc.. > >IMHO put he Qt bin directory on PATH for debugging and use BundleUtils >FixupBundle to make deployable kits. No need to do any manual or >scripted copying of libraries at all. But you have to be very careful when creating this PATH. Order is important or you will likely catch the wrong Qt release libraries. After all, even CMake ships Qt dlls in its installation directory. And other tools that are user during build might also do. Additionally, CMake is not able to set this up automatically in VS. Also, when the Qt dlls can be found so easily, why doesn't FindQt4 do it? HS From mike.jackson at bluequartz.net Sat Nov 1 09:54:55 2014 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Sat, 1 Nov 2014 09:54:55 -0400 Subject: [CMake] Copying DLLs to output directory In-Reply-To: <5453E85B.7060808@classdesign.com> References: <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net> <5453E85B.7060808@classdesign.com> Message-ID: <5EDFC072-09E7-444D-9C72-E2A9E06AA6F8@bluequartz.net> The thing I could never figure out is how to set the PATH for the Visual Studio Project/Solution. That is what I need. If I only had a single version of Qt on my system it would be very straight forward. Just set the PATH environment variable using the standard windows mechanism for doing that and you are set. Alas, that isn't the case. I have at least 4 different versions of Qt on my system at any one time. So tell me how to, in the CMake file, to tell the Visual Studio generated solution to add C:/Developer/x64/Qt-4.8.6/bin to my PATH and I would gladly rip out all my code. I also need a mechanism to "install" all those DLL's into an redistributable package (which my scripts ensure). Maybe I am just that far behind the times. One of those "if it aint broke don't fix it". Looking forward to the answer Mike Jackson On Oct 31, 2014, at 3:51 PM, Bill Somerville wrote: > On 31/10/2014 19:42, Michael Jackson wrote: >> Never said it was pretty, but here is the code I use for Qt4 based projects. I think I had to revamp a lot of this for Qt5. I call it like so: >> >> CMP_COPY_QT4_RUNTIME_LIBRARIES( "QtCore;QtGui;QtNetwork") > This seems an awful lot of messing around when qt-project.org already dump all the debug and release libraries into the installation bin directory so all you need is to ensure that the installation bin directory is on your PATH when you run or debug executables, just like you have to to build using the tools like moc, qmake, dumpcpp, qrc, etc.. > > IMHO put he Qt bin directory on PATH for debugging and use BundleUtils FixupBundle to make deployable kits. No need to do any manual or scripted copying of libraries at all. > > Regards > Bill. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From mike.jackson at bluequartz.net Sat Nov 1 10:02:23 2014 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Sat, 1 Nov 2014 10:02:23 -0400 Subject: [CMake] Copying DLLs to output directory In-Reply-To: <5D6F4EA0-1B07-407F-97BE-FF5ED2181E79@hendrik-sattler.de> References: <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net> <5453E85B.7060808@classdesign.com> <5D6F4EA0-1B07-407F-97BE-FF5ED2181E79@hendrik-sattler.de> Message-ID: <7D954CD2-2037-44E2-8D8A-1247F48568C5@bluequartz.net> I agree that if the FindQt4 would enumerate the DLLs that would be great and simply get ride a bunch of this home-brew code that I have to write for each library. Getting the Plugins would also be a great help also since I have to grab a few of those. the FindQt5 module does this I think. Cheers Mike Jackson On Nov 1, 2014, at 5:07 AM, Hendrik Sattler wrote: > > > Am 31. Oktober 2014 20:51:55 MEZ, schrieb Bill Somerville : >> On 31/10/2014 19:42, Michael Jackson wrote: >>> Never said it was pretty, but here is the code I use for Qt4 based >> projects. I think I had to revamp a lot of this for Qt5. I call it like >> so: >>> >>> CMP_COPY_QT4_RUNTIME_LIBRARIES( "QtCore;QtGui;QtNetwork") >> This seems an awful lot of messing around when qt-project.org already >> dump all the debug and release libraries into the installation bin >> directory so all you need is to ensure that the installation bin >> directory is on your PATH when you run or debug executables, just like >> you have to to build using the tools like moc, qmake, dumpcpp, qrc, >> etc.. >> >> IMHO put he Qt bin directory on PATH for debugging and use BundleUtils >> FixupBundle to make deployable kits. No need to do any manual or >> scripted copying of libraries at all. > > But you have to be very careful when creating this PATH. Order is important or you will likely catch the wrong Qt release libraries. After all, even CMake ships Qt dlls in its installation directory. And other tools that are user during build might also do. > > Additionally, CMake is not able to set this up automatically in VS. > > Also, when the Qt dlls can be found so easily, why doesn't FindQt4 do it? > > HS > > -- > > 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 bill at classdesign.com Sat Nov 1 10:07:56 2014 From: bill at classdesign.com (Bill Somerville) Date: Sat, 01 Nov 2014 14:07:56 +0000 Subject: [CMake] Copying DLLs to output directory In-Reply-To: <7D954CD2-2037-44E2-8D8A-1247F48568C5@bluequartz.net> References: <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net> <5453E85B.7060808@classdesign.com> <5D6F4EA0-1B07-407F-97BE-FF5ED2181E79@hendrik-sattler.de> <7D954CD2-2037-44E2-8D8A-1247F48568C5@bluequartz.net> Message-ID: <5454E93C.8020304@classdesign.com> On 01/11/2014 14:02, Michael Jackson wrote: Hi Michael, > I agree that if the FindQt4 would enumerate the DLLs that would be great and simply get ride a bunch of this home-brew code that I have to write for each library. Getting the Plugins would also be a great help also since I have to grab a few of those. the FindQt5 module does this I think. A standard Qt installation is hard coded to use the plugins in the installation tree. If you have no qt.conf file override the default behaviour works just fine for debugging and testing without moving the plugins at all. > > > Cheers > Mike Jackson Regards Bill. > > On Nov 1, 2014, at 5:07 AM, Hendrik Sattler wrote: > >> >> Am 31. Oktober 2014 20:51:55 MEZ, schrieb Bill Somerville : >>> On 31/10/2014 19:42, Michael Jackson wrote: >>>> Never said it was pretty, but here is the code I use for Qt4 based >>> projects. I think I had to revamp a lot of this for Qt5. I call it like >>> so: >>>> CMP_COPY_QT4_RUNTIME_LIBRARIES( "QtCore;QtGui;QtNetwork") >>> This seems an awful lot of messing around when qt-project.org already >>> dump all the debug and release libraries into the installation bin >>> directory so all you need is to ensure that the installation bin >>> directory is on your PATH when you run or debug executables, just like >>> you have to to build using the tools like moc, qmake, dumpcpp, qrc, >>> etc.. >>> >>> IMHO put he Qt bin directory on PATH for debugging and use BundleUtils >>> FixupBundle to make deployable kits. No need to do any manual or >>> scripted copying of libraries at all. >> But you have to be very careful when creating this PATH. Order is important or you will likely catch the wrong Qt release libraries. After all, even CMake ships Qt dlls in its installation directory. And other tools that are user during build might also do. >> >> Additionally, CMake is not able to set this up automatically in VS. >> >> Also, when the Qt dlls can be found so easily, why doesn't FindQt4 do it? >> >> HS >> >> -- >> >> 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 cory.quammen at kitware.com Sat Nov 1 10:15:44 2014 From: cory.quammen at kitware.com (Cory Quammen) Date: Sat, 1 Nov 2014 10:15:44 -0400 Subject: [CMake] Copying DLLs to output directory In-Reply-To: <5EDFC072-09E7-444D-9C72-E2A9E06AA6F8@bluequartz.net> References: <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net> <5453E85B.7060808@classdesign.com> <5EDFC072-09E7-444D-9C72-E2A9E06AA6F8@bluequartz.net> Message-ID: Mike, You can modify or override the PATH variable in Visual Studio by pulling up the properties for the startup project and going to Configuration Properties -> Debugging, and add an entry for your preferred PATH under the "Environment" setting. By default, this will merge your PATH with the PATH currently defined for Visual Studio, so if you have a different Qt in your system PATH, you'll want to change "Merge Environment" to No. Note that if you do this, you'll need to add SystemRoot=C:\Windows to your path as well. Hope that helps, Cory On Sat, Nov 1, 2014 at 9:54 AM, Michael Jackson wrote: > The thing I could never figure out is how to set the PATH for the Visual > Studio Project/Solution. That is what I need. If I only had a single > version of Qt on my system it would be very straight forward. Just set the > PATH environment variable using the standard windows mechanism for doing > that and you are set. Alas, that isn't the case. I have at least 4 > different versions of Qt on my system at any one time. So tell me how to, > in the CMake file, to tell the Visual Studio generated solution to add > C:/Developer/x64/Qt-4.8.6/bin to my PATH and I would gladly rip out all my > code. I also need a mechanism to "install" all those DLL's into an > redistributable package (which my scripts ensure). Maybe I am just that far > behind the times. One of those "if it aint broke don't fix it". > > Looking forward to the answer > Mike Jackson > > On Oct 31, 2014, at 3:51 PM, Bill Somerville wrote: > > > On 31/10/2014 19:42, Michael Jackson wrote: > >> Never said it was pretty, but here is the code I use for Qt4 based > projects. I think I had to revamp a lot of this for Qt5. I call it like so: > >> > >> CMP_COPY_QT4_RUNTIME_LIBRARIES( "QtCore;QtGui;QtNetwork") > > This seems an awful lot of messing around when qt-project.org already > dump all the debug and release libraries into the installation bin > directory so all you need is to ensure that the installation bin directory > is on your PATH when you run or debug executables, just like you have to to > build using the tools like moc, qmake, dumpcpp, qrc, etc.. > > > > IMHO put he Qt bin directory on PATH for debugging and use BundleUtils > FixupBundle to make deployable kits. No need to do any manual or scripted > copying of libraries at all. > > > > Regards > > Bill. > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at classdesign.com Sat Nov 1 10:22:40 2014 From: bill at classdesign.com (Bill Somerville) Date: Sat, 01 Nov 2014 14:22:40 +0000 Subject: [CMake] Copying DLLs to output directory In-Reply-To: References: <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net> <5453E85B.7060808@classdesign.com> <5EDFC072-09E7-444D-9C72-E2A9E06AA6F8@bluequartz.net> Message-ID: <5454ECB0.1090208@classdesign.com> On 01/11/2014 14:15, Cory Quammen wrote: > Mike, > > You can modify or override the PATH variable in Visual Studio by > pulling up the properties for the startup project and going to > Configuration Properties -> Debugging, and add an entry for your > preferred PATH under the "Environment" setting. By default, this will > merge your PATH with the PATH currently defined for Visual Studio, so > if you have a different Qt in your system PATH, you'll want to change > "Merge Environment" to No. Note that if you do this, you'll need to > add SystemRoot=C:\Windows to your path as well. Indeed, and I think the syntax is VAR=value as in: PATH=c:\Qt\5.3\msvc2012\bin Simples especially if you don't pollute your standard PATH with Qt or any other Framework/Library on startup/login! > > Hope that helps, > Cory Regards Bill. > > On Sat, Nov 1, 2014 at 9:54 AM, Michael Jackson > > wrote: > > The thing I could never figure out is how to set the PATH for the > Visual Studio Project/Solution. That is what I need. If I only had > a single version of Qt on my system it would be very straight > forward. Just set the PATH environment variable using the standard > windows mechanism for doing that and you are set. Alas, that isn't > the case. I have at least 4 different versions of Qt on my system > at any one time. So tell me how to, in the CMake file, to tell the > Visual Studio generated solution to add > C:/Developer/x64/Qt-4.8.6/bin to my PATH and I would gladly rip > out all my code. I also need a mechanism to "install" all those > DLL's into an redistributable package (which my scripts ensure). > Maybe I am just that far behind the times. One of those "if it > aint broke don't fix it". > > Looking forward to the answer > Mike Jackson > > On Oct 31, 2014, at 3:51 PM, Bill Somerville > wrote: > > > On 31/10/2014 19:42, Michael Jackson wrote: > >> Never said it was pretty, but here is the code I use for Qt4 > based projects. I think I had to revamp a lot of this for Qt5. I > call it like so: > >> > >> CMP_COPY_QT4_RUNTIME_LIBRARIES( "QtCore;QtGui;QtNetwork") > > This seems an awful lot of messing around when qt-project.org > already dump all the debug and release > libraries into the installation bin directory so all you need is > to ensure that the installation bin directory is on your PATH when > you run or debug executables, just like you have to to build using > the tools like moc, qmake, dumpcpp, qrc, etc.. > > > > IMHO put he Qt bin directory on PATH for debugging and use > BundleUtils FixupBundle to make deployable kits. No need to do any > manual or scripted copying of libraries at all. > > > > Regards > > Bill. > > -- > > > > Powered by www.kitware.com > > > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > > > Kitware offers various services to support the CMake community. > For more information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. > For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saadrustam at gmail.com Sat Nov 1 12:16:30 2014 From: saadrustam at gmail.com (Saad Khattak) Date: Sat, 01 Nov 2014 16:16:30 +0000 Subject: [CMake] Extracting the configure and generate command Message-ID: Once I have configured and generated a CMake project, is there a way to extract that into a command? So, let's say I have configured and generated a project using the CMake GUI. I am then able to extract (somehow) the full configure/generate command which looks like this: cmake -DOPTION_1=ON -DOPTION_2=OFF -G "Visual Studio 10 1010" ../ -------------- next part -------------- An HTML attachment was scrubbed... URL: From irwin at beluga.phys.uvic.ca Sat Nov 1 14:24:58 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sat, 1 Nov 2014 11:24:58 -0700 (PDT) Subject: [CMake] What generator(s) should be used for MinGW-w64? In-Reply-To: References: Message-ID: On 2014-10-30 14:07-0700 Alan W. Irwin wrote: >[...] Furthermore, there is an MSYS2 project (a completely independent > project from MSYS, see ) > which _is_ API-compatible with MinGW-w64 since it is built with that > compiler. > > The combination of MinGW-w64 and MSYS2 seems fairly well documented > (see the above wiki reference). It appears for example, this > combination is a "lite" version of Cygwin. So I assume > that if MSYS2 is on the PATH, then the "Unix Makefiles" generator > is the correct one to use for this case (since that is the > recommended generator for Cygwin), but I would like confirmation > of that if someone here has experience with the combination > of MinGW-w64 and MSYS2. I did get what appears to be an excellent answer to the part (not quoted) of my original question concerning MinGW-w64 alone which I have passed on to PLplot developers who are in a position to utilize that information, but so far nobody here has answered the above part of my question. MSYS2 appears to be fairly popular at SF. The weekly download statistic of nearly 8000 at is obviously inflated by the number of different packages that have to be downloaded for an MSYS2 installation, but nevertheless that overall download statistic is still pretty impressive. Is there really no practical CMake experience here with the combination of MinGW-w64 and MSYS2? 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 scott.bloom at onshorecs.com Sat Nov 1 17:00:09 2014 From: scott.bloom at onshorecs.com (Scott Aron Bloom) Date: Sat, 1 Nov 2014 21:00:09 +0000 Subject: [CMake] Variable for AUTOMOC files? Message-ID: <6FD2E165340D9A429CF831C7A2D4F42E4E440C3B@WIN-R92V03RFJ85.onshorecs.local> I am setting and using CMAKE_AUTOMOC to on, however, for Qt4+Cmake 2.8 builds, I would put the moc files into a separate folder (Visual Studio) using source_group("Generated Files" FILES ${qtproject_MOC_SRCS}) Where qtproject_MOC_SRCS was defined via QT4_WRAP_CPP(qtproject_MOC_SRCS ${mocheaders}) Is there a variable set in CMake 3.X for AUTOMOC that would allow the same flexibility? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcdailey.lists at gmail.com Sat Nov 1 18:32:26 2014 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sat, 1 Nov 2014 17:32:26 -0500 Subject: [CMake] Copying DLLs to output directory In-Reply-To: <5EDFC072-09E7-444D-9C72-E2A9E06AA6F8@bluequartz.net> References: <75D7D5EE-1FD7-4FAE-931E-7DCB09836D2E@bluequartz.net> <5453E85B.7060808@classdesign.com> <5EDFC072-09E7-444D-9C72-E2A9E06AA6F8@bluequartz.net> Message-ID: I've solved the problem that way in the past. What you do is copy the .user file and make the environment setup driven by configure_file() in CMake. That way at CMake configure time you can create a .user file for each .VCPROJ that has PATH setup to point to third party BIN directories as needed. These will work when you debug. However, this only benefits visual studio. If I use nmake on Windows or want to use some other IDE on Windows, these methods won't work but copying the DLL there will always work. It has added benefits: 1. You can run the executable from the output directory 2. You can zip up the output directory to send adhoc builds to other people. On Sat, Nov 1, 2014 at 8:54 AM, Michael Jackson wrote: > The thing I could never figure out is how to set the PATH for the Visual Studio Project/Solution. That is what I need. If I only had a single version of Qt on my system it would be very straight forward. Just set the PATH environment variable using the standard windows mechanism for doing that and you are set. Alas, that isn't the case. I have at least 4 different versions of Qt on my system at any one time. So tell me how to, in the CMake file, to tell the Visual Studio generated solution to add C:/Developer/x64/Qt-4.8.6/bin to my PATH and I would gladly rip out all my code. I also need a mechanism to "install" all those DLL's into an redistributable package (which my scripts ensure). Maybe I am just that far behind the times. One of those "if it aint broke don't fix it". > > Looking forward to the answer > Mike Jackson > > On Oct 31, 2014, at 3:51 PM, Bill Somerville wrote: > >> On 31/10/2014 19:42, Michael Jackson wrote: >>> Never said it was pretty, but here is the code I use for Qt4 based projects. I think I had to revamp a lot of this for Qt5. I call it like so: >>> >>> CMP_COPY_QT4_RUNTIME_LIBRARIES( "QtCore;QtGui;QtNetwork") >> This seems an awful lot of messing around when qt-project.org already dump all the debug and release libraries into the installation bin directory so all you need is to ensure that the installation bin directory is on your PATH when you run or debug executables, just like you have to to build using the tools like moc, qmake, dumpcpp, qrc, etc.. >> >> IMHO put he Qt bin directory on PATH for debugging and use BundleUtils FixupBundle to make deployable kits. No need to do any manual or scripted copying of libraries at all. >> >> Regards >> Bill. >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From mle+tools at mega-nerd.com Sun Nov 2 00:55:25 2014 From: mle+tools at mega-nerd.com (Erik de Castro Lopo) Date: Sun, 2 Nov 2014 15:55:25 +1100 Subject: [CMake] Problems with CMP0037 Message-ID: <20141102155525.137aed6ceed7c5b186f63ffe@mega-nerd.com> Hi, I'm a project maintainer. I just upgraded to CMake 3.0.2 and now I'm getting this: CMake Warning (dev) at CMakeLists.txt:284 (add_executable): Policy CMP0037 is not set: Target names should not be reserved and should match a validity pattern. Run "cmake --help-policy CMP0037" for policy details. Use the cmake_policy command to set the policy and suppress this warning. The target name "tests/win32_test" is reserved or not valid for certain CMake features, such as generator expressions, and may result in undefined behavior. After some debugging, it seems that its the forward slash path separator that CMake is complaining about. I don't understand why the forward slash is not allowed as all Unix (including OSX) and Windows accept a forward slash. Clues? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From eike at sf-mail.de Sun Nov 2 03:14:05 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Sun, 02 Nov 2014 09:14:05 +0100 Subject: [CMake] Problems with CMP0037 In-Reply-To: <20141102155525.137aed6ceed7c5b186f63ffe@mega-nerd.com> References: <20141102155525.137aed6ceed7c5b186f63ffe@mega-nerd.com> Message-ID: <2408865.YOZf5YtZUW@caliban.sf-tec.de> Am Sonntag, 2. November 2014, 15:55:25 schrieb Erik de Castro Lopo: > Hi, > > I'm a project maintainer. I just upgraded to CMake 3.0.2 and now I'm > getting this: > > CMake Warning (dev) at CMakeLists.txt:284 (add_executable): > Policy CMP0037 is not set: Target names should not be reserved and > should match a validity pattern. Run "cmake --help-policy CMP0037" for > policy details. Use the cmake_policy command to set the policy and > suppress this warning. > > The target name "tests/win32_test" is reserved or not valid for certain > CMake features, such as generator expressions, and may result in > undefined behavior. > > After some debugging, it seems that its the forward slash path separator > that CMake is complaining about. I don't understand why the forward slash > is not allowed as all Unix (including OSX) and Windows accept a forward > slash. > > Clues? Because you can't create files or directories with that name, you would end up getting one directory "tests" and a file/directory win32_test*. And creating both with one API call isn't possible, so this may work if there is a directory "tests" before because of some other reason, but it will not reliably work. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From DLRdave at aol.com Sun Nov 2 10:13:23 2014 From: DLRdave at aol.com (David Cole) Date: Sun, 2 Nov 2014 10:13:23 -0500 Subject: [CMake] Extracting the configure and generate command In-Reply-To: References: Message-ID: The "Show My Changes" menu item in the Tools menu gives you the -D command line options for the things you've touched in the cmake-gui program... HTH, David C. On Sat, Nov 1, 2014 at 12:16 PM, Saad Khattak wrote: > Once I have configured and generated a CMake project, is there a way to > extract that into a command? So, let's say I have configured and generated > a project using the CMake GUI. I am then able to extract > (somehow) the full configure/generate command which looks like this: > > cmake -DOPTION_1=ON -DOPTION_2=OFF -G "Visual Studio 10 1010" ../ > > -- > > 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 irwin at beluga.phys.uvic.ca Sun Nov 2 12:30:12 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sun, 2 Nov 2014 09:30:12 -0800 (PST) Subject: [CMake] Problems with CMP0037 In-Reply-To: <2408865.YOZf5YtZUW@caliban.sf-tec.de> References: <20141102155525.137aed6ceed7c5b186f63ffe@mega-nerd.com> <2408865.YOZf5YtZUW@caliban.sf-tec.de> Message-ID: Eike said: >Because you can't create files or directories with that name, you >would end up >getting one directory "tests" and a file/directory win32_test*. And >creating >both with one API call isn't possible, so this may work if there is a >directory "tests" before because of some other reason, but it will not >reliably work. Hi Eike: I just want to confirm something about your answer. The OP was getting complaints about a _target_ with a slash in the name. At the CMake level there is a huge distinction between targets and files. Are you saying that at least for some generators a target eventually ends up as a filename (e.g., at the configured Makefile level) with exactly the same name as the target so a slash propagates to that filename? I agree if that were the case, it could cause issues on Unix platforms if the "directory" portion of the filename was not independently created first. If this is actually the case, I am somewhat surprised that CMake exposes such implementation details at the CMake level. For example, it should be possible to use a unique hash of target names when creating the corresponding configured filename such that the filename does not include any characters such as "/" that have special meaning at the file level on some platforms. 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 Andreas-Naumann at gmx.net Sun Nov 2 12:52:25 2014 From: Andreas-Naumann at gmx.net (Andreas Naumann) Date: Sun, 02 Nov 2014 18:52:25 +0100 Subject: [CMake] Problems with CMP0037 In-Reply-To: References: <20141102155525.137aed6ceed7c5b186f63ffe@mega-nerd.com> <2408865.YOZf5YtZUW@caliban.sf-tec.de> Message-ID: <54566F59.1000009@gmx.net> Hi Alan, with cmake 2.8.12.1 I can confirm this behavior at least for Makefile generator on Linux, see the attached small CMakeLists.txt. But what would be a better behavior? Changing the target name would change the output at end. So the user would have to figure out, what changed why. At this point, I would prefer the current behavior, because cmake does at least with the Makefile generator, the same thing as the user writes. So the warning is appropriate. Andreas Am 02.11.2014 18:30, schrieb Alan W. Irwin: > Eike said: > >> Because you can't create files or directories with that name, you >> would end up getting one directory "tests" and a file/directory >> win32_test*. And >> creating both with one API call isn't possible, so this may work if >> there is a directory "tests" before because of some other reason, but >> it will not reliably work. > > Hi Eike: > > I just want to confirm something about your answer. The OP > was getting complaints about a _target_ with a slash in the name. At > the CMake level there is a huge distinction between targets and files. > > Are you saying that at least for some generators a target eventually > ends up as a filename (e.g., at the configured Makefile level) with > exactly the same name as the target so a slash propagates to that > filename? I > agree if that were the case, it could cause issues on Unix platforms > if the "directory" portion of the filename was not independently > created first. > > If this is actually the case, I am somewhat surprised that CMake > exposes such implementation details at the CMake level. For example, > it should be possible to use a unique hash of target names when > creating the corresponding configured filename such that the filename > does not include any characters such as "/" that have special meaning > at the file level on some platforms. > > 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 > __________________________ -------------- next part -------------- project(testSlash) cmake_minimum_required(VERSION 2.8) file(WRITE "main.c" "int main() { return 0; }") add_executable(testDir/TestExe main.c) From irwin at beluga.phys.uvic.ca Sun Nov 2 14:13:50 2014 From: irwin at beluga.phys.uvic.ca (Alan W. Irwin) Date: Sun, 2 Nov 2014 11:13:50 -0800 (PST) Subject: [CMake] Problems with CMP0037 In-Reply-To: <54566F59.1000009@gmx.net> References: <20141102155525.137aed6ceed7c5b186f63ffe@mega-nerd.com> <2408865.YOZf5YtZUW@caliban.sf-tec.de> <54566F59.1000009@gmx.net> Message-ID: On 2014-11-02 18:52+0100 Andreas Naumann wrote: > Hi Alan, > > with cmake 2.8.12.1 I can confirm this behavior at least for Makefile > generator on Linux, see the attached small CMakeLists.txt. But what would be > a better behavior? Changing the target name would change the output at end. > So the user would have to figure out, what changed why. At this point, I > would prefer the current behavior, because cmake does at least with the > Makefile generator, the same thing as the user writes. > So the warning is appropriate. Absolutely! For now, a warning is essential because bad things could happen for target names with slashes in them that propagate to the filename level on Unix platforms. But all I am saying is in the long-term it would be a good idea to make it impossible for those bad things to happen so the current constraints on what is allowed for target names could be relaxed. 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 mle+tools at mega-nerd.com Sun Nov 2 15:01:55 2014 From: mle+tools at mega-nerd.com (Erik de Castro Lopo) Date: Sun, 2 Nov 2014 12:01:55 -0800 Subject: [CMake] Problems with CMP0037 In-Reply-To: <2408865.YOZf5YtZUW@caliban.sf-tec.de> References: <20141102155525.137aed6ceed7c5b186f63ffe@mega-nerd.com> <2408865.YOZf5YtZUW@caliban.sf-tec.de> Message-ID: <20141102120155.4825295a912b300787dc3f41@mega-nerd.com> Rolf Eike Beer wrote: > Because you can't create files or directories with that name, you would end up > getting one directory "tests" and a file/directory win32_test*. And creating > both with one API call isn't possible, so this may work if there is a > directory "tests" before because of some other reason, but it will not > reliably work. In the 2.8.whatever, the following worked without any complaints: add_executable (tests/win32_test tests/win32_test.c) In fact it worked just as I expected to in all ways, including being about to run make tests/win32_test to make just that executable. I also discussed this issue on IRC with @ngladitz who suggested the following: add_executable (win32_test tests/win32_test.c) set_target_properties (win32_test PROPERTIES EXECUTABLE_OUTPUT_PATH tests) Unfortunately, that does not behave as intended. The win32_test target ends up in the "." directory instead of the in the "tests/" directory. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From nilsgladitz at gmail.com Sun Nov 2 15:06:52 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Sun, 02 Nov 2014 21:06:52 +0100 Subject: [CMake] Problems with CMP0037 In-Reply-To: <20141102120155.4825295a912b300787dc3f41@mega-nerd.com> References: <20141102155525.137aed6ceed7c5b186f63ffe@mega-nerd.com> <2408865.YOZf5YtZUW@caliban.sf-tec.de> <20141102120155.4825295a912b300787dc3f41@mega-nerd.com> Message-ID: <54568EDC.6060505@gmail.com> On 02.11.2014 21:01, Erik de Castro Lopo wrote: > I also discussed this issue on IRC with @ngladitz who suggested the following: > > add_executable (win32_test tests/win32_test.c) > set_target_properties (win32_test PROPERTIES EXECUTABLE_OUTPUT_PATH tests) To my defense what I suggested was "RUNTIME_OUTPUT_DIRECTORY" not "EXECUTABLE_OUTPUT_PATH". Nils From mle+tools at mega-nerd.com Sun Nov 2 16:57:37 2014 From: mle+tools at mega-nerd.com (Erik de Castro Lopo) Date: Sun, 2 Nov 2014 13:57:37 -0800 Subject: [CMake] Problems with CMP0037 In-Reply-To: <54568EDC.6060505@gmail.com> References: <20141102155525.137aed6ceed7c5b186f63ffe@mega-nerd.com> <2408865.YOZf5YtZUW@caliban.sf-tec.de> <20141102120155.4825295a912b300787dc3f41@mega-nerd.com> <54568EDC.6060505@gmail.com> Message-ID: <20141102135737.e2b8bb6d4408eabe9c43b607@mega-nerd.com> Nils Gladitz wrote: > To my defense what I suggested was "RUNTIME_OUTPUT_DIRECTORY" not > "EXECUTABLE_OUTPUT_PATH". You are correct and yes, RUNTIME_OUTPUT_DIRECTORY does the right thing. Thanks for your help. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From saadrustam at gmail.com Sun Nov 2 19:03:41 2014 From: saadrustam at gmail.com (Saad Khattak) Date: Mon, 03 Nov 2014 00:03:41 +0000 Subject: [CMake] Extracting the configure and generate command References: Message-ID: Thanks David. That at least makes it easier to write the scripts for generating the projects. It would be great if the GUI has an option to show the full CMake command. On Sun Nov 02 2014 at 10:13:24 AM David Cole wrote: > The "Show My Changes" menu item in the Tools menu gives you the -D command > line options for the things you've touched in the cmake-gui program... > > HTH, > David C. > > > On Sat, Nov 1, 2014 at 12:16 PM, Saad Khattak > wrote: > >> Once I have configured and generated a CMake project, is there a way to >> extract that into a command? So, let's say I have configured and generated >> a project using the CMake GUI. I am then able to extract >> (somehow) the full configure/generate command which looks like this: >> >> cmake -DOPTION_1=ON -DOPTION_2=OFF -G "Visual Studio 10 1010" ../ >> >> -- >> >> 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 jackie at sdiwc.info Mon Nov 3 05:20:43 2014 From: jackie at sdiwc.info (Conference Updates) Date: Mon, 03 Nov 2014 03:20:43 -0700 Subject: [CMake] CFP: Fourth World Congress - SEMCMI2015 - Malaysia Message-ID: <49c2a1eb935961ab01df433f830d571e@sdiwc.info> The International Conference on Software Engineering, Mobile Computing and Media Informatics (SEMCMI2015) - Part of The Fourth World Congress on Computing and Information Technology (WCIT) - Asia Pacific University of Technology and Innovation (APU) Kuala Lumpur, Malaysia September 29 - October 1, 2015 http://sdiwc.net/conferences/semcmi2015/ All registered papers will be included in SDIWC Digital Library ================================================================ The proposed conference on the above theme will be held at Asia Pacific University of Technology and Innovation (APU) on September 29 - October 1, 2015 which aims to enable researchers build connections between different digital applications. The conference welcomes papers on the following (but not limited to) research topics: *Software Engineering Advanced Database Systems Advanced Human-Computer Interaction Artificial Intelligence Data Mining Economics of Innovation & Entrepreneurship Electronic Circuits Embedded Systems Design & Interfacing Globalisation & the World Economy Managing the International Enterprise Service-Oriented Architectures Spatial and Multimedia Databases Systems Safety Engineering Virtual Organisation Management Advanced Embedded Systems Algorithms & Data Structures Carbon & Energy Management Distributed Computing Electrical Energy Conversion & Utilisation Embedded Systems Design & Interfacing Engineering Project Management Information Security Operating Systems Architecture Signals, Systems & Control Systems Engineering Systems Thinking for Sustainability Web Information Systems *Mobile Computing Access Control Application Service Providers Bluetooth Broadband Wireless Networks Enterprise Asset Management Software Fixed Wireless Networks Converged Networks Data Security PDA Operating Systems Satellite Communications Systems Wireless Application Development Wireless Applications Software Wireless Development Tools Wireless Home Networks Application Performance Management Base Stations Broadband Satellite Systems Enhanced Messaging Service Ethernet Cable Fixed-mobile Convergence Data Migration Document Management Voice Communications Software Security Managers Wireless Application Services Providers Wireless Computing Wireless Hardware Wireless Infrared Communications *Media Informatics Computer Graphics/Animation/Visualisation Data Communication Digital Interactive Media Game Design Knowledge Management Multimedia Technology Speech/Image/Video Processing and Technology Cooperative Work Environments Designing Interactive Systems E-Business Internet Infrastructures Management of Information Security and Cryptography Virtual and Augmented Reality Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. Important Dates ============== Submission Dates : The submission is open from now until Aug. 30, 2015 Notification of Acceptance : 3-4 weeks from the submission date Camera Ready Submission : September 15, 2015 Registration : September 15, 2015 Conference Dates : September 29 - October 1, 2015 From jmerkow at gmail.com Mon Nov 3 17:46:01 2014 From: jmerkow at gmail.com (jmerkow) Date: Mon, 3 Nov 2014 14:46:01 -0800 (PST) Subject: [CMake] ExternalProjectDependency (artichoke) and ctest Message-ID: <1415054761801-7588929.post@n2.nabble.com> Hello, My project is using ExternalProjectDependency from [1]. I know that is not a kitware/cmake project, but I thought Id ask here anyway.... I have been using testing (ctest) with it by adding tests in the top level build with hard-coded directories and names (these targets aren't built until the non-superbuild project is built). I wanted to move the tests to the non-superbuild portion of the code so I can use generator expressions, but I am having some trouble. Basically, what I am doing is to include ctest in the non-superbuild portion then add a custom target. This works for 'make test' but does not work with ctest. add_custom_target(test) add_custom_command(TARGET test POST_BUILD COMMAND ${CMAKE_COMMAND} --build ${${PROJECT_NAME}_BINARY_DIR}/build --target test) ExternalProjectDependency added a function to add install: 'ExternalProject_Install_CMake' I don't see a similar function for testing. Is there another good way to do this? Im not sure what ctest calls to initiate testing, using that info, I might be able to get a good work around. -Jameson [1] https://github.com/commontk/Artichoke -- View this message in context: http://cmake.3232098.n2.nabble.com/ExternalProjectDependency-artichoke-and-ctest-tp7588929.html Sent from the CMake mailing list archive at Nabble.com. From jmerkow at gmail.com Mon Nov 3 20:13:57 2014 From: jmerkow at gmail.com (jmerkow) Date: Mon, 3 Nov 2014 17:13:57 -0800 (PST) Subject: [CMake] CMake - Error in configuration process, project files may be invalid In-Reply-To: <1414960687574-7588925.post@n2.nabble.com> References: <1414960687574-7588925.post@n2.nabble.com> Message-ID: <1415063637388-7588930.post@n2.nabble.com> It looks like you don't have a CXX compiler. Make sure that visual studio is installed properly, with C++ compilers. -Jameson -- View this message in context: http://cmake.3232098.n2.nabble.com/CMake-Error-in-configuration-process-project-files-may-be-invalid-tp7588925p7588930.html Sent from the CMake mailing list archive at Nabble.com. From fenjuan at bios.au.dk Tue Nov 4 05:48:41 2014 From: fenjuan at bios.au.dk (Fenjuan Hu) Date: Tue, 4 Nov 2014 10:48:41 +0000 Subject: [CMake] Cmake 3.1 generated projects for VS2010+ifort12.1, compiler can't recognize $(Configuration) Message-ID: Hi all I am using Cmake3.1, and want to generate a Fortran project on Visual Studio 2010. And I have ifort 12.1 installed on my computer. After generated the project, when I build them, I got error: Error 1 fatal error LNK1181: cannot open input file 'C:\MODELS\build\fabm\0d\models\bb\bb.dir\\filter_feeder.obj' LINK The Filter_feeder.obj file is under path 'C:\MODELS\build\fabm\0d\models\bb\bb.dir\Release\filter_feeder.obj' While in Fortran project file, it tells Visual studio to look for 'C:\MODELS\build\fabm\0d\models\bb\bb.dir\($Configuration)\filter_feeder.obj And apparently, my platform(VS2010 + ifort 12.1) can't recognize "($Configuration)" during compilation. It is said it's due to the Visual Studio has changed environment variable ($ConfigurationName) to ($Configuration) from VS2008 to VS2010. Then I replaced all ($Configuration) by ($ConfigurationName) in the vfproj file, the compilation worked. And by the way, we have several people work on the same project, and two of my colleague using VS2010 and ifort worked perfectly with this CMake generating system. Their settings on my colleague's are: VS2010, version 10.0.40219.1 SP1Rel Intel Visual Fortran Composer XE 2013 Update 1, version 13.0.1.119 And VS2010, version 10.0.40219.1 SP1Rel Intel Visual Fortran Composer XE 2013 Update 1, version 13.0.1.119 And mine is : VS2010, version 10.0.40219.1 SP1Rel Intel Visual Fortran Composer XE 2013 Update 1, version 12.1.3534 So the only difference was the versions of ifort compiler. My version is a little old. So can CMake take this into consideration when generating project files for Fortran? Best regards Fen ====================================================================== Fenjuan Hu Joint Ph.D student of Southern Denmark University and Aarhus University Adr.: Department of Bioscience, Aarhus University,Vejls?vej 25, 8600 Silkeborg, Denmark Contact info: fenjuan at bios.au.dk Contact info: fenjuan at biology.sdu.dk Mobile: +45 52640478 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.atkins at kitware.com Tue Nov 4 13:07:06 2014 From: chuck.atkins at kitware.com (Chuck Atkins) Date: Tue, 4 Nov 2014 13:07:06 -0500 Subject: [CMake] FIND_PATH() search custom path first In-Reply-To: <8420daa09a3747bfb0cd37a3023f401d@DBXPR03MB478.eurprd03.prod.outlook.com> References: <8420daa09a3747bfb0cd37a3023f401d@DBXPR03MB478.eurprd03.prod.outlook.com> Message-ID: Hi George, Jakub, > NO_DEFAULT_PATH > > NO_CMAKE_ENVIRONMENT_PATH > > NO_CMAKE_PATH > > NO_SYSTEM_ENVIRONMENT_PATH > > NO_CMAKE_SYSTEM_PATH > The options specified are redundant. NO_DEFAULT_PATH implies the later 4. If you just specify NO_DEFAULT_PATH then only HINTS and user guess paths (those specified by the PATH argument) will be checked. > NO_CMAKE_FIND_ROOT_PATH > This is specific to cross compiling, and usually isn't needed unless that's your situation. A particularly effective and commonly used pattern is to build up the options to the find call in a variable. The FindBoost module does this very thing to restrict it's component search to all the same directory. The idea is that if you have a specific location that you know your file should be found in when set, then something like this could work: set(FOO_FIND_OPTS) if(FOO_DIR) set(FOO_FIND_OPTS HINTS "${FOO_DIR}" NO_DEFAULT_PATH NO_CMAKE_FIND_ROOT_PATH) endif() find_library(FOO_LIBRARY MyFooLib ${FOO_FIND_OPTS}) This way, if FOO_DIR is set, then it will only look there. However, if it's not, then FOO_FIND_OPTS is empty and the standard search will happen. - Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Tue Nov 4 18:21:00 2014 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 4 Nov 2014 15:21:00 -0800 Subject: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing! In-Reply-To: References: <5453AA07.1000104@kitware.com> Message-ID: On 10/31/14, Gilles Khouzam wrote: > We actually have a couple if extra changes that are not fully ready to be > pushed upstream yet. > > ~Gilles > Sent from my Windows Phone Since I have your attention, using CMakeMS, I hit what looks like a bug in the generation for the Windows Phone simulator. I have not tested 3.1.0-rc1, but since it is the from the same code base, I'm assuming it is affected too. I get a linking failure for only the WinPhone simulator (Win32) binary. This is the error the linker is spitting out: vccorlib.lib(compiler.obj) : error LNK2038: mismatch detected for 'vccorlib_lib_should_be_specified_before_msvcrt_lib_to_linker': value '1' doesn't match '0' in MSVCRT.lib(appinit.obj) vccorlib.lib(compiler.obj) : error LNK2005: ___crtWinrtInitType already defined in MSVCRT.lib(appinit.obj) D:\\Release\FlappyBlurrr.exe : fatal error LNK1169: one or more multiply defined symbols found This only happens for me with the Win32 simulator binary. I do not have this problem with the ARM device binary, nor do I have this problem with the Windows Store x64 binary. (I do not bother with Win32 Windows Store.) Somebody helped me and told me to add these switches directly to my Visual Studio project: - for Debug builds, add: /nodefaultlib:vccorlibd /nodefaultlib:msvcrtd vccorlibd.lib msvcrtd.lib - for Release builds, add: /nodefaultlib:vccorlib /nodefaultlib:msvcrt vccorlib.lib msvcrt.lib This seemed to make my linking problems go away. I'm thinking that CMake should automatically be setting these for me for the Windows Phone simulator. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From ewmailing at gmail.com Tue Nov 4 18:38:47 2014 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 4 Nov 2014 15:38:47 -0800 Subject: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui In-Reply-To: References: <8D0A84A143D83B9-798-58886@webmail-m164.sysops.aol.com> <201311052036.08983.neundorf@kde.org> <8D0A88F2490D7CF-798-61E36@webmail-m164.sysops.aol.com> <543D585D-2052-489B-BA05-755C21694077@aol.com> <527AA7B2.2090103@kitware.com> Message-ID: Bump. With CMake 3.1 on the horizon, I was wondering if there was any progress on this. This would be really useful to me. I am basically invoking command line cmake.exe so I can pass all the right options, including my own CMake Initial Cache file. I ship an entire self-contained "SDK" of sorts which has all the prebuilt library dependencies in a place relative to a .bat or .sh script used to invoke cmake.exe, which makes project generation for all of my platforms essentially a turn-key operation. However, my projects have a couple of configurable options (e.g. I don't need to link in OpenAL), And it would be nice if I could present the CMake gui first so they can uncheck the options before generation. (I copy some things into the build directory on generation which means they get stuff they may not want if they can't uncheck the option first.) I think basically the behavior I want is essentially the same as ccmake, except have a proper GUI (a lot of Windows and newer users don't grok the curses thing). Thanks, Eric From ewmailing at gmail.com Tue Nov 4 19:46:50 2014 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 4 Nov 2014 16:46:50 -0800 Subject: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing! In-Reply-To: <33dd5601ba2845b7a1c1adf951522022@BY2PR0301MB0709.namprd03.prod.outlook.com> References: <5453AA07.1000104@kitware.com> <33dd5601ba2845b7a1c1adf951522022@BY2PR0301MB0709.namprd03.prod.outlook.com> Message-ID: On 11/4/14, Gilles Khouzam wrote: > Hi Eric, > > Can you send me a little more details or an example that exhibits the > problem? I'd be happy to take a look. > Sure. I'll respond offlist for this. Thanks, Eric From Gilles.Khouzam at microsoft.com Tue Nov 4 19:24:46 2014 From: Gilles.Khouzam at microsoft.com (Gilles Khouzam) Date: Wed, 5 Nov 2014 00:24:46 +0000 Subject: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing! In-Reply-To: References: <5453AA07.1000104@kitware.com> Message-ID: <33dd5601ba2845b7a1c1adf951522022@BY2PR0301MB0709.namprd03.prod.outlook.com> Hi Eric, Can you send me a little more details or an example that exhibits the problem? I'd be happy to take a look. -----Original Message----- From: Eric Wing [mailto:ewmailing at gmail.com] Sent: Tuesday, November 4, 2014 15:21 To: Gilles Khouzam Cc: Brad King; Robert Maynard; CMake Developers; CMake MailingList Subject: Re: [CMake] [cmake-developers] [ANNOUNCE] CMake 3.1.0-rc1 now ready for testing! On 10/31/14, Gilles Khouzam wrote: > We actually have a couple if extra changes that are not fully ready to > be pushed upstream yet. > > ~Gilles > Sent from my Windows Phone Since I have your attention, using CMakeMS, I hit what looks like a bug in the generation for the Windows Phone simulator. I have not tested 3.1.0-rc1, but since it is the from the same code base, I'm assuming it is affected too. I get a linking failure for only the WinPhone simulator (Win32) binary. This is the error the linker is spitting out: vccorlib.lib(compiler.obj) : error LNK2038: mismatch detected for 'vccorlib_lib_should_be_specified_before_msvcrt_lib_to_linker': value '1' doesn't match '0' in MSVCRT.lib(appinit.obj) vccorlib.lib(compiler.obj) : error LNK2005: ___crtWinrtInitType already defined in MSVCRT.lib(appinit.obj) D:\\Release\FlappyBlurrr.exe : fatal error LNK1169: one or more multiply defined symbols found This only happens for me with the Win32 simulator binary. I do not have this problem with the ARM device binary, nor do I have this problem with the Windows Store x64 binary. (I do not bother with Win32 Windows Store.) Somebody helped me and told me to add these switches directly to my Visual Studio project: - for Debug builds, add: /nodefaultlib:vccorlibd /nodefaultlib:msvcrtd vccorlibd.lib msvcrtd.lib - for Release builds, add: /nodefaultlib:vccorlib /nodefaultlib:msvcrt vccorlib.lib msvcrt.lib This seemed to make my linking problems go away. I'm thinking that CMake should automatically be setting these for me for the Windows Phone simulator. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From traits.zhang at gmail.com Tue Nov 4 20:20:15 2014 From: traits.zhang at gmail.com (Zhang Xianyi) Date: Wed, 5 Nov 2014 09:20:15 +0800 Subject: [CMake] Support OpenBLAS in FindBLAS module Message-ID: Hi Folks, I am the developer of OpenBLAS, an optimized BLAS implementation forked from GotoBLAS2. So far, the FindBLAS.cmake module cannot recognize OpenBLAS as a legitimate library. Is it possible to support OpenBLAS in FindBLAS module? Best Regards, Xianyi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Tue Nov 4 20:20:06 2014 From: ewmailing at gmail.com (Eric Wing) Date: Tue, 4 Nov 2014 17:20:06 -0800 Subject: [CMake] Using CMake to build an Emscripten output? Message-ID: Not that I really have time to fix this, but I was experimenting with my C based codebase to see if I could compile it with Emscripten so it could run in a browser. After working around a lot of scary compiler bugs, I got it to work. But I invoked the build process by hand. So the next thing on my mind is how to leverage CMake (since all my other platforms use it already). My incantation for my test project is pretty straight foward and looks very much like a clang invocation. The major difference is that all my assets needed to be part of the compile process using the --preload-file flag. (A minor difference is the output file ends in .html) ~/Source/GIT/emscripten/emcc -O2 --js-opts 0 -g4 CircularQueue.c TimeTicker.c main_c.c -I/opt/local/emscripten/include -I/opt/local/emscripten/include/SDL2 -I /opt/local/emscripten/include/chipmunk /opt/local/emscripten/lib/libSDL2_ttf.a /opt/local/emscripten/lib/libfreetype.a /opt/local/emscripten/lib/libSDL2_image.a /opt/local/emscripten/lib/libpng.a /opt/local/emscripten/lib/libz.a /opt/local/emscripten/lib/libALmixer.a /opt/local/emscripten/lib/libchipmunk.a /opt/local/emscripten/lib/libSDL2.a -o FlappyBlurrr.html --preload-file fly2.png --preload-file fly1.png --preload-file fly0.png --preload-file VeraMono.ttf --preload-file gamecontrollerdb.txt --preload-file coin_ding.wav --preload-file background.png --preload-file bush.png --preload-file clouds.png --preload-file ground.png --preload-file pipe_bottom.png --preload-file pipe_top.png --preload-file davedes_fastsimplechop5b.wav --preload-file LeftHook_SoundBible_com-516660386.wav --preload-file SlideWhistle.wav --preload-file 14609__man__swosh.wav --preload-file acknowtt.ttf --preload-file MedalBackground.png --preload-file momoko_Bronze_Medallion.png --preload-file momoko_Silver_Medallion.png --preload-file momoko_Gold_Medallion.png --preload-file momoko_Platinum_Medallion.png --preload-file Placeholder_Medallion.png --preload-file playbutton.png --preload-file quitbutton.png --preload-file 04B_19__.TTF -s ASSERTIONS=1 Anybody used CMake with Emscripten for this purpose? Or any thoughts on what I should do? (I also have some concerns the preload-file list is going to get too long. Perhaps I'm missing something with Emscripten.) Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From eike at sf-mail.de Wed Nov 5 02:10:11 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Wed, 05 Nov 2014 08:10:11 +0100 Subject: [CMake] Support OpenBLAS in FindBLAS module In-Reply-To: References: Message-ID: <4264631.hzuSDd0uN0@caliban.sf-tec.de> Am Mittwoch, 5. November 2014, 09:20:15 schrieb Zhang Xianyi: > Hi Folks, > > I am the developer of OpenBLAS, an optimized BLAS implementation forked > from GotoBLAS2. > > So far, the FindBLAS.cmake module cannot recognize OpenBLAS as a legitimate > library. Is it possible to support OpenBLAS in FindBLAS module? Yes, but the preferable solution would be that you ship a OpenBLASConfig.cmake with your installation, so it would work with any CMake version and you can adapt that file yourself in case of new components, library locations or other things. Eike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From Fabien.Spindler at inria.fr Wed Nov 5 02:38:55 2014 From: Fabien.Spindler at inria.fr (Fabien Spindler) Date: Wed, 05 Nov 2014 08:38:55 +0100 Subject: [CMake] What is recommended to export / import target libraries with dependencies that are also exported Message-ID: <5459D40F.1020001@inria.fr> Hello, Consider the following case where: - I want to export/import my library named mylib - This library depends on OpenCV that is also exported According to http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages the CMakeLists.txt of my library is simpilar to: project(mylib) find_package(OpenCV) add_library(mylib foo.c foo.h) target_link_libraries(mylib ${OpenCV_LIBS}) ... export(EXPORT mylibTargets FILE "${CMAKE_CURRENT_BINARY_DIR}/mylibTargets.cmake") ... Now the CMakeLists of an other project that uses mylib will be like : project(test) find_package(mylib) add_executable(test test.c) target_link_libraries(test mylib) During the build of this project the linker complains that OpenCV libraries are not found Linking C executable test "/Applications/CMake 3.0.0.app/Contents/bin/cmake" -E cmake_link_script CMakeFiles/test.dir/link.txt --verbose=1 /usr/bin/cc -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/test.dir/test.c.o -o test -lopencv_videostab -lopencv_video ... ld: library not found for -lopencv_videostab The problem comes from mylibTargets.cmake where I have: set_target_properties(mylib PROPERTIES IMPORTED_LINK_INTERFACE_LIBRARIES_NOCONFIG "opencv_videostab;opencv_video;..." IMPORTED_LOCATION_NOCONFIG "/tmp/build/libmylib.dylib" IMPORTED_SONAME_NOCONFIG "/tmp/build/libmylib.3.dylib" ) while I wanted to have the full path to OpenCV libraries (ie /tmp/OpenCV/lib/libopencv_videostab.2.4.10.dylib ... Is there a proper way to include OpenCV dependencies during the export of my library ? Fabien From brad.king at kitware.com Wed Nov 5 10:30:30 2014 From: brad.king at kitware.com (Brad King) Date: Wed, 05 Nov 2014 10:30:30 -0500 Subject: [CMake] [cmake-developers] Forwarding parameters to cmake through cmake-gui In-Reply-To: References: <8D0A84A143D83B9-798-58886@webmail-m164.sysops.aol.com> <201311052036.08983.neundorf@kde.org> <8D0A88F2490D7CF-798-61E36@webmail-m164.sysops.aol.com> <543D585D-2052-489B-BA05-755C21694077@aol.com> <527AA7B2.2090103@kitware.com> Message-ID: <545A4296.5090900@kitware.com> On 11/04/2014 06:38 PM, Eric Wing wrote: > This would be really useful to me. No one plans to work on it AFAIK. You'd have to dig in yourself. Sorry, -Brad From wewolski at gmail.com Wed Nov 5 11:28:00 2014 From: wewolski at gmail.com (Witold E Wolski) Date: Wed, 5 Nov 2014 17:28:00 +0100 Subject: [CMake] [java] How do I add an "implements MyI" to Swig generated java class? Message-ID: I have some C++ classes which implement an interface. On the C++ side I have: struct Block{ void waitForNotify()=0; } class B : Listener{ void waitForNotify(); ... } what I would love to get generated on the java side is: interface Block{ void notifiy(); } class B implements Block{ swig gernated private long swigCPtr; protected boolean swigCMemOwn; ... .... @Override public boolean waitForNotify() { return SwigTestWrappersJNI.B_waitForNotify(swigCPtr, this); } } But what I get when I tell swig to wrap the Block interface and the class B is in java public class Block { private long swigCPtr; protected boolean swigCMemOwn; protected Block(long cPtr, boolean cMemoryOwn) { swigCMemOwn = cMemoryOwn; ..... } and public class B extends Block { .... So I am thinking about a solution just to let swig wrap the class B and declare in addition the interface Block also in java by hand but what I am missing at the moment is how to tell swig to add to the auto generated class B declaration the "implements Block" clause. Thank you -- Witold Eryk Wolski From eric.huhtala at gmail.com Wed Nov 5 14:50:44 2014 From: eric.huhtala at gmail.com (Eric Huhtala) Date: Wed, 5 Nov 2014 13:50:44 -0600 Subject: [CMake] Asm object files in object libraries Message-ID: I have both cpp's and assembly files which I would like to include in an object library, however, I get: OBJECT library "blah" contains: blah1.spp blah2.spp but may contain only headers and sources that compile. why can't an object created from assembly code be grouped together with objects created from cpp code? -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshua.studen at gmail.com Wed Nov 5 15:01:35 2014 From: joshua.studen at gmail.com (Joshua Studen) Date: Wed, 5 Nov 2014 15:01:35 -0500 Subject: [CMake] Having a real hardtime installing CMake on a Linux cluster machine Message-ID: Hi, The problem is relatively simple. I've downloaded cmake and have run configure as follows: ./configure --prefix=$HOME/x86_64-6.4 --no-qt-gui The configure phase seems to work fine.. throws no errors, but then when I type gmake, I get the following errrors: /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.h:46:31: error: ncurses/ncurses.h: No such file or directory In file included from /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.priv.h:34, from /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/fld_arg.c:33: /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.h:93: error: expected specifier-qualifier-list before ?chtype? /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.h:120: error: expected specifier-qualifier-list before ?bool? /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.h:144: error: expected specifier-qualifier-list before ?WINDOW? ... ... a bunch of stuff like this, and then gmake[2]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o] Error 1 gmake[1]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/all] Error 2 gmake: *** [all] Error 2 I have ncurses installed in /net/hu19/jstuden3/x86_64-6.4/ (lib/ for the .a's, and include/ for the headers). It seems that I can't specify a directory for ncurses when configuring cmake? doing ./configure --help doesn't seem to indicate anyway to specify include and link paths...... Regards, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.kacvinsky at vectorcast.com Wed Nov 5 15:07:19 2014 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Wed, 5 Nov 2014 15:07:19 -0500 Subject: [CMake] Having a real hardtime installing CMake on a Linux cluster machine In-Reply-To: References: Message-ID: With bash: CFLAGS="-IXXX" CXXFLAGS="-IXXX" LDFLAGS="-LXXX" ./configure ... This should indicate to configure that headers and libraries are found in the locations you specify. On Wed, Nov 5, 2014 at 3:01 PM, Joshua Studen wrote: > Hi, > > The problem is relatively simple. I've downloaded cmake and have run > configure as follows: > > ./configure --prefix=$HOME/x86_64-6.4 --no-qt-gui > > The configure phase seems to work fine.. throws no errors, but then when I > type gmake, I get the following errrors: > > /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.h:46:31: > error: ncurses/ncurses.h: No such file or directory > In file included from > /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.priv.h:34, > from > /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/fld_arg.c:33: > /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.h:93: > error: expected specifier-qualifier-list before ?chtype? > /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.h:120: > error: expected specifier-qualifier-list before ?bool? > /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.h:144: > error: expected specifier-qualifier-list before ?WINDOW? > ... > ... > a bunch of stuff like this, and then > > gmake[2]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o] > Error 1 > gmake[1]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/all] Error 2 > gmake: *** [all] Error 2 > > I have ncurses installed in /net/hu19/jstuden3/x86_64-6.4/ (lib/ for the > .a's, and include/ for the headers). > > It seems that I can't specify a directory for ncurses when configuring > cmake? doing ./configure --help doesn't seem to indicate anyway to specify > include and link paths...... > > Regards, > Josh > > > > -- > > 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 joshua.studen at gmail.com Wed Nov 5 16:03:06 2014 From: joshua.studen at gmail.com (Joshua Studen) Date: Wed, 5 Nov 2014 16:03:06 -0500 Subject: [CMake] Having a real hardtime installing CMake on a Linux cluster machine In-Reply-To: References: Message-ID: It's not working. the problem is this /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.h:46:31: error: ncurses/ncurses.h: No such file or directory It's trying to reference the directory specified in CFLAGS/ncurses/ncurses.h so if I pass in CFLAGS="-I/net/hu19/jstuden3/x86_64-6.4/include/ncurses" CXXFLAGS="-I/net/hu19/jstuden3/x86_64-6.4/include/ncurses" it will look for /net/hu19/jstuden3/x86_64-6.4/include/ncurses/ncurses/ncurses.h Okay, fine, so then don't specify the additional ncurses (just -I /net/hu19/jstuden3/x86_64-6.4/include).. Then i get the SAME thing. I don't think the configure script is respecting the variables at all. For example, even though I've specified --no-qt-gui, I still get this after configure: Could NOT find Qt4 (missing: QT_QMAKE_EXECUTABLE QT_MOC_EXECUTABLE QT_RCC_EXECUTABLE QT_UIC_EXECUTABLE QT_INCLUDE_DIR QT_LIBRARY_DIR QT_QTCORE_LIBRARY) Regards, Josh. On Wed, Nov 5, 2014 at 3:07 PM, Tom Kacvinsky wrote: > With bash: > > CFLAGS="-IXXX" CXXFLAGS="-IXXX" LDFLAGS="-LXXX" ./configure ... > > This should indicate to configure that headers and libraries are found in > the locations you specify. > > On Wed, Nov 5, 2014 at 3:01 PM, Joshua Studen > wrote: > >> Hi, >> >> The problem is relatively simple. I've downloaded cmake and have run >> configure as follows: >> >> ./configure --prefix=$HOME/x86_64-6.4 --no-qt-gui >> >> The configure phase seems to work fine.. throws no errors, but then when >> I type gmake, I get the following errrors: >> >> /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.h:46:31: >> error: ncurses/ncurses.h: No such file or directory >> In file included from >> /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.priv.h:34, >> from >> /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/fld_arg.c:33: >> /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.h:93: >> error: expected specifier-qualifier-list before ?chtype? >> /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.h:120: >> error: expected specifier-qualifier-list before ?bool? >> /net/hp95/users/jstuden3/cmake-2.8.8/Source/CursesDialog/form/form.h:144: >> error: expected specifier-qualifier-list before ?WINDOW? >> ... >> ... >> a bunch of stuff like this, and then >> >> gmake[2]: *** >> [Source/CursesDialog/form/CMakeFiles/cmForm.dir/fld_arg.c.o] Error 1 >> gmake[1]: *** [Source/CursesDialog/form/CMakeFiles/cmForm.dir/all] Error 2 >> gmake: *** [all] Error 2 >> >> I have ncurses installed in /net/hu19/jstuden3/x86_64-6.4/ (lib/ for the >> .a's, and include/ for the headers). >> >> It seems that I can't specify a directory for ncurses when configuring >> cmake? doing ./configure --help doesn't seem to indicate anyway to specify >> include and link paths...... >> >> Regards, >> Josh >> >> >> >> -- >> >> 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 eric.huhtala at gmail.com Wed Nov 5 16:41:32 2014 From: eric.huhtala at gmail.com (Eric Huhtala) Date: Wed, 5 Nov 2014 15:41:32 -0600 Subject: [CMake] Asm object files in object libraries In-Reply-To: References: Message-ID: It looks like the issue was that "spp" isn't recognized as "assembly", so after setting the source file LANGUAGE property to ASM, it worked as expected. On Wed, Nov 5, 2014 at 1:50 PM, Eric Huhtala wrote: > I have both cpp's and assembly files which I would like to include in an > object library, however, I get: > OBJECT library "blah" contains: > blah1.spp > blah2.spp > > but may contain only headers and sources that compile. > > why can't an object created from assembly code be grouped together with > objects created from cpp code? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Wed Nov 5 18:13:51 2014 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 06 Nov 2014 00:13:51 +0100 Subject: [CMake] How to find Python 2.7 libraries if 3.x is installed too Message-ID: <4440017.gg9I5F9cSd@portia.local> Hello, I am trying to get a not-so-old project to build (gizmod.sourceforge.net) which requires Python2.7 and libboost-python. I cannot seem to figure out how to do a find_package(PythonLibs REQUIRED) that will not consider that Python 3.4 is a suitable newer version of Python 2.7 . Is that even possible? The documentation in FindPythonLibs.cmake suggests that one can limit the search to specific versions, but that doesn't work. And using find_package(PythonLibs 2.7.5 EXACT REQUIRED) raises an error because it too finds v3.4 ... Thanks, R.B. From christopher.mullins at kitware.com Wed Nov 5 18:27:05 2014 From: christopher.mullins at kitware.com (Christopher Mullins) Date: Wed, 5 Nov 2014 18:27:05 -0500 Subject: [CMake] How to find Python 2.7 libraries if 3.x is installed too In-Reply-To: <4440017.gg9I5F9cSd@portia.local> References: <4440017.gg9I5F9cSd@portia.local> Message-ID: Consider doing what ITK does: https://github.com/InsightSoftwareConsortium/ITK/blob/master/Wrapping/Generators/Python/CMakeLists.txt#L1-18 Also make sure you're using the latest CMake release. On Wed, Nov 5, 2014 at 6:13 PM, Ren? J.V. wrote: > Hello, > > I am trying to get a not-so-old project to build (gizmod.sourceforge.net) > which requires Python2.7 and libboost-python. > I cannot seem to figure out how to do a find_package(PythonLibs REQUIRED) > that will not consider that Python 3.4 is a suitable newer version of > Python 2.7 . Is that even possible? The documentation in > FindPythonLibs.cmake suggests that one can limit the search to specific > versions, but that doesn't work. > And using find_package(PythonLibs 2.7.5 EXACT REQUIRED) raises an error > because it too finds v3.4 ... > > Thanks, > R.B. > -- > > 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 > -- Christopher Mullins R&D Engineer Kitware Inc., 919.869.8871 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Wed Nov 5 18:58:02 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed, 05 Nov 2014 18:58:02 -0500 Subject: [CMake] Having a real hardtime installing CMake on a Linux cluster machine In-Reply-To: References: Message-ID: <545AB98A.7040109@kitware.com> On 11/5/2014 4:03 PM, Joshua Studen wrote: > > I don't think the configure script is respecting the variables at all. > For example, even though I've specified --no-qt-gui, I still get this > after configure: > > Could NOT find Qt4 (missing: QT_QMAKE_EXECUTABLE QT_MOC_EXECUTABLE > QT_RCC_EXECUTABLE QT_UIC_EXECUTABLE QT_INCLUDE_DIR QT_LIBRARY_DIR > QT_QTCORE_LIBRARY) I would not worry about this. At the end of the day the configure script bootstraps cmake. It works like this: 1. build a minimal version of cmake 2. use that cmake to configure cmake 3. then you type make, ninja or what ever to get the build. It would seem that what is happening with your build is that it is detecting curses, but badly. You might want to play around with --init=FILE load FILE as script to populate cache You could put BUILD_CursesDialog set to off in that script to keep it from trying to build curses. It would also be helpful if you could show more than just the build error. " The configure phase seems to work fine.. throws no errors" What does it do? Does it say something about curses? -Bill From wewolski at gmail.com Thu Nov 6 04:17:02 2014 From: wewolski at gmail.com (Witold E Wolski) Date: Thu, 6 Nov 2014 10:17:02 +0100 Subject: [CMake] [java] How do I add an "implements MyI" to Swig generated java class? In-Reply-To: References: Message-ID: An answer to my question https://stackoverflow.com/questions/5477747/cant-figure-out-how-to-make-swig-java-force-a-proxy-class-to-implement-an-inter On 5 November 2014 17:28, Witold E Wolski wrote: > I have some C++ classes which implement an interface. > > On the C++ side I have: > > struct Block{ > void waitForNotify()=0; > } > > class B : Listener{ > void waitForNotify(); > ... > } > > what I would love to get generated on the java side is: > > interface Block{ > void notifiy(); > } > > class B implements Block{ > swig gernated > private long swigCPtr; > protected boolean swigCMemOwn; > ... > .... > @Override > public boolean waitForNotify() { > return SwigTestWrappersJNI.B_waitForNotify(swigCPtr, this); > } > } > > But what I get when I tell swig to wrap the Block interface and the > class B is in java > > public class Block { > private long swigCPtr; > protected boolean swigCMemOwn; > > protected Block(long cPtr, boolean cMemoryOwn) { > swigCMemOwn = cMemoryOwn; > ..... > > } > > and > > public class B extends Block { > .... > > So I am thinking about a solution just to let swig wrap the class B > and declare in addition the interface Block also in java by hand but > what I am missing at the moment is how to tell swig to add to the auto > generated class B declaration the "implements Block" clause. > > Thank you > > > > -- > Witold Eryk Wolski -- Witold Eryk Wolski From andrew.bell.ia at gmail.com Thu Nov 6 12:22:27 2014 From: andrew.bell.ia at gmail.com (Andrew Bell) Date: Thu, 6 Nov 2014 11:22:27 -0600 Subject: [CMake] Policy Scope/Stack Message-ID: Hi, I'm setting policy through a file included with NO_POLICY_SCOPE, but I'm still having trouble with cmake complaining that a policy isn't set in a particular instance. Is there a way I can dump the policy stack or might someone have another suggesting on how to debug a problem where a policy isn't set though I think it should be? In particular, I'm dealing with CMP0042 and the documentation isn't clear which command (add_library() or target_link_library()) might be causing the policy warning. Thanks, -- Andrew Bell andrew.bell.ia at gmail.com From bill.hoffman at kitware.com Thu Nov 6 17:14:40 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 06 Nov 2014 17:14:40 -0500 Subject: [CMake] blog post on clang sanitizer additions to CTest/CDash Message-ID: <545BF2D0.2090303@kitware.com> I thought people on the list might be interested in this blog post: http://www.kitware.com/blog/home/post/762 Enjoy. -Bill From martin.apel at simpack.de Fri Nov 7 09:27:06 2014 From: martin.apel at simpack.de (Martin Apel) Date: Fri, 7 Nov 2014 15:27:06 +0100 Subject: [CMake] CMAKE_ROOT env variable not honored anymore Message-ID: <545CD6BA.9000700@simpack.de> Hi all, we used CMake 2.8 so far and had used the environment variable CMAKE_ROOT to tell the cmake binary, where to find its Modules etc. directories. We used this in a multiplatform context to store the architecture-independent files of CMake only once. It seems, that CMake 3.0 does not honor this environment variable anymore. Is this a bug or a feature? Martin From oliora at gmail.com Fri Nov 7 10:23:54 2014 From: oliora at gmail.com (Andrey Upadyshev) Date: Fri, 7 Nov 2014 16:23:54 +0100 Subject: [CMake] Calling of find_package from function Message-ID: Hello! I'm writing a wrapper around find_package so I call find_package from my own function. I found it's near impossible because all the variables set by finders remain in the scope of my wrapper function, rather than in the caller's scope. Is there any way to force find_package to set all variables in my function caller's scope? I.e. something like find_package(... PARENT_SCOPE)? Thank you, Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Fri Nov 7 10:39:34 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Fri, 7 Nov 2014 16:39:34 +0100 Subject: [CMake] Calling of find_package from function In-Reply-To: References: Message-ID: Hi Andrey. As a workaround, you could make the calling context a macro instead of a function. Macros don't introduce variable scope. Petr On Fri, Nov 7, 2014 at 4:23 PM, Andrey Upadyshev wrote: > Hello! > > I'm writing a wrapper around find_package so I call find_package from my > own function. I found it's near impossible because all the variables set by > finders remain in the scope of my wrapper function, rather than in the > caller's scope. Is there any way to force find_package to set all variables > in my function caller's scope? I.e. something like find_package(... > PARENT_SCOPE)? > > Thank you, > Andrey > > -- > > 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 oliora at gmail.com Fri Nov 7 10:56:19 2014 From: oliora at gmail.com (Andrey Upadyshev) Date: Fri, 7 Nov 2014 16:56:19 +0100 Subject: [CMake] Calling of find_package from function In-Reply-To: References: Message-ID: Thank you for advice Petr! I will go with this solution if can't find another one. CMake macroses are slightly weird so I'm trying to avoid them :) On Fri, Nov 7, 2014 at 4:39 PM, Petr Kmoch wrote: > Hi Andrey. > > As a workaround, you could make the calling context a macro instead of a > function. Macros don't introduce variable scope. > > Petr > > On Fri, Nov 7, 2014 at 4:23 PM, Andrey Upadyshev wrote: > >> Hello! >> >> I'm writing a wrapper around find_package so I call find_package from my >> own function. I found it's near impossible because all the variables set by >> finders remain in the scope of my wrapper function, rather than in the >> caller's scope. Is there any way to force find_package to set all variables >> in my function caller's scope? I.e. something like find_package(... >> PARENT_SCOPE)? >> >> Thank you, >> Andrey >> >> -- >> >> 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 oliora at gmail.com Fri Nov 7 12:44:21 2014 From: oliora at gmail.com (Andrey Upadyshev) Date: Fri, 7 Nov 2014 18:44:21 +0100 Subject: [CMake] Calling of find_package from function In-Reply-To: References: Message-ID: I've solved my problem with special macroses. First saves all non-cache variables (have to be called at the beginning of the function) and second one propagates all the changed/added variables to the parent scope (have to be called of at end of the function). If someone interested in code, it's here https://gist.github.com/oliora/4961727299ed67337aba Andrey On Fri, Nov 7, 2014 at 4:56 PM, Andrey Upadyshev wrote: > Thank you for advice Petr! I will go with this solution if can't find > another one. CMake macroses are slightly weird so I'm trying to avoid them > :) > > > On Fri, Nov 7, 2014 at 4:39 PM, Petr Kmoch wrote: > >> Hi Andrey. >> >> As a workaround, you could make the calling context a macro instead of a >> function. Macros don't introduce variable scope. >> >> Petr >> >> On Fri, Nov 7, 2014 at 4:23 PM, Andrey Upadyshev >> wrote: >> >>> Hello! >>> >>> I'm writing a wrapper around find_package so I call find_package from my >>> own function. I found it's near impossible because all the variables set by >>> finders remain in the scope of my wrapper function, rather than in the >>> caller's scope. Is there any way to force find_package to set all variables >>> in my function caller's scope? I.e. something like find_package(... >>> PARENT_SCOPE)? >>> >>> Thank you, >>> Andrey >>> >>> -- >>> >>> 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 ewmailing at gmail.com Fri Nov 7 18:50:32 2014 From: ewmailing at gmail.com (Eric Wing) Date: Fri, 7 Nov 2014 15:50:32 -0800 Subject: [CMake] CPack: .desktop files with tar.gz maker? Message-ID: I have a build and packaging system where I can distribute (mostly) standalone apps for Linux desktop. I am using the default CPack installer which creates .tar.gz, .Z, and .sh files. I like this opposed to the .deb/.rpm package systems because users don't need root access to install/use my stuff (and can place anywhere), and I only need a single package for all Linux desktops. But it's pretty plain-Jane and it would be nice to provide an icon or something. So I was wondering if anybody had suggestions/advice/strategies on supporting .desktop files. As far as I can tell, I need paths to the icon and the executable, which is completely variable based on where the user puts it. And I'm not sure where this file is supposed to be written to. (Remember that I don't use root access.) Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From clinton at elemtech.com Fri Nov 7 19:07:47 2014 From: clinton at elemtech.com (Clinton Stimpson) Date: Fri, 07 Nov 2014 17:07:47 -0700 Subject: [CMake] CPack: .desktop files with tar.gz maker? In-Reply-To: References: Message-ID: <5056611.nIJTuoAl0I@stryke> On Friday, November 07, 2014 03:50:32 PM Eric Wing wrote: > I have a build and packaging system where I can distribute (mostly) > standalone apps for Linux desktop. I am using the default CPack > installer which creates .tar.gz, .Z, and .sh files. > > I like this opposed to the .deb/.rpm package systems because users > don't need root access to install/use my stuff (and can place > anywhere), and I only need a single package for all Linux desktops. > > But it's pretty plain-Jane and it would be nice to provide an icon or > something. So I was wondering if anybody had > suggestions/advice/strategies on supporting .desktop files. As far as > I can tell, I need paths to the icon and the executable, which is > completely variable based on where the user puts it. And I'm not sure > where this file is supposed to be written to. (Remember that I don't > use root access.) > > Thanks, > Eric Perhaps you can do this: Include the .desktop file in your installation. To add, your installer can call xdg-desktop-menu install /share/applications/MyApp.desktop To remove, your installer can call xdg-desktop-menu uninstall /share/applications/MyApp.desktop If xdg-desktop-menu is called as root, it'll copy the .desktop file to the system location. If it is called as a non-root user, it'll copy the file to the user specific desktop area. xdg-desktop-menu also takes care of refreshing the icons in the launcher. During uninstall, it'll remove the copy. By the way, we do .rpm and .deb, but also give instructions for users to extract the files if they want their own installation directory. The above .desktop support can be put in a script and added to the postinst and prerm scripts for rpm and deb. This makes things more automatic for the majority of our users (basically download-click-and-run). Clint From jchris.fillionr at kitware.com Fri Nov 7 20:13:49 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Fri, 7 Nov 2014 20:13:49 -0500 Subject: [CMake] Using CMake to build an Emscripten output? In-Reply-To: References: Message-ID: Hi Eric, While I don't have yet an example dealing with assets, here is an example of project using emscripten. See https://github.com/commontk/dcmjs May be you could re-use the macro "em_add_tracked_link_flag" like it is done for --pre-js, etc .... See [1] Hth Jc [1] https://github.com/kripken/emscripten/blob/fe95de75315496bca817090cb65095b6731f59a2/cmake/Modules/Platform/Emscripten.cmake#L220-239 On Tue, Nov 4, 2014 at 8:20 PM, Eric Wing wrote: > Not that I really have time to fix this, but I was experimenting with > my C based codebase to see if I could compile it with Emscripten so it > could run in a browser. > > After working around a lot of scary compiler bugs, I got it to work. > But I invoked the build process by hand. So the next thing on my mind > is how to leverage CMake (since all my other platforms use it > already). > > My incantation for my test project is pretty straight foward and looks > very much like a clang invocation. The major difference is that all my > assets needed to be part of the compile process using the > --preload-file flag. (A minor difference is the output file ends in > .html) > > > ~/Source/GIT/emscripten/emcc -O2 --js-opts 0 -g4 CircularQueue.c > TimeTicker.c main_c.c -I/opt/local/emscripten/include > -I/opt/local/emscripten/include/SDL2 -I > /opt/local/emscripten/include/chipmunk > /opt/local/emscripten/lib/libSDL2_ttf.a > /opt/local/emscripten/lib/libfreetype.a > /opt/local/emscripten/lib/libSDL2_image.a > /opt/local/emscripten/lib/libpng.a /opt/local/emscripten/lib/libz.a > /opt/local/emscripten/lib/libALmixer.a > /opt/local/emscripten/lib/libchipmunk.a > /opt/local/emscripten/lib/libSDL2.a -o FlappyBlurrr.html > --preload-file fly2.png --preload-file fly1.png --preload-file > fly0.png --preload-file VeraMono.ttf --preload-file > gamecontrollerdb.txt --preload-file coin_ding.wav --preload-file > background.png --preload-file bush.png --preload-file clouds.png > --preload-file ground.png --preload-file pipe_bottom.png > --preload-file pipe_top.png --preload-file > davedes_fastsimplechop5b.wav --preload-file > LeftHook_SoundBible_com-516660386.wav --preload-file SlideWhistle.wav > --preload-file 14609__man__swosh.wav --preload-file acknowtt.ttf > --preload-file MedalBackground.png --preload-file > momoko_Bronze_Medallion.png --preload-file momoko_Silver_Medallion.png > --preload-file momoko_Gold_Medallion.png --preload-file > momoko_Platinum_Medallion.png --preload-file Placeholder_Medallion.png > --preload-file playbutton.png --preload-file quitbutton.png > --preload-file 04B_19__.TTF -s ASSERTIONS=1 > > > Anybody used CMake with Emscripten for this purpose? Or any thoughts > on what I should do? (I also have some concerns the preload-file list > is going to get too long. Perhaps I'm missing something with > Emscripten.) > > > Thanks, > Eric > -- > Beginning iPhone Games Development > http://playcontrol.net/iphonegamebook/ > -- > > 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 > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Fri Nov 7 20:21:32 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Fri, 7 Nov 2014 20:21:32 -0500 Subject: [CMake] Support OpenBLAS in FindBLAS module In-Reply-To: <4264631.hzuSDd0uN0@caliban.sf-tec.de> References: <4264631.hzuSDd0uN0@caliban.sf-tec.de> Message-ID: Hi Xianyi, By updating FindBlas.cmake, did you mean that the module should try to find OpenBlas if it could not find any other implementation ? Or do you want to provide an easy for developer to import the OpenBlas library in their project ? Either way, as described by Eike, the first step would be to update your project so that it can create a OpenBlasConfig.cmake. See [1] for some documentation With such a file, it would then be possible for developer to do something like: find_package(OpenBlas) .. and have the CMake targets available in the current scope. Let us know if you have any questions, Jc [1] http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html#creating-packages On Wed, Nov 5, 2014 at 2:10 AM, Rolf Eike Beer wrote: > Am Mittwoch, 5. November 2014, 09:20:15 schrieb Zhang Xianyi: > > Hi Folks, > > > > I am the developer of OpenBLAS, an optimized BLAS implementation forked > > from GotoBLAS2. > > > > So far, the FindBLAS.cmake module cannot recognize OpenBLAS as a > legitimate > > library. Is it possible to support OpenBLAS in FindBLAS module? > > Yes, but the preferable solution would be that you ship a > OpenBLASConfig.cmake > with your installation, so it would work with any CMake version and you can > adapt that file yourself in case of new components, library locations or > other > things. > > Eike > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Fri Nov 7 20:39:29 2014 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Fri, 7 Nov 2014 20:39:29 -0500 Subject: [CMake] ExternalProjectDependency (artichoke) and ctest In-Reply-To: <1415054761801-7588929.post@n2.nabble.com> References: <1415054761801-7588929.post@n2.nabble.com> Message-ID: Hi Jameson, Good to know you are using Artichoke. As you described Artichoke provides "ExternalProjectDependency", a CMake module extending the capabilities of ExternalProject. It could eventually by integrated into CMake once the API is stable, the documentation is complete it is more widely adopted. All of that said, here are few questions: - By using the add_custom_target/add_custom_command with POST_BUILD, is your intent to systematically start the test once the build is done ? - Or are you trying to add a "test" target at the top-level that would run the test of all projects ? Finally, the addition ExternalProject_Install_CMake was an attempt to facilitate installation of the whole project by having "make install" working in the top-level build directory. We would have to first address an issue in CMake itself http://www.cmake.org/Bug/view.php?id=14955. For now, to avoid confusion, I will remove the function. Hth Jc On Mon, Nov 3, 2014 at 5:46 PM, jmerkow wrote: > Hello, > > My project is using ExternalProjectDependency from [1]. I know that is not > a > kitware/cmake project, but I thought Id ask here anyway.... > I have been using testing (ctest) with it by adding tests in the top level > build with hard-coded directories and names (these targets aren't built > until the non-superbuild project is built). I wanted to move the tests to > the non-superbuild portion of the code so I can use generator expressions, > but I am having some trouble. > > Basically, what I am doing is to include ctest in the non-superbuild > portion > then add a custom target. This works for 'make test' but does not work > with > ctest. > > add_custom_target(test) > add_custom_command(TARGET test POST_BUILD > COMMAND ${CMAKE_COMMAND} --build ${${PROJECT_NAME}_BINARY_DIR}/build > --target test) > > ExternalProjectDependency added a function to add install: > 'ExternalProject_Install_CMake' I don't see a similar function for testing. > Is there another good way to do this? Im not sure what ctest calls to > initiate testing, using that info, I might be able to get a good work > around. > > -Jameson > > [1] https://github.com/commontk/Artichoke > > > > -- > View this message in context: > http://cmake.3232098.n2.nabble.com/ExternalProjectDependency-artichoke-and-ctest-tp7588929.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ewmailing at gmail.com Sun Nov 9 07:22:08 2014 From: ewmailing at gmail.com (Eric Wing) Date: Sun, 9 Nov 2014 04:22:08 -0800 Subject: [CMake] CPack: .desktop files with tar.gz maker? In-Reply-To: <5056611.nIJTuoAl0I@stryke> References: <5056611.nIJTuoAl0I@stryke> Message-ID: On 11/7/14, Clinton Stimpson wrote: > On Friday, November 07, 2014 03:50:32 PM Eric Wing wrote: >> I have a build and packaging system where I can distribute (mostly) >> standalone apps for Linux desktop. I am using the default CPack >> installer which creates .tar.gz, .Z, and .sh files. >> >> I like this opposed to the .deb/.rpm package systems because users >> don't need root access to install/use my stuff (and can place >> anywhere), and I only need a single package for all Linux desktops. >> >> But it's pretty plain-Jane and it would be nice to provide an icon or >> something. So I was wondering if anybody had >> suggestions/advice/strategies on supporting .desktop files. As far as >> I can tell, I need paths to the icon and the executable, which is >> completely variable based on where the user puts it. And I'm not sure >> where this file is supposed to be written to. (Remember that I don't >> use root access.) >> >> Thanks, >> Eric > > Perhaps you can do this: > > Include the .desktop file in your installation. > > To add, your installer can call > xdg-desktop-menu install /share/applications/MyApp.desktop > > To remove, your installer can call > xdg-desktop-menu uninstall /share/applications/MyApp.desktop > > If xdg-desktop-menu is called as root, it'll copy the .desktop file to the > system location. If it is called as a non-root user, it'll copy the file to > > the user specific desktop area. xdg-desktop-menu also takes care of > refreshing > the icons in the launcher. > > During uninstall, it'll remove the copy. > > By the way, we do .rpm and .deb, but also give instructions for users to > extract the files if they want their own installation directory. > > The above .desktop support can be put in a script and added to the postinst > > and prerm scripts for rpm and deb. > > This makes things more automatic for the majority of our users (basically > download-click-and-run). > > Clint > > Thanks for the information. Based on that, I wrote a script that is bundled with the contents and when run, will generate the correct .desktop file with the correct absolute paths needed and invoke xdg-desktop-menu install. I noticed that the CPack tarball generator also generates a self-extracting .sh ball. Is there anyway to hook into that to add a postinst like stage so I can invoke my script? Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ From elfring at users.sourceforge.net Sun Nov 9 14:34:05 2014 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Sun, 09 Nov 2014 20:34:05 +0100 Subject: [CMake] Automatic regeneration of software packages by CPack? Message-ID: <545FC1AD.2030502@users.sourceforge.net> Hello, I configured a specific software to use the CPack modules to generate corresponding DEB and RPM packages together with CMake 3 a while ago. I notice now that package specifications and control files contain outdated version data after I called the command "make package". How can I achieve that another build dependency is automatically considered there? Regards, Markus From kris at asc.uk.com Sun Nov 9 18:46:26 2014 From: kris at asc.uk.com (Kris Thielemans) Date: Sun, 9 Nov 2014 23:46:26 -0000 Subject: [CMake] problems with Visual Studio Express 2013 [SOLVED, I think] Message-ID: <371f01cffc77$6109be50$231d3af0$@asc.uk.com> > From: Kris Thielemans > Sent: 05 March 2014 11:28 > > Hi all > > We're trying to build an application using ITK on Windows using Visual Studio > Express 2013 (downloads of all software happened last week, so I guess > we're up-to-date). Unfortunately, we get a lot of configuration errors (see full > list below), implying that CMake 2.8.12.2 has problems with this compiler. > The first one is like this: > > CMake Error at C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/CMakeDetermineCompilerId.cmake:311 > (file): > file STRINGS file > > > We first thought that we could get through this, as when pressing the > Configure button again, those warnings disappear, and we can generate the > project files, and VSE2013 loads them without problem, and indeed even can > compile. However, we do get a lot of errors building ITK. On closer > inspection, the compiler flags are not set properly (for instance, exception > handling is not enabled). Indeed, checking the CMake Advanced variables, all > compiler flags are just empty. > Hi all, I had a related problem on another computer just now, this time figured out what I did wrong, and so thought that I'd send it out for benefit of others. This time, I didn't have any configuration errors as above, but I did have loads of build errors because the CMAKE_CXX_FLAGS were again all empty. What happened was the following: I installed Visual Studio for Windows (wrong!), ran CMake forcing it to use Visual Studio 2013, it loudly complained that it couldn't find the compiler, I realised my mistake and installed Visual Studio for Desktop (right!), and ran CMake, re-configuring the build. CMake was happy, but obviously the projects were faulty. The solution was simple: clear the cache, get rid of the whole build directory and start from scratch. Oh well. I hope that my struggles will help somebody else... Kris From rcdailey.lists at gmail.com Sun Nov 9 23:02:55 2014 From: rcdailey.lists at gmail.com (Robert Dailey) Date: Sun, 9 Nov 2014 22:02:55 -0600 Subject: [CMake] Removing compiler options Message-ID: When setting up a CLR project through CMake, it becomes important to be able to *remove* compiler options at the project level. For example, the following need to be removed (MSVC12): /RTC1 /EHsc There is no "remove_compile_options()" (which would be convenient). Any reason why this doesn't exist? Right now I'm trying to remove these via CMAKE_CXX_FLAGS locally but this doesn't work unless I forcefully change the cache. But this is a permanent operation that affects *all* projects, which I do not want. This is crazy, I'm hoping there is a better way. I'm using CMake 3.1 RC1. Can anyone help me figure out how to remove compiler options on a per-project basis? Here is what I'm doing: function( add_clr_library target_name references ) set( source_files ${ARGN} ) set( default_references System System.Core System.Data System.Drawing #System.Xml #WindowsBase ) if( CMAKE_CXX_FLAGS_DEBUG MATCHES "/RTC1" ) string( REGEX REPLACE "/RTC(su|[1su])" "" CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG}" ) endif() if( CMAKE_CXX_FLAGS MATCHES "/EHsc" ) string( REPLACE "/EHsc" "" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}" ) endif() add_library( ${target_name} SHARED ${source_files} ) list( APPEND references ${default_references} ) set_target_properties( ${target_name} PROPERTIES VS_DOTNET_REFERENCES "${references}" VS_DOTNET_TARGET_FRAMEWORK_VERSION "v4.5" COMPILE_FLAGS "/clr /EHa" DEBUG_POSTFIX "d" ) endfunction() From yue.nicholas at gmail.com Mon Nov 10 00:32:06 2014 From: yue.nicholas at gmail.com (Nicholas Yue) Date: Sun, 9 Nov 2014 21:32:06 -0800 Subject: [CMake] FIND_PACKAGE () : self location ? Message-ID: Hi, I am improving an in-house Find*.cmake and need to determine (programmatically) where it (the Find*.cmake file) is located because I need to run a companion python script. Is there some variable I can query ? If not, I will find a different way but the above seems more intuitive and less fragile when moving things around. Cheers -- Nicholas Yue Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows http://au.linkedin.com/in/nicholasyue https://vimeo.com/channels/naiadtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From yue.nicholas at gmail.com Mon Nov 10 01:44:32 2014 From: yue.nicholas at gmail.com (Nicholas Yue) Date: Sun, 9 Nov 2014 22:44:32 -0800 Subject: [CMake] Generator : "Visual Studio 11 Win64" - AdditionalIncludeDirectories error Message-ID: Hi, Using CMake 2.8.12.2 on Windows 7 x64 with Visual Studio 2012 WDExpress, my include_directories() information are being embedded in the AdditionalOptions part of the generated *.vcxproj XML file instead of the AdditionalIncludeDirectories part I have tried with CMake 3.0.x, same problem This cause the builds to fail because the compiler options will be filled with incorrect information. I tried googling but it does not seem to be an existing problem. Is my installation bad otherwise, is there a work around ? Cheers -- Nicholas Yue Graphics - Arnold, Alembic, RenderMan, OpenGL, HDF5 Custom Dev - C++ porting, OSX, Linux, Windows http://au.linkedin.com/in/nicholasyue https://vimeo.com/channels/naiadtools -------------- next part -------------- An HTML attachment was scrubbed... URL: From nilsgladitz at gmail.com Mon Nov 10 03:52:12 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 10 Nov 2014 09:52:12 +0100 Subject: [CMake] FIND_PACKAGE () : self location ? In-Reply-To: References: Message-ID: <54607CBC.5020902@gmail.com> On 11/10/2014 06:32 AM, Nicholas Yue wrote: > I am improving an in-house Find*.cmake and need to determine > (programmatically) where it (the Find*.cmake file) is located because I > need to run a companion python script. Is there some variable I can query ? CMAKE_CURRENT_LIST_DIR for the full path to the parent directory or CMAKE_CURRENT_LIST_FILE for the full path of the script file itself. Nils From nilsgladitz at gmail.com Mon Nov 10 03:58:33 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Mon, 10 Nov 2014 09:58:33 +0100 Subject: [CMake] Generator : "Visual Studio 11 Win64" - AdditionalIncludeDirectories error In-Reply-To: References: Message-ID: <54607E39.1080202@gmail.com> On 11/10/2014 07:44 AM, Nicholas Yue wrote: > Hi, > > Using CMake 2.8.12.2 on Windows 7 x64 with Visual Studio 2012 > WDExpress, my include_directories() information are being embedded in > the AdditionalOptions part of the generated *.vcxproj XML file instead > of the AdditionalIncludeDirectories part > > I have tried with CMake 3.0.x, same problem > > This cause the builds to fail because the compiler options will be > filled with incorrect information. Can you provide a self-contained minimal example that reproduces the problem? Nils From micha.hergarden at gmail.com Mon Nov 10 13:01:49 2014 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Mon, 10 Nov 2014 19:01:49 +0100 Subject: [CMake] Automatic regeneration of software packages by CPack? In-Reply-To: <545FC1AD.2030502@users.sourceforge.net> References: <545FC1AD.2030502@users.sourceforge.net> Message-ID: <5460FD8D.2040003@gmail.com> On 11/09/2014 08:34 PM, SF Markus Elfring wrote: > Hello, > > I configured a specific software to use the CPack modules to generate > corresponding DEB and RPM packages together with CMake 3 a while ago. > > I notice now that package specifications and control files contain > outdated version data after I called the command "make package". > How can I achieve that another build dependency is automatically > considered there? > > Regards, > Markus Hello, You could, as a workaround for the problem, define a add_custom_target that removes the corresponding rpm/deb packages and just calls 'cmake --build --target package' to regenerate them. It's not an ideal solution, but it worked just fine for me. Regards, Micha -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From micha.hergarden at gmail.com Mon Nov 10 13:44:46 2014 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Mon, 10 Nov 2014 19:44:46 +0100 Subject: [CMake] Automatic regeneration of software packages by CPack? In-Reply-To: <54610684.2020006@users.sourceforge.net> References: <545FC1AD.2030502@users.sourceforge.net> <5460FD8D.2040003@gmail.com> <54610684.2020006@users.sourceforge.net> Message-ID: <5461079E.2010101@gmail.com> On 11/10/2014 07:40 PM, SF Markus Elfring wrote: >> You could, as a workaround for the problem, define a add_custom_target >> that removes the corresponding rpm/deb packages and just calls 'cmake >> --build --target package' to regenerate them. > Thanks for your suggestion. > > >> It's not an ideal solution, but it worked just fine for me. > Does this feedback mean that you stumbled also on missing build > dependencies around generation of DEB and RPM packages with CPack? > > Regards, > Markus Not sure.. cpack is an external tool in the perspective of cmake, so in that respect I don't think you need/want this kind of integration. On the other hand, this type of operation does seem to pop up quite often. I actually don't know if this is an omission or a deliberate design choice. Regards, Micha -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From elfring at users.sourceforge.net Mon Nov 10 13:40:04 2014 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Mon, 10 Nov 2014 19:40:04 +0100 Subject: [CMake] Automatic regeneration of software packages by CPack? In-Reply-To: <5460FD8D.2040003@gmail.com> References: <545FC1AD.2030502@users.sourceforge.net> <5460FD8D.2040003@gmail.com> Message-ID: <54610684.2020006@users.sourceforge.net> > You could, as a workaround for the problem, define a add_custom_target > that removes the corresponding rpm/deb packages and just calls 'cmake > --build --target package' to regenerate them. Thanks for your suggestion. > It's not an ideal solution, but it worked just fine for me. Does this feedback mean that you stumbled also on missing build dependencies around generation of DEB and RPM packages with CPack? Regards, Markus From elfring at users.sourceforge.net Mon Nov 10 13:50:23 2014 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Mon, 10 Nov 2014 19:50:23 +0100 Subject: [CMake] Automatic regeneration of software packages by CPack? In-Reply-To: <5461079E.2010101@gmail.com> References: <545FC1AD.2030502@users.sourceforge.net> <5460FD8D.2040003@gmail.com> <54610684.2020006@users.sourceforge.net> <5461079E.2010101@gmail.com> Message-ID: <546108EF.3000808@users.sourceforge.net> > I actually don't know if this is an omission or a deliberate design choice. How often do use DEB and RPM package generation with CPack for your software? Regards, Markus From micha.hergarden at gmail.com Mon Nov 10 13:55:21 2014 From: micha.hergarden at gmail.com (Micha Hergarden) Date: Mon, 10 Nov 2014 19:55:21 +0100 Subject: [CMake] Automatic regeneration of software packages by CPack? In-Reply-To: <546108EF.3000808@users.sourceforge.net> References: <545FC1AD.2030502@users.sourceforge.net> <5460FD8D.2040003@gmail.com> <54610684.2020006@users.sourceforge.net> <5461079E.2010101@gmail.com> <546108EF.3000808@users.sourceforge.net> Message-ID: <54610A19.80009@gmail.com> On 11/10/2014 07:50 PM, SF Markus Elfring wrote: >> I actually don't know if this is an omission or a deliberate design choice. > How often do use DEB and RPM package generation with CPack for your software? > > Regards, > Markus I used it quite often (only rpm), but having said that: I had a need for creating packages and signing them. In some cases that meant 'rebuild packages & sign', in others that meant 'just resign, don't rebuild'. This meant that having a few custom commands was actually handy. Regards, Micha -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From elfring at users.sourceforge.net Mon Nov 10 15:45:26 2014 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Mon, 10 Nov 2014 21:45:26 +0100 Subject: [CMake] Distinguishing between source and binary packages with CPack? Message-ID: <546123E6.4080905@users.sourceforge.net> Hello, Software package formats like DEB and RPM can help to distinguish the provided contents between source and binary files. https://wiki.debian.org/SourcePackage http://www.rpm.org/max-rpm/s1-rpm-miscellania-srpms.html How can I achieve a corresponding distinction with CPack? http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack#Ideas_for_Future_Development Regards, Markus From Anjaneyulu.Korapu-contr at trw.com Mon Nov 10 15:50:50 2014 From: Anjaneyulu.Korapu-contr at trw.com (Anjaneyulu Korapu-contr) Date: Mon, 10 Nov 2014 20:50:50 +0000 Subject: [CMake] How to import Visual studio project properties using Cmake Message-ID: Hello CMake Team, I would like to know how to import Visual studio project properties using CMAKE? And what is the equivalent command for element in CMake? Below is the section in the *.vcxproj file where I am importing General_Project_Properties.props file. Example : Thanks Anji -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgorac at gmail.com Mon Nov 10 17:03:30 2014 From: cgorac at gmail.com (cgorac) Date: Mon, 10 Nov 2014 15:03:30 -0700 (MST) Subject: [CMake] L In-Reply-To: <4264631.hzuSDd0uN0@caliban.sf-tec.de> References: <4264631.hzuSDd0uN0@caliban.sf-tec.de> Message-ID: <1415657010919-7588979.post@n2.nabble.com> Rolf Eike Beer wrote > Yes, but the preferable solution would be that you ship a > OpenBLASConfig.cmake > with your installation, so it would work with any CMake version and you > can > adapt that file yourself in case of new components, library locations or > other > things. Why would OpenBLAS have to do this, when none of other BLAS implementations supported by FindBLAS.cmake aren't? OpenBLAS is probably the most convenient open source BLAS implementation to use at the moment, plus very fast, and it would really make every sense to have it supported by CMake. Furthermore, I think rather simple change to FindBLAS.cmake is needed to support it: basically, as OpenBLAS is derived from Goto BLAS implementation, probably Goto BLAS related segment of FindBLAS.cmake should be just duplicated, with "Goto" changed to "OpenBLAS", and "goto2" changed to "openblas". On the other side, same type of addition would be needed for FindLAPACK.cmake, as OpenBLAS is implementing LAPACK too (also through libopenblas.{a,so} library). Thanks. -- View this message in context: http://cmake.3232098.n2.nabble.com/Support-OpenBLAS-in-FindBLAS-module-tp7588937p7588979.html Sent from the CMake mailing list archive at Nabble.com. From post at hendrik-sattler.de Mon Nov 10 17:34:20 2014 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Mon, 10 Nov 2014 23:34:20 +0100 Subject: [CMake] Distinguishing between source and binary packages with CPack? In-Reply-To: <546123E6.4080905@users.sourceforge.net> References: <546123E6.4080905@users.sourceforge.net> Message-ID: Am 10. November 2014 21:45:26 MEZ, schrieb SF Markus Elfring : >Hello, > >Software package formats like DEB and RPM can help to distinguish >the provided contents between source and binary files. >https://wiki.debian.org/SourcePackage >http://www.rpm.org/max-rpm/s1-rpm-miscellania-srpms.html This question is twisted. There is no need for a .src.rpm when you don't embed the build rules into it. However, that only makes sense for distributions that have a package maintainer for the software, creates a source package with all build options and distribution adaptions. See it as a special format to help implement build infrastructure tools. HS From mike.jackson at bluequartz.net Mon Nov 10 21:30:14 2014 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Mon, 10 Nov 2014 21:30:14 -0500 Subject: [CMake] L In-Reply-To: <1415657010919-7588979.post@n2.nabble.com> References: <4264631.hzuSDd0uN0@caliban.sf-tec.de> <1415657010919-7588979.post@n2.nabble.com> Message-ID: On Nov 10, 2014, at 5:03 PM, cgorac wrote: > > Rolf Eike Beer wrote >> Yes, but the preferable solution would be that you ship a >> OpenBLASConfig.cmake >> with your installation, so it would work with any CMake version and you >> can >> adapt that file yourself in case of new components, library locations or >> other >> things. > > Why would OpenBLAS have to do this, when none of other BLAS implementations > supported by FindBLAS.cmake aren't? > > OpenBLAS is probably the most convenient open source BLAS implementation to > use at the moment, plus very fast, and it would really make every sense to > have it supported by CMake. Furthermore, I think rather simple change to > FindBLAS.cmake is needed to support it: basically, as OpenBLAS is derived > from Goto BLAS implementation, probably Goto BLAS related segment of > FindBLAS.cmake should be just duplicated, with "Goto" changed to "OpenBLAS", > and "goto2" changed to "openblas". On the other side, same type of addition > would be needed for FindLAPACK.cmake, as OpenBLAS is implementing LAPACK too > (also through libopenblas.{a,so} library). > > Thanks. > Because if you do this then OpenBlas is instantly supported by currently released versions of CMake. If you are asking for an update to the core of CMake then you are going to have to wait for the next release of CMake and then ALL of your users are going to have to update their CMake installations. This may or may NOT be possible on all those systems. Having used OpenBLAS for a current project I would like to see the OpenBLAS developers step up and set an example for the other projects and properly support CMake. Just my 2 cents worth. Mike Jackson:: BlueQuartz Software From elfring at users.sourceforge.net Tue Nov 11 02:50:26 2014 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Tue, 11 Nov 2014 08:50:26 +0100 Subject: [CMake] Distinguishing between source and binary packages with CPack? In-Reply-To: References: <546123E6.4080905@users.sourceforge.net> Message-ID: <5461BFC2.9010903@users.sourceforge.net> > There is no need for a .src.rpm when you don't embed the build rules into it. > However, that only makes sense for distributions that have a package maintainer for the software, > creates a source package with all build options and distribution adaptions. Have you got any more ideas for the fine-tuning around the packaging of a class library for the OCaml programming language? https://github.com/elfring/OTCL/blob/eca1ed17f70176435c8575eb55a67cca33926905/package_settings.cmake#L1 Regards, Markus From cgorac at gmail.com Tue Nov 11 03:35:59 2014 From: cgorac at gmail.com (Crni Gorac) Date: Tue, 11 Nov 2014 09:35:59 +0100 Subject: [CMake] L In-Reply-To: References: <4264631.hzuSDd0uN0@caliban.sf-tec.de> <1415657010919-7588979.post@n2.nabble.com> Message-ID: On Tue, Nov 11, 2014 at 3:30 AM, Michael Jackson wrote: > > Because if you do this then OpenBlas is instantly supported by currently released versions of CMake. If you are asking for an update to the core of CMake then you are going to have to wait for the next release of CMake and then ALL of your users are going to have to update their CMake installations. This may or may NOT be possible on all those systems. Having used OpenBLAS for a current project I would like to see the OpenBLAS developers step up and set an example for the other projects and properly support CMake. Just my 2 cents worth. > This is moot argument - if OpenBLAS provides OpenBLASConfig.cmake, then its users have to update something (OpenBLAS in this case) anyway, in order to have OpenBLAS+CMake working properly together... So, again: as a CMake/OpenBLAS user, I really see no point in requiring something from OpenBLAS that none of dozen of currently supported BLAS implementations is doing. Thanks. From petr.kmoch at gmail.com Tue Nov 11 08:37:18 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Tue, 11 Nov 2014 14:37:18 +0100 Subject: [CMake] L In-Reply-To: References: <4264631.hzuSDd0uN0@caliban.sf-tec.de> <1415657010919-7588979.post@n2.nabble.com> Message-ID: Hi all. I am not using OpenBLAS so this is really just a tangential comment, but I can understand that in a production setting, it can be easier to update a library than to update something as fundamental to the build process as CMake. To the point where the former is authorisable on a much lower hierarchy level. Perhaps simply because it only affects a small fraction of the entire project, whereas a change in CMake affects everything. Petr On Tue, Nov 11, 2014 at 9:35 AM, Crni Gorac wrote: > On Tue, Nov 11, 2014 at 3:30 AM, Michael Jackson > wrote: > > > > Because if you do this then OpenBlas is instantly supported by currently > released versions of CMake. If you are asking for an update to the core of > CMake then you are going to have to wait for the next release of CMake and > then ALL of your users are going to have to update their CMake > installations. This may or may NOT be possible on all those systems. Having > used OpenBLAS for a current project I would like to see the OpenBLAS > developers step up and set an example for the other projects and properly > support CMake. Just my 2 cents worth. > > > > This is moot argument - if OpenBLAS provides OpenBLASConfig.cmake, > then its users have to update something (OpenBLAS in this case) > anyway, in order to have OpenBLAS+CMake working properly together... > So, again: as a CMake/OpenBLAS user, I really see no point in > requiring something from OpenBLAS that none of dozen of currently > supported BLAS implementations is doing. > > Thanks. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clinton at elemtech.com Tue Nov 11 09:43:12 2014 From: clinton at elemtech.com (clinton at elemtech.com) Date: Tue, 11 Nov 2014 07:43:12 -0700 (MST) Subject: [CMake] CPack: .desktop files with tar.gz maker? In-Reply-To: References: <5056611.nIJTuoAl0I@stryke> Message-ID: <889875133.322494.1415716992983.JavaMail.zimbra@elemtech.com> ----- Original Message ----- > On 11/7/14, Clinton Stimpson wrote: > > On Friday, November 07, 2014 03:50:32 PM Eric Wing wrote: > >> I have a build and packaging system where I can distribute (mostly) > >> standalone apps for Linux desktop. I am using the default CPack > >> installer which creates .tar.gz, .Z, and .sh files. > >> > >> I like this opposed to the .deb/.rpm package systems because users > >> don't need root access to install/use my stuff (and can place > >> anywhere), and I only need a single package for all Linux desktops. > >> > >> But it's pretty plain-Jane and it would be nice to provide an icon or > >> something. So I was wondering if anybody had > >> suggestions/advice/strategies on supporting .desktop files. As far as > >> I can tell, I need paths to the icon and the executable, which is > >> completely variable based on where the user puts it. And I'm not sure > >> where this file is supposed to be written to. (Remember that I don't > >> use root access.) > >> > >> Thanks, > >> Eric > > > > Perhaps you can do this: > > > > Include the .desktop file in your installation. > > > > To add, your installer can call > > xdg-desktop-menu install /share/applications/MyApp.desktop > > > > To remove, your installer can call > > xdg-desktop-menu uninstall /share/applications/MyApp.desktop > > > > If xdg-desktop-menu is called as root, it'll copy the .desktop file to the > > system location. If it is called as a non-root user, it'll copy the file > > to > > > > the user specific desktop area. xdg-desktop-menu also takes care of > > refreshing > > the icons in the launcher. > > > > During uninstall, it'll remove the copy. > > > > By the way, we do .rpm and .deb, but also give instructions for users to > > extract the files if they want their own installation directory. > > > > The above .desktop support can be put in a script and added to the postinst > > > > and prerm scripts for rpm and deb. > > > > This makes things more automatic for the majority of our users (basically > > download-click-and-run). > > > > Clint > > > > > > Thanks for the information. Based on that, I wrote a script that is > bundled with the contents and when run, will generate the correct > .desktop file with the correct absolute paths needed and invoke > xdg-desktop-menu install. > > I noticed that the CPack tarball generator also generates a > self-extracting .sh ball. Is there anyway to hook into that to add a > postinst like stage so I can invoke my script? > You can copy CMake/Modules/CPack.STGZ_Header.sh.in, make your modifications, then set CPACK_STGZ_HEADER_FILE to point to it. Clint From post at hendrik-sattler.de Tue Nov 11 11:36:34 2014 From: post at hendrik-sattler.de (Hendrik Sattler) Date: Tue, 11 Nov 2014 17:36:34 +0100 Subject: [CMake] Distinguishing between source and binary packages with CPack? In-Reply-To: <5461BFC2.9010903@users.sourceforge.net> References: <546123E6.4080905@users.sourceforge.net> <5461BFC2.9010903@users.sourceforge.net> Message-ID: <03332482-D47D-4117-B542-0BF814D7000A@hendrik-sattler.de> Am 11. November 2014 08:50:26 MEZ, schrieb SF Markus Elfring : >> There is no need for a .src.rpm when you don't embed the build rules >into it. >> However, that only makes sense for distributions that have a package >maintainer for the software, >> creates a source package with all build options and distribution >adaptions. > >Have you got any more ideas for the fine-tuning around the packaging of >a class library >for the OCaml programming language? >https://github.com/elfring/OTCL/blob/eca1ed17f70176435c8575eb55a67cca33926905/package_settings.cmake#L1 That may be sufficient for creating a .deb. For integration into Debian, you should read http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/ HS From elfring at users.sourceforge.net Tue Nov 11 11:55:40 2014 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Tue, 11 Nov 2014 17:55:40 +0100 Subject: [CMake] Distinguishing between source and binary packages with CPack? In-Reply-To: <03332482-D47D-4117-B542-0BF814D7000A@hendrik-sattler.de> References: <546123E6.4080905@users.sourceforge.net> <5461BFC2.9010903@users.sourceforge.net> <03332482-D47D-4117-B542-0BF814D7000A@hendrik-sattler.de> Message-ID: <54623F8C.4000502@users.sourceforge.net> >> https://github.com/elfring/OTCL/blob/eca1ed17f70176435c8575eb55a67cca33926905/package_settings.cmake#L1 > > That may be sufficient for creating a .deb. For integration into Debian, you should read > http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/ Thanks for your link. Can it be that the CPack software concentrates on the creation of binary packages for the formats "DEB", "NSIS" and "RPM" so far? It seems that options (like CPACK_SOURCE_TBZ2) can be set for archive formats. Regards, Markus From eric.noulard at gmail.com Tue Nov 11 12:39:11 2014 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 11 Nov 2014 18:39:11 +0100 Subject: [CMake] Distinguishing between source and binary packages with CPack? In-Reply-To: <54623F8C.4000502@users.sourceforge.net> References: <546123E6.4080905@users.sourceforge.net> <5461BFC2.9010903@users.sourceforge.net> <03332482-D47D-4117-B542-0BF814D7000A@hendrik-sattler.de> <54623F8C.4000502@users.sourceforge.net> Message-ID: 2014-11-11 17:55 GMT+01:00 SF Markus Elfring : > >> > https://github.com/elfring/OTCL/blob/eca1ed17f70176435c8575eb55a67cca33926905/package_settings.cmake#L1 > > > > That may be sufficient for creating a .deb. For integration into Debian, > you should read > > http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/ > > Thanks for your link. > > > Can it be that the CPack software concentrates on the creation of binary > packages > for the formats "DEB", "NSIS" and "RPM" so far? > It depends on the platform you are running on but no, there are more generator than those 3 see partial list here: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators you should add at least WiX and IFW that can be seen, from source. (see /Source/CPack/*) > It seems that options (like CPACK_SOURCE_TBZ2) can be set for archive > formats. > You can read the doc about CPACK_xxx variables. For 2.8.x: http://www.cmake.org/cmake/help/v2.8.12/cpack.html For 3.0.x: http://www.cmake.org/cmake/help/v3.0/manual/cpack.1.html and all CPackXXXX modules in: http://www.cmake.org/cmake/help/v3.0/manual/cmake-modules.7.html and some global vars as well: http://www.cmake.org/cmake/help/v3.0/manual/cmake-variables.7.html#variables-for-cpack or may be a search will do as well: http://www.cmake.org/cmake/help/v3.0/search.html?q=CPACK -- Eric L'?lection n'est pas la d?mocratie -- http://www.le-message.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From elfring at users.sourceforge.net Tue Nov 11 13:02:47 2014 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Tue, 11 Nov 2014 19:02:47 +0100 Subject: [CMake] Distinguishing between source and binary packages with CPack? In-Reply-To: References: <546123E6.4080905@users.sourceforge.net> <5461BFC2.9010903@users.sourceforge.net> <03332482-D47D-4117-B542-0BF814D7000A@hendrik-sattler.de> <54623F8C.4000502@users.sourceforge.net> Message-ID: <54624F47.9040401@users.sourceforge.net> > http://www.cmake.org/cmake/help/v3.0/manual/cpack.1.html Can it be automatically determined which of the available archive and package generators support a distinction between source and binary files? Regards, Markus From eric.noulard at gmail.com Tue Nov 11 13:26:47 2014 From: eric.noulard at gmail.com (Eric Noulard) Date: Tue, 11 Nov 2014 19:26:47 +0100 Subject: [CMake] Distinguishing between source and binary packages with CPack? In-Reply-To: <54624F47.9040401@users.sourceforge.net> References: <546123E6.4080905@users.sourceforge.net> <5461BFC2.9010903@users.sourceforge.net> <03332482-D47D-4117-B542-0BF814D7000A@hendrik-sattler.de> <54623F8C.4000502@users.sourceforge.net> <54624F47.9040401@users.sourceforge.net> Message-ID: 2014-11-11 19:02 GMT+01:00 SF Markus Elfring : > > http://www.cmake.org/cmake/help/v3.0/manual/cpack.1.html > > Can it be automatically determined which of the available archive and > package generators > support a distinction between source and binary files? > None of them are distinguishing source vs binary but the cygwin generator. For CPack a source generator is a binary generator which is told to package a directory which happens to contains the source. Basically package source generator (in the sense of RPM, DEB and alike) are unsupported. You can search the ML archive for similar discussion on the subject: e.g: http://www.cmake.org/pipermail/cmake/2010-August/038767.html http://www.cmake.org/pipermail/cmake/2010-October/040329.html -- Eric L'?lection n'est pas la d?mocratie -- http://www.le-message.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From elfring at users.sourceforge.net Tue Nov 11 15:10:32 2014 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Tue, 11 Nov 2014 21:10:32 +0100 Subject: [CMake] Distinguishing between source and binary packages with CPack? In-Reply-To: References: <546123E6.4080905@users.sourceforge.net> <5461BFC2.9010903@users.sourceforge.net> <03332482-D47D-4117-B542-0BF814D7000A@hendrik-sattler.de> <54623F8C.4000502@users.sourceforge.net> <54624F47.9040401@users.sourceforge.net> Message-ID: <54626D38.50705@users.sourceforge.net> > For CPack a source generator is a binary generator which is told to package > a directory which happens to contains the source. Interesting ... Do I need to introduce additional options with the prefix "CPACK_SOURCE_" for the package generators in my build configuration? > Basically package source generator (in the sense of RPM, DEB and alike) > are unsupported. I hope that this situation can be improved somehow. Regards, Markus From norulez at me.com Wed Nov 12 03:45:59 2014 From: norulez at me.com (NoRulez) Date: Wed, 12 Nov 2014 09:45:59 +0100 Subject: [CMake] Green Hills Generator #0014992 Message-ID: <20809D15-5525-4B03-BE24-5B8B4F4959FA@me.com> Hi, is it possible to get the patch for the green hills generator into CMake 3.1 Thanks in advance Best Regards From dlchnr at gmx.net Wed Nov 12 08:34:35 2014 From: dlchnr at gmx.net (Udo Lechner) Date: Wed, 12 Nov 2014 14:34:35 +0100 Subject: [CMake] codelite project files including debug AND release configuration? Message-ID: An HTML attachment was scrubbed... URL: From contact at ligh.de Thu Nov 13 03:51:05 2014 From: contact at ligh.de (=?utf-8?Q?Mario_*LigH*_Rohkr=C3=A4mer?=) Date: Thu, 13 Nov 2014 09:51:05 +0100 Subject: [CMake] CMP0053: Unable to refer to $ENV{PROGRAMFILES(X86)} Message-ID: Greetings. Updating CMake to v3.1.0-rc1, I get a warning CMP0053 when building the x265 project (https://bitbucket.org/multicoreware/x265). source/cmake/FindVLD.cmake contains a statement listing several paths where to look for an installation of the Visual Leak Detector: +---- FIND_PATH (VLD_ROOT_DIR NAMES include/vld.h PATHS ENV VLDROOT "$ENV{PROGRAMFILES}/Visual Leak Detector" "$ENV{PROGRAMFILES(X86)}/Visual Leak Detector" "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\Visual Leak Detector;InstallLocation]" "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\Visual Leak Detector;InstallLocation]" DOC "VLD root directory") +---- Win64 has two distinct environment variables pointing to usual program installation paths: * for Win64 applications = %ProgramFiles% * for Win32 applications = %ProgramFiles(x86)% The line "$ENV{PROGRAMFILES(X86)}/Visual Leak Detector" causes warning CMP0053 because parentheses in identifiers are not allowed. Trying to escape them to "$ENV{PROGRAMFILES\(X86\)}/Visual Leak Detector" instead errors out: Syntax error in cmake code; unexpected cal_SYMBOL, expecting } (19) How can this be solved? Is it possible to "quote inside quotes", or are there different escapes? -- Fun and success! Mario *LigH* Rohkr?mer mailto:contact at ligh.de From nilsgladitz at gmail.com Thu Nov 13 04:11:57 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Thu, 13 Nov 2014 10:11:57 +0100 Subject: [CMake] CMP0053: Unable to refer to $ENV{PROGRAMFILES(X86)} In-Reply-To: References: Message-ID: <546475DD.4090408@gmail.com> On 11/13/2014 09:51 AM, Mario *LigH* Rohkr?mer wrote: > The line > > "$ENV{PROGRAMFILES(X86)}/Visual Leak Detector" > > causes warning CMP0053 because parentheses in identifiers are not > allowed. Trying to escape them to > > "$ENV{PROGRAMFILES\(X86\)}/Visual Leak Detector" > > instead errors out: Syntax error in cmake code; unexpected cal_SYMBOL, > expecting } (19) > > How can this be solved? Is it possible to "quote inside quotes", or are > there different escapes? > I stumbled over the same issue earlier[1]. What should work is something like set(MYENV "PROGRAMFILES(X86)") ... "$ENV{${MYENV}}/Visual Leak Detector" Nils [1] http://public.kitware.com/pipermail/cmake-developers/2014-October/023190.html From contact at ligh.de Thu Nov 13 04:28:36 2014 From: contact at ligh.de (=?utf-8?Q?Mario_*LigH*_Rohkr=C3=A4mer?=) Date: Thu, 13 Nov 2014 10:28:36 +0100 Subject: [CMake] CMP0053: Unable to refer to $ENV{PROGRAMFILES(X86)} In-Reply-To: <546475DD.4090408@gmail.com> References: <546475DD.4090408@gmail.com> Message-ID: Thank you, I will forward this suggestion to the x265 developers. Am 13.11.2014, 10:11 Uhr, schrieb Nils Gladitz : > On 11/13/2014 09:51 AM, Mario *LigH* Rohkr?mer wrote: >> The line >> >> "$ENV{PROGRAMFILES(X86)}/Visual Leak Detector" >> >> causes warning CMP0053 because parentheses in identifiers are not >> allowed. Trying to escape them to >> >> "$ENV{PROGRAMFILES\(X86\)}/Visual Leak Detector" >> >> instead errors out: Syntax error in cmake code; unexpected cal_SYMBOL, >> expecting } (19) >> >> How can this be solved? Is it possible to "quote inside quotes", or are >> there different escapes? >> > > I stumbled over the same issue earlier[1]. > > What should work is something like > > set(MYENV "PROGRAMFILES(X86)") > > ... > > "$ENV{${MYENV}}/Visual Leak Detector" > > Nils > > [1] > http://public.kitware.com/pipermail/cmake-developers/2014-October/023190.html > > > > -- Fun and success! Mario *LigH* Rohkr?mer mailto:contact at ligh.de From eric.huhtala at gmail.com Thu Nov 13 10:26:30 2014 From: eric.huhtala at gmail.com (Eric Huhtala) Date: Thu, 13 Nov 2014 09:26:30 -0600 Subject: [CMake] Select external projects build target at build time Message-ID: Hello, I have an external project which I'd like to build a different way depending on the main project's build target (normal case is not to build "all"). e.g., I'd like "make build-A" to invoke "cmake --build ${EXTERNAL} --target build-A" "make build-B" to invoke "cmake --build ${EXTERNAL} --target build-B" in general "make X" -> "build X" would be fine. Is there a way I can do this directly? Should I generate N different external projects, each with a different source directory, but the same binary directory, and explicitly set the build target in the external project build step? Is that supposed to work? Is there a better way to get what I want? The reason I want to not build all is to save on build time, but build-A and build-B share quite a bit of work, so in the semi-rare case I *do* want to build all, I'd like that to need the least amount of time as well. Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Nov 13 12:54:26 2014 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 13 Nov 2014 12:54:26 -0500 Subject: [CMake] CMake 3.1.0-rc2 is now ready! Message-ID: I am proud to announce the CMake 3.1 second release candidate. Sources and binaries are available at: http://www.cmake.org/files/v3.1/?C=M;O=D Documentation is available at: http://www.cmake.org/cmake/help/v3.1 Release notes appear below and are also published at http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html Some of the more significant features of CMake 3.1 are: * Windows Phone and Windows Store support has been added to Visual Studio 11 (2012) and above Generators. * NVIDIA Nsight Tegra support has been added to Visual Studio 10 (2010) and above Generators. * New "target_compile_features" command allows populating target based compile features. CMake uses this information to ensure that the compiler in use is capable of building the target, and to add any necessary compile flags such as -std=gnu++11 to support language features. More information on this is found at: - http://www.cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html * The syntax for *Variable References* and *Escape Sequences* was simplified in order to allow a much faster implementation. See policy "CMP0053". * The "if" command no longer automatically dereferences variables named in quoted or bracket arguments. See policy "CMP0054". * The target property "SOURCES" now generally supports "Generator Expressions". The generator expressions may be used in the "add_library" and "add_executable" commands. * It is now possible to write and append to the target property "SOURCES". The variable "CMAKE_DEBUG_TARGET_PROPERTIES" can be used to trace the origin of sources. * CPack gained "7Z" and "TXZ" generators supporting lzma-compressed archives. * The ExternalProject module has learned to support lzma-compressed source tarballs with ".7z", ".tar.xz", and ".txz" extensions. * The ExternalProject module ExternalProject_Add command learned a new BUILD_ALWAYS option to cause the external project build step to run every time the host project is built. * The ctest_coverage command learned to support Intel coverage files with the "codecov" tool. * The ctest_memcheck command learned to support sanitizer modes, including "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer", and "UndefinedBehaviorSanitizer". Deprecated and Removed Features: * In CMake 3.0 the "target_link_libraries" command accidentally began allowing unquoted arguments to use Generator Expressions containing a semicolon separated list within them. For example: set(libs B C) target_link_libraries(A PUBLIC $) This is equivalent to writing: target_link_libraries(A PUBLIC $) and was never intended to work. It did not work in CMake 2.8.12. Such generator expressions should be in quoted arguments: set(libs B C) target_link_libraries(A PUBLIC "$") CMake 3.1 again requires the quotes for this to work correctly. CMake 3.1.0 Release Notes ************************* Changes made since CMake 3.0.0 include the following. Documentation Changes ===================== * A new "cmake-compile-features(7)" manual was added. New Features ============ Generators ---------- * A "Visual Studio 14" generator was added. Windows Phone and Windows Store ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Generators for Visual Studio 11 (2012) and above learned to generate projects for Windows Phone and Windows Store. One may set the "CMAKE_SYSTEM_NAME" variable to "WindowsPhone" or "WindowsStore" on the "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to activate these platforms. Also set "CMAKE_SYSTEM_VERSION" to "8.0" or "8.1" to specify the version of Windows to be targeted. NVIDIA Nsight Tegra ~~~~~~~~~~~~~~~~~~~ * Generators for Visual Studio 10 (2010) and above learned to generate projects for NVIDIA Nsight Tegra Visual Studio Edition. One may set the "CMAKE_SYSTEM_NAME" variable to "Android" on the "cmake(1)" command-line or in a "CMAKE_TOOLCHAIN_FILE" to activate this platform. Syntax ------ * The "cmake-language(7)" syntax for *Variable References* and *Escape Sequences* was simplified in order to allow a much faster implementation. See policy "CMP0053". * The "if()" command no longer automatically dereferences variables named in quoted or bracket arguments. See policy "CMP0054". Commands -------- * The "add_custom_command()" command learned to interpret "cmake- generator-expressions(7)" in arguments to "DEPENDS". * The "export(PACKAGE)" command learned to check the "CMAKE_EXPORT_NO_PACKAGE_REGISTRY" variable to skip exporting the package. * The "file(STRINGS)" command gained a new "ENCODING" option to enable extraction of "UTF-8" strings. * The "find_package()" command learned to check the "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" and "CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY" variables to skip searching the package registries. * The "install()" command learned a "MESSAGE_NEVER" option to avoid output during installation. * The "string()" command learned a new "GENEX_STRIP" subcommand which removes "generator expression". * The "string()" command learned a new "UUID" subcommand to generate a univerally unique identifier. * New "target_compile_features()" command allows populating the "COMPILE_FEATURES" target property, just like any other build variable. * The "target_sources()" command was added to add to the "SOURCES" target property. Variables --------- * The Visual Studio generators for versions 8 (2005) and above learned to read the target platform name from a new "CMAKE_GENERATOR_PLATFORM" variable when it is not specified as part of the generator name. The platform name may be specified on the "cmake(1)" command line with the "-A" option, e.g. "-G "Visual Studio 12 2013" -A x64". * The "CMAKE_GENERATOR_TOOLSET" variable may now be initialized in a toolchain file specified by the "CMAKE_TOOLCHAIN_FILE" variable. This is useful when cross-compiling with the Xcode or Visual Studio generators. * The "CMAKE_INSTALL_MESSAGE" variable was introduced to optionally reduce output installation. Properties ---------- * New "CXX_STANDARD" and "CXX_EXTENSIONS" target properties may specify values which CMake uses to compute required compile options such as "-std=c++11" or "-std=gnu++11". The "CMAKE_CXX_STANDARD" and "CMAKE_CXX_EXTENSIONS" variables may be set to initialize the target properties. * New "C_STANDARD" and "C_EXTENSIONS" target properties may specify values which CMake uses to compute required compile options such as "-std=c11" or "-std=gnu11". The "CMAKE_C_STANDARD" and "CMAKE_C_EXTENSIONS" variables may be set to initialize the target properties. * New "COMPILE_FEATURES" target property may contain a list of features required to compile a target. CMake uses this information to ensure that the compiler in use is capable of building the target, and to add any necessary compile flags to support language features. * New "COMPILE_PDB_NAME" and "COMPILE_PDB_OUTPUT_DIRECTORY" target properties were introduced to specify the MSVC compiler program database file location ("cl /Fd"). This complements the existing "PDB_NAME" and "PDB_OUTPUT_DIRECTORY" target properties that specify the linker program database file location ("link /pdb"). * The "INTERFACE_LINK_LIBRARIES" target property now supports a "$" "generator expression". * A new "INTERFACE_SOURCES" target property was introduced. This is consumed by dependent targets, which compile and link the listed sources. * The "SOURCES" target property now contains "generator expression" such as "TARGET_OBJECTS" when read at configure time, if policy "CMP0051" is "NEW". * The "SOURCES" target property now generally supports "generator expression". The generator expressions may be used in the "add_library()" and "add_executable()" commands. * It is now possible to write and append to the "SOURCES" target property. The "CMAKE_DEBUG_TARGET_PROPERTIES" variable may be used to trace the origin of sources. * A "VS_DEPLOYMENT_CONTENT" source file property was added to tell the Visual Studio generators to mark content for deployment in Windows Phone and Windows Store projects. * The "VS_WINRT_COMPONENT" target property was created to tell Visual Studio generators to compile a shared library as a Windows Runtime (WinRT) component. * The "Xcode" generator learned to check source file properties "XCODE_EXPLICIT_FILE_TYPE" and "XCODE_LAST_KNOWN_FILE_TYPE" for a custom Xcode file reference type. Modules ------- * The "BundleUtilities" module learned to resolve and replace "@rpath" placeholders on OS X to correctly bundle applications using them. * The "CMakePackageConfigHelpers" module "configure_package_config_file()" command learned a new "INSTALL_PREFIX" option to generate package configuration files meant for a prefix other than "CMAKE_INSTALL_PREFIX". * The "CheckFortranSourceCompiles" module was added to provide a "CHECK_Fortran_SOURCE_COMPILES" macro. * The "ExternalData" module learned to tolerate a "DATA{}" reference to a missing source file with a warning instead of rejecting it with an error. This helps developers write new "DATA{}" references to test reference outputs that have not yet been created. * The "ExternalProject" module learned to support lzma-compressed source tarballs with ".7z", ".tar.xz", and ".txz" extensions. * The "ExternalProject" module "ExternalProject_Add" command learned a new "BUILD_ALWAYS" option to cause the external project build step to run every time the host project is built. * The "ExternalProject" module "ExternalProject_Add" command learned a new "EXCLUDE_FROM_ALL" option to cause the external project target to have the "EXCLUDE_FROM_ALL" target property set. * The "ExternalProject" module "ExternalProject_Add_Step" command learned a new "EXCLUDE_FROM_MAIN" option to cause the step to not be a direct dependency of the main external project target. * The "ExternalProject" module "ExternalProject_Add" command learned a new "DOWNLOAD_NO_PROGRESS" option to disable progress output while downloading the source tarball. * The "FeatureSummary" module "feature_summary" API learned to accept multiple values for the "WHAT" option and combine them appropriately. * The "FindCUDA" module learned to support "fatbin" and "cubin" modules. * The "FindGTest" module "gtest_add_tests" macro learned a new "AUTO" option to automatically read the "SOURCES" target property of the test executable and scan the source files for tests to be added. * The "FindGLEW" module now provides imported targets. * The "FindGLUT" module now provides imported targets. * The "FindHg" module gained a new "Hg_WC_INFO" macro to help run "hg" to extract information about a Mercurial work copy. * The "FindOpenCL" module was introduced. * The "FindOpenGL" module now provides imported targets "OpenGL::GL" and "OpenGL::GLU" when the libraries are found. * The "FindOpenMP" module learned to support Fortran. * The "FindPkgConfig" module learned to use the "PKG_CONFIG" environment variable value as the "pkg-config" executable, if set. * The "FindZLIB" module now provides imported targets. * The "GenerateExportHeader" module "generate_export_header" function learned to allow use with *Object Libraries*. * The "InstallRequiredSystemLibraries" module gained a new "CMAKE_INSTALL_OPENMP_LIBRARIES" option to install MSVC OpenMP runtime libraries. * The "UseSWIG" module learned to detect the module name from ".i" source files if possible to avoid the need to set the "SWIG_MODULE_NAME" source file property explicitly. * The "WriteCompilerDetectionHeader" module was added to allow creation of a portable header file for compiler optional feature detection. Generator Expressions --------------------- * New "COMPILE_FEATURES" "generator expression" allows setting build properties based on available compiler features. CTest ----- * The "ctest_coverage()" command learned to read variable "CTEST_COVERAGE_EXTRA_FLAGS" to set "CoverageExtraFlags". * The "ctest_coverage()" command learned to support Intel coverage files with the "codecov" tool. * The "ctest_memcheck()" command learned to support sanitizer modes, including "AddressSanitizer", "MemorySanitizer", "ThreadSanitizer", and "UndefinedBehaviorSanitizer". Options may be set using the new "CTEST_MEMORYCHECK_SANITIZER_OPTIONS" variable. CPack ----- * "cpack(1)" gained an "IFW" generator to package using Qt Framework Installer tools. See the "CPackIFW" module. * "cpack(1)" gained "7Z" and "TXZ" generators supporting lzma- compressed archives. * The "CPackDeb" module learned a new "CPACK_DEBIAN_COMPRESSION_TYPE" variable to set the tarball compression type. * The "cpack(1)" "WiX" generator learned to support a "CPACK_WIX_ACL" installed file property to specify an Access Control List. Other ----- * The "cmake(1)" "-E" option learned a new "env" command. * The "cmake(1)" "-E tar" command learned to support lzma-compressed files. * *Object Libraries* may now have extra sources that do not compile to object files so long as they would not affect linking of a normal library (e.g. ".dat" is okay but not ".def"). * Visual Studio generators for VS 8 and later learned to support the "ASM_MASM" language. * The Visual Studio generators learned to treat ".hlsl" source files as High Level Shading Language sources (using "FXCompile" in ".vcxproj" files). A "VS_SHADER_TYPE" source file property was added to specify the Shader Type. New Diagnostics =============== * Policy "CMP0052" introduced to control directories in the "INTERFACE_INCLUDE_DIRECTORIES" of exported targets. Deprecated and Removed Features =============================== * In CMake 3.0 the "target_link_libraries()" command accidentally began allowing unquoted arguments to use "generator expressions" containing a (";" separated) list within them. For example: set(libs B C) target_link_libraries(A PUBLIC $) This is equivalent to writing: target_link_libraries(A PUBLIC $) and was never intended to work. It did not work in CMake 2.8.12. Such generator expressions should be in quoted arguments: set(libs B C) target_link_libraries(A PUBLIC "$") CMake 3.1 again requires the quotes for this to work correctly. * Callbacks established by the "variable_watch()" command will no longer receive the "ALLOWED_UNKNOWN_READ_ACCESS" access type when the undocumented "CMAKE_ALLOW_UNKNOWN_VARIABLE_READ_ACCESS" variable is set. Uninitialized variable accesses will always be reported as "UNKNOWN_READ_ACCESS". * The "CMakeDetermineVSServicePack" module now warns that it is deprecated and should not longer be used. Use the "CMAKE__COMPILER_VERSION" variable instead. * The "FindITK" module has been removed altogether. It was a thin- wrapper around "find_package(ITK ... NO_MODULE)". This produces much clearer error messages when ITK is not found. * The "FindVTK" module has been removed altogether. It was a thin- wrapper around "find_package(VTK ... NO_MODULE)". This produces much clearer error messages when VTK is not found. The module also provided compatibility support for finding VTK 4.0. This capability has been dropped. Other Changes ============= * The "cmake-gui(1)" learned to capture output from child processes started by the "execute_process()" command and display it in the output window. * The "cmake-language(7)" internal implementation of generator expression and list expansion parsers have been optimized and shows non-trivial speedup on large projects. * The Makefile generators learned to use response files with GNU tools on Windows to pass library directories and names to the linker. * When generating linker command-lines, CMake now avoids repeating items corresponding to SHARED library targets. * Support for the Open Watcom compiler has been overhauled. The "CMAKE__COMPILER_ID" is now "OpenWatcom", and the "CMAKE__COMPILER_VERSION" now uses the Open Watcom external version numbering. The external version numbers are lower than the internal version number by 11. * The "cmake-mode.el" major Emacs editing mode no longer treats "_" as part of words, making it more consistent with other major modes. ------------------------------------------------------------------- Changes made since CMake 3.1.0-rc1: Brad King (22): FindCurses: Include CheckLibraryExists before using it (#15220) Help: Clarify add_compile_options documentation (#15225) Help: Reference add_compile_options from add_definitions (#15225) KWSys: Fix configure_file call to use COPYONLY, not COPY_ONLY Qt4: Fix configure_file call to use COPYONLY, not COPY_ONLY FindIce: Drop use of :envvar: Sphinx markup Help: Drop TOC from latex manuals Help: Format add_library documented list of INTERFACE commands Help: Fix example in cmake-packages to avoid long line FindProtobuf: Cleanup reStructuredText documentation formatting Modules: Wrap long lines in pre-formatted documentation blocks Help: Tell latex to use a small font for cmake-language.7 productions Utilities/Sphinx: Fix html_favicon configuration Help: Update 3.1 release notes for dropping of FindITK and FindVTK Help: Wrap long lines in pre-formatted documentation blocks Help: Fix broken cross-references reported by 'nitpicky' option Xcode: Fix compiler path detection for iOS tools on Xcode <= 5.0 (#15237) ExternalProject: Restore logic to not download already-existing file Help: Link to GNUInstallDirs from CMAKE_INSTALL_PREFIX (#15246) Utilities/Sphinx: Add index entries for cross-references Help: Add 3.1 release note Emacs mode update CMake 3.1.0-rc2 Chuck Atkins (1): Workaround for short jump tables on PA-RISC. Clinton Stimpson (1): genex: Preserve order while evaluating TARGET_OBJECTS Daniele E. Domenichelli (1): Fix link line order when shared libraries are de-duplicated Iosif Neitzke (1): Help: Fix configure_file call to use COPYONLY, not COPY_ONLY J Decker (1): Watcom: Drop symfile linker option Nils Gladitz (1): Documentation: Fix minor typo thecommand -> the command Syohei YOSHIDA (1): cmake-mode.el: syntax of '_' should be treated as symbol ?dne Hovda (1): KWSys SystemInformation: Check for _SC_AIX_REALMEM before using it From benapetr at gmail.com Fri Nov 14 04:05:25 2014 From: benapetr at gmail.com (Petr Bena) Date: Fri, 14 Nov 2014 10:05:25 +0100 Subject: [CMake] Problems with FindOracle Message-ID: Hi, I run cmake on windows for a project that needs oracle libraries, and I get this error: CMake Error at cmake/modules/FindOracle.cmake:92 (IF): if given arguments: "GREATER" "120" Unknown arguments specified Call Stack (most recent call first): CMakeLists.txt:219 (FIND_PACKAGE) This looks to me like internal bug in CMake as the problem is in FindOracle.cmake rather than CMakeLists.txt Thanks From nilsgladitz at gmail.com Fri Nov 14 04:15:21 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Fri, 14 Nov 2014 10:15:21 +0100 Subject: [CMake] Problems with FindOracle In-Reply-To: References: Message-ID: <5465C829.7080705@gmail.com> On 11/14/2014 10:05 AM, Petr Bena wrote: > Hi, > > I run cmake on windows for a project that needs oracle libraries, and > I get this error: > > CMake Error at cmake/modules/FindOracle.cmake:92 (IF): > if given arguments: > > "GREATER" "120" > > Unknown arguments specified > Call Stack (most recent call first): > CMakeLists.txt:219 (FIND_PACKAGE) > > > This looks to me like internal bug in CMake as the problem is in > FindOracle.cmake rather than CMakeLists.txt > CMake does not ship a FindOracle.cmake[1]. It is probably part of the project that you are trying to build. The error could imply something like: if(${FOO} GREATER 120) Where FOO is not set and expands empty. Nils [1] http://www.cmake.org/gitweb?p=cmake.git;a=tree;f=Modules;h=b481616aef95de0570cb421cd3e46023adddf52b;hb=HEAD From glenn.coombs at gmail.com Fri Nov 14 07:56:53 2014 From: glenn.coombs at gmail.com (Glenn Coombs) Date: Fri, 14 Nov 2014 12:56:53 +0000 Subject: [CMake] Boost library directory not found unless I explicitly set BOOST_LIBRARYDIR ? Message-ID: Hi, I have installed Boost on Windows 7 for Visual Studio 2013 by running these installers: boost_1_56_0-msvc-12.0-32.exe boost_1_56_0-msvc-12.0-64.exe downloaded from http://sourceforge.net/projects/boost/files/boost-binaries/1.56.0/. I'm using CMake 2.8.12.1 and when I try to build a simple Boost example using the filesystem library my cmake configuration step fails to find the required libraries unless I use the BOOST_LIBRARYDIR variable to tell it where the libraries are: set(BOOST_VERSION_NEEDED 1.53.0) if (MSVC) set(Boost_USE_STATIC_LIBS ON) set(Boost_USE_MULTITHREADED ON) set(Boost_USE_STATIC_RUNTIME ON) # set(BOOST_LIBRARYDIR /Boost/boost_1_56_0/lib64-msvc-12.0) endif() find_package(Boost ${BOOST_VERSION_NEEDED} REQUIRED COMPONENTS system filesystem) Given that the library directory is where the official Boost installer put it shouldn't the FindBoost.cmake package be checking that directory by default ? This is the output from CMake: [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:476 ] _boost_TEST_VERSIONS = 1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53 [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:478 ] Boost_USE_MULTITHREADED = ON [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:480 ] Boost_USE_STATIC_LIBS = ON [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:482 ] Boost_USE_STATIC_RUNTIME = ON [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:484 ] Boost_ADDITIONAL_VERSIONS = [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:486 ] Boost_NO_SYSTEM_PATHS = [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:538 ] Declared as CMake or Environmental Variables: [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:540 ] BOOST_ROOT = [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:542 ] BOOST_INCLUDEDIR = [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:544 ] BOOST_LIBRARYDIR = [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:546 ] _boost_TEST_VERSIONS = 1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53 [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:639 ] location of version.hpp: C:/Boost/boost_1_56_0/boost/version.hpp [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:663 ] version.hpp reveals boost 1.56.0 [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:739 ] guessed _boost_COMPILER = -vc120 [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:749 ] _boost_MULTITHREADED = -mt [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:792 ] _boost_RELEASE_ABI_TAG = -s [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:794 ] _boost_DEBUG_ABI_TAG = -sgd [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:842 ] _boost_LIBRARY_SEARCH_DIRS = C:/Boost/boost_1_56_0/lib;C:/Boost/boost_1_56_0/../lib;C:/Boost/boost_1_56_0/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:930 ] Searching for SYSTEM_LIBRARY_RELEASE: libboost_system-vc120-mt-s-1_56;libboost_system-vc120-mt-s;libboost_system-mt-s-1_56;libboost_system-mt-s;libboost_system [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:966 ] Searching for SYSTEM_LIBRARY_DEBUG: libboost_system-vc120-mt-sgd-1_56;libboost_system-vc120-mt-sgd;libboost_system-mt-sgd-1_56;libboost_system-mt-sgd;libboost_system-mt;libboost_system [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:930 ] Searching for FILESYSTEM_LIBRARY_RELEASE: libboost_filesystem-vc120-mt-s-1_56;libboost_filesystem-vc120-mt-s;libboost_filesystem-mt-s-1_56;libboost_filesystem-mt-s;libboost_filesystem [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:966 ] Searching for FILESYSTEM_LIBRARY_DEBUG: libboost_filesystem-vc120-mt-sgd-1_56;libboost_filesystem-vc120-mt-sgd;libboost_filesystem-mt-sgd-1_56;libboost_filesystem-mt-sgd;libboost_filesystem-mt;libboost_filesystem [ C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/FindBoost.cmake:1017 ] Boost_FOUND = 1 Could NOT find Boost Boost version: 1.56.0 Boost include path: C:/Boost/boost_1_56_0 Could not find the following static Boost libraries: boost_system boost_filesystem No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost. As you can see it is looking for a directory called lib rather than lib64-msvc-12.0. -- Glenn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpavlik at iastate.edu Fri Nov 14 11:26:24 2014 From: rpavlik at iastate.edu (Ryan Pavlik) Date: Fri, 14 Nov 2014 10:26:24 -0600 Subject: [CMake] Boost library directory not found unless I explicitly set BOOST_LIBRARYDIR ? In-Reply-To: References: Message-ID: I've used a script to help it out a bit. I think these Windows installers are new. Here's the script I use - it basically sets BOOST_ROOT and BOOST_LIBRARYDIR automatically in some cases. https://gist.github.com/rpavlik/586f1fda6e32777623e1 Ryan On Fri, Nov 14, 2014 at 6:56 AM, Glenn Coombs wrote: > Hi, > > I have installed Boost on Windows 7 for Visual Studio 2013 by running > these installers: > > boost_1_56_0-msvc-12.0-32.exe > boost_1_56_0-msvc-12.0-64.exe > > downloaded from > http://sourceforge.net/projects/boost/files/boost-binaries/1.56.0/. > > I'm using CMake 2.8.12.1 and when I try to build a simple Boost example > using the filesystem library my cmake configuration step fails to find the > required libraries unless I use the BOOST_LIBRARYDIR variable to tell it > where the libraries are: > > set(BOOST_VERSION_NEEDED 1.53.0) > > if (MSVC) > set(Boost_USE_STATIC_LIBS ON) > set(Boost_USE_MULTITHREADED ON) > set(Boost_USE_STATIC_RUNTIME ON) > # set(BOOST_LIBRARYDIR /Boost/boost_1_56_0/lib64-msvc-12.0) > endif() > > find_package(Boost ${BOOST_VERSION_NEEDED} REQUIRED COMPONENTS system > filesystem) > > Given that the library directory is where the official Boost installer put > it shouldn't the FindBoost.cmake package be checking that directory by > default ? > > This is the output from CMake: > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:476 ] _boost_TEST_VERSIONS = > 1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53 > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:478 ] Boost_USE_MULTITHREADED = > ON > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:480 ] Boost_USE_STATIC_LIBS = ON > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:482 ] Boost_USE_STATIC_RUNTIME > = ON > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:484 ] Boost_ADDITIONAL_VERSIONS > = > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:486 ] Boost_NO_SYSTEM_PATHS = > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:538 ] Declared as CMake or > Environmental Variables: > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:540 ] BOOST_ROOT = > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:542 ] BOOST_INCLUDEDIR = > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:544 ] BOOST_LIBRARYDIR = > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:546 ] _boost_TEST_VERSIONS = > 1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53 > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:639 ] location of version.hpp: > C:/Boost/boost_1_56_0/boost/version.hpp > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:663 ] version.hpp reveals boost > 1.56.0 > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:739 ] guessed _boost_COMPILER = > -vc120 > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:749 ] _boost_MULTITHREADED = -mt > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:792 ] _boost_RELEASE_ABI_TAG = > -s > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:794 ] _boost_DEBUG_ABI_TAG = > -sgd > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:842 ] > _boost_LIBRARY_SEARCH_DIRS = > C:/Boost/boost_1_56_0/lib;C:/Boost/boost_1_56_0/../lib;C:/Boost/boost_1_56_0/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:930 ] Searching for > SYSTEM_LIBRARY_RELEASE: > libboost_system-vc120-mt-s-1_56;libboost_system-vc120-mt-s;libboost_system-mt-s-1_56;libboost_system-mt-s;libboost_system > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:966 ] Searching for > SYSTEM_LIBRARY_DEBUG: > libboost_system-vc120-mt-sgd-1_56;libboost_system-vc120-mt-sgd;libboost_system-mt-sgd-1_56;libboost_system-mt-sgd;libboost_system-mt;libboost_system > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:930 ] Searching for > FILESYSTEM_LIBRARY_RELEASE: > libboost_filesystem-vc120-mt-s-1_56;libboost_filesystem-vc120-mt-s;libboost_filesystem-mt-s-1_56;libboost_filesystem-mt-s;libboost_filesystem > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:966 ] Searching for > FILESYSTEM_LIBRARY_DEBUG: > libboost_filesystem-vc120-mt-sgd-1_56;libboost_filesystem-vc120-mt-sgd;libboost_filesystem-mt-sgd-1_56;libboost_filesystem-mt-sgd;libboost_filesystem-mt;libboost_filesystem > > [ C:/Program Files (x86)/CMake > 2.8/share/cmake-2.8/Modules/FindBoost.cmake:1017 ] Boost_FOUND = 1 > > Could NOT find Boost > > Boost version: 1.56.0 > > Boost include path: C:/Boost/boost_1_56_0 > > Could not find the following static Boost libraries: > > boost_system > > boost_filesystem > > No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the > directory containing Boost libraries or BOOST_ROOT to the location of Boost. > > > As you can see it is looking for a directory called lib rather than > lib64-msvc-12.0. > > -- > Glenn > > -- > > 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 joapuipe at gmail.com Fri Nov 14 12:26:27 2014 From: joapuipe at gmail.com (Joan Puigcerver) Date: Fri, 14 Nov 2014 18:26:27 +0100 Subject: [CMake] FindCUDA: Specify nvcc language in cuda_add_executable Message-ID: Hi, I'm trying to use CMake with FindCUDA to compile a C++/CUDA code, and I am having a small issue with cuda_add_executable. One of my files has the .cc extension, but it may import headers which contain CUDA kernels definitions (depending on wheather I want to use CUDA or not). So, I need to compile it as a CUDA file. You can tell nvcc to ignore the file extension and use a particular language with the -x option. For instance: nvcc -x cu foo.cc Will force to compile foo.cc as a CUDA file. However, I don't know how to pass that compilation option to nvcc through cuda_add_executable. I tried to set it in the CUDA_NVCC_FLAGS variable, but it never gets passed to nvcc, since CMake calls directly the C++ compiler. Can anyone suggest how to force the -x option? PS: One dirty fix is to create a symlink from foo.cc to foo.cu, and compile foo.cu if CUDA is enable, or foo.cc if it is not. CMake works fine with this workaround, but I'd rather pass the -x option and keep my code base clean. From glenn.coombs at gmail.com Fri Nov 14 14:09:16 2014 From: glenn.coombs at gmail.com (Glenn Coombs) Date: Fri, 14 Nov 2014 19:09:16 +0000 Subject: [CMake] Boost library directory not found unless I explicitly set BOOST_LIBRARYDIR ? In-Reply-To: References: Message-ID: Ryan, Thanks for the helper script - I'll try that out on Monday. Does anybody know if the FindBoost.cmake file is maintained by the CMake developers, or does it have a 3rd party maintainer ? It would be nice to see some logic similar to your script incorporated by default so that other people experience the simplicity of it just working straight out of the box. -- Glenn On 14 November 2014 16:23, Ryan Pavlik wrote: > I've used a script to help it out a bit. I think these Windows installers > are new. Here's the script I use - it basically sets BOOST_ROOT and > BOOST_LIBRARYDIR automatically in some cases. > https://gist.github.com/rpavlik/586f1fda6e32777623e1 > > Ryan > > On Fri, Nov 14, 2014 at 6:56 AM, Glenn Coombs > wrote: > >> Hi, >> >> I have installed Boost on Windows 7 for Visual Studio 2013 by running >> these installers: >> >> boost_1_56_0-msvc-12.0-32.exe >> boost_1_56_0-msvc-12.0-64.exe >> >> downloaded from >> http://sourceforge.net/projects/boost/files/boost-binaries/1.56.0/. >> >> I'm using CMake 2.8.12.1 and when I try to build a simple Boost example >> using the filesystem library my cmake configuration step fails to find the >> required libraries unless I use the BOOST_LIBRARYDIR variable to tell it >> where the libraries are: >> >> set(BOOST_VERSION_NEEDED 1.53.0) >> >> if (MSVC) >> set(Boost_USE_STATIC_LIBS ON) >> set(Boost_USE_MULTITHREADED ON) >> set(Boost_USE_STATIC_RUNTIME ON) >> # set(BOOST_LIBRARYDIR /Boost/boost_1_56_0/lib64-msvc-12.0) >> endif() >> >> find_package(Boost ${BOOST_VERSION_NEEDED} REQUIRED COMPONENTS system >> filesystem) >> >> Given that the library directory is where the official Boost installer >> put it shouldn't the FindBoost.cmake package be checking that directory by >> default ? >> >> This is the output from CMake: >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:476 ] _boost_TEST_VERSIONS = >> 1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53 >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:478 ] Boost_USE_MULTITHREADED = >> ON >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:480 ] Boost_USE_STATIC_LIBS = ON >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:482 ] Boost_USE_STATIC_RUNTIME >> = ON >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:484 ] Boost_ADDITIONAL_VERSIONS >> = >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:486 ] Boost_NO_SYSTEM_PATHS = >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:538 ] Declared as CMake or >> Environmental Variables: >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:540 ] BOOST_ROOT = >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:542 ] BOOST_INCLUDEDIR = >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:544 ] BOOST_LIBRARYDIR = >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:546 ] _boost_TEST_VERSIONS = >> 1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53 >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:639 ] location of version.hpp: >> C:/Boost/boost_1_56_0/boost/version.hpp >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:663 ] version.hpp reveals boost >> 1.56.0 >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:739 ] guessed _boost_COMPILER = >> -vc120 >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:749 ] _boost_MULTITHREADED = -mt >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:792 ] _boost_RELEASE_ABI_TAG = >> -s >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:794 ] _boost_DEBUG_ABI_TAG = >> -sgd >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:842 ] >> _boost_LIBRARY_SEARCH_DIRS = >> C:/Boost/boost_1_56_0/lib;C:/Boost/boost_1_56_0/../lib;C:/Boost/boost_1_56_0/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:930 ] Searching for >> SYSTEM_LIBRARY_RELEASE: >> libboost_system-vc120-mt-s-1_56;libboost_system-vc120-mt-s;libboost_system-mt-s-1_56;libboost_system-mt-s;libboost_system >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:966 ] Searching for >> SYSTEM_LIBRARY_DEBUG: >> libboost_system-vc120-mt-sgd-1_56;libboost_system-vc120-mt-sgd;libboost_system-mt-sgd-1_56;libboost_system-mt-sgd;libboost_system-mt;libboost_system >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:930 ] Searching for >> FILESYSTEM_LIBRARY_RELEASE: >> libboost_filesystem-vc120-mt-s-1_56;libboost_filesystem-vc120-mt-s;libboost_filesystem-mt-s-1_56;libboost_filesystem-mt-s;libboost_filesystem >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:966 ] Searching for >> FILESYSTEM_LIBRARY_DEBUG: >> libboost_filesystem-vc120-mt-sgd-1_56;libboost_filesystem-vc120-mt-sgd;libboost_filesystem-mt-sgd-1_56;libboost_filesystem-mt-sgd;libboost_filesystem-mt;libboost_filesystem >> >> [ C:/Program Files (x86)/CMake >> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:1017 ] Boost_FOUND = 1 >> >> Could NOT find Boost >> >> Boost version: 1.56.0 >> >> Boost include path: C:/Boost/boost_1_56_0 >> >> Could not find the following static Boost libraries: >> >> boost_system >> >> boost_filesystem >> >> No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to >> the directory containing Boost libraries or BOOST_ROOT to the location of >> Boost. >> >> >> As you can see it is looking for a directory called lib rather than >> lib64-msvc-12.0. >> >> -- >> Glenn >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >> Kitware offers various services to support the CMake community. For more >> information on each offering, please visit: >> >> CMake Support: http://cmake.org/cmake/help/support.html >> CMake Consulting: http://cmake.org/cmake/help/consulting.html >> CMake Training Courses: http://cmake.org/cmake/help/training.html >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/cmake >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Fri Nov 14 14:40:23 2014 From: DLRdave at aol.com (David Cole) Date: Fri, 14 Nov 2014 14:40:23 -0500 Subject: [CMake] Boost library directory not found unless I explicitly set BOOST_LIBRARYDIR ? In-Reply-To: References: Message-ID: You will find a list of CMake "Module Maintainers" here: http://www.cmake.org/Wiki/CMake:Module_Maintainers If a module is not listed, it is not currently claimed. (Meaning either nobody is currently maintaining it, or "everybody" is pitching in a little bit as things important to them arise.) Unfortunately, FindBoost is among the maintainer-less modules at present... However, ... patches are welcome. :-) HTH, David C. On Fri, Nov 14, 2014 at 2:09 PM, Glenn Coombs wrote: > Ryan, > > Thanks for the helper script - I'll try that out on Monday. > > Does anybody know if the FindBoost.cmake file is maintained by the CMake > developers, or does it have a 3rd party maintainer ? It would be nice to > see some logic similar to your script incorporated by default so that other > people experience the simplicity of it just working straight out of the box. > > -- > Glenn > > On 14 November 2014 16:23, Ryan Pavlik wrote: >> >> I've used a script to help it out a bit. I think these Windows installers >> are new. Here's the script I use - it basically sets BOOST_ROOT and >> BOOST_LIBRARYDIR automatically in some cases. >> https://gist.github.com/rpavlik/586f1fda6e32777623e1 >> >> Ryan >> >> On Fri, Nov 14, 2014 at 6:56 AM, Glenn Coombs >> wrote: >>> >>> Hi, >>> >>> I have installed Boost on Windows 7 for Visual Studio 2013 by running >>> these installers: >>> >>> boost_1_56_0-msvc-12.0-32.exe >>> boost_1_56_0-msvc-12.0-64.exe >>> >>> downloaded from >>> http://sourceforge.net/projects/boost/files/boost-binaries/1.56.0/. >>> >>> I'm using CMake 2.8.12.1 and when I try to build a simple Boost example >>> using the filesystem library my cmake configuration step fails to find the >>> required libraries unless I use the BOOST_LIBRARYDIR variable to tell it >>> where the libraries are: >>> >>> set(BOOST_VERSION_NEEDED 1.53.0) >>> >>> if (MSVC) >>> set(Boost_USE_STATIC_LIBS ON) >>> set(Boost_USE_MULTITHREADED ON) >>> set(Boost_USE_STATIC_RUNTIME ON) >>> # set(BOOST_LIBRARYDIR /Boost/boost_1_56_0/lib64-msvc-12.0) >>> endif() >>> >>> find_package(Boost ${BOOST_VERSION_NEEDED} REQUIRED COMPONENTS system >>> filesystem) >>> >>> Given that the library directory is where the official Boost installer >>> put it shouldn't the FindBoost.cmake package be checking that directory by >>> default ? >>> >>> This is the output from CMake: >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:476 ] _boost_TEST_VERSIONS = >>> 1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53 >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:478 ] Boost_USE_MULTITHREADED = >>> ON >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:480 ] Boost_USE_STATIC_LIBS = ON >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:482 ] Boost_USE_STATIC_RUNTIME = >>> ON >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:484 ] Boost_ADDITIONAL_VERSIONS >>> = >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:486 ] Boost_NO_SYSTEM_PATHS = >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:538 ] Declared as CMake or >>> Environmental Variables: >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:540 ] BOOST_ROOT = >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:542 ] BOOST_INCLUDEDIR = >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:544 ] BOOST_LIBRARYDIR = >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:546 ] _boost_TEST_VERSIONS = >>> 1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53 >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:639 ] location of version.hpp: >>> C:/Boost/boost_1_56_0/boost/version.hpp >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:663 ] version.hpp reveals boost >>> 1.56.0 >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:739 ] guessed _boost_COMPILER = >>> -vc120 >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:749 ] _boost_MULTITHREADED = -mt >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:792 ] _boost_RELEASE_ABI_TAG = >>> -s >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:794 ] _boost_DEBUG_ABI_TAG = >>> -sgd >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:842 ] _boost_LIBRARY_SEARCH_DIRS >>> = >>> C:/Boost/boost_1_56_0/lib;C:/Boost/boost_1_56_0/../lib;C:/Boost/boost_1_56_0/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:930 ] Searching for >>> SYSTEM_LIBRARY_RELEASE: >>> libboost_system-vc120-mt-s-1_56;libboost_system-vc120-mt-s;libboost_system-mt-s-1_56;libboost_system-mt-s;libboost_system >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:966 ] Searching for >>> SYSTEM_LIBRARY_DEBUG: >>> libboost_system-vc120-mt-sgd-1_56;libboost_system-vc120-mt-sgd;libboost_system-mt-sgd-1_56;libboost_system-mt-sgd;libboost_system-mt;libboost_system >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:930 ] Searching for >>> FILESYSTEM_LIBRARY_RELEASE: >>> libboost_filesystem-vc120-mt-s-1_56;libboost_filesystem-vc120-mt-s;libboost_filesystem-mt-s-1_56;libboost_filesystem-mt-s;libboost_filesystem >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:966 ] Searching for >>> FILESYSTEM_LIBRARY_DEBUG: >>> libboost_filesystem-vc120-mt-sgd-1_56;libboost_filesystem-vc120-mt-sgd;libboost_filesystem-mt-sgd-1_56;libboost_filesystem-mt-sgd;libboost_filesystem-mt;libboost_filesystem >>> >>> [ C:/Program Files (x86)/CMake >>> 2.8/share/cmake-2.8/Modules/FindBoost.cmake:1017 ] Boost_FOUND = 1 >>> >>> Could NOT find Boost >>> >>> Boost version: 1.56.0 >>> >>> Boost include path: C:/Boost/boost_1_56_0 >>> >>> Could not find the following static Boost libraries: >>> >>> boost_system >>> >>> boost_filesystem >>> >>> No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to >>> the directory containing Boost libraries or BOOST_ROOT to the location of >>> Boost. >>> >>> >>> As you can see it is looking for a directory called lib rather than >>> lib64-msvc-12.0. >>> >>> -- >>> Glenn >>> >>> -- >>> >>> 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 ramey at rrsd.com Fri Nov 14 14:47:28 2014 From: ramey at rrsd.com (Robert Ramey) Date: Fri, 14 Nov 2014 12:47:28 -0700 (MST) Subject: [CMake] CMake can't find Boost versions > 1.55 Message-ID: <1415994448258-7589009.post@n2.nabble.com> The module FindBoost is quite elaborate. Unfortunately it seems to depend upon searching for specific version numbers found in a list. This list only goes up to 1.55 so it can't find later versions of Boost. Better would be to eliminate the list so module doesn't "expire" -- View this message in context: http://cmake.3232098.n2.nabble.com/CMake-can-t-find-Boost-versions-1-55-tp7589009.html Sent from the CMake mailing list archive at Nabble.com. From lfdominguez at estudiantes.uci.cu Fri Nov 14 09:52:58 2014 From: lfdominguez at estudiantes.uci.cu (Luis Felipe Dominguez Vega) Date: Fri, 14 Nov 2014 14:52:58 +0000 Subject: [CMake] About option() in cmake Message-ID: <1460033.vbAvx24hgc@envy> There is a way to show the options set into the CMakeLists.txt without using feature_summary, something like in autotools "./configure --help", in others words, without modifing the CMakeLists.txt how i can see that options.... -------------- next part -------------- A non-text attachment was scrubbed... Name: Lfdominguez.vcf Type: text/vcard Size: 38514 bytes Desc: not available URL: From benoit.bleuze at 1000shapes.com Sat Nov 15 14:33:31 2014 From: benoit.bleuze at 1000shapes.com (=?UTF-8?B?QmVub8OudCBCbGV1esOp?=) Date: Sat, 15 Nov 2014 20:33:31 +0100 Subject: [CMake] Run a command depending on the output of cpack Message-ID: <5467AA8B.5060807@1000shapes.com> Hi list, Here is my goal: I would like to create component packages using the archive cpack generator, to get development packages, run time packages, and some internal packages (including some additionnal executables not available to the normal users). This works fine, I use the COMPONENT install property, I set(CPACK_ARCHIVE_COMPONENT_INSTALL TRUE), and I define some cpack components. I would also like my tar.gz packages to follow my own naming scheme, and not ${CPACK_PACKAGE_FILE_NAME}-component_name.tar.gz. I looked at the cpack cpp code, this behaviour is hard coded, so here are the solutions I saw: * patch the cpack program, adding some new property in cpack_add_component(), similarly to the ARCHIVE, knowing that, from what I understood, this function is not used so far with the ARCHIVE generators. * run a custom command after the package target has been run, and rename the tar.gz files that were generated for each component. I wanted to not spend too much time on this, so I opted for the second solution. However I don't seem to be able to create a custom command depending on the target "package". So my questions are: 1- How would you rename component based archive packages? 2- Is the Package target somehow special and can't be used as a dependency? 3- Is the custom command based on a target dependency a dead end? 4- Bonus question: I will need to include somehow the configuration name in the package name. On Linux, I can rely on the Build_type, but my knowledge of configuration on windows is limited, does CMAKE_BUILD_TYPE mean anything when running cmake custom commands? Thank you all for you help, Beno?t Bleuz?. From wmamrak at gmail.com Sun Nov 16 05:56:05 2014 From: wmamrak at gmail.com (Wojciech Mamrak) Date: Sun, 16 Nov 2014 11:56:05 +0100 Subject: [CMake] target_include_directories target issue Message-ID: Hello, the docs claim: "Specify include directories or targets to use when compiling a given target." Here is a little test of it. Project directory: Foo CMakeLists.txt FooSrc a.h a.cpp Bar main.cpp And CMakeLists.txt: cmake_minimum_required(VERSION 3.0) project(FooBar) add_library(Foo FooSrc/a.h FooSrc/a.cpp) target_include_directories(Foo PUBLIC G:/some_directory) if (TARGET Foo) message("Foo is a target!") endif() add_executable(Bar Bar/main.cpp) target_include_directories(Bar PRIVATE Foo) According to the docs, Bar's include directories should contain at least "G:/some_directory", but it contains "${PROJECT_SOURCE_DIR}/Foo". Why? If I replace the last line with target_link_libraries(Bar PRIVATE Foo), then Bar's include directories meet my expectations. regards From gerhard.gappmeier at ascolab.com Mon Nov 17 05:20:17 2014 From: gerhard.gappmeier at ascolab.com (Gerhard Gappmeier) Date: Mon, 17 Nov 2014 11:20:17 +0100 Subject: [CMake] CTest XML format Message-ID: <5469CBE1.1060002@ascolab.com> Hi all, we want to archive our unittest results, code coverage etc. when we release a product. Therefor we want to store the generated XML files in TestLink. However when we need to look at the results again we need to display them somehow. So I have some questions regarding the format: 1.) I found this link: http://public.kitware.com/Wiki/CDash:XML What is missing for me at the moment is a description of the Measurement Value field in Test.xml My files contain values using encoding="Base64" and compression="gzip". I base64 decoded these values and tried to gunzip, but it is not a valid gzip file. I also tried pure deflate, but also no success. So how are these values encoded/compressed in detail? 2.) Is there a way to re-import these values later on into CDash for inspection? 3.) Is there another GUI for inspecting these files? (Configure, Build and Test.xml) 4.) Do you know of any import filter for TestLink, so that the results could be directly be shown inside TestLink? http://testlink.org/ regards, Gerhard. From kollix at aon.at Mon Nov 17 07:01:39 2014 From: kollix at aon.at (Martin Koller) Date: Mon, 17 Nov 2014 13:01:39 +0100 Subject: [CMake] can I make an AUTOMOC generated file depend on something ? Message-ID: <1505810.OWG1IaMX4b@lapi.koller> Hi, I have a project where Qt is used, so I use AUTOMOC. However I have something special: My Qt class implementation needs another (external) Qt implemented source, which I have packed as tar.bz2 file. I have a rule which shall extract the .tar.bz2 file, which works nicely. However, the AUTOMOC generates the moc_ file BEFORE the rule to extract the .tar.bz2 file triggers, which means moc can not include some headers which are inside this tar file and the result is wrong. I have something like (excerpt): add_library(MYLIB MODULE source.cxx) set_target_properties(MYLIB PROPERTIES AUTOMOC TRUE) add_custom_command(OUTPUT header.h COMMAND ${CMAKE_COMMAND} -E tar xf ${CMAKE_CURRENT_SOURCE_DIR}/includes.tar.bz2 COMMAND ${CMAKE_COMMAND} -E tar vxf ${CMAKE_CURRENT_SOURCE_DIR}/${TARFILE} COMMAND ${CMAKE_COMMAND} -E touch_nocreate header.h DEPENDS ${TARFILE}) add_custom_target(data_lib DEPENDS header.h) add_dependencies(${TARGET} data_lib) What rules can I add so that the tar extraction is done BEFORE the moc generation ? -- Best Regards/Sch?ne Gr??e Martin From lfdominguez at estudiantes.uci.cu Mon Nov 17 03:21:19 2014 From: lfdominguez at estudiantes.uci.cu (Luis Felipe Dominguez Vega) Date: Mon, 17 Nov 2014 08:21:19 +0000 Subject: [CMake] target_include_directories target issue In-Reply-To: References: Message-ID: <2157869.tWYnqF5Hc7@envy> That's because the include directory is obtained in dependends. The documentation say that when the library is imported by dependends of a target, the dependant target obtain all the PUBLIC and INTERFACE include directories, so, with the command target_include_directories(Bar PRIVATE Foo) You are populating the property INCLUDE_DIRECTORIES of the target Bar, only with Foo. Just figure it, how cmake can guess that the Bar target depends of Foo target, you are only telling that add the DIRECTORY Foo to the PRIVATE INCLUDE_DIRECTORIES of Bar. The command target_include_directories In a reduced form is target_include_directories ( [PRIVATE | PUBLIC | INTERFACE] So, if you think that the command is getting the Foo as a target, noup, is getting as a directory. ----------------------------------------------------------- On Sunday 16 November 2014 11:56:05 AM Wojciech Mamrak wrote: > Hello, > > the docs claim: > > "Specify include directories or targets to use when compiling a given > target." > > Here is a little test of it. Project directory: > > Foo > CMakeLists.txt > FooSrc > a.h > a.cpp > Bar > main.cpp > > And CMakeLists.txt: > > cmake_minimum_required(VERSION 3.0) > > project(FooBar) > > add_library(Foo FooSrc/a.h FooSrc/a.cpp) > > target_include_directories(Foo PUBLIC G:/some_directory) > > if (TARGET Foo) > message("Foo is a target!") > endif() > > add_executable(Bar Bar/main.cpp) > > target_include_directories(Bar PRIVATE Foo) > > According to the docs, Bar's include directories should contain at > least "G:/some_directory", but it contains > "${PROJECT_SOURCE_DIR}/Foo". Why? > > If I replace the last line with target_link_libraries(Bar PRIVATE > Foo), then Bar's include directories meet my expectations. > > regards From avorop at mail.ru Mon Nov 17 07:29:30 2014 From: avorop at mail.ru (avorop at mail.ru) Date: Mon, 17 Nov 2014 13:29:30 +0100 Subject: [CMake] library dependcies and add_library(OBJECT) Message-ID: <20141117122930.GC24632@vandal.office> Hello! I'm playing with add_library(OBJECT) operation. Everything works nice but then I have one "library" that uses some external library. An attempt to add target_link_libraries here results in failure, because I don't build and library, only object files. But now comes the problem, how do I notify target that uses my "library" that it should include additional external library as dependency? Of course in the simplest case I can provide target_link_libraries for the executable, but I'd prefer to keep this setting in the CMakeLists.txt for the library. In hope to clarify the above, suppose that we have project with sources located in directories A, B and C. The final executable is built using objects from these directories. In each of directories I place CMakeLists.txt containing "add_library(X OBJECT x.c y.c)". Then in CMakeLists.txt for the executable I put line "add_executable(my_prog $ $ $)" Now, suppose files in B use external library libssl. What should I add to B/CMakeLists.txt to successfully build my executable? -- Andrei Voropaev From wmamrak at gmail.com Mon Nov 17 09:46:35 2014 From: wmamrak at gmail.com (Wojciech Mamrak) Date: Mon, 17 Nov 2014 15:46:35 +0100 Subject: [CMake] target_include_directories target issue In-Reply-To: <2157869.tWYnqF5Hc7@envy> References: <2157869.tWYnqF5Hc7@envy> Message-ID: Hello, > Just figure it, how cmake can guess that the Bar target depends of Foo target, you are only telling that add the DIRECTORY Foo to the PRIVATE INCLUDE_DIRECTORIES of Bar. Because the docs say so: "Specify include directories or targets to use when compiling a given target.". regards 2014-11-17 9:21 GMT+01:00 Luis Felipe Dominguez Vega : > That's because the include directory is obtained in dependends. The > documentation say that when the library is imported by dependends of a target, > the dependant target obtain all the PUBLIC and INTERFACE include directories, > so, with the command > > target_include_directories(Bar PRIVATE Foo) > > You are populating the property INCLUDE_DIRECTORIES of the target Bar, only > with Foo. Just figure it, how cmake can guess that the Bar target depends of > Foo target, you are only telling that add the DIRECTORY Foo to the PRIVATE > INCLUDE_DIRECTORIES of Bar. The command > > target_include_directories > > In a reduced form is target_include_directories ( [PRIVATE | PUBLIC | > INTERFACE] > > So, if you think that the command is getting the Foo as a target, noup, is > getting as a directory. > > > ----------------------------------------------------------- > On Sunday 16 November 2014 11:56:05 AM Wojciech Mamrak wrote: >> Hello, >> >> the docs claim: >> >> "Specify include directories or targets to use when compiling a given >> target." >> >> Here is a little test of it. Project directory: >> >> Foo >> CMakeLists.txt >> FooSrc >> a.h >> a.cpp >> Bar >> main.cpp >> >> And CMakeLists.txt: >> >> cmake_minimum_required(VERSION 3.0) >> >> project(FooBar) >> >> add_library(Foo FooSrc/a.h FooSrc/a.cpp) >> >> target_include_directories(Foo PUBLIC G:/some_directory) >> >> if (TARGET Foo) >> message("Foo is a target!") >> endif() >> >> add_executable(Bar Bar/main.cpp) >> >> target_include_directories(Bar PRIVATE Foo) >> >> According to the docs, Bar's include directories should contain at >> least "G:/some_directory", but it contains >> "${PROJECT_SOURCE_DIR}/Foo". Why? >> >> If I replace the last line with target_link_libraries(Bar PRIVATE >> Foo), then Bar's include directories meet my expectations. >> >> regards > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake From gerhard.gappmeier at ascolab.com Mon Nov 17 10:04:06 2014 From: gerhard.gappmeier at ascolab.com (Gerhard Gappmeier) Date: Mon, 17 Nov 2014 16:04:06 +0100 Subject: [CMake] CTest XML format In-Reply-To: <5469CBE1.1060002@ascolab.com> References: <5469CBE1.1060002@ascolab.com> Message-ID: <546A0E66.2040907@ascolab.com> Hi, I was able to figure out my first question. The first two bytes of the binary data was "78 9C". This is the file header of Zlib data with default compression. So by adding the correct gzip header manually you can decompress it. Assume the base64 data from XML is saved in ~/test.base64 you can unpack the data this way: base64 -d ~/test.base64 > ~/test.bin printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" | cat - ~/test.bin | gzip -dc Am 17.11.2014 11:20, schrieb Gerhard Gappmeier: > Hi all, > > we want to archive our unittest results, code coverage etc. when we > release a product. > Therefor we want to store the generated XML files in TestLink. > > However when we need to look at the results again we need to display > them somehow. > So I have some questions regarding the format: > > 1.) I found this link: http://public.kitware.com/Wiki/CDash:XML > What is missing for me at the moment is a description of the Measurement > Value field in Test.xml > My files contain values using encoding="Base64" and compression="gzip". > I base64 decoded these values and tried to gunzip, but it is not a valid > gzip file. > I also tried pure deflate, but also no success. > So how are these values encoded/compressed in detail? > > 2.) Is there a way to re-import these values later on into CDash for > inspection? > > 3.) Is there another GUI for inspecting these files? (Configure, Build > and Test.xml) > > 4.) Do you know of any import filter for TestLink, so that the results > could be directly be shown inside TestLink? > http://testlink.org/ > > regards, > Gerhard. > > > From johannes.zarl at jku.at Mon Nov 17 10:50:21 2014 From: johannes.zarl at jku.at (Johannes Zarl) Date: Mon, 17 Nov 2014 16:50:21 +0100 Subject: [CMake] Diagnostics for unclosed generator expressions? Message-ID: <10980497.sVjkiNIs16@ersa> Hi, Today I learned the hard way that cmake does not provide any diagnostic about unclosed generator expressions. Consider the following: add_test( NAME generator_expression_unclosed COMMAND ${CMAKE_COMMAND} -E echo "$<0:Unclosed expression gives a warning?" ) cmake happily accepts this without any diagnostic, whereas regular variables are diagnosed correctly: message(STATUS "${test") gives: Syntax error in cmake code at /home/zing/scratch/cmake_testbed/CMakeLists.txt:143 when parsing string ${unclosed syntax error, unexpected $end, expecting } (10) Should I file a bug report on this issue? Cheers, Johannes From scranen at gmail.com Mon Nov 17 11:13:50 2014 From: scranen at gmail.com (Sjoerd Cranen) Date: Mon, 17 Nov 2014 17:13:50 +0100 Subject: [CMake] Packaging command-line + GUI tools on OS X Message-ID: <83ADB749-DC78-4F8E-A0E3-326105F5048A@gmail.com> Hi all, I am trying to package a set of command line tools and some graphical tools, sharing the same libraries. Given how Apple wants people to use relocatable .app bundles, but advises to put command line tools in their usual *nix paths, I came up with the following intended paths for my files: /Applications /foo.app /Contents /MacOS foo (linked to ../lib/bar.dylib) /lib -> (symlink to /lib /lib bar.dylib /bin baz (linked to ../lib/bar.dylib) Here, foo.app is a graphical app, bar a dynamic library and baz a command line app. I would like users to have the freedom to install into any directory they like (but default would be /usr or /usr/local). Especially because I would like to be able to deploy multiple versions of the tool suite simultaneously. The suggested approach with the symlink causes the .app bundles to be relocatable, as long as the shared libraries are not moved. This is a compromise I am willing to make; the alternative is to have a private copy of each shared library per .app, defeating the point of shared libraries. As we have 5 .apps, and 80MB of shared libraries, making copies is not acceptable. Is there a way to achieve the intended setup using CPack? I have been trying to use the PackageMaker generator, but I do not see how I could add in the symlink to the /lib dir, as this is path is only known when the package is installed. Early experiments with the CPACK_POSTFLIGHT_SCRIPT caused the installer to display the (unhelpful) error message ?Something went wrong?, and I am not sure this feature is supported for new versions of OS X. Also, CMake complains about installing files in the absolute path /Applications; I am unsure if I can safely ignore these warnings. I hope someone can point me in the right direction. Best regards, Sjoerd Cranen From lfdominguez at estudiantes.uci.cu Mon Nov 17 07:42:47 2014 From: lfdominguez at estudiantes.uci.cu (Luis Felipe Dominguez Vega) Date: Mon, 17 Nov 2014 12:42:47 +0000 Subject: [CMake] target_include_directories target issue In-Reply-To: References: Message-ID: <2851609.MeQsze1Sbj@envy> I can't see into the source code of cmake, into the cmTargetIncludeDirectoriesCommand.cxx somethink like import the INCLUDE_DIRECTORIES from target passed to target_include_directories, may an error in the documentation? ----------------------------------------------------------- On Sunday 16 November 2014 11:56:05 AM Wojciech Mamrak wrote: > Hello, > > the docs claim: > > "Specify include directories or targets to use when compiling a given > target." > > Here is a little test of it. Project directory: > > Foo > CMakeLists.txt > FooSrc > a.h > a.cpp > Bar > main.cpp > > And CMakeLists.txt: > > cmake_minimum_required(VERSION 3.0) > > project(FooBar) > > add_library(Foo FooSrc/a.h FooSrc/a.cpp) > > target_include_directories(Foo PUBLIC G:/some_directory) > > if (TARGET Foo) > message("Foo is a target!") > endif() > > add_executable(Bar Bar/main.cpp) > > target_include_directories(Bar PRIVATE Foo) > > According to the docs, Bar's include directories should contain at > least "G:/some_directory", but it contains > "${PROJECT_SOURCE_DIR}/Foo". Why? > > If I replace the last line with target_link_libraries(Bar PRIVATE > Foo), then Bar's include directories meet my expectations. > > regards From burlen.loring at gmail.com Mon Nov 17 12:06:30 2014 From: burlen.loring at gmail.com (Burlen Loring) Date: Mon, 17 Nov 2014 09:06:30 -0800 Subject: [CMake] disable "interactive image" ? Message-ID: <546A2B16.6030601@gmail.com> Hi, after upgrading to cdash 2.2.2 I'm having issues re: the "Interactive Image" display for image diffs when there are more than 1 set of images in a test. Here's an example: http://visit.cdash.lbl.gov/testDetails.php?test=1028748&build=3413 It looks like it may be grabbing the wrong valid image? and the widget is only displayed on the first test so we can't see valid images for the rest of the tests. That's new, in cdash 2.2.0 things worked OK. In 2.2.2 is there a way to return to the cdash 2.2.0 behavior (note: I can't downgrade because of security issues)? Is there a way to turn on the widget for each set of diffs? Burlen From climberking2000 at gmail.com Mon Nov 17 13:44:07 2014 From: climberking2000 at gmail.com (Joe) Date: Mon, 17 Nov 2014 10:44:07 -0800 Subject: [CMake] ARGV to ARGN translation debugging Message-ID: Hey all, I know that ARGV is all arguments, and ARGN is all arguments past the last expected argument. I find myself in a weird situation with these, where identical ARGV's in the same function lead to different ARGN's. The relevant code in the CMake script is below FUNCTION(MY_FUNC_NAME EXE_NAME) MESSAGE("FINAL ARGV: ${ARGV}") MESSAGE("FINAL ARGN: ${ARGN}") ............. ENDFUNCTION() Two different calls lead to the following outputs FINAL ARGV: Multifield_Repartition;SOURCES;multifield_repartition.cpp;COMM;mpi;serial;STANDARD_PASS_OUTPUT;NUM_MPI_PROCS;4;FAIL_REGULAR_EXPRESSION;TEST FAILED;PASS_REGULAR_EXPRESSION;TEST PASSED;ARGS;--num_particles=50;--num_dimensions=2 FINAL ARGN: FINAL ARGV: Multifield_Repartition;SOURCES;multifield_repartition.cpp;COMM;mpi;serial;STANDARD_PASS_OUTPUT;NUM_MPI_PROCS;4;FAIL_REGULAR_EXPRESSION;TEST FAILED;PASS_REGULAR_EXPRESSION;TEST PASSED;ARGS;--num_particles=50;--num_dimensions=2 FINAL ARGN: SOURCES;multifield_repartition.cpp;COMM;mpi;serial;STANDARD_PASS_OUTPUT;NUM_MPI_PROCS;4;FAIL_REGULAR_EXPRESSION;TEST FAILED;PASS_REGULAR_EXPRESSION;TEST PASSED;ARGS;--num_particles=50;--num_dimensions=2 The formatting in an email is weird, but a diff on these outputs is empty on the argv lines, the only difference is in the ARGN. So I could use the answer to either of the following questions: 1) How can the same ARGV to the same function give different ARGN's? My feeling is that the answer is "never, it's something in how the MESSAGE command displays lists." 2) How can we display lists in a way that allows us to see the differences between them? That is, is there some function which I can replace MESSAGE with in order to see the discrepancy between these two lists? More info available on request, I'm still new enough to CMake to not know what to report, the CMake versions used are git head ( 3609fceee75b4f3751a702ac0a7f21e5cbd67a0a ) and a release (2.8.12.2), problem is identical in each case. Best, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Mon Nov 17 14:44:27 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon, 17 Nov 2014 14:44:27 -0500 Subject: [CMake] ARGV to ARGN translation debugging In-Reply-To: References: Message-ID: <546A501B.7020407@kitware.com> On 11/17/2014 1:44 PM, Joe wrote: > > 1) How can the same ARGV to the same function give different ARGN's? My > feeling is that the answer is "never, it's something in how the MESSAGE > command displays lists." > 2) How can we display lists in a way that allows us to see the > differences between them? That is, is there some function which I can > replace MESSAGE with in order to see the discrepancy between these two > lists? To me it looks like in the first call all of this stuff: Multifield_Repartition;SOURCES;multifield_repartition.cpp;COMM;mpi;serial;STANDARD_PASS_OUTPUT;NUM_MPI_PROCS;4;FAIL_REGULAR_EXPRESSION;TEST FAILED;PASS_REGULAR_EXPRESSION;TEST PASSED;ARGS;--num_particles=50;--num_dimensions=2 is crammed into one variable. It might be clearer if you changed your messages to do this: MESSAGE("FINAL EXE_NAME: ${EXE_NAME}") MESSAGE("FINAL ARGV: ${ARGV}") MESSAGE("FINAL ARGN: ${ARGN}") Most likely it was called quoted? my_func("lots of stuff;foo;bar") vs my_func("lots of stuff" foo bar) -Bill From brad.king at kitware.com Mon Nov 17 14:50:28 2014 From: brad.king at kitware.com (Brad King) Date: Mon, 17 Nov 2014 14:50:28 -0500 Subject: [CMake] [cmake-developers] target_include_directories target issue In-Reply-To: References: <2851609.MeQsze1Sbj@envy> Message-ID: <546A5184.4090903@kitware.com> On 11/17/2014 02:09 PM, Daniel Pfeifer wrote: > FWD to developers list. I think this is a documentation issue. > > Luis Felipe Dominguez Vega schrieb am Mon Nov 17 2014 at 5:42:55 PM: > > I can't see into the source code of cmake, into the > cmTargetIncludeDirectoriesComm__and.cxx somethink like import the > INCLUDE_DIRECTORIES from target passed to target_include_directories, may an > error in the documentation? The command was first added with that capability but was never released like that due to ambiguity of target names and relative paths. I've fixed the docs: Help: target_include_directories does not allow target names http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d22ee67 See commit message for details. Thanks, -Brad From climberking2000 at gmail.com Mon Nov 17 14:54:35 2014 From: climberking2000 at gmail.com (Joe) Date: Mon, 17 Nov 2014 11:54:35 -0800 Subject: [CMake] ARGV to ARGN translation debugging In-Reply-To: <546A501B.7020407@kitware.com> References: <546A501B.7020407@kitware.com> Message-ID: Hey all, Looks like Bill's got it. Thanks Bill. FYI, this was done as part of doing parameter sweeps (run tests with all combinations of various parameters and settings), when it has been made pretty it may get committed back. Best, David On Mon, Nov 17, 2014 at 11:44 AM, Bill Hoffman wrote: > On 11/17/2014 1:44 PM, Joe wrote: > >> >> 1) How can the same ARGV to the same function give different ARGN's? My >> feeling is that the answer is "never, it's something in how the MESSAGE >> command displays lists." >> 2) How can we display lists in a way that allows us to see the >> differences between them? That is, is there some function which I can >> replace MESSAGE with in order to see the discrepancy between these two >> lists? >> > To me it looks like in the first call all of this stuff: > Multifield_Repartition;SOURCES;multifield_repartition.cpp;COMM;mpi; > serial;STANDARD_PASS_OUTPUT;NUM_MPI_PROCS;4;FAIL_REGULAR_EXPRESSION;TEST > FAILED;PASS_REGULAR_EXPRESSION;TEST PASSED;ARGS;--num_particles= > 50;--num_dimensions=2 > > is crammed into one variable. > > It might be clearer if you changed your messages to do this: > MESSAGE("FINAL EXE_NAME: ${EXE_NAME}") > MESSAGE("FINAL ARGV: ${ARGV}") > MESSAGE("FINAL ARGN: ${ARGN}") > > Most likely it was called quoted? > > my_func("lots of stuff;foo;bar") > vs > my_func("lots of stuff" foo bar) > > -Bill > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Mon Nov 17 16:23:34 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 17 Nov 2014 22:23:34 +0100 Subject: [CMake] can I make an AUTOMOC generated file depend on something ? References: <1505810.OWG1IaMX4b@lapi.koller> Message-ID: Martin Koller wrote: > What rules can I add so that the tar extraction is done BEFORE the moc > generation ? You can add depends in the AUTOGEN_TARGET_DEPENDS target property of particular targets. http://www.cmake.org/cmake/help/v3.0/prop_tgt/AUTOGEN_TARGET_DEPENDS.html Please try that out. It will require you to set it on each target. If that's too suboptimal, we can think about adding an additional convenience interface. Thanks, Steve. From steveire at gmail.com Mon Nov 17 16:26:25 2014 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 17 Nov 2014 22:26:25 +0100 Subject: [CMake] library dependcies and add_library(OBJECT) References: <20141117122930.GC24632@vandal.office> Message-ID: avorop at mail.ru wrote: > What should I add > to B/CMakeLists.txt to successfully build my executable? You might be able to add an INTERFACE library and populate its INTERFACE_SOURCES using the target_sources command: http://www.cmake.org/cmake/help/v3.1/command/target_sources.html http://www.cmake.org/cmake/help/v3.1/manual/cmake-buildsystem.7.html#interface-libraries Thanks, Steve. From parag at ionicsecurity.com Mon Nov 17 14:43:51 2014 From: parag at ionicsecurity.com (Parag Chandra) Date: Mon, 17 Nov 2014 19:43:51 +0000 Subject: [CMake] CMake 3.x not respecting IMPORTED_LOCATION_ properties Message-ID: Hello, Until recently, I was making use of the 'debug' and 'optimized' keywords to select the config-specific versions of external dependencies to link in, i.e. if I wanted to link Bar into Foo, I would use: target_link_libraries (Foo DEBUG ${Bar_Debug} OPTIMIZED ${Bar_Release}) Now I have added my own custom configuration to CMAKE_CONFIGURATION_TYPES, let's call it "Custom", and I want Foo, when built in Custom config, to link against the Custom variant of Bar. I did some reading and came across IMPORTED targets, which seem designed for this purpose, so I added new lines like the following: add_library (Bar STATIC IMPORTED GLOBAL) set_property (TARGET Bar PROPERTY IMPORTED_LOCATION_DEBUG "/path/to/Debug/Bar.lib") set_property (TARGET Bar PROPERTY IMPORTED_LOCATION_RELEASE "/path/to/Release/Bar.lib") set_property (TARGET Bar PROPERTY IMPORTED_LOCATION_CUSTOM "/path/to/Custom/Bar.lib") target_link_libraries (Foo Bar) However, when I open the generated Visual Studio project, I see "Bar-NOTFOUND" in the linker inputs. If I add the line: set_property (TARGET Bar PROPERTY IMPORTED_LOCATION "/path/to/Release/Bar.lib") Then the linker inputs are resolved correctly, but of course all of my configurations of Foo are now going to link against the same Release configuration of Bar. Is this a bug, or am I simply not using this feature correctly? I tried both 3.0.1 and 3.1rc2 on Windows. Thanks, Parag Chandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From wmamrak at gmail.com Mon Nov 17 18:31:31 2014 From: wmamrak at gmail.com (Wojciech Mamrak) Date: Tue, 18 Nov 2014 00:31:31 +0100 Subject: [CMake] [cmake-developers] target_include_directories target issue In-Reply-To: <546A5184.4090903@kitware.com> References: <2851609.MeQsze1Sbj@envy> <546A5184.4090903@kitware.com> Message-ID: Thanks Brad, that explains everything. regards 2014-11-17 20:50 GMT+01:00 Brad King : > On 11/17/2014 02:09 PM, Daniel Pfeifer wrote: >> FWD to developers list. I think this is a documentation issue. >> >> Luis Felipe Dominguez Vega schrieb am Mon Nov 17 2014 at 5:42:55 PM: >> >> I can't see into the source code of cmake, into the >> cmTargetIncludeDirectoriesComm__and.cxx somethink like import the >> INCLUDE_DIRECTORIES from target passed to target_include_directories, may an >> error in the documentation? > > The command was first added with that capability but was never released > like that due to ambiguity of target names and relative paths. I've > fixed the docs: > > Help: target_include_directories does not allow target names > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1d22ee67 > > See commit message for details. > > Thanks, > -Brad > > -- > > 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 avorop at mail.ru Tue Nov 18 06:42:14 2014 From: avorop at mail.ru (Andrey Voropaev) Date: Tue, 18 Nov 2014 12:42:14 +0100 Subject: [CMake] library dependcies and add_library(OBJECT) In-Reply-To: References: <20141117122930.GC24632@vandal.office> Message-ID: On Mon, Nov 17, 2014 at 10:26 PM, Stephen Kelly wrote: > avorop at mail.ru wrote: > >> What should I add >> to B/CMakeLists.txt to successfully build my executable? > > You might be able to add an INTERFACE library and populate its > INTERFACE_SOURCES using the target_sources command: > > http://www.cmake.org/cmake/help/v3.1/command/target_sources.html > > http://www.cmake.org/cmake/help/v3.1/manual/cmake-buildsystem.7.html#interface-libraries Unfortunately, my version of cmake is 2.8.12 so I don't have this option. I guess add_library(OBJECT) is useless in this situation. I've returned to using "normal" add_library that creates static library. Thank you for help. From noop at posteo.de Tue Nov 18 07:19:50 2014 From: noop at posteo.de (noop at posteo.de) Date: Tue, 18 Nov 2014 13:19:50 +0100 Subject: [CMake] Parallel generation of make files Message-ID: <09728328058b6ee15e9d729208acf0e2@posteo.de> Hello, I am trying to understand if it is possible to generate make files in parallel. The build process I am looking at suffers from a slow make file generation. I understand that once the generation is done I can call make -j XY to build in parallel; but what I am after is to to generate the make files in parallel. Something like a cmake -j XY. Is that possible? If not, if found http://www.cmake.org/Wiki/CMake_Performance_Tips, is there other information I should be aware of? Thanks. From nilsgladitz at gmail.com Tue Nov 18 08:03:03 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 18 Nov 2014 14:03:03 +0100 Subject: [CMake] Parallel generation of make files In-Reply-To: <09728328058b6ee15e9d729208acf0e2@posteo.de> References: <09728328058b6ee15e9d729208acf0e2@posteo.de> Message-ID: <546B4387.6050907@gmail.com> On 11/18/2014 01:19 PM, noop at posteo.de wrote: > Hello, > > I am trying to understand if it is possible to generate make files in > parallel. The build process I am looking at suffers from a slow make > file generation. I understand that once the generation is done I can > call make -j XY to build in parallel; but what I am after is to to > generate the make files in parallel. Something like a cmake -j XY. Is > that possible? > > If not, if found http://www.cmake.org/Wiki/CMake_Performance_Tips, is > there other information I should be aware of? I don't think CMake supports parallel generation. I am not sure if it pertains configuration more than generation (though I am guessing you might mean both) but requiring a more recent cmake release (cmake_minimum_required(VERSION)) might also improve performance since newer policy behavior might be more efficient than old behavior and unset policies might slow it down further since cmake might have to compute both behavior alternatives for diagnostic comparison. Nils From mike.jackson at bluequartz.net Tue Nov 18 09:25:00 2014 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 18 Nov 2014 09:25:00 -0500 Subject: [CMake] Generic XML output file of project heirarchy Message-ID: <3A919FF4-ADA4-4945-BB83-D77E3059D0B8@bluequartz.net> Has there ever been any interest in CMake producing a generic "XML" (or some other file format) file that lays out the project structure. I envision this to be a "Generator" that has elements of the CodeBlocks and Eclipse style of project setup but groups things together a bit more? So for each target one would list the source files, the include directories, the name of the target, special target properties? I guess one could base it on Unix Makefiles and have the "make command" that would be used to actually build the project? Is there something already in CMake that I am missing perhaps? Thoughts? Thanks Mike Jackson From mark.j.abraham at gmail.com Tue Nov 18 10:18:34 2014 From: mark.j.abraham at gmail.com (Mark Abraham) Date: Tue, 18 Nov 2014 16:18:34 +0100 Subject: [CMake] issues with static linking and Intel compiler on Crays Message-ID: Hi, I have two proposals for fixing issues with CMake generating suitable command lines for static linking on Cray supercomputers when using Intel as the base compiler. I hope I'm posting to the right list for discussion. Happy to switch to cmake-developers or Mantis. :-) Summary: The default Linux-Intel.cmake platform file adds -rdynamic to the command line for compiling the test for whether the toolchain works, which can fail if the toolchain isn't set up to deal with that Background: Cray provides a wrapper compiler that handles things like MPI and CUDA, and that wrapper compiler can be configured to use the Gnu, Intel or Cray compilers as their base. The wrapper can also be configured to require the use of static linking. This requirement can be side-stepped with "export XTPE_LINK_TYPE=dynamic", but this doesn't mean that a suitable library exists. Symptoms: On Archer (Cray XC30 in Edinburgh) with CMake 2.8.12 (or pre-3.1 CMake git master) I get: debug trycompile on -- The C compiler identification is Intel 14.0.0.20140805 -- The CXX compiler identification is Intel 14.0.0.20140805 -- Check for working C compiler: /opt/cray/craype/2.2.0/bin/cc -- Check for working C compiler: /opt/cray/craype/2.2.0/bin/cc -- broken CMake Error at /home2/y07/y07/cmake/2.8.12-i386/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "/opt/cray/craype/2.2.0/bin/cc" is not able to compile a simple test program. ... /opt/cray/craype/2.2.0/bin/cc CMakeFiles/cmTryCompileExec3645868218.dir/testCCompiler.c.o -o cmTryCompileExec3645868218 -rdynamic ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/libc.a(strcmp.o)' can not be used when making an executable; recompile with -fPIE and relink with -pie There may be a fair point here that the Cray and Intel machinery should not be combining to pick up stuff from /usr/lib64/gcc, but I don't see a libc in the Intel compiler installation, so maybe that is a feature after all. Using Gnu as the base compiler also generates the -rdynamic, but it copes with it. The issue for CMake is the existence of -rdynamic on the command line, when testing for basic functionality in a toolchain intended for static linking. The -rdynamic is a feature (see http://www.cmake.org/Bug/view.php?id=9985), set in the platform file, that supports some minor functionality, and when it is a problem, it can mostly be worked around by users by SET(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "") However, fixing the above problem only works if such set() commands are present in the platform file. Unfortunately, that's where the settings they are working around are made... Solutions could be: 1) We could introduce a specific platform files for Linux-Intel-Cray-${lang}-static (in CMake or in an end-user application), just to make sure -rdynamic isn't set by default. This permits the test for compiler functionality to pass, and as a side effect, avoids users of the platform file needing to set this in their CMakery. 2) The attached patch (based on CMake git master) allows CMake to recognize a situation when there's no linking going on, and to avoid adding linking flags. However, it is general to all platforms and calls to generate linking command lines. I don't know whether this is a good idea, because it could affect other platforms that depend on such behaviour for linking system libraries, etc. How good is the CMake CI setup? :-) If so, maybe some kind of policy setting might be needed. Are there other options, or issues I haven't considered? Regards, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Stop-compiler-tests-appending-unnecessary-linking-fl.patch Type: text/x-patch Size: 3410 bytes Desc: not available URL: From DLRdave at aol.com Tue Nov 18 10:37:52 2014 From: DLRdave at aol.com (David Cole) Date: Tue, 18 Nov 2014 10:37:52 -0500 Subject: [CMake] Generic XML output file of project heirarchy In-Reply-To: <3A919FF4-ADA4-4945-BB83-D77E3059D0B8@bluequartz.net> References: <3A919FF4-ADA4-4945-BB83-D77E3059D0B8@bluequartz.net> Message-ID: This sounds pretty similar to the recent mailing list discussions about the json file listing targets and properties of them at generate time. What would be the point? Just to look at the file as a human to see what's in it? Or would you use it for something else...? On Tue, Nov 18, 2014 at 9:25 AM, Michael Jackson wrote: > Has there ever been any interest in CMake producing a generic "XML" (or some other file format) file that lays out the project structure. I envision this to be a "Generator" that has elements of the CodeBlocks and Eclipse style of project setup but groups things together a bit more? So for each target one would list the source files, the include directories, the name of the target, special target properties? I guess one could base it on Unix Makefiles and have the "make command" that would be used to actually build the project? Is there something already in CMake that I am missing perhaps? > > Thoughts? > > Thanks > Mike Jackson > > -- > > 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 parag at ionicsecurity.com Tue Nov 18 10:40:57 2014 From: parag at ionicsecurity.com (Parag Chandra) Date: Tue, 18 Nov 2014 15:40:57 +0000 Subject: [CMake] CMake 3.x not respecting IMPORTED_LOCATION_ properties In-Reply-To: References: Message-ID: I figured it out, and it's a case-sensitivity issue. I have named my configuration "Custom", so I was expecting the corresponding property to be IMPORTED_LOCATION_Custom, but in fact CMake is expecting IMPORTED_LOCATION_CUSTOM. So it's an easy fix on my part. Parag Chandra Software Engineer, Mobile Team Mobile: +1.919.824.1410 [https://www.ionicsecurity.com/IonicSigHz.png] Ionic Security Inc. 1170 Peachtree St. NE STE 2285, Atlanta, GA 30309 From: Parag Chandra > Date: Monday, November 17, 2014 at 2:43 PM To: "cmake at cmake.org" > Subject: CMake 3.x not respecting IMPORTED_LOCATION_ properties Hello, Until recently, I was making use of the 'debug' and 'optimized' keywords to select the config-specific versions of external dependencies to link in, i.e. if I wanted to link Bar into Foo, I would use: target_link_libraries (Foo DEBUG ${Bar_Debug} OPTIMIZED ${Bar_Release}) Now I have added my own custom configuration to CMAKE_CONFIGURATION_TYPES, let's call it "Custom", and I want Foo, when built in Custom config, to link against the Custom variant of Bar. I did some reading and came across IMPORTED targets, which seem designed for this purpose, so I added new lines like the following: add_library (Bar STATIC IMPORTED GLOBAL) set_property (TARGET Bar PROPERTY IMPORTED_LOCATION_DEBUG "/path/to/Debug/Bar.lib") set_property (TARGET Bar PROPERTY IMPORTED_LOCATION_RELEASE "/path/to/Release/Bar.lib") set_property (TARGET Bar PROPERTY IMPORTED_LOCATION_CUSTOM "/path/to/Custom/Bar.lib") target_link_libraries (Foo Bar) However, when I open the generated Visual Studio project, I see "Bar-NOTFOUND" in the linker inputs. If I add the line: set_property (TARGET Bar PROPERTY IMPORTED_LOCATION "/path/to/Release/Bar.lib") Then the linker inputs are resolved correctly, but of course all of my configurations of Foo are now going to link against the same Release configuration of Bar. Is this a bug, or am I simply not using this feature correctly? I tried both 3.0.1 and 3.1rc2 on Windows. Thanks, Parag Chandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.jackson at bluequartz.net Tue Nov 18 10:48:33 2014 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 18 Nov 2014 10:48:33 -0500 Subject: [CMake] Generic XML output file of project heirarchy In-Reply-To: References: <3A919FF4-ADA4-4945-BB83-D77E3059D0B8@bluequartz.net> Message-ID: Anything that is "Parsable". So XML or JSON is fine. I am working a QtCreator bug** that started out as QtCreator not being able to bring in the proper Framework directories on OS X. As I investigated the root cause, it is my belief that the CodeBlocks file that QtCreator has CMake generate in order to parse is, at its root, in-adequate for what QtCreator needs to most efficiently generate a project from a CMake based project. Now, I could go down the road of trying to get a specific QtCreator Generator put into cmake (as has been discussed in the past). QtCreators "native" project format is qmake files. So this turns into a CMake->qmake translator which I think is intractable. But if CMake could generate the hierarchy of projects in some format that can be parsed by Qt (XML or JSON) or anything else really, I think this might be a powerful type of file to output. Other things like the ".dot" file output could be generated, maybe insights into a projects complexity could be revealed? Dunno. I was just thinking that this does not have to be a QtCreator Specific solution, but a more general file could be output. Cheers Mike Jackson **https://bugreports.qt-project.org/browse/QTCREATORBUG-13432 On Nov 18, 2014, at 10:37 AM, David Cole wrote: > This sounds pretty similar to the recent mailing list discussions > about the json file listing targets and properties of them at generate > time. > > What would be the point? Just to look at the file as a human to see > what's in it? Or would you use it for something else...? > > On Tue, Nov 18, 2014 at 9:25 AM, Michael Jackson > wrote: >> Has there ever been any interest in CMake producing a generic "XML" (or some other file format) file that lays out the project structure. I envision this to be a "Generator" that has elements of the CodeBlocks and Eclipse style of project setup but groups things together a bit more? So for each target one would list the source files, the include directories, the name of the target, special target properties? I guess one could base it on Unix Makefiles and have the "make command" that would be used to actually build the project? Is there something already in CMake that I am missing perhaps? >> >> Thoughts? >> >> Thanks >> Mike Jackson >> >> -- >> >> 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 dank at kegel.com Tue Nov 18 13:47:51 2014 From: dank at kegel.com (Dan Kegel) Date: Tue, 18 Nov 2014 10:47:51 -0800 Subject: [CMake] CMake and shared|static/release|debug? In-Reply-To: <52F70D6B.5010102@tysdomain.com> References: <52F16CB3.1040404@tysdomain.com> <201402051217.05102.johannes.zarl@jku.at> <52F70D6B.5010102@tysdomain.com> Message-ID: I'm facing the question of static myself now, porting a large automake project to cmake. I guess I'll mirror automake's practice of having separate --enable-static and --enable-shared settings, and allow both to be built at once. It's a bit ambiguous (which one gets tested?), but since I'm just reproducing old behavior, that's probably ok. It was tempting to make Static be a suffix on CMAKE_BUILD_TYPE, but nobody seems to do that...? On Sat, Feb 8, 2014 at 9:08 PM, Littlefield, Tyler wrote: > hello: > thanks all for the help--I really appreciate it. that cleaned up my file > quite a lot and was exactly what I was aiming for. > Thanks again, > > > On 2/5/2014 6:17 AM, Johannes Zarl wrote: >> >> Hi, >> >> On Tuesday, 4. February 2014, 23:41:55, Littlefield, Tyler wrote: >>> >>> I've tried this a few different ways and ran into issues. If someone >>> wouldn't mind pointing out where I'm going wrong, I would appreciate it. >>> (for example if there's a better way to do what I'm trying). >> >> It would help if you also included a textual description of the thing you >> want >> to achieve and your issues. Since the cmake compiler does not do what you >> want >> it to do, it is quite plausible that the people on this list having a good >> understanding of cmake will misinterpret your cmake code... >> >> That aside, as Jakub pointed out, it seems that you try to reimplement the >> CMAKE_BUILD_TYPE support on your own. >> >> As to the shared library stuff: CMake can already build shared and static >> libraries in the same build: >> >> set( MYLIB_SRCS mylibsource1.cxx mylibsource2.cxx) >> add_library( mylib-static STATIC ${MYLIB_SRCS}) >> add_library( mylib-static SHARED ${MYLIB_SRCS}) >> >> If you want to make it a choice, you could do it like this: >> >> set( BUILD_LIBTYPE SHARED CACHE STRING "SHARED or STATIC" ) >> # enforce string in the gui: >> set_property(CACHE BUILD_LIBTYPE PROPERTY STRINGS SHARED STATIC) >> if ( NOT BUILD_LIBTYPE STREQUAL STATIC ) >> set ( BUILD_LIBTYPE SHARED CACHE STRING "" FORCE) >> endif() >> >> add_library( mylib-static ${BUILD_LIBTYPE} ${MYLIB_SRCS}) >> >> HTH, >> Johannes > > > > -- > Take care, > Ty > http://tds-solutions.net > He that will not reason is a bigot; he that cannot reason is a fool; he that > dares not reason is a slave. > > -- > > 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://www.cmake.org/mailman/listinfo/cmake From steveire at gmail.com Tue Nov 18 14:55:11 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 18 Nov 2014 20:55:11 +0100 Subject: [CMake] Generic XML output file of project heirarchy References: <3A919FF4-ADA4-4945-BB83-D77E3059D0B8@bluequartz.net> Message-ID: Michael Jackson wrote: > Has there ever been any interest in CMake producing a generic "XML" (or > some other file format) file that lays out the project structure? See http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711 Thanks, Steve. From mike.jackson at bluequartz.net Tue Nov 18 15:39:53 2014 From: mike.jackson at bluequartz.net (Michael Jackson) Date: Tue, 18 Nov 2014 15:39:53 -0500 Subject: [CMake] Generic XML output file of project heirarchy In-Reply-To: References: <3A919FF4-ADA4-4945-BB83-D77E3059D0B8@bluequartz.net> Message-ID: Yep, that is pretty much the discussion that I was wanting. Now, has there been any movement on any of the implementations? Thanks Mike Jackson _________________________________________________________ Mike Jackson mike.jackson at bluequartz.net BlueQuartz Software www.bluequartz.net Principal Software Engineer Dayton, Ohio On Tue, Nov 18, 2014 at 2:55 PM, Stephen Kelly wrote: > Michael Jackson wrote: > > > Has there ever been any interest in CMake producing a generic "XML" (or > > some other file format) file that lays out the project structure? > > See > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711 > > Thanks, > > Steve. > > > -- > > 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 steveire at gmail.com Tue Nov 18 16:08:50 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 18 Nov 2014 22:08:50 +0100 Subject: [CMake] Generic XML output file of project heirarchy References: <3A919FF4-ADA4-4945-BB83-D77E3059D0B8@bluequartz.net> Message-ID: Michael Jackson wrote: > Yep, that is pretty much the discussion that I was wanting. Now, has there > been any movement on any of the implementations? Nothing is reported beyond that thread. If you want to pick up the implementation or a creator patch, I'd say go ahead. Thanks, Steve. From iosif.neitzke+cmake at gmail.com Tue Nov 18 18:21:21 2014 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Tue, 18 Nov 2014 17:21:21 -0600 Subject: [CMake] Generic XML output file of project heirarchy In-Reply-To: References: <3A919FF4-ADA4-4945-BB83-D77E3059D0B8@bluequartz.net> Message-ID: How about parsing GraphViz files? On Tue, Nov 18, 2014 at 3:08 PM, Stephen Kelly wrote: > Michael Jackson wrote: > >> Yep, that is pretty much the discussion that I was wanting. Now, has there >> been any movement on any of the implementations? > > Nothing is reported beyond that thread. > > If you want to pick up the implementation or a creator patch, I'd say go > ahead. > > Thanks, > > Steve. > > > > -- > > 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 wesley.hoke at gmail.com Wed Nov 19 03:24:44 2014 From: wesley.hoke at gmail.com (Wesley Smith) Date: Wed, 19 Nov 2014 00:24:44 -0800 Subject: [CMake] copying dylibs into OSX bundle Message-ID: Hi, I've been searching for how to copy some dylib dependencies for quite a while and can't seem to find a definitive answer on the problem. I have a .dylib file that needs to go into my app bundle (e.g. MyApp.app/Frameworks). From what I've read, to use the FIXUP_BUNDLE command, the file already has to be copied inside the bundle. How do I do this? I tried: set(ASSIMP_DYLIB "${ASSIMP_LINK_PATH}/${ASSIMP_LIB_NAME}.dylib") set_source_files_properties(${ASSIMP_DYLIB} PROPERTIES MACOSX_PACKAGE_LOCATION Frameworks) add_executable(${PROJECT_NAME} MACOSX_BUNDLE ${AM_SOURCES} ${ASSIMP_DYLIB}) but got errors CMake Error at CMakeLists.txt:205 (add_executable): Cannot find source file: ../support/libs/assimp/lib/osx/assimp.dylib Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx What's the proper way to copy here? thanks, wes From laasunde at hotmail.com Wed Nov 19 05:14:07 2014 From: laasunde at hotmail.com (Lars) Date: Wed, 19 Nov 2014 11:14:07 +0100 Subject: [CMake] ADD_CUSTOM_COMMAND Application dependency Message-ID: The below example build "App" and copies it to EXECUTABLE_OUTPUT_PATH. ADD_EXECUTABLE(App ${source}) TARGET_LINK_LIBRARIES(App ${lib1} ${lib2}) INSTALL(TARGETS App ..) The top level CMakeLists.txt has install directives for lib1 and lib2 INSTALL(FILES ${lib1}/bin/lib1.dll DESTINATION ...) INSTALL(FILES ${lib2}/bin/lib2.dll DESTINATION ...) Later in the build process we would like to use "App" ADD_CUSTOM_COMMAND(OUTPUT "${src} COMMAND App ...) The ADD_CUSTOM_COMMAND command currently fails because lib1 and lib2 are not present in EXECUTABLE_OUTPUT_PATH. The following solutions work but are not desirable approaches: - Copying the necessary files to EXECUTABLE_OUTPUT_PATH via ADD_CUSTOM_COMMAND. This would be repeating top level install directives at target level. - Update "path" environment variable to include paths to lib1 and lib2 libraries. What other options are available using CMake? Does ADD_CUSTOM_COMMAND have a way to update path environment prior to executing a command? -------------- next part -------------- An HTML attachment was scrubbed... URL: From angeliki.chrysochou at gmail.com Wed Nov 19 08:10:07 2014 From: angeliki.chrysochou at gmail.com (Angeliki Chrysochou) Date: Wed, 19 Nov 2014 14:10:07 +0100 Subject: [CMake] ADD_CUSTOM_COMMAND Application dependency In-Reply-To: References: Message-ID: Hi Lars, What if you provide the working directory to ADD_CUSTOM_COMMAND like this: add_custom_command( OUTPUT COMMAND command_to_be_executed DEPENDS ${lib1} ${lib2} WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} VERBATIM) Would it work? Otherwise a trick (more like a hack) like the following might be useful: add_custom_command( OUTPUT COMMAND PATH=$ENV{PATH}: ENVIRONMENT_VAR= && command_to_be_executed DEPENDS WORKING_DIRECTORY VERBATIM) This sets the PATH temporarily during the execution of the command, where you could possibly add the paths to the libraries you need. You can set more environment variables as well. Cheers! Angeliki On Wed, Nov 19, 2014 at 11:14 AM, Lars wrote: > The below example build "App" and copies it to EXECUTABLE_OUTPUT_PATH. > ADD_EXECUTABLE(App ${source}) > TARGET_LINK_LIBRARIES(App ${lib1} ${lib2}) > INSTALL(TARGETS App ..) > > The top level CMakeLists.txt has install directives for lib1 and lib2 > INSTALL(FILES ${lib1}/bin/lib1.dll DESTINATION ...) > INSTALL(FILES ${lib2}/bin/lib2.dll DESTINATION ...) > Later in the build process we would like to use "App" > ADD_CUSTOM_COMMAND(OUTPUT "${src} COMMAND App ...) > > The ADD_CUSTOM_COMMAND command currently fails because lib1 and lib2 are > not present in EXECUTABLE_OUTPUT_PATH. > > The following solutions work but are not desirable approaches: > - Copying the necessary files to EXECUTABLE_OUTPUT_PATH via > ADD_CUSTOM_COMMAND. This would be repeating top level install directives at > target level. > - Update "path" environment variable to include paths to lib1 and lib2 > libraries. > What other options are available using CMake? Does ADD_CUSTOM_COMMAND have > a way to update path environment prior to executing a command? > > > -- > > 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 hauke.heibel at gmail.com Wed Nov 19 08:26:54 2014 From: hauke.heibel at gmail.com (Hauke Heibel) Date: Wed, 19 Nov 2014 13:26:54 +0000 Subject: [CMake] Imported targets with additional dependencies Message-ID: Hi, I would like to declare an imported target which uses a header only library and which has some further link dependencies. If need be, I can specify a use case for this. I thought I could simply declare this target as add_library(Foo::Foo UNKNOWN IMPORTED) and then configure its dependencies via the target property IMPORTED_LOCATION. This used to work in 3.0.2, since it allowed me to specify multiple libraries separated by a semicolon (see here http://pastebin.com/Y1SYJFHh) but int 3.1-rc2 this semicolon is escaped to/replace by %3B. I was told that happens since there should only ever be a single entity specified by "IMPORTED_LOCATION". So I got the suggestion to use LINK_INTERFACE_LIBRARIES instead. When linking against such a target via target_link_libraries(Bar Foo::Foo) without specifying the IMPORTED_LOCATION property, I get Foo::Foo-NOTFOUND in my linker dependencies. The thing is I cannot specify IMPORTED_LOCATION, since there is really none. I could use my first library dependency to fake one but that does not sound right. I also cannot define my imported library as an INTERFACE target because for these, LINK_INTERFACE_LIBRARIES is not supported. Is there any way to achieve the declaration of such a target in 3.1? Regards, Hauke -------------- next part -------------- An HTML attachment was scrubbed... URL: From hauke.heibel at gmail.com Wed Nov 19 09:05:51 2014 From: hauke.heibel at gmail.com (Hauke Heibel) Date: Wed, 19 Nov 2014 14:05:51 +0000 Subject: [CMake] Imported targets with additional dependencies References: Message-ID: I just received help on IRC. The solution is to use an INTERFACE target and INTERFACE_LINK_LIBRARIES (and NOT LINK_INTERFACE_LIBRARIES). Hauke On Wed Nov 19 2014 at 2:26:54 PM Hauke Heibel wrote: > Hi, > > I would like to declare an imported target which uses a header only > library and which has some further link dependencies. If need be, I can > specify a use case for this. > > I thought I could simply declare this target as > > add_library(Foo::Foo UNKNOWN IMPORTED) > > and then configure its dependencies via the target property > IMPORTED_LOCATION. > > This used to work in 3.0.2, since it allowed me to specify multiple > libraries separated by a semicolon (see here http://pastebin.com/Y1SYJFHh) > but int 3.1-rc2 this semicolon is escaped to/replace by %3B. I was told > that happens since there should only ever be a single entity specified by > "IMPORTED_LOCATION". > > So I got the suggestion to use LINK_INTERFACE_LIBRARIES instead. When > linking against such a target via target_link_libraries(Bar Foo::Foo) > without specifying the IMPORTED_LOCATION property, I get Foo::Foo-NOTFOUND > in my linker dependencies. > > The thing is I cannot specify IMPORTED_LOCATION, since there is really > none. I could use my first library dependency to fake one but that does not > sound right. > > I also cannot define my imported library as an INTERFACE target because > for these, LINK_INTERFACE_LIBRARIES is not supported. > > Is there any way to achieve the declaration of such a target in 3.1? > > Regards, > Hauke > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angeliki.chrysochou at gmail.com Wed Nov 19 13:21:54 2014 From: angeliki.chrysochou at gmail.com (Angeliki Chrysochou) Date: Wed, 19 Nov 2014 19:21:54 +0100 Subject: [CMake] ADD_CUSTOM_COMMAND Application dependency In-Reply-To: References: Message-ID: Hi Lars, I see...Why don't you set the working directory then to lib1 and lib2, and use the full path to App to call App? Not sure it will work, but maybe. Cheers! Angeliki On Wed, Nov 19, 2014 at 7:19 PM, Lars wrote: > Hi Angeliki, > > Thank you for the suggestions. > > I suspect your first example wont work because lib1 and lib2 are not in > executable_output_path. So when the add_custom_command executes "App" it > wont be able to resolve the dependencies to lib1 and lib2. If I only had > one dependency I could possibly set the working_directory to the path of > lib1 and use the absolute path of the "App" for the command. That would > probably work but not with multiple dependencies. > > Your second example might do the job but wont be accepted as a solution in > our company. > > regards, Lars > > ------------------------------ > Date: Wed, 19 Nov 2014 14:10:07 +0100 > Subject: Re: [CMake] ADD_CUSTOM_COMMAND Application dependency > From: angeliki.chrysochou at gmail.com > To: laasunde at hotmail.com > CC: cmake at cmake.org > > > Hi Lars, > > What if you provide the working directory to ADD_CUSTOM_COMMAND like this: > > add_custom_command( > OUTPUT > COMMAND command_to_be_executed > DEPENDS ${lib1} ${lib2} > WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} > VERBATIM) > > Would it work? > > Otherwise a trick (more like a hack) like the following might be useful: > > add_custom_command( > OUTPUT > COMMAND PATH=$ENV{PATH}: > ENVIRONMENT_VAR= && command_to_be_executed > DEPENDS > WORKING_DIRECTORY > VERBATIM) > > This sets the PATH temporarily during the execution of the command, where > you could possibly add the paths to the libraries you need. You can set > more environment variables as well. > > Cheers! > Angeliki > > > On Wed, Nov 19, 2014 at 11:14 AM, Lars wrote: > > The below example build "App" and copies it to EXECUTABLE_OUTPUT_PATH. > ADD_EXECUTABLE(App ${source}) > TARGET_LINK_LIBRARIES(App ${lib1} ${lib2}) > INSTALL(TARGETS App ..) > > The top level CMakeLists.txt has install directives for lib1 and lib2 > INSTALL(FILES ${lib1}/bin/lib1.dll DESTINATION ...) > INSTALL(FILES ${lib2}/bin/lib2.dll DESTINATION ...) > Later in the build process we would like to use "App" > ADD_CUSTOM_COMMAND(OUTPUT "${src} COMMAND App ...) > > The ADD_CUSTOM_COMMAND command currently fails because lib1 and lib2 are > not present in EXECUTABLE_OUTPUT_PATH. > > The following solutions work but are not desirable approaches: > - Copying the necessary files to EXECUTABLE_OUTPUT_PATH via > ADD_CUSTOM_COMMAND. This would be repeating top level install directives at > target level. > - Update "path" environment variable to include paths to lib1 and lib2 > libraries. > What other options are available using CMake? Does ADD_CUSTOM_COMMAND have > a way to update path environment prior to executing a command? > > > -- > > 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 laasunde at hotmail.com Wed Nov 19 13:19:25 2014 From: laasunde at hotmail.com (Lars) Date: Wed, 19 Nov 2014 19:19:25 +0100 Subject: [CMake] ADD_CUSTOM_COMMAND Application dependency In-Reply-To: References: , Message-ID: Hi Angeliki, Thank you for the suggestions. I suspect your first example wont work because lib1 and lib2 are not in executable_output_path. So when the add_custom_command executes "App" it wont be able to resolve the dependencies to lib1 and lib2. If I only had one dependency I could possibly set the working_directory to the path of lib1 and use the absolute path of the "App" for the command. That would probably work but not with multiple dependencies. Your second example might do the job but wont be accepted as a solution in our company. regards, Lars Date: Wed, 19 Nov 2014 14:10:07 +0100 Subject: Re: [CMake] ADD_CUSTOM_COMMAND Application dependency From: angeliki.chrysochou at gmail.com To: laasunde at hotmail.com CC: cmake at cmake.org Hi Lars, What if you provide the working directory to ADD_CUSTOM_COMMAND like this: add_custom_command( OUTPUT COMMAND command_to_be_executed DEPENDS ${lib1} ${lib2} WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} VERBATIM) Would it work? Otherwise a trick (more like a hack) like the following might be useful: add_custom_command( OUTPUT COMMAND PATH=$ENV{PATH}: ENVIRONMENT_VAR= && command_to_be_executed DEPENDS WORKING_DIRECTORY VERBATIM) This sets the PATH temporarily during the execution of the command, where you could possibly add the paths to the libraries you need. You can set more environment variables as well. Cheers!Angeliki On Wed, Nov 19, 2014 at 11:14 AM, Lars wrote: The below example build "App" and copies it to EXECUTABLE_OUTPUT_PATH. ADD_EXECUTABLE(App ${source}) TARGET_LINK_LIBRARIES(App ${lib1} ${lib2}) INSTALL(TARGETS App ..) The top level CMakeLists.txt has install directives for lib1 and lib2 INSTALL(FILES ${lib1}/bin/lib1.dll DESTINATION ...) INSTALL(FILES ${lib2}/bin/lib2.dll DESTINATION ...) Later in the build process we would like to use "App" ADD_CUSTOM_COMMAND(OUTPUT "${src} COMMAND App ...) The ADD_CUSTOM_COMMAND command currently fails because lib1 and lib2 are not present in EXECUTABLE_OUTPUT_PATH. The following solutions work but are not desirable approaches: - Copying the necessary files to EXECUTABLE_OUTPUT_PATH via ADD_CUSTOM_COMMAND. This would be repeating top level install directives at target level. - Update "path" environment variable to include paths to lib1 and lib2 libraries. What other options are available using CMake? Does ADD_CUSTOM_COMMAND have a way to update path environment prior to executing a command? -- 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 laasunde at hotmail.com Wed Nov 19 15:50:49 2014 From: laasunde at hotmail.com (Lars) Date: Wed, 19 Nov 2014 21:50:49 +0100 Subject: [CMake] ADD_CUSTOM_COMMAND Application dependency In-Reply-To: References: , , , Message-ID: Hello again, There can only be one working directory and the two lib's are located in different dirs. regards, Lars Date: Wed, 19 Nov 2014 19:21:54 +0100 Subject: Re: [CMake] ADD_CUSTOM_COMMAND Application dependency From: angeliki.chrysochou at gmail.com To: laasunde at hotmail.com CC: cmake at cmake.org Hi Lars, I see...Why don't you set the working directory then to lib1 and lib2, and use the full path to App to call App? Not sure it will work, but maybe. Cheers!Angeliki On Wed, Nov 19, 2014 at 7:19 PM, Lars wrote: Hi Angeliki, Thank you for the suggestions. I suspect your first example wont work because lib1 and lib2 are not in executable_output_path. So when the add_custom_command executes "App" it wont be able to resolve the dependencies to lib1 and lib2. If I only had one dependency I could possibly set the working_directory to the path of lib1 and use the absolute path of the "App" for the command. That would probably work but not with multiple dependencies. Your second example might do the job but wont be accepted as a solution in our company. regards, Lars Date: Wed, 19 Nov 2014 14:10:07 +0100 Subject: Re: [CMake] ADD_CUSTOM_COMMAND Application dependency From: angeliki.chrysochou at gmail.com To: laasunde at hotmail.com CC: cmake at cmake.org Hi Lars, What if you provide the working directory to ADD_CUSTOM_COMMAND like this: add_custom_command( OUTPUT COMMAND command_to_be_executed DEPENDS ${lib1} ${lib2} WORKING_DIRECTORY ${EXECUTABLE_OUTPUT_PATH} VERBATIM) Would it work? Otherwise a trick (more like a hack) like the following might be useful: add_custom_command( OUTPUT COMMAND PATH=$ENV{PATH}: ENVIRONMENT_VAR= && command_to_be_executed DEPENDS WORKING_DIRECTORY VERBATIM) This sets the PATH temporarily during the execution of the command, where you could possibly add the paths to the libraries you need. You can set more environment variables as well. Cheers!Angeliki On Wed, Nov 19, 2014 at 11:14 AM, Lars wrote: The below example build "App" and copies it to EXECUTABLE_OUTPUT_PATH. ADD_EXECUTABLE(App ${source}) TARGET_LINK_LIBRARIES(App ${lib1} ${lib2}) INSTALL(TARGETS App ..) The top level CMakeLists.txt has install directives for lib1 and lib2 INSTALL(FILES ${lib1}/bin/lib1.dll DESTINATION ...) INSTALL(FILES ${lib2}/bin/lib2.dll DESTINATION ...) Later in the build process we would like to use "App" ADD_CUSTOM_COMMAND(OUTPUT "${src} COMMAND App ...) The ADD_CUSTOM_COMMAND command currently fails because lib1 and lib2 are not present in EXECUTABLE_OUTPUT_PATH. The following solutions work but are not desirable approaches: - Copying the necessary files to EXECUTABLE_OUTPUT_PATH via ADD_CUSTOM_COMMAND. This would be repeating top level install directives at target level. - Update "path" environment variable to include paths to lib1 and lib2 libraries. What other options are available using CMake? Does ADD_CUSTOM_COMMAND have a way to update path environment prior to executing a command? -- 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 pwang_xjtu at hotmail.com Wed Nov 19 16:45:55 2014 From: pwang_xjtu at hotmail.com (WangPing) Date: Thu, 20 Nov 2014 05:45:55 +0800 Subject: [CMake] read imageJ ROI to matlab Message-ID: sorry list, I am not sure if I could ask a different question: does anyone know how to read an ROI from ImageJ to matlab? Or how to save the ImageJ ROI to a file (such as nifti format)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From braden at endoframe.com Wed Nov 19 17:55:34 2014 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 19 Nov 2014 22:55:34 +0000 (UTC) Subject: [CMake] =?utf-8?q?Interaction_between_source_COMPILE=5FFLAGS_and_?= =?utf-8?q?directory_COMPILE=5FOPTIONS?= Message-ID: The documentation for the source property COMPILE_FLAGS describes it as, "Additional flags to be added when compiling this source file." However, when using the Visual Studio 2013 generator (at least), it appears to replace (rather than complement) the options added via the directory property COMPILE_OPTIONS. It (i.e., source COMPILE_FLAGS) also replaces options added by setting the CMAKE__FLAGS variable. Is this the intended behavior? Braden From steveire at gmail.com Wed Nov 19 18:16:51 2014 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 20 Nov 2014 00:16:51 +0100 Subject: [CMake] CMake can't find Boost versions > 1.55 References: <1415994448258-7589009.post@n2.nabble.com> Message-ID: Robert Ramey wrote: > The module FindBoost is quite elaborate. Unfortunately it seems to depend > upon searching for specific version numbers found in a list. This list > only > goes up to 1.55 so it can't find later versions of Boost. Better would be > to eliminate the list so module doesn't "expire" It would be awesome if you could teach bjam to generate cmake config packages: http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html Qt uses qmake to generate those, and LLVM generates them with a non-CMake buildsystem too. Thanks, Steve. From rleigh at codelibre.net Wed Nov 19 19:10:37 2014 From: rleigh at codelibre.net (Roger Leigh) Date: Thu, 20 Nov 2014 00:10:37 +0000 Subject: [CMake] read imageJ ROI to matlab In-Reply-To: References: Message-ID: <20141120001037.GR1657@codelibre.net> On Thu, Nov 20, 2014 at 05:45:55AM +0800, WangPing wrote: > sorry list, I am not sure if I could ask a different question: does anyone know how to read an ROI from ImageJ to matlab? Or how to save the ImageJ ROI to a file (such as nifti format)? You might want to ask this question on the ImageJ mailing list ;-) As an initial hint, you can save ROIs to a file using the ROI Manager. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 From iosif.neitzke+cmake at gmail.com Wed Nov 19 19:35:13 2014 From: iosif.neitzke+cmake at gmail.com (Iosif Neitzke) Date: Wed, 19 Nov 2014 18:35:13 -0600 Subject: [CMake] CMake can't find Boost versions > 1.55 In-Reply-To: References: <1415994448258-7589009.post@n2.nabble.com> Message-ID: Seconded! On Wed, Nov 19, 2014 at 5:16 PM, Stephen Kelly wrote: > Robert Ramey wrote: > >> The module FindBoost is quite elaborate. Unfortunately it seems to depend >> upon searching for specific version numbers found in a list. This list >> only >> goes up to 1.55 so it can't find later versions of Boost. Better would be >> to eliminate the list so module doesn't "expire" > > It would be awesome if you could teach bjam to generate cmake config > packages: > > http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html > > Qt uses qmake to generate those, and LLVM generates them with a non-CMake > buildsystem too. > > Thanks, > > Steve. > > > -- > > 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 andrew.amaclean at gmail.com Thu Nov 20 00:32:33 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 20 Nov 2014 16:32:33 +1100 Subject: [CMake] CMake and VS Community Edition Message-ID: Just playing around with Visual Studio Community Edition. I had VS 2013 Express installed and I found it best to uninstall it as the same functionality (and more) is in the community edition. The reason that I uninstalled it is that when CMake builds the solution file (if both are installed) the the Microsoft Visual Studio Version Selector will select VS 2013 Express. This is because the first two lines of the solution file read: Microsoft Visual Studio Solution File, Format Version 12.00 # Visual Studio Express 2013 for Windows Desktop So it is finding VS Express 2013 by default. Uninstalling VS 2013 Express produces the correct solution file: Microsoft Visual Studio Solution File, Format Version 12.00 # Visual Studio 2013 I only picked this up because I use the Microsoft Visual Studio Version Selector to open the *.sln file by default. Tested on CMake 3.0.2 and the pre-release version CMake 3.1.20141119 VS 2013 Community Edition will happily use the VS Express 2013 solution file. Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bertrand.cachet at gmail.com Thu Nov 20 05:18:27 2014 From: bertrand.cachet at gmail.com (CACHET Bertrand) Date: Thu, 20 Nov 2014 11:18:27 +0100 Subject: [CMake] BasicRuntimeChecks inside CompilerId/VS-10.vcxproj.in Message-ID: <546DBFF3.6010609@gmail.com> Hello, I would like to add support for INtime (v6) platform (RTOS for Windows). I add these variables to my CMakeLists.txt project: SET(CMAKE_SYSTEM_NAME INtime) SET(CMAKE_GENERATOR_PLATFORM INtime) I generated a platform/INtime.cmake file (attach to this email). When trying to generate my build environment with CMake, I got an error when CMake try to detect C/CXX Compilers: "/NO CMAKE_C_COMPILER could be found/" due to compilation error: "/CMakeCCompilerId.obj : error LNK2001: unresolved external symbol __RTC_InitBase/". This compilation error is due to /RTC1 compilation flag usage. Presence of this compilation flag is due to EnableFastChecks in CompilerId/VS-10.vcxproj.in template. Is there any reason to always perform this RunTime Check when looking for valid compiler on Visual Studio ? Thanks for your answer Sincerely Bertrand -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- IF(__INTIME) RETURN() ENDIF() SET(__INTIME 1) SET(WIN32 0) SET(MSVC 1) SET(CMAKE_GENERATOR_PLATFORM "INtime") set(CMAKE_STATIC_LIBRARY_PREFIX "") set(CMAKE_STATIC_LIBRARY_SUFFIX ".lib") set(CMAKE_SHARED_LIBRARY_PREFIX "") set(CMAKE_SHARED_LIBRARY_SUFFIX ".rsl") set(CMAKE_IMPORT_LIBRARY_PREFIX "") set(CMAKE_IMPORT_LIBRARY_SUFFIX ".lib") set(CMAKE_EXECUTABLE_SUFFIX ".rta") set(CMAKE_LINK_LIBRARY_SUFFIX ".lib") set(CMAKE_DL_LIBS "") set(CMAKE_FIND_LIBRARY_PREFIXES "") set(CMAKE_FIND_LIBRARY_SUFFIXES ".lib") set(CMAKE_LINK_LIBRARY_FLAG "") set(CMAKE_LIBRARY_PATH_FLAG "-LIBPATH:") set(CMAKE_BUILD_TYPE_INIT Debug) FILE(TO_CMAKE_PATH $ENV{PROGRAMFILES}/INtime INTIME_PATH) INCLUDE_DIRECTORIES(${INTIME_PATH}/rt/include/network7) INCLUDE_DIRECTORIES(${INTIME_PATH}/rt/include/cpp) INCLUDE_DIRECTORIES(${INTIME_PATH}/rt/include) LINK_DIRECTORIES(${INTIME_PATH}/rt/lib) SET(CMAKE_C_STANDARD_LIBRARIES_INIT rtppd.lib cpplib.lib) # For C++ support SET(CMAKE_C_STANDARD_LIBRARIES_INIT ${CMAKE_C_STANDARD_LIBRARIES_INIT} rt.lib pcibus.lib netlib.lib clib.lib vshelper.lib) SET(CMAKE_C_STANDARD_LIBRARIES_INIT ${CMAKE_C_STANDARD_LIBRARIES_INIT} iwin32.lib) # Win32 API support SET(CMAKE_CXX_STANDARD_LIBRARIES_INIT ${CMAKE_C_STANDARD_LIBRARIES_INIT}) SET(CMAKE_EXE_LINKER_FLAGS_INIT "/NODEFAULTLIB /MANIFEST:NO /INCREMENTAL:NO /ASSEMBLYDEBUG:DISABLE /VERSION:21076.20053 /SAFESEH:NO") SET(CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT "${CMAKE_EXE_LINKER_FLAGS_INIT} /DEBUG") SET(CMAKE_EXE_LINKER_FLAGS_RELEASE_INIT ${CMAKE_EXE_LINKER_FLAGS_INIT}) SET(CMAKE_SHARED_LINKER_FLAGS_INIT ${CMAKE_EXE_LINKER_FLAGS_INIT}) SET(CMAKE_SHARED_LINKER_FLAGS_DEBUG_INIT ${CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT}) SET(CMAKE_SHARED_LINKER_FLAGS_RELEASE_INIT ${CMAKE_EXE_LINKER_FLAGS_RELEASE_INIT}) SET(CMAKE_MODULE_LINKER_FLAGS_INIT ${CMAKE_EXE_LINKER_FLAGS_INIT}) SET(CMAKE_MODULE_LINKER_FLAGS_DEBUG_INIT ${CMAKE_EXE_LINKER_FLAGS_DEBUG_INIT}) SET(CMAKE_MODULE_LINKER_FLAGS_RELEASE_INIT ${CMAKE_EXE_LINKER_FLAGS_RELEASE_INIT}) MACRO(INtime_compiler_MSVC lang) # /X => Do not use default libraries # /TP => Compile for C++ # /MT => Multithreaded lib # /EHa => Enable C++ Exceptions with SEH # /GR => Enable Run-Time Type Information (needed by libjson-rpc) # /Od => No optimization # /Gy- => Disable Funtion-Leve Linking # /openmp- => Disable OpenMP SET(CMAKE_${lang}_FLAGS_INIT "/X /MT /EHa /GR /Od /Gy- /openmp- /GF -D__C99__ -D__INTIME__ -DVS7_CPP -D_HAS_NAMESPACE -DEC_INTIME_VERSION=400 /W3") SET(CMAKE_${lang}_FLAGS_DEBUG_INIT "/Zi -D_DEBUG") ENDMACRO() INtime_compiler_MSVC(C) INtime_compiler_MSVC(CXX) -------------- next part -------------- Compiling the C compiler identification source file "CMakeCCompilerId.c" failed. Compiler: Build flags: Id flags: The output was: 1 Microsoft (R) Build Engine version 12.0.31101.0 [Microsoft .NET Framework, version 4.0.30319.18444] Copyright (C) Microsoft Corporation. All rights reserved. Build started 20.11.2014 11:09:46. Project "C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdC\CompilerIdC.vcxproj" on node 1 (default targets). PrepareForBuild: Creating directory "Debug\". Creating directory "Debug\CompilerIdC.tlog\". InitializeBuildStatus: Creating "Debug\CompilerIdC.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified. ClCompile: C:\Program Files\Microsoft Visual Studio 12.0\VC\bin\CL.exe /c /I"C:\Program Files\INtime\rt\include\network7" /I"C:\Program Files\INtime\rt\include" /nologo /W0 /WX- /Od /Oy- /D _DEBUG /D __C99__ /D __INTIME__ /X /GF /Gm- /EHa /RTC1 /MDd /GS /Gy- /fp:precise /fp:except- /Zc:wchar_t /Zc:forScope /GR- /openmp- /Fo"Debug\\" /Fd"Debug\vc120.pdb" /Gd /TC /analyze- /errorReport:prompt CMakeCCompilerId.c CMakeCCompilerId.c Link: C:\Program Files\Microsoft Visual Studio 12.0\VC\bin\link.exe /ERRORREPORT:PROMPT /OUT:".\CompilerIdC.rta" /VERSION:"21076.20052" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\Program Files\INtime\rt\lib" rt.lib pcibus.lib netlib.lib clib.lib vshelper.lib rmxiff3m.lib /NODEFAULTLIB /MANIFEST:NO /PDB:".\CompilerIdC.pdb" /ASSEMBLYDEBUG:DISABLE /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdC.lib" /MACHINE:X86 /SAFESEH:NO /SAFESEH:NO Debug\CMakeCCompilerId.obj CMakeCCompilerId.obj : error LNK2001: unresolved external symbol __RTC_InitBase [C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdC\CompilerIdC.vcxproj] CMakeCCompilerId.obj : error LNK2001: unresolved external symbol __RTC_Shutdown [C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdC\CompilerIdC.vcxproj] .\CompilerIdC.rta : fatal error LNK1120: 2 unresolved externals [C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdC\CompilerIdC.vcxproj] Done Building Project "C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdC\CompilerIdC.vcxproj" (default targets) -- FAILED. Build FAILED. "C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdC\CompilerIdC.vcxproj" (default target) (1) -> (Link target) -> CMakeCCompilerId.obj : error LNK2001: unresolved external symbol __RTC_InitBase [C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdC\CompilerIdC.vcxproj] CMakeCCompilerId.obj : error LNK2001: unresolved external symbol __RTC_Shutdown [C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdC\CompilerIdC.vcxproj] .\CompilerIdC.rta : fatal error LNK1120: 2 unresolved externals [C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdC\CompilerIdC.vcxproj] 0 Warning(s) 3 Error(s) Time Elapsed 00:00:03.04 Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed. Compiler: Build flags: Id flags: The output was: 1 Microsoft (R) Build Engine version 12.0.31101.0 [Microsoft .NET Framework, version 4.0.30319.18444] Copyright (C) Microsoft Corporation. All rights reserved. Build started 20.11.2014 11:09:50. Project "C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdCXX\CompilerIdCXX.vcxproj" on node 1 (default targets). PrepareForBuild: Creating directory "Debug\". Creating directory "Debug\CompilerIdCXX.tlog\". InitializeBuildStatus: Creating "Debug\CompilerIdCXX.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified. ClCompile: C:\Program Files\Microsoft Visual Studio 12.0\VC\bin\CL.exe /c /I"C:\Program Files\INtime\rt\include\network7" /I"C:\Program Files\INtime\rt\include" /nologo /W0 /WX- /Od /Oy- /D _DEBUG /D __C99__ /D __INTIME__ /X /GF /Gm- /EHa /RTC1 /MDd /GS /Gy- /fp:precise /fp:except- /Zc:wchar_t /Zc:forScope /GR- /openmp- /Fo"Debug\\" /Fd"Debug\vc120.pdb" /Gd /TP /analyze- /errorReport:prompt CMakeCXXCompilerId.cpp CMakeCXXCompilerId.cpp Link: C:\Program Files\Microsoft Visual Studio 12.0\VC\bin\link.exe /ERRORREPORT:PROMPT /OUT:".\CompilerIdCXX.rta" /VERSION:"21076.20052" /INCREMENTAL:NO /NOLOGO /LIBPATH:"C:\Program Files\INtime\rt\lib" rt.lib pcibus.lib netlib.lib clib.lib vshelper.lib rmxiff3m.lib /NODEFAULTLIB /MANIFEST:NO /PDB:".\CompilerIdCXX.pdb" /ASSEMBLYDEBUG:DISABLE /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\CompilerIdCXX.lib" /MACHINE:X86 /SAFESEH:NO /SAFESEH:NO Debug\CMakeCXXCompilerId.obj CMakeCXXCompilerId.obj : error LNK2001: unresolved external symbol __RTC_InitBase [C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdCXX\CompilerIdCXX.vcxproj] CMakeCXXCompilerId.obj : error LNK2001: unresolved external symbol __RTC_Shutdown [C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdCXX\CompilerIdCXX.vcxproj] .\CompilerIdCXX.rta : fatal error LNK1120: 2 unresolved externals [C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdCXX\CompilerIdCXX.vcxproj] Done Building Project "C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdCXX\CompilerIdCXX.vcxproj" (default targets) -- FAILED. Build FAILED. "C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdCXX\CompilerIdCXX.vcxproj" (default target) (1) -> (Link target) -> CMakeCXXCompilerId.obj : error LNK2001: unresolved external symbol __RTC_InitBase [C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdCXX\CompilerIdCXX.vcxproj] CMakeCXXCompilerId.obj : error LNK2001: unresolved external symbol __RTC_Shutdown [C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdCXX\CompilerIdCXX.vcxproj] .\CompilerIdCXX.rta : fatal error LNK1120: 2 unresolved externals [C:\Users\bca\Desktop\test_build\build\CMakeFiles\3.1.0-rc2\CompilerIdCXX\CompilerIdCXX.vcxproj] 0 Warning(s) 3 Error(s) Time Elapsed 00:00:01.14 From braden at endoframe.com Thu Nov 20 08:48:59 2014 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 20 Nov 2014 08:48:59 -0500 Subject: [CMake] Interaction between source COMPILE_FLAGS and directory COMPILE_OPTIONS In-Reply-To: References: Message-ID: <1416491339.2633.4.camel@hinge.endoframe.net> On Wed, 2014-11-19 at 22:55 +0000, Braden McDaniel wrote: > The documentation for the source property COMPILE_FLAGS describes it > as, "Additional flags to be added when compiling this source file." > However, when using the Visual Studio 2013 generator (at least), it appears > to replace (rather than complement) the options added via the directory > property COMPILE_OPTIONS. > > It (i.e., source COMPILE_FLAGS) also replaces options added by setting the > CMAKE__FLAGS variable. > > Is this the intended behavior? Actually, let me amend this a bit... Upon further testing, the flags that seem to be affected are the ones that disable warnings (i.e., "/wdXXXX"). That is, if I add these flags in the source COMPILE_FLAGS, they replace any "/wdXXXX" flags specified in the directory COMPILE_OPTIONS. AFAICT so far, other flags in the directory COMPILE_OPTIONS are left intact. I am using CMake 3.0.2. -- Braden McDaniel From erik.sjolund at gmail.com Thu Nov 20 08:56:35 2014 From: erik.sjolund at gmail.com (=?UTF-8?Q?Erik_Sj=C3=B6lund?=) Date: Thu, 20 Nov 2014 14:56:35 +0100 Subject: [CMake] empty CMAKE_CXX_KNOWN_FEATURES in cmake 3.1.0-rc2 Message-ID: CMAKE_CXX_KNOWN_FEATURES seems to be empty in cmake 3.1.0-rc2 Should it be? cheers, Erik Sj?lund erik at ubuntu:~/tmp$ cat CMakeLists.txt cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR) project(foobar CXX) list(LENGTH CMAKE_CXX_KNOWN_FEATURES length1) message("length of CMAKE_CXX_KNOWN_FEATURES=${length1}") list(LENGTH CMAKE_CXX_COMPILE_FEATURES length2) message("length of CMAKE_CXX_COMPILE_FEATURES=${length2}") erik at ubuntu:~/tmp$ ../cmake-3.1.0-rc2-Linux-i386/bin/cmake . length of CMAKE_CXX_KNOWN_FEATURES=0 length of CMAKE_CXX_COMPILE_FEATURES=54 -- Configuring done -- Generating done -- Build files have been written to: /home/esjolund/tmp erik at ubuntu:~/tmp$ cat /etc/issue Ubuntu 14.10 \n \l From bill.hoffman at kitware.com Thu Nov 20 11:40:45 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 20 Nov 2014 11:40:45 -0500 Subject: [CMake] CMake and VS Community Edition In-Reply-To: References: Message-ID: <546E198D.8070900@kitware.com> On 11/20/2014 12:32 AM, Andrew Maclean wrote: > I only picked this up because I use the Microsoft Visual Studio Version > Selector to open the *.sln file by default. > > Tested on CMake 3.0.2 and the pre-release version CMake 3.1.20141119 > > VS 2013 Community Edition will happily use the VS Express 2013 solution > file. > Not sure there is much that can be done about this... The code checks the registry: cmGlobalVisualStudio12Generator.cxx: ... std::string vc12Express; this->ExpressEdition = cmSystemTools::ReadRegistryValue( "HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VCExpress\\12.0\\Setup\\VC;" "ProductDir", vc12Express, cmSystemTools::KeyWOW64_32); this->DefaultPlatformToolset = "v120"; I guess you could check it for both, and if the non-express one was around use that one... At least it seems to work with both. -Bill From kgt at lanl.gov Thu Nov 20 12:18:53 2014 From: kgt at lanl.gov (Thompson, KT) Date: Thu, 20 Nov 2014 17:18:53 +0000 Subject: [CMake] issues with static linking and Intel compiler on Crays In-Reply-To: References: Message-ID: <0458DF31F610EF42BFC78C497E806C7B3B535D32@ECS-EXG-P-MB03.win.lanl.gov> Mark, I also have had a lot of difficulty using cmake in the Cray computing environment (Cray XE6). My team has given up on autodetection of the build environment. Instead we use cmake in a cross compiling environment (http://www.cmake.org/Wiki/CMake_Cross_Compiling), where we manually specify CMAKE_SYSTEM_NAME, CMAKE_[C|CXX|Fortran]_COMPILER, MPIEXEC, MPI_[C|CXX|Fortran]_LIBRARIES, etc. This seems to be the most reliable way of building with all of the Cray wrapper scripts. Obviously, the above comment doesn't address your specific issue. However, I wanted to voice my solution here for the benefit of other mailing list readers or the cmake dev team. If someone has a robust way of using cmake's autodetect features under the Cray development environment I would like to know how to make that work! -kt ________________________________ From: CMake [cmake-bounces at cmake.org] on behalf of Mark Abraham [mark.j.abraham at gmail.com] Sent: Tuesday, November 18, 2014 8:18 AM To: cmake at cmake.org Subject: [CMake] issues with static linking and Intel compiler on Crays Hi, I have two proposals for fixing issues with CMake generating suitable command lines for static linking on Cray supercomputers when using Intel as the base compiler. I hope I'm posting to the right list for discussion. Happy to switch to cmake-developers or Mantis. :-) Summary: The default Linux-Intel.cmake platform file adds -rdynamic to the command line for compiling the test for whether the toolchain works, which can fail if the toolchain isn't set up to deal with that Background: Cray provides a wrapper compiler that handles things like MPI and CUDA, and that wrapper compiler can be configured to use the Gnu, Intel or Cray compilers as their base. The wrapper can also be configured to require the use of static linking. This requirement can be side-stepped with "export XTPE_LINK_TYPE=dynamic", but this doesn't mean that a suitable library exists. Symptoms: On Archer (Cray XC30 in Edinburgh) with CMake 2.8.12 (or pre-3.1 CMake git master) I get: debug trycompile on -- The C compiler identification is Intel 14.0.0.20140805 -- The CXX compiler identification is Intel 14.0.0.20140805 -- Check for working C compiler: /opt/cray/craype/2.2.0/bin/cc -- Check for working C compiler: /opt/cray/craype/2.2.0/bin/cc -- broken CMake Error at /home2/y07/y07/cmake/2.8.12-i386/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "/opt/cray/craype/2.2.0/bin/cc" is not able to compile a simple test program. ... /opt/cray/craype/2.2.0/bin/cc CMakeFiles/cmTryCompileExec3645868218.dir/testCCompiler.c.o -o cmTryCompileExec3645868218 -rdynamic ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/libc.a(strcmp.o)' can not be used when making an executable; recompile with -fPIE and relink with -pie There may be a fair point here that the Cray and Intel machinery should not be combining to pick up stuff from /usr/lib64/gcc, but I don't see a libc in the Intel compiler installation, so maybe that is a feature after all. Using Gnu as the base compiler also generates the -rdynamic, but it copes with it. The issue for CMake is the existence of -rdynamic on the command line, when testing for basic functionality in a toolchain intended for static linking. The -rdynamic is a feature (see http://www.cmake.org/Bug/view.php?id=9985), set in the platform file, that supports some minor functionality, and when it is a problem, it can mostly be worked around by users by SET(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "") However, fixing the above problem only works if such set() commands are present in the platform file. Unfortunately, that's where the settings they are working around are made... Solutions could be: 1) We could introduce a specific platform files for Linux-Intel-Cray-${lang}-static (in CMake or in an end-user application), just to make sure -rdynamic isn't set by default. This permits the test for compiler functionality to pass, and as a side effect, avoids users of the platform file needing to set this in their CMakery. 2) The attached patch (based on CMake git master) allows CMake to recognize a situation when there's no linking going on, and to avoid adding linking flags. However, it is general to all platforms and calls to generate linking command lines. I don't know whether this is a good idea, because it could affect other platforms that depend on such behaviour for linking system libraries, etc. How good is the CMake CI setup? :-) If so, maybe some kind of policy setting might be needed. Are there other options, or issues I haven't considered? Regards, Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Thu Nov 20 12:33:37 2014 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 20 Nov 2014 18:33:37 +0100 Subject: [CMake] empty CMAKE_CXX_KNOWN_FEATURES in cmake 3.1.0-rc2 References: Message-ID: Erik Sj?lund wrote: > CMAKE_CXX_KNOWN_FEATURES seems to be empty in > cmake 3.1.0-rc2 > > Should it be? Yes, it's not a variable, but a global property: get_property(cxx_features GLOBAL PROPERTY CMAKE_CXX_KNOWN_FEATURES) message("known: ${cxx_features}") Thanks, Steve. From alexey.petruchik at gmail.com Thu Nov 20 12:39:56 2014 From: alexey.petruchik at gmail.com (Alexey Petruchik) Date: Thu, 20 Nov 2014 20:39:56 +0300 Subject: [CMake] How to build shared library as bundle on OS X? Message-ID: I have a shared library. To build it as framework i write: set_target_properties(lib_name FRAMEWORK TRUE) How I build it as bundle? Please dont confuse library bundle with application bundle. Regards, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.kreuzberger at procitec.de Fri Nov 21 09:59:50 2014 From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=) Date: Fri, 21 Nov 2014 15:59:50 +0100 Subject: [CMake] INSTALL with FILES and generator expressions Message-ID: Hi! i would like to install files with generator expressions. I define a variable with my qt install files. These looks like this: QT_INSTALL_FILES $<$:/home/src/qt/486-64-dbg/lib/libQtCore-486-ubgcc482x64.so.4>;$<$:/home/src/qt/486-64-dbg/lib/libQtCore-486-ubgcc482x64.so.4>;$<$:/home/src/qt/486-64-dbg/lib/libQtXml-486-ubgcc482x64.so.4>;$<$:/home/src/qt/486-64-dbg/lib/libQtXml-486-ubgcc482x64.so.4>;/home/src/s4_branch/s4/src/procitec/src/tools/internal/genmaw/$<$:/home/src/qt/486-64-dbg/lib/libQtCore-486-ubgcc482x64.so.4>;/home/src/s4_branch/s4/src/procitec/src/tools/internal/genmaw/$<$:/home/src/qt/486-64-dbg/lib/libQtCore-486-ubgcc482x64.so.4>;/home/src/s4_branch/s4/src/procitec/src/tools/internal/genmaw/$<$:/home/src/qt/486-64-dbg/lib/libQtXml-486-ubgcc482x64.so.4>;/home/src/s4_branch/s4/src/procitec/src/tools/internal/genmaw/$<$:/home/src/qt/486-64-dbg/lib/libQtXml-486-ubgcc482x64.so.4> If i now install, cmake prepends the CMAKE_CURRENT_SOURCE_DIR to the files and fails with "cannot find file /my/current/source/dir/home/...." Why is the file detected as "full" path? Environment is unix and cmake 3.0, generator is unix makefiles Thanks for any help Joerg From j.kreuzberger at procitec.de Fri Nov 21 10:09:17 2014 From: j.kreuzberger at procitec.de (=?utf-8?Q?J=C3=B6rg_Kreuzberger?=) Date: Fri, 21 Nov 2014 16:09:17 +0100 Subject: [CMake] =?utf-8?q?INSTALL_with_FILES_and_generator_expressions?= Message-ID: Ok, found the issues. A little later in the script a collegue added a few lines which "resolved" the files with realpath. this seems to corrupt the generator expression :-) after removing those lines, everything workes as expected. Have a nice weekend. Joerg From cliffyapp at gmail.com Fri Nov 21 11:27:31 2014 From: cliffyapp at gmail.com (Clifford Yapp) Date: Fri, 21 Nov 2014 11:27:31 -0500 Subject: [CMake] Default selected build configuration when opening Visual Studio project Message-ID: We have a large project defined in CMake that we generate Visual Studio solution files for, and we've noticed that even if the default build type is set to Release in CMake, the Visual Studio project still opens in Debug mode by default. Is there some setting we can enable that would make Visual Studio open up the project by default with the same configuration specified as default by CMake? Cheers, CY From parag at ionicsecurity.com Fri Nov 21 15:37:01 2014 From: parag at ionicsecurity.com (Parag Chandra) Date: Fri, 21 Nov 2014 20:37:01 +0000 Subject: [CMake] Looking for a way to post-process Visual Studio projects generated by CMake Message-ID: I've been using the RC builds of CMake 3.1 to generate Visual Studio projects for Native Client. I have things working pretty well with a few workarounds, but I'm still having one problem that I can't figure out a solution to. I am targeting the PNaCl environment of Native Client, and by default, Google's project system for Visual Studio will perform a very expensive translation step to convert the final .pexe executable file into architecture-specific .nexe files, one each for x86, x86_64, and ARM. There are project settings to disable this translation step, but these options do not seem to translate into any compiler/linker flags that I can see. Instead, XML nodes are added to the resultant .vcxproj file when you disable the translation. My question is if there is a way to post-process the .vcxproj file that CMake generates in order to add these additional XML nodes? The na?ve thing I tried first is to just run a script to make the modifications, but of course the next time CMake runs it will regenerate the project file and wipe out these changes. Regards, Parag Chandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From becker.tobi at gmail.com Sat Nov 22 17:34:47 2014 From: becker.tobi at gmail.com (Tobias Becker) Date: Sat, 22 Nov 2014 23:34:47 +0100 Subject: [CMake] CTest integration in Visual Studio TestExplorer Message-ID: So I tried my luck with creating an extension for Visual Studio that allows you to use the Test Explorer to discover and run your CTests. You can download it in the visual studio gallery. Read about it on http://thetoeb.de/2014/11/22/ctest-integration-visualstudio/ . I'd be happy if anyone wanted to give me feedback or contribute on https://github.com/toeb/CTestTestAdapter ;) Sorry for the shameless plug (but hey - its free) Kind Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.kmoch at gmail.com Mon Nov 24 06:16:33 2014 From: petr.kmoch at gmail.com (Petr Kmoch) Date: Mon, 24 Nov 2014 12:16:33 +0100 Subject: [CMake] Looking for a way to post-process Visual Studio projects generated by CMake In-Reply-To: References: Message-ID: Hi Parag. There is no way to hook arbitrary postprocessing, and as per http://public.kitware.com/Bug/view.php?id=13020 , that is by design. For your specific issue, CMake has some support for customising a .vc[x]proj using target properties like VS_KEYWORD or VS_GLOBAL_. You can look whether any of them might help generate what you need. Petr On Fri, Nov 21, 2014 at 9:37 PM, Parag Chandra wrote: > I?ve been using the RC builds of CMake 3.1 to generate Visual Studio > projects for Native Client. I have things working pretty well with a few > workarounds, but I?m still having one problem that I can?t figure out a > solution to. I am targeting the PNaCl environment of Native Client, and by > default, Google?s project system for Visual Studio will perform a very > expensive translation step to convert the final .pexe executable file into > architecture-specific .nexe files, one each for x86, x86_64, and ARM. There > are project settings to disable this translation step, but these options do > not seem to translate into any compiler/linker flags that I can see. > Instead, XML nodes are added to the resultant .vcxproj file when you > disable the translation. > > My question is if there is a way to post-process the .vcxproj file that > CMake generates in order to add these additional XML nodes? The na?ve thing > I tried first is to just run a script to make the modifications, but of > course the next time CMake runs it will regenerate the project file and > wipe out these changes. > > Regards, > > Parag Chandra > > -- > > 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 Mon Nov 24 09:01:43 2014 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Mon, 24 Nov 2014 14:01:43 +0000 Subject: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... Message-ID: <8D981219EEA621479C112DA9BDC39A8E26D387A3@EXMBS1.ad.igd.fraunhofer.de> I am trying to add a library via it's variable(s) in an installed (static library) target, but BUILD_INTERFACE appears to be used for the generation of *-targets-*.cmake even when using install(EXPORT...), instead of INSTALL_INTERFACE: CMakeLists.txt [...] target_link_libraries(${PROJECT_NAME} PUBLIC $<$:$> $<$>:$> ) [...] install(EXPORT ${PROJECT_NAME}-targets DESTINATION share/cmake) produces a file containing: IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "${Boost_COROUTINE_LIBRARY_RELEASE}" Which seems wrong (and since I had to use the variable in BUILD_INTERFACE I can no longer use it from other projects within the same Build -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) 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 jamesbigler at gmail.com Mon Nov 24 12:54:18 2014 From: jamesbigler at gmail.com (James Bigler) Date: Mon, 24 Nov 2014 10:54:18 -0700 Subject: [CMake] FindCUDA: Specify nvcc language in cuda_add_executable In-Reply-To: References: Message-ID: cuda_add_executable(mytarget foo.cc OPTIONS -x cu) Unfortunately, FindCUDA is setup to ignore any files that aren't .cu files. CUDA_WRAP_SRCS() ... foreach(file ${ARGN}) # Ignore any file marked as a HEADER_FILE_ONLY get_source_file_property(_is_header ${file} HEADER_FILE_ONLY) if(${file} MATCHES ".*\\.cu$" AND NOT _is_header) On Fri, Nov 14, 2014 at 10:26 AM, Joan Puigcerver wrote: > Hi, > > I'm trying to use CMake with FindCUDA to compile a C++/CUDA code, and > I am having a small issue with cuda_add_executable. > > One of my files has the .cc extension, but it may import headers which > contain CUDA kernels definitions (depending on wheather I want to use > CUDA or not). So, I need to compile it as a CUDA file. You can tell > nvcc to ignore the file extension and use a particular language with > the -x option. For instance: > > nvcc -x cu foo.cc > > Will force to compile foo.cc as a CUDA file. > > However, I don't know how to pass that compilation option to nvcc > through cuda_add_executable. I tried to set it in the CUDA_NVCC_FLAGS > variable, but it never gets passed to nvcc, since CMake calls directly > the C++ compiler. > > Can anyone suggest how to force the -x option? > > PS: One dirty fix is to create a symlink from foo.cc to foo.cu, and > compile foo.cu if CUDA is enable, or foo.cc if it is not. CMake works > fine with this workaround, but I'd rather pass the -x option and keep > my code base clean. > -- > > 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 andrew.amaclean at gmail.com Tue Nov 25 00:45:55 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 25 Nov 2014 16:45:55 +1100 Subject: [CMake] CMake & QT5.3 Message-ID: When I build CMake (master version: 3.1.20141123-g2a0c) with VS2013 Community Edition (win64) and Qt 5,3 I get the following warning: CMake Warning (dev) at C:/Qt/5.3/msvc2013_64_opengl/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:224 (configure_file): configure_file called with unknown argument(s): COPY_ONLY Call Stack (most recent call first): Source/QtDialog/CMakeLists.txt:28 (qt5_add_resources) Source/QtDialog/CMakeLists.txt:122 (QT4_ADD_RESOURCES) This warning is for project developers. Use -Wno-dev to suppress it. cannot compile simplest ever MFC app, avoiding MFC test Configuring done Generating done Ignore MFC I don't have it installed so the status message is correct. Line 224 reads: configure_file("${infile}" "${out_depends}" COPY_ONLY) The documentation on cmake_packages makes no reference to COPY_ONLY (it did in 3.0.2 see: http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#id12). In http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html there is no mention that this has been dropped. Maybe a reference should be inserted here noting that COPY_ONLY is no longer a parameter in configure_file(). It looks like it has been replaced by COPYONLY. The Qt developers may not have picked up on this. Also in Source/QtDialog/CMakeLists.txt would it be possible to modify it so that when QT5 is found, the QT4 warning is suppressed? Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eike at sf-mail.de Tue Nov 25 01:55:47 2014 From: eike at sf-mail.de (Rolf Eike Beer) Date: Tue, 25 Nov 2014 07:55:47 +0100 Subject: [CMake] CMake & QT5.3 In-Reply-To: References: Message-ID: <12884391.C8uNmef16l@eto> Andrew Maclean wrote: > When I build CMake (master version: 3.1.20141123-g2a0c) with VS2013 > Community Edition (win64) and Qt 5,3 I get the following warning: > > CMake Warning (dev) at > C:/Qt/5.3/msvc2013_64_opengl/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:224 > (configure_file): > configure_file called with unknown argument(s): > > COPY_ONLY > > Call Stack (most recent call first): > Source/QtDialog/CMakeLists.txt:28 (qt5_add_resources) > Source/QtDialog/CMakeLists.txt:122 (QT4_ADD_RESOURCES) > This warning is for project developers. Use -Wno-dev to suppress it. > > cannot compile simplest ever MFC app, avoiding MFC test > > Configuring done > Generating done > > Ignore MFC I don't have it installed so the status message is correct. > > Line 224 reads: > configure_file("${infile}" "${out_depends}" COPY_ONLY) > > The documentation on cmake_packages makes no reference to COPY_ONLY (it did > in 3.0.2 see: > http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#id12). > In http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html there is no > mention that this has been dropped. Maybe a reference should be inserted > here noting that COPY_ONLY is no longer a parameter in configure_file(). It > looks like it has been replaced by COPYONLY. The Qt developers may not have > picked up on this. From CMake git: commit e9282782e489a78de9c2896ee01fdd02ce8ca396 Author: Iosif Neitzke Date: Fri Oct 31 11:26:51 2014 -0500 Help: Fix configure_file call to use COPYONLY, not COPY_ONLY The configure_file signature has option 'COPYONLY' (no underscore). Fix the example in 'cmake-packages.7.rst'. It had been wrong forever, there was a typo in the documentation and some code, but this never worked. Eike -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From andrew.amaclean at gmail.com Tue Nov 25 02:28:26 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 25 Nov 2014 18:28:26 +1100 Subject: [CMake] CMake & QT5.3 In-Reply-To: <12884391.C8uNmef16l@eto> References: <12884391.C8uNmef16l@eto> Message-ID: Thanks Rolf. I'll modify my QT 5.3 version to silence this. Regards Andrew On Tue, Nov 25, 2014 at 5:55 PM, Rolf Eike Beer wrote: > Andrew Maclean wrote: > > When I build CMake (master version: 3.1.20141123-g2a0c) with VS2013 > > Community Edition (win64) and Qt 5,3 I get the following warning: > > > > CMake Warning (dev) at > > C:/Qt/5.3/msvc2013_64_opengl/lib/cmake/Qt5Core/Qt5CoreMacros.cmake:224 > > (configure_file): > > configure_file called with unknown argument(s): > > > > COPY_ONLY > > > > Call Stack (most recent call first): > > Source/QtDialog/CMakeLists.txt:28 (qt5_add_resources) > > Source/QtDialog/CMakeLists.txt:122 (QT4_ADD_RESOURCES) > > This warning is for project developers. Use -Wno-dev to suppress it. > > > > cannot compile simplest ever MFC app, avoiding MFC test > > > > Configuring done > > Generating done > > > > Ignore MFC I don't have it installed so the status message is correct. > > > > Line 224 reads: > > configure_file("${infile}" "${out_depends}" COPY_ONLY) > > > > The documentation on cmake_packages makes no reference to COPY_ONLY (it > did > > in 3.0.2 see: > > http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#id12). > > In http://www.cmake.org/cmake/help/v3.1/release/3.1.0.html there is no > > mention that this has been dropped. Maybe a reference should be inserted > > here noting that COPY_ONLY is no longer a parameter in configure_file(). > It > > looks like it has been replaced by COPYONLY. The Qt developers may not > have > > picked up on this. > > From CMake git: > > commit e9282782e489a78de9c2896ee01fdd02ce8ca396 > Author: Iosif Neitzke > Date: Fri Oct 31 11:26:51 2014 -0500 > > Help: Fix configure_file call to use COPYONLY, not COPY_ONLY > > The configure_file signature has option 'COPYONLY' (no underscore). > Fix the example in 'cmake-packages.7.rst'. > > It had been wrong forever, there was a typo in the documentation and some > code, but this never worked. > > Eike > -- > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Tue Nov 25 02:45:45 2014 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 25 Nov 2014 18:45:45 +1100 Subject: [CMake] Using CMAKE_CXX_KNOWN_FEATURES Message-ID: Is this a reasonable approach to using cx_11 features on multiple platforms? The issue is that I think you need to manually select the MSVC compiler version that supports these features target_compile_features only works for gcc. #------------------------------------------ project(nullptr) #----------------------------------------------------------------------------- # We will enforce an out of source build. string(COMPARE EQUAL "${${project_name}_source_dir}" "${${PROJECT_NAME}_BINARY_DIR}" INSOURCE) if(INSOURCE) message(FATAL_ERROR "${PROJECT_NAME} requires an out of source build. Please create a separate binary directory and run CMake there.") endif(INSOURCE) #----------------------------------------------------------------------------- # Don't build anything unless the version of CMake is high enough. cmake_minimum_required(VERSION 2.8) #----------------------------------------------------------------------------- # Directory where the CMakeFiles are set ( CMAKE_FILE_DIR ${PROJECT_SOURCE_DIR}/CMake ) #----------------------------------------------------------------------------- # Includes. set ( INCS ) #----------------------------------------------------------------------------- # Sources. set ( SRCS main.cpp ) get_property(cxx_features GLOBAL PROPERTY CMAKE_CXX_KNOWN_FEATURES) message(STATUS "This CMake version supports these C++ features:") foreach(i ${cxx_features}) message(STATUS "${i}") endforeach() message(STATUS "Compiler ID/Version: ${CMAKE_CXX_COMPILER_ID} ${CMAKE_CXX_COMPILER_VERSION}") #----------------------------------------------------------------------------- # Includes. set ( INCS ) #----------------------------------------------------------------------------- # Sources. set ( SRCS main.cpp ) set(needed_features cxx_lambdas cxx_nullptr) # We may need to define flags based on the needed features. foreach(i ${needed_features}) string(TOUPPER ${i} s) add_definitions("-D${s}") endforeach() if(UNIX) add_executable(${PROJECT_NAME} ${SRCS} ${INCS}) target_compile_features(${PROJECT_NAME} PUBLIC ${needed_features}) elseif (MSVC_VERSION GREATER "1700") # Pick a MSVC version that supports what you need. add_executable(${PROJECT_NAME} ${SRCS} ${INCS}) else() message(FATAL_ERROR "No suitable compiler exists.") endif() #------------------------------------------ -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Tue Nov 25 07:40:19 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 25 Nov 2014 13:40:19 +0100 Subject: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... References: <8D981219EEA621479C112DA9BDC39A8E26D387A3@EXMBS1.ad.igd.fraunhofer.de> Message-ID: Mueller-Roemer, Johannes Sebastian wrote: > produces a file containing: > IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE > "${Boost_COROUTINE_LIBRARY_RELEASE}" You need to make sure policy CMP0022 is NEW for the BUILD_INTERFACE to be handled correctly. Unfortunately there is no warning in this case. See http://www.cmake.org/cmake/help/v3.1/manual/cmake-policies.7.html for more. Thanks, Steve. From steveire at gmail.com Tue Nov 25 07:44:11 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 25 Nov 2014 13:44:11 +0100 Subject: [CMake] Using CMAKE_CXX_KNOWN_FEATURES References: Message-ID: Andrew Maclean wrote: > Is this a reasonable approach to using cx_11 features on multiple > platforms? The issue is that I think you need to manually select the MSVC > compiler version that supports these features target_compile_features only > works for gcc. Correct, I'm no confident I can maintain the known MSVC features as new MSVC releases appear and as CMake gains knowledge of new features in the future. If you can do that, then https://gitorious.org/cmake/steveires-cmake/source/0156b7f4f169fe91971a072460db0f781ade2119:Modules/Compiler/MSVC-CXX-FeatureTests.cmake is a starting point listing features of some existing releases. It should maybe be updated with information from http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2015-preview.aspx Please post to the cmake-developers mailing list if you wish to maintain that file, and we can get it into a future release. Thanks, Steve. From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Tue Nov 25 08:31:09 2014 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Tue, 25 Nov 2014 13:31:09 +0000 Subject: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... In-Reply-To: References: <8D981219EEA621479C112DA9BDC39A8E26D387A3@EXMBS1.ad.igd.fraunhofer.de> Message-ID: <8D981219EEA621479C112DA9BDC39A8E26D39B36@EXMBS1.ad.igd.fraunhofer.de> It appears that wasn't really the issue, but rather that I had my CMake minimum version set to 2.8.11 and not 2.8.12. Is there a cleaner solution for the "debug" and "optimized" keyword issue than using individual library variables? -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) 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 -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Stephen Kelly Sent: Tuesday, November 25, 2014 13:40 To: cmake at cmake.org Subject: Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... Mueller-Roemer, Johannes Sebastian wrote: > produces a file containing: > IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE > "${Boost_COROUTINE_LIBRARY_RELEASE}" You need to make sure policy CMP0022 is NEW for the BUILD_INTERFACE to be handled correctly. Unfortunately there is no warning in this case. See http://www.cmake.org/cmake/help/v3.1/manual/cmake-policies.7.html for more. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake From nilsgladitz at gmail.com Tue Nov 25 08:49:13 2014 From: nilsgladitz at gmail.com (Nils Gladitz) Date: Tue, 25 Nov 2014 14:49:13 +0100 Subject: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E26D39B36@EXMBS1.ad.igd.fraunhofer.de> References: <8D981219EEA621479C112DA9BDC39A8E26D387A3@EXMBS1.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E26D39B36@EXMBS1.ad.igd.fraunhofer.de> Message-ID: <547488D9.8010202@gmail.com> On 11/25/2014 02:31 PM, Mueller-Roemer, Johannes Sebastian wrote: > It appears that wasn't really the issue, but rather that I had my CMake minimum version set to 2.8.11 and not 2.8.12. cmake_minimum_required(VERSION 2.8.12) sets policy CMP0022 to NEW because the policy was introduced in 2.8.12. Nils From steveire at gmail.com Tue Nov 25 09:04:50 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 25 Nov 2014 15:04:50 +0100 Subject: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... References: <8D981219EEA621479C112DA9BDC39A8E26D387A3@EXMBS1.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E26D39B36@EXMBS1.ad.igd.fraunhofer.de> Message-ID: Mueller-Roemer, Johannes Sebastian wrote: > It appears that wasn't really the issue, but rather that I had my CMake > minimum version set to 2.8.11 and not 2.8.12. See the reply from Nils and the documentation link I posted previously. > Is there a cleaner solution > for the "debug" and "optimized" keyword issue than using individual > library variables? I don't fully understand the question. Imported targets for Boost would be cleaner, but there's no one submitting and maintaining such a thing. There was a discussion that could be picked up though. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10332/focus=10370 Thanks, Steve. From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Tue Nov 25 09:11:18 2014 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Tue, 25 Nov 2014 14:11:18 +0000 Subject: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... In-Reply-To: References: <8D981219EEA621479C112DA9BDC39A8E26D387A3@EXMBS1.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E26D39B36@EXMBS1.ad.igd.fraunhofer.de> Message-ID: <8D981219EEA621479C112DA9BDC39A8E26D39B64@EXMBS1.ad.igd.fraunhofer.de> For clarification: As an imported target can't have debug and optimized keywords, I can't simply use $ $ But have to do $: ${Boost_COROUTINE_LIBRARY_DEBUG} ${Boost_CONTEXT_LIBRARY_DEBUG} ${Boost_SYSTEM_LIBRARY_DEBUG} > $<$>: ${Boost_COROUTINE_LIBRARY_RELEASE} ${Boost_CONTEXT_LIBRARY_RELEASE} ${Boost_SYSTEM_LIBRARY_RELEASE} > > $: \${Boost_COROUTINE_LIBRARY_DEBUG} \${Boost_CONTEXT_LIBRARY_DEBUG} \${Boost_SYSTEM_LIBRARY_DEBUG} > $<$>: \${Boost_COROUTINE_LIBRARY_RELEASE} \${Boost_CONTEXT_LIBRARY_RELEASE} \${Boost_SYSTEM_LIBRARY_RELEASE} > > Instead which is excessively verbose... -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) 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 -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Stephen Kelly Sent: Tuesday, November 25, 2014 15:05 To: cmake at cmake.org Subject: Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... Mueller-Roemer, Johannes Sebastian wrote: > It appears that wasn't really the issue, but rather that I had my > CMake minimum version set to 2.8.11 and not 2.8.12. See the reply from Nils and the documentation link I posted previously. > Is there a cleaner solution > for the "debug" and "optimized" keyword issue than using individual > library variables? I don't fully understand the question. Imported targets for Boost would be cleaner, but there's no one submitting and maintaining such a thing. There was a discussion that could be picked up though. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10332/focus=10370 Thanks, Steve. -- 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 steveire at gmail.com Tue Nov 25 10:14:21 2014 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 25 Nov 2014 16:14:21 +0100 Subject: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... References: <8D981219EEA621479C112DA9BDC39A8E26D387A3@EXMBS1.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E26D39B36@EXMBS1.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E26D39B64@EXMBS1.ad.igd.fraunhofer.de> Message-ID: Mueller-Roemer, Johannes Sebastian wrote: > For clarification: > > As an imported target can't have debug and optimized keywords, I can't > simply use $ > $ But have to do > $ $<$: > ... Yes, but for the user of the target, it's just target_link_libraries(mytgt Boost::Coroutine) This is academic though anyway until someone decides to submit and maintain IMPORTED targets for Boost, or until Boost decides to make them available itself. So, for now, you are correct, it's verbose. Thanks, Steve. From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Tue Nov 25 10:25:34 2014 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Tue, 25 Nov 2014 15:25:34 +0000 Subject: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... In-Reply-To: References: <8D981219EEA621479C112DA9BDC39A8E26D387A3@EXMBS1.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E26D39B36@EXMBS1.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E26D39B64@EXMBS1.ad.igd.fraunhofer.de> Message-ID: <8D981219EEA621479C112DA9BDC39A8E26D39BB3@EXMBS1.ad.igd.fraunhofer.de> Actually, I'm using this to make a static library that uses boost useable via find_package without having hard-coded paths inside it and my Config.cmake contains a find_package(Boost 1.56 EXACT REQUIRED COMPONENTS coroutine context system). So it isn't exactly only academic... Yes, it would be simpler if Boost already provided IMPORTED targets, but expecting IMPORTED targets for every library out there is not realistic, so another, ideally less verbose, solution would be incredibly useful. -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) 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 -----Original Message----- From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Stephen Kelly Sent: Tuesday, November 25, 2014 16:14 To: cmake at cmake.org Subject: Re: [CMake] BUILD_INTERFACE genex used even in install(EXPORT... Mueller-Roemer, Johannes Sebastian wrote: > For clarification: > > As an imported target can't have debug and optimized keywords, I can't > simply use $ > $ But have to do > $ $<$: > ... Yes, but for the user of the target, it's just target_link_libraries(mytgt Boost::Coroutine) This is academic though anyway until someone decides to submit and maintain IMPORTED targets for Boost, or until Boost decides to make them available itself. So, for now, you are correct, it's verbose. Thanks, Steve. -- 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 elfring at users.sourceforge.net Tue Nov 25 14:00:51 2014 From: elfring at users.sourceforge.net (SF Markus Elfring) Date: Tue, 25 Nov 2014 20:00:51 +0100 Subject: [CMake] Generation of source file packages? In-Reply-To: References: <546123E6.4080905@users.sourceforge.net> <5461BFC2.9010903@users.sourceforge.net> <03332482-D47D-4117-B542-0BF814D7000A@hendrik-sattler.de> <54623F8C.4000502@users.sourceforge.net> <54624F47.9040401@users.sourceforge.net> Message-ID: <5474D1E3.9090302@users.sourceforge.net> > Basically package source generator (in the sense of RPM, DEB and alike) > are unsupported. I hoped that the CPack software can also help with the corresponding processing for such data formats. http://www.cmake.org/Wiki/CMake:CPackPackageGenerators Do I need to achieve the desired source file archive variants with template files instead? http://www.cmake.org/cmake/help/v3.0/command/configure_file.html Regards, Markus From cxjohnson at gmail.com Tue Nov 25 19:35:58 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Tue, 25 Nov 2014 18:35:58 -0600 Subject: [CMake] Creating a library from subdirectories Message-ID: This CMake wiki page ( http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library) claims one can create a library from subdirectories containing libraries, which is exactly what I want to do. However, it doesn't seem to work. Here's my SSCCE ( http://sscce.org) "toy" example file structure: . |-- CMakeLists.txt |-- component1/ | |-- CMakeLists.txt | `-- c1.c |-- component2/ | |-- CMakeLists.txt | `-- c2.c `-- dummy.c ## Here's the top level CMakeLists.txt, per example from Wiki: cmake_minimum_required(VERSION 2.8.4) project(lib) add_subdirectory(component1) add_subdirectory(component2) add_library(lib dummy.c) target_link_libraries(lib component1 component2) ## The subdirectory CMakeLists.txt files contain effectively just: add_library(component1 STATIC c1.c) ## and add_library(component2 STATIC c2.c) ## The resulting library file liblib.a contains only the dummy placeholder, but none of the subdirectory content: lib$ ar tv liblib.a rw-r--r-- 502/20 696 Nov 25 18:23 2014 dummy.c.o ## Is there some way to make this work? * Ideally, I would not even need the dummy.c placeholder, but I can live with that. * I do not want to list all of the source files in the top level CMakeLists.txt file. * I do not want to use the add_library(component1 OBJECT ${component1_sources}) and add_library(toplevel $ ... ) syntax if it can be avoided. The reasons for my limitations is that to the greatest extent possible, I am generating CMakeLists.txt files via automation which needs to use a sort of a least-common-denominator approach to building those files. ..chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Wed Nov 26 07:50:01 2014 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Wed, 26 Nov 2014 12:50:01 +0000 Subject: [CMake] Creating a library from subdirectories In-Reply-To: References: Message-ID: <8D981219EEA621479C112DA9BDC39A8E26D3BDF8@EXMBS1.ad.igd.fraunhofer.de> In the example on that site an OBJECT library is created (the output consists of multiple .obj files), you used STATIC libraries instead (which each output a single .lib) -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) 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: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Chris Johnson Sent: Wednesday, November 26, 2014 01:36 To: cmake at cmake.org Subject: [CMake] Creating a library from subdirectories This CMake wiki page (http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library) claims one can create a library from subdirectories containing libraries, which is exactly what I want to do. However, it doesn't seem to work. Here's my SSCCE (http://sscce.org) "toy" example file structure: . |-- CMakeLists.txt |-- component1/ | |-- CMakeLists.txt | `-- c1.c |-- component2/ | |-- CMakeLists.txt | `-- c2.c `-- dummy.c ## Here's the top level CMakeLists.txt, per example from Wiki: cmake_minimum_required(VERSION 2.8.4) project(lib) add_subdirectory(component1) add_subdirectory(component2) add_library(lib dummy.c) target_link_libraries(lib component1 component2) ## The subdirectory CMakeLists.txt files contain effectively just: add_library(component1 STATIC c1.c) ## and add_library(component2 STATIC c2.c) ## The resulting library file liblib.a contains only the dummy placeholder, but none of the subdirectory content: lib$ ar tv liblib.a rw-r--r-- 502/20 696 Nov 25 18:23 2014 dummy.c.o ## Is there some way to make this work? * Ideally, I would not even need the dummy.c placeholder, but I can live with that. * I do not want to list all of the source files in the top level CMakeLists.txt file. * I do not want to use the add_library(component1 OBJECT ${component1_sources}) and add_library(toplevel $ ... ) syntax if it can be avoided. The reasons for my limitations is that to the greatest extent possible, I am generating CMakeLists.txt files via automation which needs to use a sort of a least-common-denominator approach to building those files. ..chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Wed Nov 26 07:52:36 2014 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Wed, 26 Nov 2014 12:52:36 +0000 Subject: [CMake] Creating a library from subdirectories References: Message-ID: <8D981219EEA621479C112DA9BDC39A8E26D3BE0F@EXMBS1.ad.igd.fraunhofer.de> Sorry overread the last point in your mail. I don?t believe there is a way to avoid this directly. What you seem to want is what Xcode calls a prelinked library (http://cocoadev.com/SingleObjectPrelink) . CMake does not have such an option as far as I know -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) 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: Mueller-Roemer, Johannes Sebastian Sent: Wednesday, November 26, 2014 13:50 To: 'Chris Johnson'; cmake at cmake.org Subject: RE: [CMake] Creating a library from subdirectories In the example on that site an OBJECT library is created (the output consists of multiple .obj files), you used STATIC libraries instead (which each output a single .lib) -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) 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: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Chris Johnson Sent: Wednesday, November 26, 2014 01:36 To: cmake at cmake.org Subject: [CMake] Creating a library from subdirectories This CMake wiki page (http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library) claims one can create a library from subdirectories containing libraries, which is exactly what I want to do. However, it doesn't seem to work. Here's my SSCCE (http://sscce.org) "toy" example file structure: . |-- CMakeLists.txt |-- component1/ | |-- CMakeLists.txt | `-- c1.c |-- component2/ | |-- CMakeLists.txt | `-- c2.c `-- dummy.c ## Here's the top level CMakeLists.txt, per example from Wiki: cmake_minimum_required(VERSION 2.8.4) project(lib) add_subdirectory(component1) add_subdirectory(component2) add_library(lib dummy.c) target_link_libraries(lib component1 component2) ## The subdirectory CMakeLists.txt files contain effectively just: add_library(component1 STATIC c1.c) ## and add_library(component2 STATIC c2.c) ## The resulting library file liblib.a contains only the dummy placeholder, but none of the subdirectory content: lib$ ar tv liblib.a rw-r--r-- 502/20 696 Nov 25 18:23 2014 dummy.c.o ## Is there some way to make this work? * Ideally, I would not even need the dummy.c placeholder, but I can live with that. * I do not want to list all of the source files in the top level CMakeLists.txt file. * I do not want to use the add_library(component1 OBJECT ${component1_sources}) and add_library(toplevel $ ... ) syntax if it can be avoided. The reasons for my limitations is that to the greatest extent possible, I am generating CMakeLists.txt files via automation which needs to use a sort of a least-common-denominator approach to building those files. ..chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Wed Nov 26 08:08:33 2014 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Wed, 26 Nov 2014 13:08:33 +0000 Subject: [CMake] out-of-tree buildable libraries and find_package Message-ID: <8D981219EEA621479C112DA9BDC39A8E26D3BE27@EXMBS1.ad.igd.fraunhofer.de> I have a project which uses a number of libraries, a bit like this: CMakeLists.txt -> add_subdirectories, add_executable Lib1 -> add_library Lib2 -> add_library, links to/uses Lib1 As the libraries are individually useful I'd like to keep them individually buildable (i.e., out-of-tree). Obviously, Lib2 will then have to do a find_package(Lib1). However, the find_package will fail if it is built in-tree. I currently see three options: 1. Protect the find_package() with if(CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_SOURCE_DIR) 2. Use export(TARGETS) and export(PACKAGE), however this leads to warnings when using CMake 3 3. Write an empty (or ALIAS-target only if using namespaces for the real config) ${PROJECT_NAME}-config.cmake to CMAKE_BINARY_DIR and add CMAKE_BINARY_DIR to CMAKE_PREFIX PATH in the root CMakeLists.txt None of these really feels right. Are there better options? What is the cleanest solution? -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) 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 cxjohnson at gmail.com Wed Nov 26 14:45:33 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Wed, 26 Nov 2014 13:45:33 -0600 Subject: [CMake] Creating a library from subdirectories In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E26D3BE0F@EXMBS1.ad.igd.fraunhofer.de> References: <8D981219EEA621479C112DA9BDC39A8E26D3BE0F@EXMBS1.ad.igd.fraunhofer.de> Message-ID: I know that one cannot link static libraries together; they're just archives of objects, really. But since CMake abstracts the actual construction of the library, it could conceivably know how to do the right thing and collect all the needed objects recursively, as it appears to do for executables. It seems it does not know how to do this. Hence, I believe the section of the wiki quoted below is thus in error, as it implies this kind of transitive linking resolution can be done. I've made it work using OBJECT libraries, but as I originally mentioned, I'm really trying for the simplest, most basic kind CMakeLists.txt syntax possible so as to allow my automation to do most of the work (I have a very large source tree). Thanks. Quote: For example, we can create two subdirectories: # A/CMakeLists.txt add_library(A ${A_srcs}) # B/CMakeLists.txt add_library(B ${B_srcs}) and then refer to those libraries from the top directory: # CMakeLists.txt add_subdirectory(A) add_subdirectory(B) add_library(big ${other_srcs}) target_link_libraries(big A B) This approach is easy to use and helps organize the project source tree. Since CMake tracks link dependencies automatically it is easy to refer to the "big" library in target_link_libraries calls elsewhere in the project and let CMake propagate the dependency on A and B. On Wed, Nov 26, 2014 at 6:52 AM, Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > Sorry overread the last point in your mail. I don?t believe there is a > way to avoid this directly. What you seem to want is what Xcode calls a > prelinked library (http://cocoadev.com/SingleObjectPrelink) . CMake does > not have such an option as far as I know > > > > -- > > Johannes S. Mueller-Roemer, MSc > > Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) > > > > 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:* Mueller-Roemer, Johannes Sebastian > *Sent:* Wednesday, November 26, 2014 13:50 > *To:* 'Chris Johnson'; cmake at cmake.org > *Subject:* RE: [CMake] Creating a library from subdirectories > > > > In the example on that site an OBJECT library is created (the output > consists of multiple .obj files), you used STATIC libraries instead (which > each output a single .lib) > > > > -- > > Johannes S. Mueller-Roemer, MSc > > Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) > > > > 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:* CMake [mailto:cmake-bounces at cmake.org ] *On > Behalf Of *Chris Johnson > *Sent:* Wednesday, November 26, 2014 01:36 > *To:* cmake at cmake.org > *Subject:* [CMake] Creating a library from subdirectories > > > > This CMake wiki page ( > http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library) claims one can > create a library from subdirectories containing libraries, which is exactly > what I want to do. However, it doesn't seem to work. Here's my SSCCE ( > http://sscce.org) "toy" example file structure: > > > > . > > |-- CMakeLists.txt > > |-- component1/ > > | |-- CMakeLists.txt > > | `-- c1.c > > |-- component2/ > > | |-- CMakeLists.txt > > | `-- c2.c > > `-- dummy.c > > > > > > ## Here's the top level CMakeLists.txt, per example from Wiki: > > > > cmake_minimum_required(VERSION 2.8.4) > > project(lib) > > add_subdirectory(component1) > > add_subdirectory(component2) > > add_library(lib dummy.c) > > target_link_libraries(lib component1 component2) > > > > ## The subdirectory CMakeLists.txt files contain effectively just: > > add_library(component1 STATIC c1.c) > > ## and > > add_library(component2 STATIC c2.c) > > > > > > ## The resulting library file liblib.a contains only the dummy > placeholder, but none of the subdirectory content: > > > > lib$ ar tv liblib.a > > > > rw-r--r-- 502/20 696 Nov 25 18:23 2014 dummy.c.o > > > > > > ## Is there some way to make this work? > > > > * Ideally, I would not even need the dummy.c placeholder, but I can live > with that. > > > > * I do not want to list all of the source files in the top level > CMakeLists.txt file. > > > > * I do not want to use the add_library(component1 OBJECT > ${component1_sources}) and add_library(toplevel > $ ... ) syntax if it can be avoided. > > > > > > The reasons for my limitations is that to the greatest extent possible, I > am generating CMakeLists.txt files via automation which needs to use a sort > of a least-common-denominator approach to building those files. > > > > ..chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de Wed Nov 26 15:10:50 2014 From: Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de (Mueller-Roemer, Johannes Sebastian) Date: Wed, 26 Nov 2014 20:10:50 +0000 Subject: [CMake] Creating a library from subdirectories In-Reply-To: References: <8D981219EEA621479C112DA9BDC39A8E26D3BE0F@EXMBS1.ad.igd.fraunhofer.de>, Message-ID: <8D981219EEA621479C112DA9BDC39A8E26D3DF9A@EXMBS1.ad.igd.fraunhofer.de> No, the quoted text is absolutely correct. If you were to do add_executable(exec ${srcs}) target_link_libraries(exec big) A and B would be linked in automatically, as CMake tracks the link dependencies, just as the quote states. This does not mean that libbig.a contains libA.a and libB.a, only that CMake knows that those have to be linked as well. ________________________________ From: Chris Johnson [cxjohnson at gmail.com] Sent: Wednesday, November 26, 2014 8:45 PM To: Mueller-Roemer, Johannes Sebastian Cc: cmake at cmake.org Subject: Re: [CMake] Creating a library from subdirectories I know that one cannot link static libraries together; they're just archives of objects, really. But since CMake abstracts the actual construction of the library, it could conceivably know how to do the right thing and collect all the needed objects recursively, as it appears to do for executables. It seems it does not know how to do this. Hence, I believe the section of the wiki quoted below is thus in error, as it implies this kind of transitive linking resolution can be done. I've made it work using OBJECT libraries, but as I originally mentioned, I'm really trying for the simplest, most basic kind CMakeLists.txt syntax possible so as to allow my automation to do most of the work (I have a very large source tree). Thanks. Quote: For example, we can create two subdirectories: # A/CMakeLists.txt add_library(A ${A_srcs}) # B/CMakeLists.txt add_library(B ${B_srcs}) and then refer to those libraries from the top directory: # CMakeLists.txt add_subdirectory(A) add_subdirectory(B) add_library(big ${other_srcs}) target_link_libraries(big A B) This approach is easy to use and helps organize the project source tree. Since CMake tracks link dependencies automatically it is easy to refer to the "big" library in target_link_libraries calls elsewhere in the project and let CMake propagate the dependency on A and B. On Wed, Nov 26, 2014 at 6:52 AM, Mueller-Roemer, Johannes Sebastian > wrote: Sorry overread the last point in your mail. I don?t believe there is a way to avoid this directly. What you seem to want is what Xcode calls a prelinked library (http://cocoadev.com/SingleObjectPrelink) . CMake does not have such an option as far as I know -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) 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: Mueller-Roemer, Johannes Sebastian Sent: Wednesday, November 26, 2014 13:50 To: 'Chris Johnson'; cmake at cmake.org Subject: RE: [CMake] Creating a library from subdirectories In the example on that site an OBJECT library is created (the output consists of multiple .obj files), you used STATIC libraries instead (which each output a single .lib) -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) 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: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Chris Johnson Sent: Wednesday, November 26, 2014 01:36 To: cmake at cmake.org Subject: [CMake] Creating a library from subdirectories This CMake wiki page (http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library) claims one can create a library from subdirectories containing libraries, which is exactly what I want to do. However, it doesn't seem to work. Here's my SSCCE (http://sscce.org) "toy" example file structure: . |-- CMakeLists.txt |-- component1/ | |-- CMakeLists.txt | `-- c1.c |-- component2/ | |-- CMakeLists.txt | `-- c2.c `-- dummy.c ## Here's the top level CMakeLists.txt, per example from Wiki: cmake_minimum_required(VERSION 2.8.4) project(lib) add_subdirectory(component1) add_subdirectory(component2) add_library(lib dummy.c) target_link_libraries(lib component1 component2) ## The subdirectory CMakeLists.txt files contain effectively just: add_library(component1 STATIC c1.c) ## and add_library(component2 STATIC c2.c) ## The resulting library file liblib.a contains only the dummy placeholder, but none of the subdirectory content: lib$ ar tv liblib.a rw-r--r-- 502/20 696 Nov 25 18:23 2014 dummy.c.o ## Is there some way to make this work? * Ideally, I would not even need the dummy.c placeholder, but I can live with that. * I do not want to list all of the source files in the top level CMakeLists.txt file. * I do not want to use the add_library(component1 OBJECT ${component1_sources}) and add_library(toplevel $ ... ) syntax if it can be avoided. The reasons for my limitations is that to the greatest extent possible, I am generating CMakeLists.txt files via automation which needs to use a sort of a least-common-denominator approach to building those files. ..chris From d3ck0r at gmail.com Wed Nov 26 15:30:32 2014 From: d3ck0r at gmail.com (J Decker) Date: Wed, 26 Nov 2014 12:30:32 -0800 Subject: [CMake] Creating a library from subdirectories In-Reply-To: <8D981219EEA621479C112DA9BDC39A8E26D3DF9A@EXMBS1.ad.igd.fraunhofer.de> References: <8D981219EEA621479C112DA9BDC39A8E26D3BE0F@EXMBS1.ad.igd.fraunhofer.de> <8D981219EEA621479C112DA9BDC39A8E26D3DF9A@EXMBS1.ad.igd.fraunhofer.de> Message-ID: So a) add_library( OBJECT) you could add a custom target and rename big to big_part add_custom_target( big ) add_custom_command( TARGET big OUTPUT bigl.a DEPENDS big_part A B COMMAND ... ) ties you to a platform though.... why are you conglomerating? On Wed, Nov 26, 2014 at 12:10 PM, Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > > No, the quoted text is absolutely correct. If you were to do > > add_executable(exec ${srcs}) > target_link_libraries(exec big) > > A and B would be linked in automatically, as CMake tracks the link dependencies, just as the quote states. This does not mean that libbig.a contains libA.a and libB.a, only that CMake knows that those have to be linked as well. > ________________________________ > From: Chris Johnson [cxjohnson at gmail.com] > Sent: Wednesday, November 26, 2014 8:45 PM > To: Mueller-Roemer, Johannes Sebastian > Cc: cmake at cmake.org > Subject: Re: [CMake] Creating a library from subdirectories > > I know that one cannot link static libraries together; they're just archives of objects, really. But since CMake abstracts the actual construction of the library, it could conceivably know how to do the right thing and collect all the needed objects recursively, as it appears to do for executables. It seems it does not know how to do this. Hence, I believe the section of the wiki quoted below is thus in error, as it implies this kind of transitive linking resolution can be done. I've made it work using OBJECT libraries, but as I originally mentioned, I'm really trying for the simplest, most basic kind CMakeLists.txt syntax possible so as to allow my automation to do most of the work (I have a very large source tree). Thanks. > > Quote: > > For example, we can create two subdirectories: > > # A/CMakeLists.txt > add_library(A ${A_srcs}) > > # B/CMakeLists.txt > add_library(B ${B_srcs}) > > > and then refer to those libraries from the top directory: > > # CMakeLists.txt > add_subdirectory(A) > add_subdirectory(B) > add_library(big ${other_srcs}) > target_link_libraries(big A B) > > > This approach is easy to use and helps organize the project source tree. Since CMake tracks link dependencies automatically it is easy to refer to the "big" library in target_link_libraries calls elsewhere in the project and let CMake propagate the dependency on A and B. > > > > On Wed, Nov 26, 2014 at 6:52 AM, Mueller-Roemer, Johannes Sebastian < Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > Sorry overread the last point in your mail. I don?t believe there is a way to avoid this directly. What you seem to want is what Xcode calls a prelinked library (http://cocoadev.com/SingleObjectPrelink) . CMake does not have such an option as far as I know > > -- > Johannes S. Mueller-Roemer, MSc > Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) > > 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< http://www.igd.fraunhofer.de> > > From: Mueller-Roemer, Johannes Sebastian > Sent: Wednesday, November 26, 2014 13:50 > To: 'Chris Johnson'; cmake at cmake.org > Subject: RE: [CMake] Creating a library from subdirectories > > In the example on that site an OBJECT library is created (the output consists of multiple .obj files), you used STATIC libraries instead (which each output a single .lib) > > -- > Johannes S. Mueller-Roemer, MSc > Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) > > 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< http://www.igd.fraunhofer.de> > > From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Chris Johnson > Sent: Wednesday, November 26, 2014 01:36 > To: cmake at cmake.org > Subject: [CMake] Creating a library from subdirectories > > This CMake wiki page ( http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library) claims one can create a library from subdirectories containing libraries, which is exactly what I want to do. However, it doesn't seem to work. Here's my SSCCE ( http://sscce.org) "toy" example file structure: > > . > |-- CMakeLists.txt > |-- component1/ > | |-- CMakeLists.txt > | `-- c1.c > |-- component2/ > | |-- CMakeLists.txt > | `-- c2.c > `-- dummy.c > > > ## Here's the top level CMakeLists.txt, per example from Wiki: > > cmake_minimum_required(VERSION 2.8.4) > project(lib) > add_subdirectory(component1) > add_subdirectory(component2) > add_library(lib dummy.c) > target_link_libraries(lib component1 component2) > > ## The subdirectory CMakeLists.txt files contain effectively just: > add_library(component1 STATIC c1.c) > ## and > add_library(component2 STATIC c2.c) > > > ## The resulting library file liblib.a contains only the dummy placeholder, but none of the subdirectory content: > > lib$ ar tv liblib.a > > rw-r--r-- 502/20 696 Nov 25 18:23 2014 dummy.c.o > > > ## Is there some way to make this work? > > * Ideally, I would not even need the dummy.c placeholder, but I can live with that. > > * I do not want to list all of the source files in the top level CMakeLists.txt file. > > * I do not want to use the add_library(component1 OBJECT ${component1_sources}) and add_library(toplevel lt;TARGET_OBJECTS:component1> ... ) syntax if it can be avoided. > > > The reasons for my limitations is that to the greatest extent possible, I am generating CMakeLists.txt files via automation which needs to use a sort of a least-common-denominator approach to building those files. > > ..chris > > -- > > 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 steveire at gmail.com Wed Nov 26 16:30:31 2014 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 26 Nov 2014 22:30:31 +0100 Subject: [CMake] Creating a library from subdirectories References: Message-ID: Chris Johnson wrote: > * I do not want to use the add_library(component1 OBJECT > ${component1_sources}) and add_library(toplevel > $ ... ) syntax if it can be avoided. Is the constraint that you want a top-level something like # All components: set(components component1 component2) foreach(comp ${components}) add_subdirectory(${comp}) endforeach() add_library(mylib dummy.c) target_link_libraries(mylib ${components}) add_executable(other_target main.c) target_link_libraries(other_target mylib) ? While at the same time not caring what type the components libraries are (OBJECT/STATIC etc)? A solution for that is in CMake 3.1 by creating an INTERFACE library to hide the TARGET_OBJECTS expression: add_library(component1_objs OBJECT c1.c) add_library(component1 INTERFACE) target_sources(component1 INTERFACE $ ) There is a bug however, but I just pushed a fix for it after trying to extend your test case to use it: http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=672f1001 An INTERFACE library also helps you avoid the dummy.c by not creating the intermediate archive at all, if that fits within what you're trying to achieve here: add_library(mylib INTERFACE) target_link_libraries(mylib INTERFACE ${components}) In the future it may be possible to link to OBJECT libraries directly without the INTERFACE library: http://public.kitware.com/Bug/view.php?id=14970 Another obvious solution, if it fits within what you're trying to achieve, is to avoid the OBJECT libraries instead: add_library(component1 INTERFACE) target_sources(component1 INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/c1.c ) This means that all binary consumers will compile their own version of each file, which you probably want to avoid. Additionally, you do need to specify an absolute path or CMake issues a not- informative-enough error. A second bug found from this thread, but which I haven't yet addressed (but should get done for 3.1 too). Thanks, Steve. From shlomi at hexadite.com Thu Nov 27 04:00:41 2014 From: shlomi at hexadite.com (shlomi) Date: Thu, 27 Nov 2014 02:00:41 -0700 (MST) Subject: [CMake] Compiling python with CMake Message-ID: <1417078841697-7589097.post@n2.nabble.com> Hello, I am trying to compile python 2.7.x with CMake using gcc I am actually wrapping the original project with cmake. my project already work on windows machine using VS2013 at the moment my code looks like this: #include "Python.h" int main(int argc, char* argv[]) { return 1; } very simple. I have issues with the CRT include files. I can't find the proper includes. my CMakeLists.txt looks like this: PROJECT(lib C ) cmake_minimum_required(VERSION 2.8) SET_TARGET_PROPERTIES(my_lib PROPERTIES LINKER_LANGUAGE C) set_source_files_properties(main.c PROPERTIES LANGUAGE C ) include_directories("/usr/lib/gcc/x86_64-linux-gnu/4.8/include") include_directories("Include") # python source include_directories("PC") # python source include_directories("/usr/include") include_directories("/usr/include/linux") include_directories("/usr/include/x86_64-linux-gnu/sys") I get many error, at they are from improper definitions. the errors now are: In file included from /usr/include/stdio.h:74, from /home/shlomi/git/AIRS/src/airs/actions_providers/agent/hosting_process/tmp/src/PC/pyconfig.h:296, from /home/shlomi/git/AIRS/src/airs/actions_providers/agent/hosting_process/tmp/src/Include/Python.h:8, from /home/shlomi/git/AIRS/src/airs/actions_providers/agent/hosting_process/tmp/main.c:1: /usr/include/libio.h:306: error: expected specifier-qualifier-list before ?size_t? /usr/include/libio.h:338: error: expected declaration specifiers or ?...? before ?size_t? following this: https://gcc.gnu.org/gcc-4.6/porting_to.html I changed my gcc from 4.8 to 4.4. so this: error: 'size_t' has not been declared changed to this: error: expected declaration specifiers or ?...? before ?size_t? my question is: what is the right setup for compiling python 2.7.x with cmake on linux using gcc? I would really appreciate assistance. -- View this message in context: http://cmake.3232098.n2.nabble.com/Compiling-python-with-CMake-tp7589097.html Sent from the CMake mailing list archive at Nabble.com. From becker.tobi at gmail.com Thu Nov 27 18:59:44 2014 From: becker.tobi at gmail.com (Tobias Becker) Date: Fri, 28 Nov 2014 00:59:44 +0100 Subject: [CMake] CMake and the Filesystem Message-ID: Hi! I've been continuing work on my enhancement suite for cmake. And just finished documenting and writing up some things about paths and filesystem handling using a couple of self developed functions. Also convenience functions for git, hg and svn. If your interested you can look at my blog post http://thetoeb.de/2014/11/27/cmake-filesystem/ or directly at the github repository https://github.com/toeb/oo-cmake Cheers! Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From traits.zhang at gmail.com Fri Nov 28 04:29:42 2014 From: traits.zhang at gmail.com (Zhang Xianyi) Date: Fri, 28 Nov 2014 17:29:42 +0800 Subject: [CMake] How about GNU Automatic Variables Message-ID: Hi, I want to use cmake for a library which supports different floating point precision. In Makefile, I used $(*F) to generate the different function name. Could I use $(*F) in cmake? ================== test.c =============== #ifdef DOUBLE #define TYPE double #else #define TYPE float #endif void CNAME(TYPE * a) { a[0]=1.0; } =========== Makefile ================ OBJS=test_single.o test_double.o all:$(OBJS) ar -rua libtest.a $(OBJS) test_single.o : test.c $(CC) -DCNAME=$(*F) -UDOUBLE -c $< -o $(@F) test_double.o : test.c $(CC) -DCNAME=$(*F) -DDOUBLE -c $< -o $(@F) ============ Thank you Xianyi -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Fri Nov 28 10:03:14 2014 From: d3ck0r at gmail.com (J Decker) Date: Fri, 28 Nov 2014 07:03:14 -0800 Subject: [CMake] How about GNU Automatic Variables In-Reply-To: References: Message-ID: On Fri, Nov 28, 2014 at 1:29 AM, Zhang Xianyi wrote: > Hi, > > I want to use cmake for a library which supports different floating point > precision. > > In Makefile, I used $(*F) to generate the different function name. > > Could I use $(*F) in cmake? > > > ================== > > test.c > > =============== > > #ifdef DOUBLE > > > #define TYPE double > > > #else > > > #define TYPE float > > > #endif > > > > void CNAME(TYPE * a) > > { > > a[0]=1.0; > > } > > > CMakeLists.txt ==================== cmake_minimum_required(VERSION 2.8) add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/test_double.c DEPENDS test.c COMMAND ${CMAKE_COMMAND} -E copy_if_different test.c ${CMAKE_BINARY_DIR}/test_double.c COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/test_double.c ) add_library( libtest test.c ${CMAKE_BINARY_DIR}/test_double.c ) SET_PROPERTY(SOURCE ${CMAKE_BINARY_DIR}/test_double.c APPEND PROPERTY COMPILE_DEFINITIONS "DOUBLE" ) ====================== =========== > > Makefile > > ================ > > OBJS=test_single.o test_double.o > > all:$(OBJS) > > ar -rua libtest.a $(OBJS) > > test_single.o : test.c > > $(CC) -DCNAME=$(*F) -UDOUBLE -c $< -o $(@F) > > test_double.o : test.c > > $(CC) -DCNAME=$(*F) -DDOUBLE -c $< -o $(@F) > > > ============ > > Thank you > > Xianyi > > -- > > 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 traits.zhang at gmail.com Fri Nov 28 13:41:10 2014 From: traits.zhang at gmail.com (Zhang Xianyi) Date: Sat, 29 Nov 2014 02:41:10 +0800 Subject: [CMake] L In-Reply-To: References: <4264631.hzuSDd0uN0@caliban.sf-tec.de> <1415657010919-7588979.post@n2.nabble.com> Message-ID: Hi Crni, I just added generating OpenBLASConfig.cmake on OpenBLAS develop branch. ( https://github.com/xianyi/OpenBLAS/commit/fe7dcf98f3666388b75839c6b3e6656580dcd222 ) I think the find_package(OpenBLAS) works fine now. Xianyi 2014-11-11 16:35 GMT+08:00 Crni Gorac : > On Tue, Nov 11, 2014 at 3:30 AM, Michael Jackson > wrote: > > > > Because if you do this then OpenBlas is instantly supported by currently > released versions of CMake. If you are asking for an update to the core of > CMake then you are going to have to wait for the next release of CMake and > then ALL of your users are going to have to update their CMake > installations. This may or may NOT be possible on all those systems. Having > used OpenBLAS for a current project I would like to see the OpenBLAS > developers step up and set an example for the other projects and properly > support CMake. Just my 2 cents worth. > > > > This is moot argument - if OpenBLAS provides OpenBLASConfig.cmake, > then its users have to update something (OpenBLAS in this case) > anyway, in order to have OpenBLAS+CMake working properly together... > So, again: as a CMake/OpenBLAS user, I really see no point in > requiring something from OpenBLAS that none of dozen of currently > supported BLAS implementations is doing. > > Thanks. > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cxjohnson at gmail.com Fri Nov 28 17:40:12 2014 From: cxjohnson at gmail.com (Chris Johnson) Date: Fri, 28 Nov 2014 16:40:12 -0600 Subject: [CMake] Creating a library from subdirectories In-Reply-To: References: Message-ID: Thanks to all who have replied for your efforts in trying to help me. My apologies for any lack of clarity in describing my problem. With the various information and advice you provided, I have been able to get my CMake configuration working. Thanks again! ..chris On Wed, Nov 26, 2014 at 3:30 PM, Stephen Kelly wrote: > Chris Johnson wrote: > > > * I do not want to use the add_library(component1 OBJECT > > ${component1_sources}) and add_library(toplevel > > $ ... ) syntax if it can be avoided. > > Is the constraint that you want a top-level something like > > # All components: > set(components component1 component2) > > foreach(comp ${components}) > add_subdirectory(${comp}) > endforeach() > > add_library(mylib dummy.c) > target_link_libraries(mylib ${components}) > > add_executable(other_target main.c) > target_link_libraries(other_target mylib) > > ? > > While at the same time not caring what type the components libraries are > (OBJECT/STATIC etc)? > > A solution for that is in CMake 3.1 by creating an INTERFACE library to > hide > the TARGET_OBJECTS expression: > > add_library(component1_objs OBJECT c1.c) > > add_library(component1 INTERFACE) > target_sources(component1 INTERFACE > $ > ) > > There is a bug however, but I just pushed a fix for it after trying to > extend your test case to use it: > > http://www.cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=672f1001 > > An INTERFACE library also helps you avoid the dummy.c by not creating the > intermediate archive at all, if that fits within what you're trying to > achieve here: > > add_library(mylib INTERFACE) > target_link_libraries(mylib INTERFACE ${components}) > > In the future it may be possible to link to OBJECT libraries directly > without the INTERFACE library: > > http://public.kitware.com/Bug/view.php?id=14970 > > Another obvious solution, if it fits within what you're trying to achieve, > is to avoid the OBJECT libraries instead: > > add_library(component1 INTERFACE) > target_sources(component1 INTERFACE > ${CMAKE_CURRENT_SOURCE_DIR}/c1.c > ) > > This means that all binary consumers will compile their own version of each > file, which you probably want to avoid. > > Additionally, you do need to specify an absolute path or CMake issues a > not- > informative-enough error. A second bug found from this thread, but which I > haven't yet addressed (but should get done for 3.1 too). > > Thanks, > > Steve. > > > -- > > 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 rob.zumwalt at gmail.com Fri Nov 28 22:12:48 2014 From: rob.zumwalt at gmail.com (Rob Zumwalt) Date: Fri, 28 Nov 2014 19:12:48 -0800 (PST) Subject: [CMake] Support OpenBLAS in FindBLAS module Message-ID: <997608DD-A743-43B6-8BE0-A58C117C7B7E@gmail.com> Apologies for the new thread, I just subscribed in order to comment on this, and didnt know how to reply in the existing thread. I am grateful to Xianyi for his addition of?OpenBlasConfig.cmake, and I do recognize that this is the direction that projects should go when wanting to build CMake support for their users. The issue, as cgorac points out, is that other projects (LAPACK in this case) use FindBLAS.cmake inside their FindLAPACK.cmake files. So, in order to get FindLAPACK.cmake to work with OpenBLAS, it would require that the developers that maintain FindLAPACK.cmake change that file. The same would have to happen for any other projects that use FindBLAS.cmake. In short, CMake already has a ?blessed? set of BLAS implementations (MKL, Intel, Goto, etc.), and it would be easier for users of LAPACK (and users of projects that use BLAS), if OpenBLAS were included in this set of CMake ?blessed? BLAS implementations. Of course, OpenBLAS would still be happy to provide OpenBlasConfig.cmake (I am guessing) for users of OpenBLAS directly. Best Regards, Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From traits.zhang at gmail.com Sat Nov 29 03:27:27 2014 From: traits.zhang at gmail.com (Zhang Xianyi) Date: Sat, 29 Nov 2014 16:27:27 +0800 Subject: [CMake] How about GNU Automatic Variables In-Reply-To: References: Message-ID: Hi Decker, Thank you for the answer. If I want to debug test_double, the debugger will refer to ${CMAKE_BINARY_DIR}/test_double.c. I am not sure it is appropriate to debug a generated file. Xianyi 2014-11-28 23:03 GMT+08:00 J Decker : > > > On Fri, Nov 28, 2014 at 1:29 AM, Zhang Xianyi > wrote: > >> Hi, >> >> I want to use cmake for a library which supports different floating point >> precision. >> >> In Makefile, I used $(*F) to generate the different function name. >> >> Could I use $(*F) in cmake? >> >> >> ================== >> >> test.c >> >> =============== >> >> #ifdef DOUBLE >> >> >> #define TYPE double >> >> >> #else >> >> >> #define TYPE float >> >> >> #endif >> >> >> >> void CNAME(TYPE * a) >> >> { >> >> a[0]=1.0; >> >> } >> >> >> > CMakeLists.txt > ==================== > cmake_minimum_required(VERSION 2.8) > > add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/test_double.c > DEPENDS test.c > COMMAND ${CMAKE_COMMAND} -E copy_if_different > test.c ${CMAKE_BINARY_DIR}/test_double.c > COMMAND ${CMAKE_COMMAND} -E touch > ${CMAKE_BINARY_DIR}/test_double.c > ) > > > add_library( libtest test.c ${CMAKE_BINARY_DIR}/test_double.c ) > > SET_PROPERTY(SOURCE ${CMAKE_BINARY_DIR}/test_double.c > APPEND > PROPERTY COMPILE_DEFINITIONS "DOUBLE" ) > > ====================== > > =========== >> >> Makefile >> >> ================ >> >> OBJS=test_single.o test_double.o >> >> all:$(OBJS) >> >> ar -rua libtest.a $(OBJS) >> >> test_single.o : test.c >> >> $(CC) -DCNAME=$(*F) -UDOUBLE -c $< -o $(@F) >> >> test_double.o : test.c >> >> $(CC) -DCNAME=$(*F) -DDOUBLE -c $< -o $(@F) >> >> >> ============ >> >> Thank you >> >> Xianyi >> >> -- >> >> 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 domen.vrankar at gmail.com Sat Nov 29 04:31:30 2014 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Sat, 29 Nov 2014 10:31:30 +0100 Subject: [CMake] How about GNU Automatic Variables In-Reply-To: References: Message-ID: Hi, I haven't tested this but I think you could write something like this: add_library(test_single test.c) set_property( TARGET test_single PROPERTY COMPILE_DEFINITIONS DOUBLE=some_val ) add_library(test_double test.c) set_property( TARGET test_double PROPERTY COMPILE_DEFINITIONS DOUBLE=some_other_val ) and then link the static libraries to an executable. As far as I know you could also use set_target_properties(test_single PROPERTIES COMPILE_DEFINITIONS DOUBLE=some_val) but I'm not certain what the difference is... Probably back compatibility... Hope this helps, Domen 2014-11-29 9:27 GMT+01:00 Zhang Xianyi : > Hi Decker, > > Thank you for the answer. > > If I want to debug test_double, the debugger will refer to > ${CMAKE_BINARY_DIR}/test_double.c. > I am not sure it is appropriate to debug a generated file. > > > Xianyi > > 2014-11-28 23:03 GMT+08:00 J Decker : >> >> >> >> On Fri, Nov 28, 2014 at 1:29 AM, Zhang Xianyi >> wrote: >>> >>> Hi, >>> >>> I want to use cmake for a library which supports different floating point >>> precision. >>> >>> In Makefile, I used $(*F) to generate the different function name. >>> >>> Could I use $(*F) in cmake? >>> >>> >>> ================== >>> >>> test.c >>> >>> =============== >>> >>> #ifdef DOUBLE >>> >>> #define TYPE double >>> >>> #else >>> >>> #define TYPE float >>> >>> #endif >>> >>> >>> void CNAME(TYPE * a) >>> >>> { >>> >>> a[0]=1.0; >>> >>> } >>> >>> >> >> CMakeLists.txt >> ==================== >> cmake_minimum_required(VERSION 2.8) >> >> add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/test_double.c >> DEPENDS test.c >> COMMAND ${CMAKE_COMMAND} -E copy_if_different >> test.c ${CMAKE_BINARY_DIR}/test_double.c >> COMMAND ${CMAKE_COMMAND} -E touch >> ${CMAKE_BINARY_DIR}/test_double.c >> ) >> >> >> add_library( libtest test.c ${CMAKE_BINARY_DIR}/test_double.c ) >> >> SET_PROPERTY(SOURCE ${CMAKE_BINARY_DIR}/test_double.c >> APPEND >> PROPERTY COMPILE_DEFINITIONS "DOUBLE" ) >> >> ====================== >> >>> =========== >>> >>> Makefile >>> >>> ================ >>> >>> OBJS=test_single.o test_double.o >>> >>> all:$(OBJS) >>> >>> ar -rua libtest.a $(OBJS) >>> >>> test_single.o : test.c >>> >>> $(CC) -DCNAME=$(*F) -UDOUBLE -c $< -o $(@F) >>> >>> test_double.o : test.c >>> >>> $(CC) -DCNAME=$(*F) -DDOUBLE -c $< -o $(@F) >>> >>> >>> ============ >>> >>> Thank you >>> >>> Xianyi >>> >>> >>> -- >>> >>> 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 domen.vrankar at gmail.com Sat Nov 29 04:48:59 2014 From: domen.vrankar at gmail.com (Domen Vrankar) Date: Sat, 29 Nov 2014 10:48:59 +0100 Subject: [CMake] How about GNU Automatic Variables In-Reply-To: References: Message-ID: I was curious and I looked a bit further: http://www.cmake.org/cmake/help/v3.0/command/add_library.html has a OBJECT target that perhaps you could use instead of static library. http://www.cmake.org/cmake/help/v3.0/command/set_property.html also has a SOURCE option that I haven't mentioned before because I'm not certain how to produce two differently named .o files but maybe you'll be able to figure that out... Regards, Domen 2014-11-29 10:31 GMT+01:00 Domen Vrankar : > Hi, > > I haven't tested this but I think you could write something like this: > > add_library(test_single test.c) > set_property( > TARGET test_single > PROPERTY COMPILE_DEFINITIONS DOUBLE=some_val > ) > add_library(test_double test.c) > set_property( > TARGET test_double > PROPERTY COMPILE_DEFINITIONS DOUBLE=some_other_val > ) > > and then link the static libraries to an executable. > > As far as I know you could also use > set_target_properties(test_single PROPERTIES COMPILE_DEFINITIONS > DOUBLE=some_val) > but I'm not certain what the difference is... Probably back compatibility... > > Hope this helps, > Domen > > > > 2014-11-29 9:27 GMT+01:00 Zhang Xianyi : >> Hi Decker, >> >> Thank you for the answer. >> >> If I want to debug test_double, the debugger will refer to >> ${CMAKE_BINARY_DIR}/test_double.c. >> I am not sure it is appropriate to debug a generated file. >> >> >> Xianyi >> >> 2014-11-28 23:03 GMT+08:00 J Decker : >>> >>> >>> >>> On Fri, Nov 28, 2014 at 1:29 AM, Zhang Xianyi >>> wrote: >>>> >>>> Hi, >>>> >>>> I want to use cmake for a library which supports different floating point >>>> precision. >>>> >>>> In Makefile, I used $(*F) to generate the different function name. >>>> >>>> Could I use $(*F) in cmake? >>>> >>>> >>>> ================== >>>> >>>> test.c >>>> >>>> =============== >>>> >>>> #ifdef DOUBLE >>>> >>>> #define TYPE double >>>> >>>> #else >>>> >>>> #define TYPE float >>>> >>>> #endif >>>> >>>> >>>> void CNAME(TYPE * a) >>>> >>>> { >>>> >>>> a[0]=1.0; >>>> >>>> } >>>> >>>> >>> >>> CMakeLists.txt >>> ==================== >>> cmake_minimum_required(VERSION 2.8) >>> >>> add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/test_double.c >>> DEPENDS test.c >>> COMMAND ${CMAKE_COMMAND} -E copy_if_different >>> test.c ${CMAKE_BINARY_DIR}/test_double.c >>> COMMAND ${CMAKE_COMMAND} -E touch >>> ${CMAKE_BINARY_DIR}/test_double.c >>> ) >>> >>> >>> add_library( libtest test.c ${CMAKE_BINARY_DIR}/test_double.c ) >>> >>> SET_PROPERTY(SOURCE ${CMAKE_BINARY_DIR}/test_double.c >>> APPEND >>> PROPERTY COMPILE_DEFINITIONS "DOUBLE" ) >>> >>> ====================== >>> >>>> =========== >>>> >>>> Makefile >>>> >>>> ================ >>>> >>>> OBJS=test_single.o test_double.o >>>> >>>> all:$(OBJS) >>>> >>>> ar -rua libtest.a $(OBJS) >>>> >>>> test_single.o : test.c >>>> >>>> $(CC) -DCNAME=$(*F) -UDOUBLE -c $< -o $(@F) >>>> >>>> test_double.o : test.c >>>> >>>> $(CC) -DCNAME=$(*F) -DDOUBLE -c $< -o $(@F) >>>> >>>> >>>> ============ >>>> >>>> Thank you >>>> >>>> Xianyi >>>> >>>> >>>> -- >>>> >>>> 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 bill at classdesign.com Sat Nov 29 06:58:33 2014 From: bill at classdesign.com (Bill Somerville) Date: Sat, 29 Nov 2014 11:58:33 +0000 Subject: [CMake] 3.1 can't link my MinGW executables any more. Message-ID: <5479B4E9.3010203@classdesign.com> Hi, I have just tried 3.1.0-rc2 and my executable links are failing because all the link libraries are not being added. I use: add_executable (jt65code lib/jt65code.f90 wsjtx.rc) target_link_libraries (jt65code wsjt) where wsjt is a static library target with Fortran and C functions. This normally gives a link edit step of: C:\Tools\Qt\Tools\mingw48_32\bin\g++.exe -Wall -Wextra -std=c++11 -fexceptions -frtti -pthread -g -Wl,--whole-archive CMakeFiles\jt65code.dir/objects.a -Wl,--no-whole-archive -o jt65code.exe -Wl,--out-implib,libjt65code.dll.a -Wl,--major-image-version,0,--minor-image-version,0 libwsjt.a -lgfortran -lquadmath -lm -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 but in 3.1.0-rc2 I get: C:\Tools\Qt\Tools\mingw48_32\bin\ar.exe cr CMakeFiles\jt65code.dir/objects.a @CMakeFiles\jt65code.dir\objects1.rsp C:\Tools\Qt\Tools\mingw48_32\bin\g++.exe -Wall -Wextra -std=c++11 -fexceptions -frtti -pthread -g -Wl,--whole-archive CMakeFiles\jt65code.dir/objects.a -Wl,--no-whole-archive -o jt65code.exe -Wl,--out-implib,libjt65code.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles\jt65code.dir\linklibs.rsp So it looks like the linklibs.rsp response file doesn't have the required entries. Looking at the build tree I find a linklibs.rsp in the top level directory (CMakeFIles/jt65code.dir) with the correct entries but the link edit command is passing a file in the subordinate 'lib' directory that doesn't exist. Something wrong with the use of a source in a subdirectory perhaps? Regards Bill Somerville. From bill at classdesign.com Sat Nov 29 07:02:42 2014 From: bill at classdesign.com (Bill Somerville) Date: Sat, 29 Nov 2014 12:02:42 +0000 Subject: [CMake] 3.1 can't link my MinGW executables any more. In-Reply-To: <5479B4E9.3010203@classdesign.com> References: <5479B4E9.3010203@classdesign.com> Message-ID: <5479B5E2.7080807@classdesign.com> On 29/11/2014 11:58, Bill Somerville wrote: > Hi, > > I have just tried 3.1.0-rc2 and my executable links are failing > because all the link libraries are not being added. > > I use: > > add_executable (jt65code lib/jt65code.f90 wsjtx.rc) > target_link_libraries (jt65code wsjt) > > where wsjt is a static library target with Fortran and C functions. > This normally gives a link edit step of: > > C:\Tools\Qt\Tools\mingw48_32\bin\g++.exe -Wall -Wextra -std=c++11 > -fexceptions -frtti -pthread -g -Wl,--whole-archive > CMakeFiles\jt65code.dir/objects.a -Wl,--no-whole-archive -o > jt65code.exe -Wl,--out-implib,libjt65code.dll.a > -Wl,--major-image-version,0,--minor-image-version,0 libwsjt.a > -lgfortran -lquadmath -lm -lkernel32 -luser32 -lgdi32 -lwinspool > -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 > > but in 3.1.0-rc2 I get: > > C:\Tools\Qt\Tools\mingw48_32\bin\ar.exe cr > CMakeFiles\jt65code.dir/objects.a @CMakeFiles\jt65code.dir\objects1.rsp > C:\Tools\Qt\Tools\mingw48_32\bin\g++.exe -Wall -Wextra -std=c++11 > -fexceptions -frtti -pthread -g -Wl,--whole-archive > CMakeFiles\jt65code.dir/objects.a -Wl,--no-whole-archive -o > jt65code.exe -Wl,--out-implib,libjt65code.dll.a > -Wl,--major-image-version,0,--minor-image-version,0 > @CMakeFiles\jt65code.dir\linklibs.rsp > > So it looks like the linklibs.rsp response file doesn't have the > required entries. > > Looking at the build tree I find a linklibs.rsp in the top level > directory (CMakeFIles/jt65code.dir) with the correct entries but the > link edit command is passing a file in the subordinate 'lib' directory > that doesn't exist. Something wrong with the use of a source in a > subdirectory perhaps? Sorry, I am talking rubbish here! So something is wrong with the response file itself, here it is: libwsjt.a -lquadmath -lm -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 and the problem is in fact that -lgfortran is missing! > > Regards > Bill Somerville. Regards Bill Somerville. From d3ck0r at gmail.com Sat Nov 29 07:36:37 2014 From: d3ck0r at gmail.com (J Decker) Date: Sat, 29 Nov 2014 04:36:37 -0800 Subject: [CMake] How about GNU Automatic Variables In-Reply-To: References: Message-ID: On Sat, Nov 29, 2014 at 12:27 AM, Zhang Xianyi wrote: > Hi Decker, > > Thank you for the answer. > > If I want to debug test_double, the debugger will refer to > ${CMAKE_BINARY_DIR}/test_double.c. > I am not sure it is appropriate to debug a generated file. > > it's as valid as any other source file... if you're not on that machine you'll have to map it in a exact location (which is why I usuauly use a drive like M: for all work... whether subst, net use; truecrypt, VHD etc... > > Xianyi > > 2014-11-28 23:03 GMT+08:00 J Decker : > >> >> >> On Fri, Nov 28, 2014 at 1:29 AM, Zhang Xianyi >> wrote: >> >>> Hi, >>> >>> I want to use cmake for a library which supports different floating >>> point precision. >>> >>> In Makefile, I used $(*F) to generate the different function name. >>> >>> Could I use $(*F) in cmake? >>> >>> >>> ================== >>> >>> test.c >>> >>> =============== >>> >>> #ifdef DOUBLE >>> >>> >>> #define TYPE double >>> >>> >>> #else >>> >>> >>> #define TYPE float >>> >>> >>> #endif >>> >>> >>> >>> void CNAME(TYPE * a) >>> >>> { >>> >>> a[0]=1.0; >>> >>> } >>> >>> >>> >> CMakeLists.txt >> ==================== >> cmake_minimum_required(VERSION 2.8) >> >> add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/test_double.c >> DEPENDS test.c >> COMMAND ${CMAKE_COMMAND} -E copy_if_different >> test.c ${CMAKE_BINARY_DIR}/test_double.c >> COMMAND ${CMAKE_COMMAND} -E touch >> ${CMAKE_BINARY_DIR}/test_double.c >> ) >> >> >> add_library( libtest test.c ${CMAKE_BINARY_DIR}/test_double.c ) >> >> SET_PROPERTY(SOURCE ${CMAKE_BINARY_DIR}/test_double.c >> APPEND >> PROPERTY COMPILE_DEFINITIONS "DOUBLE" ) >> >> ====================== >> >> =========== >>> >>> Makefile >>> >>> ================ >>> >>> OBJS=test_single.o test_double.o >>> >>> all:$(OBJS) >>> >>> ar -rua libtest.a $(OBJS) >>> >>> test_single.o : test.c >>> >>> $(CC) -DCNAME=$(*F) -UDOUBLE -c $< -o $(@F) >>> >>> test_double.o : test.c >>> >>> $(CC) -DCNAME=$(*F) -DDOUBLE -c $< -o $(@F) >>> >>> >>> ============ >>> >>> Thank you >>> >>> Xianyi >>> >>> -- >>> >>> 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 d3ck0r at gmail.com Sat Nov 29 07:43:18 2014 From: d3ck0r at gmail.com (J Decker) Date: Sat, 29 Nov 2014 04:43:18 -0800 Subject: [CMake] How about GNU Automatic Variables In-Reply-To: References: Message-ID: On Sat, Nov 29, 2014 at 1:48 AM, Domen Vrankar wrote: > I was curious and I looked a bit further: > http://www.cmake.org/cmake/help/v3.0/command/add_library.html has a > OBJECT target that perhaps you could use instead of static library. > > referencing objects is kinda messy, was actually cleaner to just copy things; I already did it for a whole slew of files so I could compile .c as C/C++/CLI ... but needed other compiler options; ended up copying almost the whole tree to ${cmake_binary_dir}/(subst/.c/.cpp/) because I couldn't set compile properties per project only per source.... > http://www.cmake.org/cmake/help/v3.0/command/set_property.html also > has a SOURCE option that I haven't mentioned before because I'm not > certain how to produce two differently named .o files but maybe you'll > be able to figure that out... > > That works, but it only applies to the name of the source; if you don't have differntly named sources it doesn't help; and I think that's the one I used in the first place.... ---- and as a related note; is better to make the generated output into binary dir; if into source_dir will just mess up source control and people will commit generated sources.... Regards, > Domen > > > 2014-11-29 10:31 GMT+01:00 Domen Vrankar : > > Hi, > > > > I haven't tested this but I think you could write something like this: > > > > add_library(test_single test.c) > > set_property( > > TARGET test_single > > PROPERTY COMPILE_DEFINITIONS DOUBLE=some_val > > ) > > add_library(test_double test.c) > > set_property( > > TARGET test_double > > PROPERTY COMPILE_DEFINITIONS DOUBLE=some_other_val > > ) > > > wouldn't be included in a single library, and you'd have to know later to include 2 libs, or maintain a varible that's a list of libs... > > and then link the static libraries to an executable. > > > > As far as I know you could also use > > set_target_properties(test_single PROPERTIES COMPILE_DEFINITIONS > > DOUBLE=some_val) > > but I'm not certain what the difference is... Probably back > compatibility... > > > > Hope this helps, > > Domen > > > > > > > > 2014-11-29 9:27 GMT+01:00 Zhang Xianyi : > >> Hi Decker, > >> > >> Thank you for the answer. > >> > >> If I want to debug test_double, the debugger will refer to > >> ${CMAKE_BINARY_DIR}/test_double.c. > >> I am not sure it is appropriate to debug a generated file. > >> > >> > >> Xianyi > >> > >> 2014-11-28 23:03 GMT+08:00 J Decker : > >>> > >>> > >>> > >>> On Fri, Nov 28, 2014 at 1:29 AM, Zhang Xianyi > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> I want to use cmake for a library which supports different floating > point > >>>> precision. > >>>> > >>>> In Makefile, I used $(*F) to generate the different function name. > >>>> > >>>> Could I use $(*F) in cmake? > >>>> > >>>> > >>>> ================== > >>>> > >>>> test.c > >>>> > >>>> =============== > >>>> > >>>> #ifdef DOUBLE > >>>> > >>>> #define TYPE double > >>>> > >>>> #else > >>>> > >>>> #define TYPE float > >>>> > >>>> #endif > >>>> > >>>> > >>>> void CNAME(TYPE * a) > >>>> > >>>> { > >>>> > >>>> a[0]=1.0; > >>>> > >>>> } > >>>> > >>>> > >>> > >>> CMakeLists.txt > >>> ==================== > >>> cmake_minimum_required(VERSION 2.8) > >>> > >>> add_custom_command( OUTPUT ${CMAKE_BINARY_DIR}/test_double.c > >>> DEPENDS test.c > >>> COMMAND ${CMAKE_COMMAND} -E > copy_if_different > >>> test.c ${CMAKE_BINARY_DIR}/test_double.c > >>> COMMAND ${CMAKE_COMMAND} -E touch > >>> ${CMAKE_BINARY_DIR}/test_double.c > >>> ) > >>> > >>> > >>> add_library( libtest test.c ${CMAKE_BINARY_DIR}/test_double.c ) > >>> > >>> SET_PROPERTY(SOURCE ${CMAKE_BINARY_DIR}/test_double.c > >>> APPEND > >>> PROPERTY COMPILE_DEFINITIONS "DOUBLE" ) > >>> > >>> ====================== > >>> > >>>> =========== > >>>> > >>>> Makefile > >>>> > >>>> ================ > >>>> > >>>> OBJS=test_single.o test_double.o > >>>> > >>>> all:$(OBJS) > >>>> > >>>> ar -rua libtest.a $(OBJS) > >>>> > >>>> test_single.o : test.c > >>>> > >>>> $(CC) -DCNAME=$(*F) -UDOUBLE -c $< -o $(@F) > >>>> > >>>> test_double.o : test.c > >>>> > >>>> $(CC) -DCNAME=$(*F) -DDOUBLE -c $< -o $(@F) > >>>> > >>>> > >>>> ============ > >>>> > >>>> Thank you > >>>> > >>>> Xianyi > >>>> > >>>> > >>>> -- > >>>> > >>>> 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 pa at letnes.com Sat Nov 29 09:44:00 2014 From: pa at letnes.com (Paul Anton Letnes) Date: Sat, 29 Nov 2014 14:44:00 GMT Subject: [CMake] Organization of larger projects Message-ID: <1417272240702.21068.5130@webmail5> Hello, list! A bit of background: I am currently working inside a large perforce repository, containing source code for several programs. Some functionality has been separated out into separate directories, e.g., some linear algebra operations, file I/O, etc. Currently, all programs (save for one, which I've CMakeified) build by Makefiles, which basically list all source files, residing in all sorts of directories scattered around the repository. An abbreviated example file structure could be -- root |-- category-1 | |-- somelib | | `-- foo.f | `-- someprogram | |-- main.f | `-- Makefile `-- category-2 |-- otherlib | `-- bar.f `-- otherprogram |-- main.f `-- Makefile Every Makefile can, conceivably, shop any number of files from any "library" directory, using the "add_executable (target file1 file2 ...)" type of logic. I've managed to CMakeify one of these programs, basically, by listing all the source files and having CMake link them together. I would, however, prefer to create modules/libraries in some sense. My initial idea is that "otherlib" and "somelib" could be built into static libraries "on the fly", but by a CMakeLists.txt in each directory. The "add_subdirectory" command comes to mind, but it does not work for directories that are not actual subdirectories in the filesystem. I've been playing with the idea of using Externalproject_add commands or custom find_package, but these seem to be geared towards globally installed libraries, which I do not want (yet, at least). The reasons for the project organization is of cource "history" and "legacy" much more than anything else, and with several applications and "libraries" mixed together, it's a challenge to refactor both build systems and code into a more sensible architecture. What do you recommend in this case? I would highly prefer not creating static libraries outside the build system, since in this case, the combinatorics make for a lot of pre-built libraries - one per 32/64 bit, operating system, and across 3-4 compilers... ----------- Paul Anton Letnes -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Sun Nov 30 13:36:48 2014 From: d3ck0r at gmail.com (J Decker) Date: Sun, 30 Nov 2014 10:36:48 -0800 Subject: [CMake] Organization of larger projects In-Reply-To: <1417272240702.21068.5130@webmail5> References: <1417272240702.21068.5130@webmail5> Message-ID: add_subdirectory works for any subdirectroy... just if it's above your start point, you need to specify an additional name to mount the subdir as in the cmake_binary_dir... add_subdirectory( ../libs/widgets widgets ) the problem can be that you end up including the same subdirectory twice as two different target paths; then you'll get warnings about dupilicate definition and have to test like if( NOT TARGET ) .... endif() On Sat, Nov 29, 2014 at 6:44 AM, Paul Anton Letnes wrote: > Hello, list! > > A bit of background: I am currently working inside a large perforce > repository, containing source code for several programs. Some functionality > has been separated out into separate directories, e.g., some linear algebra > operations, file I/O, etc. Currently, all programs (save for one, which > I've CMakeified) build by Makefiles, which basically list all source files, > residing in all sorts of directories scattered around the repository. An > abbreviated example file structure could be > -- root > |-- category-1 > | |-- somelib > | | `-- foo.f > | `-- someprogram > | |-- main.f > | `-- Makefile > `-- category-2 > |-- otherlib > | `-- bar.f > `-- otherprogram > |-- main.f > `-- Makefile > > Every Makefile can, conceivably, shop any number of files from any > "library" directory, using the "add_executable (target file1 file2 ...)" > type of logic. > > I've managed to CMakeify one of these programs, basically, by listing all > the source files and having CMake link them together. I would, however, > prefer to create modules/libraries in some sense. My initial idea is that > "otherlib" and "somelib" could be built into static libraries "on the fly", > but by a CMakeLists.txt in each directory. The "add_subdirectory" command > comes to mind, but it does not work for directories that are not actual > subdirectories in the filesystem. I've been playing with the idea of using > Externalproject_add commands or custom find_package, but these seem to be > geared towards globally installed libraries, which I do not want (yet, at > least). The reasons for the project organization is of cource "history" and > "legacy" much more than anything else, and with several applications and > "libraries" mixed together, it's a challenge to refactor both build systems > and code into a more sensible architecture. > > What do you recommend in this case? > > I would highly prefer not creating static libraries outside the build > system, since in this case, the combinatorics make for a lot of pre-built > libraries - one per 32/64 bit, operating system, and across 3-4 compilers... > > ----------- > Paul Anton Letnes > > -- > > 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: