Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-09-14 21:54-0700 Alan W. Irwin wrote: On 2011-09-01 05:45-0700 Alan W. Irwin wrote: On 2011-08-28 14:34-0400 Bill Hoffman wrote: Can you try and build CMake 2.8.4, then 2.8.3 and see what happens? [...]I thought wine-1.3.27 might have been to culprit, but it turns out I was just now able to generate the same cmake-2.8.5 build error with MinGW/MSYS/wine-1.3.26. On that same platform, and with the binary version of cmake-2.8.5 (which worked very well for me with ephcom2) I will now attempt builds of cmake-2.8.4 and earlier to see whether the cmake-2.8.5 build error I am getting is a cmake-source code regression for this fixed platform. There is exactly the same build error when attempting to build cmake-2.8.4 and 2.8.3 using binary cmake-2.8.5 and when attempting to build 2.8.3 with binary cmake-2.8.3. I have built cmake-2.8.3 successfully before with binary cmake-2.8.3 on a MinGW/MSYS/wine platform so this appears to be some incompatibility of cmake builds with either (i) recent versions of wine or (ii) recent versions of MinGW/MSYS. To eliminate the latter possibility, could somebody please try to build cmake with the MSYS Makefiles generator on Windows? It literally is only a 5 minute download to install the required MinGW/MSYS these days (see below). That automatic installer (available at http://sourceforge.net/projects/mingw/files/Automated MinGW Installer/mingw-get-inst/) literally takes about 5 minutes to download and install all of MinGW/MSYS on wine, and I am sure that it would even be faster on Windows. Is there anybody game to try the build of cmake on Windows using the latest MinGW/MSYS stack you install with the automatic installer? 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012459]: wish: CheckFortranSourceCompiles.cmake/CheckFortranCompilerFlags.cmake
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12459 == Reported By:Daniel Franke Assigned To: == Project:CMake Issue ID: 12459 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2011-09-15 04:36 EDT Last Modified: 2011-09-15 04:36 EDT == Summary:wish: CheckFortranSourceCompiles.cmake/CheckFortranCompilerFlags.cmake Description: It would be nice to have CheckFortranSourceCompiles.cmake CheckFortranCompilerFlags.cmake similar to CheckC[XX]SourceCompiles.cmake and CheckC[XX]CompilerFLags.cmake. == Issue History Date ModifiedUsername FieldChange == 2011-09-15 04:36 Daniel Franke New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 9/15/2011 4:12 AM, Alan W. Irwin wrote: To eliminate the latter possibility, could somebody please try to build cmake with the MSYS Makefiles generator on Windows? We have a dashboard for this. I build that all the time on my own machine too. Just in case, I updated the toolchain: mingw-get install gcc mingw-get install g++ mingw-get install gfortran mingw-get install binutils CMake 2.8.5 builds the latest CMake master with no errors. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 9/15/2011 4:12 AM, Alan W. Irwin wrote: That automatic installer (available at http://sourceforge.net/projects/mingw/files/Automated MinGW Installer/mingw-get-inst/) literally takes about 5 minutes to download and install all of MinGW/MSYS on wine, and I am sure that it would even be faster on Windows. Is there anybody game to try the build of cmake on Windows using the latest MinGW/MSYS stack you install with the automatic installer? I just built with the most recent MinGW makefile build, and it works. Also, we have dashboards that do mingw and msys. See these builds: amber12.kitware Win32-mingw-gcc-4.5 amber12.kitware Win32-msys-gcc-4.5 Sounds to me it is the windows.h that comes with wine maybe. Really you should just debug this and find the issue. Run make help in Utilities/cmlibarchive/libarchive. You will see file.i. targets you want this one: archive_read.i That will create a cpp processed version of the file. Then you need to grep around the files that are included and find the problem. -Bill ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-09-15 09:22-0400 Brad King wrote: On 9/15/2011 4:12 AM, Alan W. Irwin wrote: To eliminate the latter possibility, could somebody please try to build cmake with the MSYS Makefiles generator on Windows? We have a dashboard for this. I build that all the time on my own machine too. Just in case, I updated the toolchain: mingw-get install gcc mingw-get install g++ mingw-get install gfortran mingw-get install binutils CMake 2.8.5 builds the latest CMake master with no errors. That sounds definitive, but I don't really trust MinGW/MSYS installers (since that is alpha software) to do the right thing with updates. It wasn't that long ago that that functionality was completely broken. Instead, what I did was a complete install with mingw-get-inst-20110802, and I hope you will try that as well to completely eliminate this possibility. 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 9/15/2011 12:34 PM, Alan W. Irwin wrote: That sounds definitive, but I don't really trust MinGW/MSYS installers (since that is alpha software) to do the right thing with updates. It wasn't that long ago that that functionality was completely broken. Instead, what I did was a complete install with mingw-get-inst-20110802, and I hope you will try that as well to completely eliminate this possibility. Seriously, it would be quicker to just debug this on the system you are on. Find out where the bad #define is and then we will know. -Bill ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012460]: Cant edit FILEPATH variables in cmake-gui on OSX
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=12460 == Reported By:David Partyka Assigned To: == Project:CMake Issue ID: 12460 Category: QtDialog Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2011-09-15 13:13 EDT Last Modified: 2011-09-15 13:13 EDT == Summary:Cant edit FILEPATH variables in cmake-gui on OSX Description: Note: Using the new x64 Universal 2.8.6-rc3 binary. When I begin to type in the value of a FILEPATH variable it kicks me out of edit mode. Steps to Reproduce: Select the value of a FILEPATH variable (example: QT_QMAKE_EXECUTABLE) with the mouse. Try to clear the field with backspace or type anything for that matter. Additional Information: This is using the new x64 OSX Universal binary. == Issue History Date ModifiedUsername FieldChange == 2011-09-15 13:13 David Partyka New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-09-15 09:27-0400 Bill Hoffman wrote: On 9/15/2011 4:12 AM, Alan W. Irwin wrote: That automatic installer (available at http://sourceforge.net/projects/mingw/files/Automated MinGW Installer/mingw-get-inst/) literally takes about 5 minutes to download and install all of MinGW/MSYS on wine, and I am sure that it would even be faster on Windows. Is there anybody game to try the build of cmake on Windows using the latest MinGW/MSYS stack you install with the automatic installer? I just built with the most recent MinGW makefile build, and it works. MinGW Makefiles is quite different than the MSYS Makefiles builds I am doing. Also, note my comments to Brad about what constitutes the latest MinGW/MSYS. I am pretty sure from Brad's MSYS Makefiles result that all is well with MSYS Makefiles builds of CMake on Microsoft Windows, but being absolutely sure is even better than pretty sure which is why I asked him to try replicating exactly the same MinGW/MSYS install steps that I did. Also, we have dashboards that do mingw and msys. See these builds: amber12.kitware Win32-mingw-gcc-4.5 amber12.kitware Win32-msys-gcc-4.5 For the msys one you appear to be referring to http://www.cdash.org/CDash/iphone/buildsummary.php?buildid=1039633. There is no identification there of the exact MinGW/MSYS being used for that build. Furthermore, the cmake time is 6 seconds and the build time is 0 seconds (same start and end time). So it appears to be an update of a previous build rather than a build from scratch. That makes sense from the perspective of saving a lot of computer time on the machine doing the build, but it is not the same as the build from scratch that I am doing here. Again, it is the difference between being pretty sure and absolutely sure there is no trouble with MSYS Makefiles builds of CMake on Microsoft windows. Sounds to me it is the windows.h that comes with wine maybe. Really you should just debug this and find the issue. Run make help in Utilities/cmlibarchive/libarchive. You will see file.i. targets you want this one: archive_read.i That will create a cpp processed version of the file. Then you need to grep around the files that are included and find the problem. I have avoided this step because I have been frankly intimidated by the size and complexity of the CMake code and my lack of (free) Windows platform knowledge. However, now you have encouraged me to try debugging it, I realize there is an even easier way to track down what is going on with the macros in question. That is, find the exact g++ command that failed from the VERBOSE=1 ouput, then repeat that by hand using the g++ -E -dD (or -dM) options. More later after I give that idea a try. 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 __ ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Some advice
On Mon, Sep 12, 2011 at 3:35 PM, James Bigler jamesbig...@gmail.com wrote:
I need some advice on how to fix a problem I'm having with files with the
same name.
I have two CUDA files with the same name in different directories:
CUDA_ADD_EXECUTABLE(test-conflict
path with spaces/conflict.cpp
path with spaces/conflict.cu
path with spaces/no-conflict.cpp
path with spaces/no-conflict.cu
conflict-main.cpp
conflict.cpp
conflict.cu
)
I notice that the cpp files get the following outputs:
path with spaces/no-conflict.cpp: test-conflict.dir\Debug
path with spaces/conflict.cpp:
test-conflict.dir\Debug\/path_with_spaces/conflict.cpp.obj
conflict.cpp: test-conflict.dir\Debug\/conflict.cpp.obj
This seems to work well and everyone is happy.
The FindCUDA code is a different story, and one I wish to get some more
input on. The current implementation takes the basename and merges it in
with the target name like so (one example given):
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}/${cuda_target}_generated_${basename}${generated_extension}
The problem is two files with the same basename can cause collisions in the
naming scheme. I'm wondering if the best solution is to keep a per target
list of basenames as a directory property and when collisions happen, create
a new sub-directory to be used by the build script. My question at this
point is what and how to compute the non-conflicting directories. Does
anyone have any good suggestions for how to implement this?
Thanks,
James
How about telling me where I can find how CMake does this for the C code? I
notice that it only puts sub directories when there's a conflict, so there's
logic somewhere that determines this and then determines what the
intermediate directories should be.
Thanks,
James
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform
On 2011-08-27 16:22-0700 Alan W. Irwin wrote: If you compare the types of archive_read_data and archive_read_data_into_buffer in archive_read.c versus archive.h, the *.c versions are ssize_t archive_read_data(struct archive *_a, void *buff, size_t s) int archive_read_data_into_buffer(struct archive *a, void *d, ssize_t len) while the *.h versions are __LA_DECL __LA_SSIZE_T archive_read_data(struct archive *, void *, size_t); __LA_DECL int archive_read_data_into_buffer(struct archive *, void *buffer, __LA_SSIZE_T len); So it appears on the MinGW/MSYS/wine platform at least that something is screwed up with the __LA_DECL and/or __LA_SSIZE_T macros. Hi Bill: As promised, I am now following up with -E -dD information (for the case of binary cmake-2.8.3 building cmake-2.8.3, but I assume the results would be identical for 2.8.4 and 2.8.5 since I got the same build errors for them). This combination of options really does the job, and I wish I had thought of them sooner. From the above __LA_DECL must have an empty #define, and __LA_SSIZE_T must be #defined to ssize_t to avoid the build error. Also, the above declarations of the functions occur on lines 308 and 407 of /home/software/cmake/cmake-2.8.3/Utilities/cmlibarchive/libarchive/archive.h -dD output says the following concerning __LA_DECL prior to lines 308 and 409 (it was changed later on, but that is not relevant) # 98 z:/home/software/cmake/cmake-2.8.3/Utilities/cmlibarchive/libarchive/archive.h #define __LA_DECL So that shows the desired empty result which avoids any build error from this cause. However, I was surprised the whole thicket of preprocessing directives just above line 98 in that file (which #define __LA_DECL to different values) was somehow avoided. -dD output say the following concerning __LA_SSIZE_T The second #define after # 54 z:/home/software/cmake/cmake-2.8.3/Utilities/cmlibarchive/libarchive/archive.h is #define __LA_SSIZE_T long which is inconsistent with the ssize_t function type for archive_read_data in archive.c which causes the build error. The relevant preprocessing code after line 54 is #define __LA_INT64_T__int64 # if defined(_SSIZE_T_DEFINED) # define __LA_SSIZE_T ssize_t # elif defined(_WIN64) # define __LA_SSIZE_T__int64 # else # define __LA_SSIZE_Tlong # endif The -dD results show that _SSIZE_T_DEFINED is not #defined, allthough they do show the following: #define _SSIZE_T_ typedef int _ssize_t; typedef _ssize_t ssize_t; Furthermore, they show that _WIN64 is not #defined (which makes sense since my platform is 32-bit wine on a 64-bit hardware platform (amd64)). But the point is both the __int64 and long result would cause a broken build because ssize_t is typedef'ed to int on (32-bit) wine. So in sum, it looks like the CMake code avoids a broken build on wine (and other platforms with ssize_t typedef'ed to int) only if _SSIZE_T_DEFINED is always #defined. I then tried export CFLAGS='-O3 -D_SSIZE_T_DEFINED' for a build from scratch of cmake-2.8.5 using cmake binary 2.8.5, and it worked with no errors or warnings! It is good to know that workaround is available for the cmake build on wine (presumably regardless of the x in cmake-2.8.x). I doubt very much though that I will have to be concerned with that workaround for builds of other software that is not as complicated as the CMake build. Of course, Wine _might_ be at fault here for not #defining _SSIZE_T_DEFINED when ssize_t is typedefed. But is that a standard that you expect to be followed on all platforms or a Microsoft Windows idiosyncrasy that more robust CMake code would not have to worry about? What I mean by that comment is the following. The current situation is the function and argument types in cmake-2.8.x/Utilities/cmlibarchive/libarchive/*.c files do not use the same macro-based approach as that used in cmake-2.8.x/Utilities/cmlibarchive/libarchive/archive.h for defining the types and arguments of functions. That seems like an accident waiting to happen (and, in fact, that accident has already happened on wine.) Perhaps there is some reason for this fundamental inconsistency in the definitions of the function types and arguments in the libarchive code, but I don't understand what that reason might be. I know virtually nothing about Windows platforms. So if you think it should be an expected standard, could you advise me where _SSIZE_T_DEFINED is #defined for Microsoft Windows so I could advise Wine to do the same in their equivalent header? I could find nothing official from Microsoft about _SSIZE_T_DEFINED in a google search. Instead, there appeared to be mostly google hits for projects #defining _SSIZE_T_DEFINED themselves. If you advise me to go ahead with the wine bug report, I assume they would eventually act on it as a low priority since they claim to want to follow every Microsoft Windows idiosyncrasy that makes a practical difference. Of course, that
[CMake] Using cmake to build a static library
Hi, I came across cmake few weeks ago as a very interesting way to build projects for multiple platforms. It allows us at work to use a common code base for multiple platforms without actual duplication which is really neat. Though we're facing an issue related to the fact cmake isn't the only tool involved in our build process. We have split our code between the core logic which is compiled in C++ for multiple platforms (windows x86 and x86_64, Mac OSX and in the future linux) then based on that core logic we would like to produce SDKs for each platform using their specific features (for easier integration in projects). The problem is the following: The core logic is meant to be a static library (.lib on windows, .a on Mac / Linux) and then another project should pick up that library and include it into an executable. That final project is (a) not linked with the original cmake project (b) potentially not even built by cmake. For those reasons we'd like that the generated static library include its own dependencies in order to avoid dragging a long list of dependencies, unfortunately that does not seem to be be case in the current state of things. If I set the type of my output to SHARED (through the ADD_LIBRARY command), I see all dependencies appear in the Visual Studio project and the produced DLL seems correct. Though if the type is set to STATIC (the one we want), the dependencies are simply not passed to the Visual Studio project (AdditionalDependencies AdditionalLibraryDirectories are not set for VCLibrarianTool). Hence my overall question: How can I have cmake produce a static library in which dependencies are linked ? Thanks in advance for your help. Denis PS: I know DLLs work on windows but those are not an option, because of deployment constraints we need to produce a single executable file in the end. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using cmake to build a static library
have you looked at target_link_libraries command?? not sure but worth giving it a try. http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:target_link_libraries best regards Cristobal On Thu, Sep 15, 2011 at 3:49 AM, Denis Carniel denis.carn...@loginpeople.com wrote: Hi, I came across cmake few weeks ago as a very interesting way to build projects for multiple platforms. It allows us at work to use a common code base for multiple platforms without actual duplication which is really neat. Though we're facing an issue related to the fact cmake isn't the only tool involved in our build process. We have split our code between the core logic which is compiled in C++ for multiple platforms (windows x86 and x86_64, Mac OSX and in the future linux) then based on that core logic we would like to produce SDKs for each platform using their specific features (for easier integration in projects). The problem is the following: The core logic is meant to be a static library (.lib on windows, .a on Mac / Linux) and then another project should pick up that library and include it into an executable. That final project is (a) not linked with the original cmake project (b) potentially not even built by cmake. For those reasons we'd like that the generated static library include its own dependencies in order to avoid dragging a long list of dependencies, unfortunately that does not seem to be be case in the current state of things. If I set the type of my output to SHARED (through the ADD_LIBRARY command), I see all dependencies appear in the Visual Studio project and the produced DLL seems correct. Though if the type is set to STATIC (the one we want), the dependencies are simply not passed to the Visual Studio project (AdditionalDependencies AdditionalLibraryDirectories are not set for VCLibrarianTool). Hence my overall question: How can I have cmake produce a static library in which dependencies are linked ? Thanks in advance for your help. Denis PS: I know DLLs work on windows but those are not an option, because of deployment constraints we need to produce a single executable file in the end. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using cmake to build a static library
On 09/15/2011 08:49 AM, Denis Carniel wrote: Hi, I came across cmake few weeks ago as a very interesting way to build projects for multiple platforms. It allows us at work to use a common code base for multiple platforms without actual duplication which is really neat. Though we're facing an issue related to the fact cmake isn't the only tool involved in our build process. We have split our code between the core logic which is compiled in C++ for multiple platforms (windows x86 and x86_64, Mac OSX and in the future linux) then based on that core logic we would like to produce SDKs for each platform using their specific features (for easier integration in projects). The problem is the following: The core logic is meant to be a static library (.lib on windows, .a on Mac / Linux) and then another project should pick up that library and include it into an executable. That final project is (a) not linked with the original cmake project (b) potentially not even built by cmake. For those reasons we'd like that the generated static library include its own dependencies in order to avoid dragging a long list of dependencies, unfortunately that does not seem to be be case in the current state of things. If I set the type of my output to SHARED (through the ADD_LIBRARY command), I see all dependencies appear in the Visual Studio project and the produced DLL seems correct. Though if the type is set to STATIC (the one we want), the dependencies are simply not passed to the Visual Studio project (AdditionalDependencies AdditionalLibraryDirectories are not set for VCLibrarianTool). Hence my overall question: How can I have cmake produce a static library in which dependencies are linked ? Thanks in advance for your help. Denis PS: I know DLLs work on windows but those are not an option, because of deployment constraints we need to produce a single executable file in the end. Well, static libraries just don't give you that. They are essentially glorified archive files (think zip-file) containing the object files. When you do a TARGET_LINK_LIBRARIES(myStaticLib someOtherLib), CMake remembers that dependency internally and will add someOtherLib to all the link-lines where myStaticLib is used, but it can't possibly embed that information into the static library. If your downstream projects are CMake, you can tell CMake to export the myStaticLib target along with its dependencies to a special file which then can be imported by the downstream project. If it isn't, on Linux Mac and other Unix-ish platforms (MinGW, Cygwin, etc.) you would write a pkg-config file which contains that information. With pure MSVC I don't think that this is possible, so IMHO you'll have to add the dependencies manually. Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] force to install doxygen each time
hello, i was reading this tutorial about integrating doxygen documentation into the cmake build process. http://invalidmagic.wordpress.com/2009/11/30/cmake-and-doxygen-github-com/ is found it really cool because the doxyconf file feeds from some cmake variables i set, letting me handle version information on a single file. my problem is that when i made some modifications to the source comments, the updated documentation didnt install because it said up-to-date i would like cmake to force the instalation of the generated doxy-files (even make sure that cmake is waiting for doxygen to finnish before installing) is there a way to accomplish this? thanks and best regards Cristobal ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On 9/14/2011 5:37 AM, Clifford Yapp wrote: Looks like that's working. Running ninja again, I'm seeing another issue: BRL-CAD uses dependency assignment to make sure our build time delta calculator is the last target to be built (and hence actually times the build). With ninja, it doesn't seem to be respecting this, but instead tries to run the delta target immediately. Do custom targets respect dependency information? I would think the best think to do would be to focus on the CMake tests. If these are not all passing, then there is a good chance any large project will fail at some point. If all the tests are passing, I would think most anything could be built. -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Why do jom/nmake generators require cl to build with mingw?
I was trying to configure a project to use jom or name with the mingw compilers. I was configuring with cmake \ -DCMAKE_INSTALL_PREFIX:PATH=C:/winsame/volatile-mingw/txphysics-r1504-ser \ -DCMAKE_BUILD_TYPE:STRING=RELEASE \ -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE \ -DCMAKE_INSTALL_ALWAYS:BOOL=TRUE \ -DCMAKE_COLOR_MAKEFILE:BOOL=FALSE \ -G 'NMake Makefiles' \ -DCMAKE_C_COMPILER:FILEPATH='mingw32-gcc' \ -DCMAKE_CXX_COMPILER:FILEPATH='mingw32-g++' \ -DCMAKE_Fortran_COMPILER:FILEPATH='mingw32-gfortran' \ C:/cygwin/home/user/vorpalall-mg/txphysics but got the warning, CMake Warning at CMakeLists.txt:10 (project): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. and ultimately the error, CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeRCInformation.cmake:22 (GET_FILENAME_COMPONENT): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/Platform/Windows-GNU.cmake:60 (enable_language) C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/Platform/Windows-GNU-C.cmake:1 (include) C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeCInformation.cmake:56 (INCLUDE) CMakeLists.txt:2 (PROJECT) So I did put cl in my path, and now it configures, but this seems strange. Is it necessary to still have cl when using mingw? ThxJohn Cary ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Proper way to build static binaries
Hi, I'm surprised to see that there is no optional [STATIC] argument in add_executable cmake command. I think it should be very important to have this because a lot of people like having static binaries. Thus for the moment what is the best way and more portable way to set a binary to be build as static ? Cheers, -- David Demelier ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
Hi,
On Wed, Sep 14, 2011 at 12:00:05PM -0400, cmake-requ...@cmake.org wrote:
Date: Wed, 14 Sep 2011 05:37:20 -0400
From: Clifford Yapp cliffy...@gmail.com
Looks like that's working. Running ninja again, I'm seeing another issue:
BRL-CAD uses dependency assignment to make sure our build time delta
calculator is the last target to be built (and hence actually times the
build). With ninja, it doesn't seem to be respecting this, but instead
tries to run the delta target immediately. Do custom targets respect
dependency information?
I'm seeing the same thing here, and I think I semi-nailed it.
I've got:
function(scm_sos_pull_db_tree _pull_target _scm_dir)
if(NOT TARGET scm_sos_pull_db_tree)
# this crap does not work the way it should...
#set(scm_spec ${scm_repo_prefix}/${_scm_dir})
set(scm_spec ${scm_repo_prefix})
#set(stamp_file_tree
${sos_wrapper_stamps_dir}/scm_sos_pull_db_tree_${_pull_target}.stamp)
set(stamp_file_tree ${sos_wrapper_stamps_dir}/scm_sos_pull_db_tree.stamp)
set(db_tree_output ${sos_wrapper_db_file_pathname})
add_custom_command(OUTPUT ${db_tree_output}
COMMAND ${sos_wrapper_cmdline_constant_part} -project ${scm_spec}
-command GetProjectTree
COMMAND ${CMAKE_COMMAND} -E touch ${stamp_file_tree}
# Cannot specify the full ${scm_sos_dependencies} list here
# (we're creating the very database file that it lists).
# And we should avoid adding ${sos_wrapper_script} as a dependency
# here, since a simple update of that script most certainly doesn't
# justify doing the _AWFULLY_ lengthy operation of pulling
# the entire database anew. All other SCM targets _should_ properly
depend on
# SosWrap.bash, however, since they're much cheaper...
DEPENDS ${MASTER_SCM_HAS_BEEN_UPDATED}
COMMENT fetching SOS SCM database tree for ${scm_spec}
VERBATIM
)
add_custom_target(scm_sos_pull_db_tree VERBATIM DEPENDS ${db_tree_output})
add_dependencies(scm_sos_pull_db_tree scm_sos_setup)
endif(NOT TARGET scm_sos_pull_db_tree)
# add a dependency to make sure that before pulling a file/project we fetch
its project tree
add_dependencies(${_pull_target} scm_sos_pull_db_tree)
endfunction(scm_sos_pull_db_tree _pull_target _scm_dir)
So you can see that I'm clearly adding a dependency of target
scm_sos_pull_db_tree on the
target scm_sos_setup (which is the one to make sure that the SosWrap.bash script
is properly prepared before continuing).
However, what I'm ending up with is:
# Phony custom command for CMakeFiles/scm_sos_pull_db_tree
build CMakeFiles/scm_sos_pull_db_tree: phony
_SCM/sos/database/servers/SERVER/DATABASE.sos
# Utility command for scm_sos_pull_db_tree
build scm_sos_pull_db_tree: phony CMakeFiles/scm_sos_pull_db_tree
_SCM/sos/database/servers/SERVER/DATABASE.sos scm_sos_setup
# Phony custom command for CMakeFiles/scm_sos_setup
build CMakeFiles/scm_sos_setup: phony _SCM/sos/stamps/sos_setup.stamp
# Custom command for _SCM/sos/stamps/sos_setup.stamp
build _SCM/sos/stamps/sos_setup.stamp: CUSTOM_COMMAND
COMMAND = cd [[CMAKE_BINARY_DIR]] /usr/local/bin/cmake -E make_directory
[[CMAKE_BINARY_DIR]]/_SCM/sos/stamps /usr/local/bin/cmake -E touch
[[CMAKE_BINARY_DIR]]/_SCM/sos/stamps/sos_setup.stamp
DESC = Generating _SCM/sos/stamps/sos_setup.stamp
# Utility command for scm_sos_setup
build scm_sos_setup: phony CMakeFiles/scm_sos_setup
_SCM/sos/stamps/sos_setup.stamp
copy_prep_file__[[CMAKE_BINARY_DIR]]_SosWrap.bash
IOW, from what I'm gathering here, it seems as if scm_sos_pull_db_tree
lists its _internal_
target/rule/whatever CMakeFiles/scm_sos_pull_db_tree with same-hierarchy
priority as scm_sos_setup.
And that internal target/rule/whatever then gets executed in advance, despite
scm_sos_setup not having been executed (prepared) yet.
And this is most likely because add_custom_command() in Ninja generator
actually gets realised as an inner target of its corresponding CMake
add_custom_target(),
and we then have a logical disconnect since it's the _outer_, CMake-_public_
target
which gets configured a constraint (scm_sos_setup needs to run first).
IOW, it's a MISTAKE to implement (emulate) add_custom_command() via inner
targets in Ninja build config,
since those inner targets don't inherit those dependency constraints
(ordering)
which have been explicitly imposed on their outer targets.
So:
- either keep custom commands implemented via inner targets - and then make sure
that those inner (internal!) targets do have _all_ dependencies of the outer,
CMake-public target specified
- or don't implement custom commands via internal, logically disconnected
targets [better?]
Or am I missing something?
(I believe my CMake construct is correct - but who knows...)
OK, I should perhaps add a file dependency (DEPENDS) within
add_custom_command() on the
SosWrap.bash script (but that was done _very_ deliberately - see comment in
that function() above,
and
Re: [CMake] Why do jom/nmake generators require cl to build with mingw?
On Thu, Sep 15, 2011 at 8:08 AM, John R. Cary c...@txcorp.com wrote: I was trying to configure a project to use jom or name with the mingw compilers. I was configuring with cmake \ -DCMAKE_INSTALL_PREFIX:PATH=C:/winsame/volatile-mingw/txphysics-r1504-ser \ -DCMAKE_BUILD_TYPE:STRING=RELEASE \ -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE \ -DCMAKE_INSTALL_ALWAYS:BOOL=TRUE \ -DCMAKE_COLOR_MAKEFILE:BOOL=FALSE \ -G 'NMake Makefiles' \ -DCMAKE_C_COMPILER:FILEPATH='mingw32-gcc' \ -DCMAKE_CXX_COMPILER:FILEPATH='mingw32-g++' \ -DCMAKE_Fortran_COMPILER:FILEPATH='mingw32-gfortran' \ C:/cygwin/home/user/vorpalall-mg/txphysics but got the warning, CMake Warning at CMakeLists.txt:10 (project): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. and ultimately the error, CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeRCInformation.cmake:22 (GET_FILENAME_COMPONENT): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/Platform/Windows-GNU.cmake:60 (enable_language) C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/Platform/Windows-GNU-C.cmake:1 (include) C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeCInformation.cmake:56 (INCLUDE) CMakeLists.txt:2 (PROJECT) So I did put cl in my path, and now it configures, but this seems strange. Is it necessary to still have cl when using mingw? I thought jom and nmake Generators were both for Visual Studio. John ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why do jom/nmake generators require cl to build with mingw?
On 9/15/11 8:27 AM, John Drescher wrote: On Thu, Sep 15, 2011 at 8:08 AM, John R. Caryc...@txcorp.com wrote: I was trying to configure a project to use jom or name with the mingw compilers. I was configuring with cmake \ -DCMAKE_INSTALL_PREFIX:PATH=C:/winsame/volatile-mingw/txphysics-r1504-ser \ -DCMAKE_BUILD_TYPE:STRING=RELEASE \ -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE \ -DCMAKE_INSTALL_ALWAYS:BOOL=TRUE \ -DCMAKE_COLOR_MAKEFILE:BOOL=FALSE \ -G 'NMake Makefiles' \ -DCMAKE_C_COMPILER:FILEPATH='mingw32-gcc' \ -DCMAKE_CXX_COMPILER:FILEPATH='mingw32-g++' \ -DCMAKE_Fortran_COMPILER:FILEPATH='mingw32-gfortran' \ C:/cygwin/home/user/vorpalall-mg/txphysics but got the warning, CMake Warning at CMakeLists.txt:10 (project): To use the NMake generator, cmake must be run from a shell that can use the compiler cl from the command line. This environment does not contain INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to work. and ultimately the error, CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeRCInformation.cmake:22 (GET_FILENAME_COMPONENT): get_filename_component called with incorrect number of arguments Call Stack (most recent call first): C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/Platform/Windows-GNU.cmake:60 (enable_language) C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/Platform/Windows-GNU-C.cmake:1 (include) C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeCInformation.cmake:56 (INCLUDE) CMakeLists.txt:2 (PROJECT) So I did put cl in my path, and now it configures, but this seems strange. Is it necessary to still have cl when using mingw? I thought jom and nmake Generators were both for Visual Studio. I seem to be able to use them in a cygwin shell, but only if I have cl and all the defines in my path, even if I never use cl in the compilation (because I def'd the compilers to be mingw...) Also, jom, cl, mingw, nmake all have the same (Windows) path concepts, instead of the cygwin paths. So I think they should work together, and I observe that they do. So not sure how to answer your question John ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] ExternalProject_Add without download of local sources?
Hello, i am wondering if it is possible to have an external project building from local sources, *without* attemtping to download (in that case, copy) to a specific location. My sources of the externals are already in my repository, i do not want to have them compiled. I looked around for some while now, but didn't find anything rearding this topic. Maybe i just missed it. Setting URL and SOURCE_DIR to the same directory deletes the files... The 3rdpart project in question is just a normal CMakke project, nothing fancy. Regards, Thomas ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ExternalProject_Add without download of local sources?
small correction: i DO indeed want to have them compiled, but by taking the sources from the original location, not copying them to another directory and then have them compiled.. Regards, Thomas ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why do jom/nmake generators require cl to build with mingw?
On 9/15/2011 10:35 AM, John R. Cary wrote: I seem to be able to use them in a cygwin shell, but only if I have cl and all the defines in my path, even if I never use cl in the compilation (because I def'd the compilers to be mingw...) Also, jom, cl, mingw, nmake all have the same (Windows) path concepts, instead of the cygwin paths. So I think they should work together, and I observe that they do. So not sure how to answer your question This is a new use case. I had never thought of using jom or nmake for anything other than cl. As gmake is usually better. Once the -j stuff fix for mingw gets into gmake, then there would be no reason to use jom I would think. There seem to be two problems: 1. The warning about INCLUDE, LIB, etc. This was done because so many people try to use cl without setting up the environment for it. This should be reworked to only warn if cl is being used. 2. There is an error with the rc compiler. This is what is failing: enable_language(RC) This seems to only look for windres when the MinGW or Msys generators are used. If you want to create two bugs for this that would be good. Not sure when we will get to fixing it... But, if you wanted to try I could help you. Bugs would be: - only warn about missing INCLUDE,LIB env when using the MS compiler. - Look for windres when using gcc with nmake and jom if using gcc. -Bill ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules
On Thu, Sep 15, 2011 at 03:28:42PM +0200, Andreas Mohr wrote: Hi, On Wed, Sep 14, 2011 at 12:00:05PM -0400, cmake-requ...@cmake.org wrote: Date: Wed, 14 Sep 2011 05:37:20 -0400 From: Clifford Yapp cliffy...@gmail.com Looks like that's working. Running ninja again, I'm seeing another issue: BRL-CAD uses dependency assignment to make sure our build time delta calculator is the last target to be built (and hence actually times the build). With ninja, it doesn't seem to be respecting this, but instead tries to run the delta target immediately. Do custom targets respect dependency information? Yes, but the dependencies are currently only attached to the target, not to any of its custom commands. This behaviour is correct for CMake's built-in targets, such as 'install' and 'test', for which the commands are attached directly to the target, but add_custom_target is actually implemented internally using custom commands (the command given to add_custom_target is stored as a custom command attached to a dummy source file), so the target dependencies are not currently attached in the correct place for add_custom_target. IOW, from what I'm gathering here, it seems as if scm_sos_pull_db_tree lists its _internal_ target/rule/whatever CMakeFiles/scm_sos_pull_db_tree with same-hierarchy priority as scm_sos_setup. And that internal target/rule/whatever then gets executed in advance, despite scm_sos_setup not having been executed (prepared) yet. This is a symptom of the behaviour described above. IOW, it's a MISTAKE to implement (emulate) add_custom_command() via inner targets in Ninja build config, since those inner targets don't inherit those dependency constraints (ordering) which have been explicitly imposed on their outer targets. So: - either keep custom commands implemented via inner targets - and then make sure that those inner (internal!) targets do have _all_ dependencies of the outer, CMake-public target specified - or don't implement custom commands via internal, logically disconnected targets [better?] The former is the correct solution. The Ninja generator already does this for object files to ensure that target dependencies are built before any object file in the target (one of the build systems I tested with uses a target dependency to generate a header file used by some of the target's source files). I now realise this also needs to happen for custom commands. Thanks, -- Peter ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ExternalProject_Add without download of local sources?
Did you tried specifying SOURCE_DIR without any URL and / or DOWNLOAD_COMMAND UPDATE_COMMAND Not sure this is correct but for my case seems to work HTH Luigi On 15/09/2011 17.13, Thomas Wolf wrote: Hello, i am wondering if it is possible to have an external project building from local sources, *without* attemtping to download (in that case, copy) to a specific location. My sources of the externals are already in my repository, i do not want to have them compiled. I looked around for some while now, but didn't find anything rearding this topic. Maybe i just missed it. Setting URL and SOURCE_DIR to the same directory deletes the files... The 3rdpart project in question is just a normal CMakke project, nothing fancy. Regards, Thomas ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Luigi Calori SuperComputing Applications and Innovation Department CINECA - via Magnanelli, 6/3, 40033 Casalecchio di Reno (Bologna) - ITALY Tel: +39 051 6171509 Fax: +39 051 6132198 hpc.cineca.it ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OpenCL Module?
Am 29.08.2011 15:44, schrieb Michael Jackson: Does anyone have an FindOpenCL.cmake file that they would like to share? ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio https://bitbucket.org/sergiu/opencl-cmake/src/tip/FindOpenCL.cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ExternalProject_Add without download of local sources?
On 15.09.2011 17:48, Luigi Calori wrote:
Did you tried specifying SOURCE_DIR without any URL and / or
DOWNLOAD_COMMAND
UPDATE_COMMAND
Not sure this is correct but for my case seems to work
HTH
mhm,
i swapped URL for the SOURCE_DIR, yes, and there is also no
DOWNLOAD_COMMAND or UPDATE_COMMAND. My build always reports 'succeeded'
without doing anything.
well, i just have:
---
ExternalProject_Add(${proj}
SOURCE_DIR ${Log4Qt_SOURCE_DIR}
BINARY_DIR ${proj}_bin
INSTALL_DIR ${proj}_install
INSTALL_COMMAND
CMAKE_GENERATOR ${gen}
CMAKE_ARGS
${common_args}
-DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE}
CMAKE_CACHE_ARGS
-DCMAKE_INCLUDE_CURRENT_DIR:BOOL=ON
DEPENDS ${proj_DEPENDENCIES}
)
---
with common_args beeing:
-
-DBUILD_TESTING:BOOL=${ep_build_testing}
-DCMAKE_INSTALL_PREFIX:PATH=${ep_install_dir}
-DBUILD_SHARED_LIBS:BOOL=ON
-DCMAKE_BUILD_TYPE:STRING=${CMAKE_BUILD_TYPE}
-DCMAKE_C_COMPILER:FILEPATH=${CMAKE_C_COMPILER}
-DCMAKE_CXX_COMPILER:FILEPATH=${CMAKE_CXX_COMPILER}
-DCMAKE_C_FLAGS:STRING=${ep_common_C_FLAGS}
-DCMAKE_CXX_FLAGS:STRING=${ep_common_CXX_FLAGS}
#debug flags
-DCMAKE_CXX_FLAGS_DEBUG:STRING=${CMAKE_CXX_FLAGS_DEBUG}
-DCMAKE_C_FLAGS_DEBUG:STRING=${CMAKE_C_FLAGS_DEBUG}
#release flags
-DCMAKE_CXX_FLAGS_RELEASE:STRING=${CMAKE_CXX_FLAGS_RELEASE}
-DCMAKE_C_FLAGS_RELEASE:STRING=${CMAKE_C_FLAGS_RELEASE}
#relwithdebinfo
-DCMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=${CMAKE_CXX_FLAGS_RELWITHDEBINFO}
-DCMAKE_C_FLAGS_RELWITHDEBINFO:STRING=${CMAKE_C_FLAGS_RELWITHDEBINFO}
)
Regards,
Thomas
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ExternalProject_Add without download of local sources?
Luigi is correct:
To use an existing source directory (just use the source in its place
without any copy operations), simply say:
DOWNLOAD_COMMAND
SOURCE_DIR ${Log4Qt_SOURCE_DIR}
The default behavior of copying the source tree when it is specified
via URL is present for two reasons:
(1) some packages require an in-source build, and copying the source
tree is a good way to keep a clean copy of the source tree around
(2) it's the same as all the other URL operations: in the http case,
it's downloaded and then extracted (copied) into the SOURCE_DIR
location, in a local directory case, we also chose to make the copy
simply for ease of implementation
HTH,
David
On Thu, Sep 15, 2011 at 12:17 PM, Thomas Wolf
thomas.w...@vision.ee.ethz.ch wrote:
On 15.09.2011 17:48, Luigi Calori wrote:
Did you tried specifying SOURCE_DIR without any URL and / or
DOWNLOAD_COMMAND
UPDATE_COMMAND
Not sure this is correct but for my case seems to work
HTH
mhm,
i swapped URL for the SOURCE_DIR, yes, and there is also no
DOWNLOAD_COMMAND or UPDATE_COMMAND. My build always reports 'succeeded'
without doing anything.
well, i just have:
---
ExternalProject_Add(${proj}
SOURCE_DIR ${Log4Qt_SOURCE_DIR}
BINARY_DIR ${proj}_bin
INSTALL_DIR ${proj}_install
INSTALL_COMMAND
CMAKE_GENERATOR ${gen}
CMAKE_ARGS
${common_args}
-DQT_QMAKE_EXECUTABLE:FILEPATH=${QT_QMAKE_EXECUTABLE}
CMAKE_CACHE_ARGS
-DCMAKE_INCLUDE_CURRENT_DIR:BOOL=ON
DEPENDS ${proj_DEPENDENCIES}
)
---
with common_args beeing:
-
-DBUILD_TESTING:BOOL=${ep_build_testing}
-DCMAKE_INSTALL_PREFIX:PATH=${ep_install_dir}
-DBUILD_SHARED_LIBS:BOOL=ON
-DCMAKE_BUILD_TYPE:STRING=${CMAKE_BUILD_TYPE}
-DCMAKE_C_COMPILER:FILEPATH=${CMAKE_C_COMPILER}
-DCMAKE_CXX_COMPILER:FILEPATH=${CMAKE_CXX_COMPILER}
-DCMAKE_C_FLAGS:STRING=${ep_common_C_FLAGS}
-DCMAKE_CXX_FLAGS:STRING=${ep_common_CXX_FLAGS}
#debug flags
-DCMAKE_CXX_FLAGS_DEBUG:STRING=${CMAKE_CXX_FLAGS_DEBUG}
-DCMAKE_C_FLAGS_DEBUG:STRING=${CMAKE_C_FLAGS_DEBUG}
#release flags
-DCMAKE_CXX_FLAGS_RELEASE:STRING=${CMAKE_CXX_FLAGS_RELEASE}
-DCMAKE_C_FLAGS_RELEASE:STRING=${CMAKE_C_FLAGS_RELEASE}
#relwithdebinfo
-DCMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=${CMAKE_CXX_FLAGS_RELWITHDEBINFO}
-DCMAKE_C_FLAGS_RELWITHDEBINFO:STRING=${CMAKE_C_FLAGS_RELWITHDEBINFO}
)
Regards,
Thomas
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Correct way to link with libstdc++ from non-C++ project?
Suppose project Foo depends on a library Bar that uses C++ internally, but was not properly linked, so foo would need to be linked with 1. $CC -shared -o libfoo.so *.o -lbar -lstdc++ or 2. $CXX -shared -o libfoo.so *.o -lbar Note that find_library (LIBSTDCXX NAMES stdc++) does not work because this library is often not in a public directory, so a full path cannot be resolved. My understanding is that current recommended practice is to use option 2 above, but this breaks down if Foo also needs to link some Fortran libraries because you can't link using both the C++ compiler and the Fortran compiler. If the Fortran and C++ compilers come from the same suite, passing a literal -lstdc++ will generally work, but this is not robust if they come from different suites. Is there a way to mark a library as depending on a language or some other internal compiler library, so that CMake will sort out how to do the multi-language link in the same way it does if the project has source files in each language? ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Using cmake to build a static library
Michael's correct. If CMake generates the build instructions for the final executable, then all is well, because CMake knows all the dependencies from the target_link_libraries commands, and it can produce the linker line containing all the right lib references. If all you are doing is building static libraries and then feeding them to some other build system, you also have to feed it all the libraries you depend on too, because that information is simply NOT encoded into static libraries. The best way, as always, to depend on 3rd party stuff, is simply to avoid those dependencies whenever possible. 2nd best is to incorporate their source directly into your library. After that, you just have to list them explicitly by hand somewhere... HTH, David On Thu, Sep 15, 2011 at 3:12 AM, Michael Wild them...@gmail.com wrote: On 09/15/2011 08:49 AM, Denis Carniel wrote: Hi, I came across cmake few weeks ago as a very interesting way to build projects for multiple platforms. It allows us at work to use a common code base for multiple platforms without actual duplication which is really neat. Though we're facing an issue related to the fact cmake isn't the only tool involved in our build process. We have split our code between the core logic which is compiled in C++ for multiple platforms (windows x86 and x86_64, Mac OSX and in the future linux) then based on that core logic we would like to produce SDKs for each platform using their specific features (for easier integration in projects). The problem is the following: The core logic is meant to be a static library (.lib on windows, .a on Mac / Linux) and then another project should pick up that library and include it into an executable. That final project is (a) not linked with the original cmake project (b) potentially not even built by cmake. For those reasons we'd like that the generated static library include its own dependencies in order to avoid dragging a long list of dependencies, unfortunately that does not seem to be be case in the current state of things. If I set the type of my output to SHARED (through the ADD_LIBRARY command), I see all dependencies appear in the Visual Studio project and the produced DLL seems correct. Though if the type is set to STATIC (the one we want), the dependencies are simply not passed to the Visual Studio project (AdditionalDependencies AdditionalLibraryDirectories are not set for VCLibrarianTool). Hence my overall question: How can I have cmake produce a static library in which dependencies are linked ? Thanks in advance for your help. Denis PS: I know DLLs work on windows but those are not an option, because of deployment constraints we need to produce a single executable file in the end. Well, static libraries just don't give you that. They are essentially glorified archive files (think zip-file) containing the object files. When you do a TARGET_LINK_LIBRARIES(myStaticLib someOtherLib), CMake remembers that dependency internally and will add someOtherLib to all the link-lines where myStaticLib is used, but it can't possibly embed that information into the static library. If your downstream projects are CMake, you can tell CMake to export the myStaticLib target along with its dependencies to a special file which then can be imported by the downstream project. If it isn't, on Linux Mac and other Unix-ish platforms (MinGW, Cygwin, etc.) you would write a pkg-config file which contains that information. With pure MSVC I don't think that this is possible, so IMHO you'll have to add the dependencies manually. Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Correct way to link with libstdc++ from non-C++ project?
On 09/15/2011 06:39 PM, Jed Brown wrote: Suppose project Foo depends on a library Bar that uses C++ internally, but was not properly linked, so foo would need to be linked with 1. $CC -shared -o libfoo.so *.o -lbar -lstdc++ or 2. $CXX -shared -o libfoo.so *.o -lbar Note that find_library (LIBSTDCXX NAMES stdc++) does not work because this library is often not in a public directory, so a full path cannot be resolved. My understanding is that current recommended practice is to use option 2 above, but this breaks down if Foo also needs to link some Fortran libraries because you can't link using both the C++ compiler and the Fortran compiler. If the Fortran and C++ compilers come from the same suite, passing a literal -lstdc++ will generally work, but this is not robust if they come from different suites. Is there a way to mark a library as depending on a language or some other internal compiler library, so that CMake will sort out how to do the multi-language link in the same way it does if the project has source files in each language? Just set the LINKER_LANGUAGE target property to CXX. HTH Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] force to install doxygen each time
update: i had a bug somewhere, and was installing and old documentation. fixed that, and cmake is smart enough to install the files after a minor change is detected. On Thu, Sep 15, 2011 at 4:13 AM, Cristobal Navarro axisch...@gmail.comwrote: hello, i was reading this tutorial about integrating doxygen documentation into the cmake build process. http://invalidmagic.wordpress.com/2009/11/30/cmake-and-doxygen-github-com/ is found it really cool because the doxyconf file feeds from some cmake variables i set, letting me handle version information on a single file. my problem is that when i made some modifications to the source comments, the updated documentation didnt install because it said up-to-date i would like cmake to force the instalation of the generated doxy-files (even make sure that cmake is waiting for doxygen to finnish before installing) is there a way to accomplish this? thanks and best regards Cristobal ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Correct way to link with libstdc++ from non-C++ project?
On Thu, Sep 15, 2011 at 18:57, Michael Wild them...@gmail.com wrote: Just set the LINKER_LANGUAGE target property to CXX. This seems to be exclusive (single-valued). How can I specify that, for example, a target containing only C sources needs to be linked as though it also had both C++ and Fortran sources (because of leaky dependent libraries)? (I will assume that I have found functional compilers for all three languages.) ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Getting the source file list for an executable fails
Hi, I would expect this would work from reading the docs but it gives
add_executable(mytarget ${SRC})
get_property(TESTPROP_A TARGET mytarget PROPERTY SOURCE)
get_target_property(TESTPROP_B mytarget SOURCE)
message(FATAL_ERROR Testing ${TESTPROP_A}, ${TESTPROP_B})
The output I get is:
Testing '', 'TESTPROP_B-NOTFOUND'
This is odd since properties TYPE and LOCATION are found
Obviously in this case ${SRC} is already available, but I'm just
trying to figure out why it fails.
tested on cmake 2.8.5
--
- Campbell
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Getting the source file list for an executable fails
On 09/16/2011 02:59 AM, Campbell Barton wrote:
Hi, I would expect this would work from reading the docs but it gives
add_executable(mytarget ${SRC})
get_property(TESTPROP_A TARGET mytarget PROPERTY SOURCE)
get_target_property(TESTPROP_B mytarget SOURCE)
message(FATAL_ERROR Testing ${TESTPROP_A}, ${TESTPROP_B})
The output I get is:
Testing '', 'TESTPROP_B-NOTFOUND'
This is odd since properties TYPE and LOCATION are found
Obviously in this case ${SRC} is already available, but I'm just
trying to figure out why it fails.
tested on cmake 2.8.5
The property you probably refer to is named SOURCES, not SOURCE. The
different results returned by GET_PROPERTY() and GET_TARGET_PROPERTY()
are documented: The former returns an empty value if the property isn't
set, and the latter returns the NOTFOUND value, both evaluating to FALSE.
Regards,
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Getting the source file list for an executable fails
On Fri, Sep 16, 2011 at 11:11 AM, Michael Hertling mhertl...@online.de wrote:
On 09/16/2011 02:59 AM, Campbell Barton wrote:
Hi, I would expect this would work from reading the docs but it gives
add_executable(mytarget ${SRC})
get_property(TESTPROP_A TARGET mytarget PROPERTY SOURCE)
get_target_property(TESTPROP_B mytarget SOURCE)
message(FATAL_ERROR Testing ${TESTPROP_A}, ${TESTPROP_B})
The output I get is:
Testing '', 'TESTPROP_B-NOTFOUND'
This is odd since properties TYPE and LOCATION are found
Obviously in this case ${SRC} is already available, but I'm just
trying to figure out why it fails.
tested on cmake 2.8.5
The property you probably refer to is named SOURCES, not SOURCE. The
different results returned by GET_PROPERTY() and GET_TARGET_PROPERTY()
are documented: The former returns an empty value if the property isn't
set, and the latter returns the NOTFOUND value, both evaluating to FALSE.
Regards,
Michael
Ack!, sorry for the dumb mistake, but now I'm faced with a different problem.
Getting the sources for a library defined in another directory, and it
gives me relative paths.
How do you get the path a library is defined in so I can make the
absolute paths? - tried LOCATION but this gives the output location.
PREFIX, SUFFIX are not set.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Correct way to link with libstdc++ from non-C++ project?
On Thu 15 Sep 2011 11:04:58 PM CEST, Jed Brown wrote: On Thu, Sep 15, 2011 at 18:57, Michael Wild them...@gmail.com mailto:them...@gmail.com wrote: Just set the LINKER_LANGUAGE target property to CXX. This seems to be exclusive (single-valued). How can I specify that, for example, a target containing only C sources needs to be linked as though it also had both C++ and Fortran sources (because of leaky dependent libraries)? (I will assume that I have found functional compilers for all three languages.) In that case AFAIK the variables CMAKE_LANG_IMPLICIT_LINK_LIBRARIES (where LANG is C, CXX and Fortran) could help. Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, master, updated. v2.8.5-463-g7fca32a
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 7fca32a0bb4fa53ea95fd7f515798c21b59f1542 (commit) from ec0f23515f92fbdb0f887f6e44c897080e9defd0 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7fca32a0bb4fa53ea95fd7f515798c21b59f1542 commit 7fca32a0bb4fa53ea95fd7f515798c21b59f1542 Author: KWSys Robot kwro...@kitware.com AuthorDate: Fri Sep 16 00:01:11 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Fri Sep 16 00:14:06 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index dd90c05..2aac25b 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 09) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 15) +SET(KWSYS_DATE_STAMP_DAY 16) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
